I do agree with you. What's sad is that you see the inevitability of what will occur if this issue of simple helpful compromose is not addressed. Without a true understanding on the mgmt side, it may take numerous catastophic outages to wake them up and what's catastrophic to mgmt is loss of revenue of an epic proportion. It makes life miserable when the average empoyee has not a clue of the corporate path forward. There may be good reason why ideas that would help the organization go unnoticed or outright ignored. Many a time, you feel you have no say so at all...and always the feeling of fighting an uphill battle. Sometimes it makes you wonder if they all read from the same 'Acceptable Losses' reference book
What's funny is that we aree all getting paid to convince them of this critical need and we have to continue to do so, but in a polically correct way. Oh boy, now, we get into the politics and how they are played. I know individuals that are masters of the game and they are moving up in the world. I am still learning that hard work and determination are only part of the makings of a top notch employee in the overall corporate scheme of things.
There are various noc-Cisco products to help with viruses and worms. You have an entire slew of anti-virus products out there that would help with this, as well as programs like deep freeze that allow you to restore a system after a reboot.
NAC is something that I would really like to get into more as far as my real work environment is concerned. Another thing that helps with worms and viruses is blocking outgoing traffic as well as incomming. I was at a Tech Summit in the State of Utah and was very suprised how many people did not block unneccessary outgoing traffic. Doing such is a good way to stop the viruses from spreading. I think of blocking outgoing traffic as "staying away when sick" If a host is infected with a virus (sick) then why allow it to infect others while contagious? Keep it from talking out on certain ports, and it won't be able to infect others or at the very least, have a harder time doing so.
The egress filtering concept is a great thing to implement. I will say that I have seen that help in a lot of cases. If you log the drops and investigate, it can also give you an additional point of detection which is always good. Another problem today is that some traffic (both legitimate an malicious) uses port 80 or 443, or even can masquerade itself as real http traffic.
Some very legitimate companies do this to make it easier to get their applications working through a firewall. These can applications can place our networks or data at risk when in the wrong hands. For example, GoToMyPC, WebEX (now a Cisco Product), and GoToMeeting make outbound connections that are difficult to detect and allow remote users to control computers. These are a little difficult to see from the perspective of the network without some content filter. I'm not faulting the applications or their vendors, but calling attention to the challenge.
You also mentioned NAC. I would certainly like to hear from those who have or are in the midst of NAC deployments. Was it more or less difficult to implement than expected? Are you using in-band or out-of-band? How branch out-of-band? I would also like to hear from those that have even taken this a step further and have or are working toward a fully "self defending network"? What are some scenarios in which your network has been protected with this solutions?
I am very well aware of the challenge of traffic riding on port 80 or 443. Part of my security deployment is an inline content filter because of this very issue. Also, my content filter requires a special authentication process so if you are an unauthorized user, you can't even get windows updates from the Internet.
I too would like to hear from any one who has implemented any NAC deployment from any NAC vendor. It is something I would like to do myself and to hear others experience would be most beneficial for all here at CLN.
When we get talking about the threat of packet sniffers there are a few things we can do to protect our traffic in transit. For example, encryption is the perfect solution, but with it comes other challenges. Encryption can blind our IDS sensor from packet payload. So if everything were encrypted, our network based ids sensors, as well as deep packet inspection in network devices would be less useful. I'm not discouraging the use of encryption when necessary, but pointing out some of the things we need to think about as we add encryption into our networks.
Switches are a basic part of most networks today. They keep a lot of the traffic away from the general pc population and thus a first step toward protecting against packet sniffers. Switches learn mac addresses and place port/address associations in a table called the CAM (or content addressable memory) table. If we overflow this table by sending random mac addresses into a single port, we can cause the switch to operate like a hub. When this happens, a packet sniffer can pick up all of the traffic because it is flooded to all ports just like if it were connected to a hub.
How can this be prevented? First recall, that the CAM table is built from the source MAC address on frames that the switch receives on a given port. We can use "switchport port-security" to limit the number of mac addresses on a switchport. When this number is exceeded, we can ignore it (not put it in the CAM table) or shut the port down. This will keep some tools like Macof from overflowing the cam table and allowing sniffer and MiTM to work.
What about traffic that is sent out to destination mac addresses that are not yet known to a switch. Most pc's are a bit chatty when they boot up so, they will typically have their mac address registered immediately. In other words traffic toward a PC should be in the CAM table of at least the switch it is connected to. If a machine sends traffic to a destination mac address that is not known to a switch, it is flooded to all ports by default. There could be some information leakage in this way. To prevent against this, we can block flooding of unknown unicast and multicast flooding with the "switchport block unicast" and "switchport block multicast" interface commands.
There are other ways that we can reroute our traffic to our traffic sniffer. For example, we could use arp poisining to trick all pc's into thinking the MAC address of our PC was that of the default gateway. Arp is a very simple protocol that does not have a lot of controls. Combined with arp poisining, we could then install a IP stack that has routing capabilities. This would give our sniffer access to all non local traffic. How can we prevent this? We could use dhcp snooping in conjunction with dynamic arp inspection. The switches can see the dhcp requests and make a note of the mac address to ip address pairings. When the arp request/replies our not in sync with this they would be dropped. The exception to this would be that we would have to trust the ports connected to devices with static IP addresses (these may be devices that we have tighter control over though).
These methods would go a long way toward protecting us from local attacks that could reroute traffic to a pc or host with a sniffer installed.
Have you looked at the Botnet filter that you can now license in the ASA version 8.2. It basically downloads a list of IP addresses that are known botnets and logs any connection attempts to those addresses. It also builds a nice graphical representation of it in the ASDM Dashboard. I sort of disagree with Cisco calling it a filter though, since it really only logs connection attempts and does not prevent them.
It would be nice if there were a BGP feed for known "Spybot" addresses. If we could implement Black Hole routing of any IP addresses that were in that category like we do email, it would really help.
I think that Ironport can block those same addresses with Senderbase. I'm not sure if it works accross the board or with well known web ports though. I know you said previously that you used a content filter, but didn't specify if it was Ironport or some other product. Personally, that is one of the few Cisco products I don't have in the field anywhere.
That's good to know. When it comes to security, you cannot just think Cisco. Although Cisco has some great products. We have used Surfcontrol quite a bit in promiscuous mode. I have stressed over and over again certain limitations due to its design. However, it can give you a good idea where your users are going. It only blocks through TCP resets which is not as good as inline IMO. They have been bought by Websense. I am curious to other's thoughts on Ironport, Websense, and the ThreatX AIP as well as Total Traffic Control. What do you like? What do you not like?
The thing with content or Internet filtering is that filtering on port 80 alone is not enough anymore. After all, there are 65500+ ports that traffic can flow on. I have the following criteria that I look for in a filtering solution:
1) filtering on ports other than port 80
2) background or single sign on authentication
3) good reports
4) ability to combat SSL proxies and other measures to get around filtering.
There are more, but these are the major ones. We looked at WebSense a few years back, but their price was 3 times that of other competitors and we haven't look at them since. Total Traffic Control is a product from Lightspeed Systems and specializes in Internet filtering.
I agree with everything you are saying. We must keep an eye on traffic flowing on all ports. I think an inline inspection of all ports against all deep packet inspection engines is difficult. I think ultimately, a device needs to be inline and able to inspect the normal ports for a protocol inline and inspect the other traffic that you allow through without affecting performance. If a port becomes relevant to a particular protocol, it needs to be automatically placed inline. I guess there are a lot of different ways that vendors deal with (or choose not to deal with) this.
Another thing that is often mentioned as a threat is port scanning. We are limited in what we can do in regards to those reconnaissance efforts against our networks. Basically our networks are there to provide services. When someone does a port scan, they are trying to figure out what those services are. When these services are meant to be used by a group we cannot block service on the port. Therefore, there we will always be vulnerable to the threat of port scanning.
Now the question is is this really a threat? From a CCNA Security perspective is it technically considered a threat (I don't know, this is a real question)? My opinion is that port scanning is an opportunity for us to catch a would be attacker and block potential attacks. Port scans detectable and we can shun or block anything from the source for a period of time. Now it doesn't mean that the attacker will not change the address as he tries to exploit a vulnerability. In any case, it is my opinion that the port scan is not really that much of a threat. I does allow someone to discover what ports and services we have exposed to them. The thing is that we need to do what we can to minimize these ports and watch for traffic that shouldn't be there. In my opinion, the bigger threat is the motivation behind the scan and the code that will be used to exploit the services found.
This may just be my paranoid point of view, but anything can be considered a threat. It just depends on how something is used. For example, If I had a hammer, every one would assume that it is a tool intended to pound nails into boards to build something. But I could take that tool and use it to pound a persons skull, thus killing them. That is a threat!
Depending on how something is used depends on wether is it a threat or not. Look at a ping. Ping is a great tool used for troubleshooting, but can be used in a DoS attack as well.... so as far as port scans... they can be used as a threat and especially on the outside interface of a firewall, if they can be stopped, I feel they should be.
I am in agreement with blocking a host that is scanning you. Is that stopping the scan? Not really, but you are altering the attacker's results which is a good thing. I guess you're right to say that almost anything can be considered a threat. I just guess I prefer my threats to be more bark and less bite than less bark and more bite. Scans are typically noisy and detectable. It can clue us in to more destructive attacks that are soon to come. Thanks for the feedback.