>Yes. However, the proxy-based firewall solutions offer the ability to >require that traffic with destination port 80 is actually http traffic, >that traffic with destination port 143 is actually imap, traffic with >destination port 25 is actuall smtp, etc. Proxy-based firewalls are also a hell of a lot slower than stateful packet firewalls. They also can hide the details of the outside world, making IDSs unusable inside your network. Personally, I find that a good stateful firewall can filter out all the junk and handle authentication and monitoring. And then a well tuned IDS can focus in on the traffic and what it is trying to do. The two working together can form a rather significant barrier to hacker scum. It also creates a "separation of duties" the firewall does its job and the IDS does its job. You don't have one unit (hence a single point of failure) trying to do both. >> Furthermore, not all IDS's are passive - "ruin your weekend" - type of >> systems. Some IDSs can also kill intrusions at the host, on the >> network, or at the gateway. >I tend to think of the active response-oriented IDS systems as the sort >that will wreck your whole day on occasion. I don't yet feel that we are >to the point that automated responses to "hacks" are a good idea -- what >about emails discussing code red, or someone retrieving files over http >that reference bind exploits .. will your IDS system think that the >embedded payload is malicious or not? What happens when active attackers >start sending bogon packets with spoofed sources that cause your system >to send RSTs to legitimate connections? Again, this is all a matter of configuration, management, and use. Poorly implemented, an active response IDS can cause trouble regardless of who makes it. Properly implemented, it can really cut down on attacks. One other thing to consider the type of IDS. Most IDSs are merely pattern recognition engines. They see a pattern, they block based on a rule fed into the system. The IDS's I support and use are full-on protocol analyzers. They know the difference between an email with an attachment and HTTP traffic - and can make intelligent decisions about that traffic based on their rules. These IDSs know that an email with the letters "AAAAAA" repeated are not a threat, but an HTTP payload with code red attributes is. Also, spoofing is an issue that any system would have problems with. And generally you setup an IDS with policies to ensure internal addresses are treated differently than external addresses. Once again, this is an area where Snort is extremely difficult to use because there is no centralized policy creation and management system as well as a reporting mechanism. Something that virtually all the commercial products - even Sourcefire's commercial product - has. Another problem is that Snort is not a protocol analyzer. Its essentially a pattern recognition engine with a wide array of "pre-processors" that can perform some protocol decodes. Yes, its a very good one and there are a billion signatures for it. But therein lies another weakness. There is a heavy responsibility placed on the operator to make sure he selects the "correct" signatures. This can be a daunting task, even for skilled IDS people. I never have time to keep the sigs up to date on our Snort system. This is an area where commercial products have a pretty significant leg up because they can organize and categorize signatures and provide a simple way to keep their products up-to-date. > This is actually one of my bigger complaints with Snort. As capable as > it is, it has no integrated response capabilities other than to shoot > off alerts. You'd have to custom build a response mechanism for it, > which isn't easy. >http://hogwash.sourceforge.net/ <http://hogwash.sourceforge.net/> Hogwash is pretty good, but have you ever actually put one in place? Its no easy task. Its takes months to tune the system, and it is still worthless against day zero exploits. It also must operate in-line, which means performance degradation. Also the active response features in Snort are very limited in capability and require the user to go through every new signature and assign a response. That can take a very, very long time. The IDSs I use are passive, taps that can respond with RST packets - hence no performance degradation. The Guard unit I mentioned is an in-line solution. But on the right platform, it sings. Considering its the same engine that ISS uses for their Gigabit IDSs ----------------------------------- Andrew Plato, CISSP President / Principal Consultant Anitian Corporation (503) 644-5656 office (503) 201-0821 cell http://www.anitian.com <http://www.anitian.com> ------------------------------------
This archive was generated by hypermail 2b30 : Wed Aug 28 2002 - 17:27:38 PDT