Quote from igsi:
My point is, if you system is patched and you are running desktop firewall, you are fine and you do not need IDS.
I disagree with this. What happens between the time you patch your system and
another vulnerability is discovered? I used Code Red and Slapper worm as an example of widely known vulnerabilities that infected many, many systems quickly before administrators had a chance to patch their systems. Relying on "firewall + patches" is insufficient. You also need an IDS.
Even though Slapper is a Linux worm the concept is the same - how many machines with iptables or ipchains were affected by Slapper despite the high regard in opensource community for these firewalls? The point is it's not just the firewall alone- vulnerabilities within the
individual service are also at risk. Very few people expected Linux + iptables + openSSL to be at risk, but viola, it was.
Quote from igsi:
First, in your post, where you used isapi Buffer overflow example, which BTW you cut-and-pasted from http://grcsucks.com/the.idiocy.goes.on.and.on.htm, you implied that the home user may need IDS.
I did not cut & pasted from grcsucks.com intentionally, but from another post on a security forum. Don't know which was the source- all I was interested in was the content. (i.e. look at the facts, and decide which are relevant, refute them as necessary, and perform your analysis... just like trading!)
Quote from igsi:
I am sorry but I think you are not knowledgeable enough on this subject so that you could present an opinion that would be worthy enough to take into account while choosing a product to secure a desktop connected to the Internet.
Hmm... you should not make such assumptions. You don't even know what I did in my former life before I started trading full-time. If you dig deep in some of my previous posts you might have an idea. This is typical EliteTrader behavior where so many people have to put others down. Why speculate on what you think I may know or not known. Do you know my credentials? I have not called you any names. Why not just address the specific points and leave it at that?
For example, you still have not satisfactorily addressed the scenario of a firewall letting *all traffic* on a specified port through, thereby allowing hackers to attack specific vulnerabilities on a service listening on said port. Several HTTP, SSL, SSH apps have all had *major* vulnerabilities discovered in the last year alone. You have said that timely patching of your system is a solution. I say it is not. Relying on system administrators to "quickly patch" a system is 100% impractical. Ask on any real security forum, like comp.security.firewalls or alt.computer.security if relying on firewall + system administrator to patch vulnerabilities is sufficient security?
Now I will give some *specific examples* on the usefulness of BID vs. traditional firewall.
1. Does ZA or Tiny or any other personal firewall protect against application-proxy type attacks as described in
http://www.securityfocus.com/bid/3647? BID does, because BID is
[begin cut & paste] a protocol analysis based IDS which in addition to spotting anomalous protocols, it also has a signature base that can spot suspicious patterns in the traffic stream. Protocol analysis based IDS's are more accurate because they can see traffic inside encrypted, fragmented, or even mangled transmissions. So, an IDS can spot malware based on its signature. And it doesn't matter which application was used to send the information. Because an IDS is looking at raw network traffic (packets) the application sending those packets is irrelevant. Therefore, BID is not susceptible to application-proxy type attacks
[end cut & paste] as described in above URL.
2. Here are three major exploits that were stopped by BID without updating intrusion signatures. These three were:
2a. Code Red
Code Red attempts an ISAPI overflow, so even though Black Ice did not know to call the vulnerability a "Code Red attack" it labeled it as "ISAPI Extension Overflow" and stopped Code Red for two weeks before it was made public. There was a press release on the NetworkIce page around the time Code Red came out, as well as concurrent reporting on alt.computer.security and comp.security.firewalls regarding this very issue (this was during the height of the "BID vs. ZAP" discussions).
I personally had ICEcap with BID agents (an enterprise level client/server implementation of BID where intrusion attempts are shared to other machines so as soon as one node locks out an intruder all nodes will) and distinctly remember seeing a lot of ISAPI overflow attacks about a week before the first public release about Code Red. There are many users on the security forums I've previously mentioned who had BID version 2.1cn (very old!) running and caught Code Red prior to the public announcement.
2b. Nimda "hybrid" threats
The Nimda viruses, similar to Code Red, attempted ISAPI backtick overflow and IIS system32 exploits, both of which BID detected and stopped before it even knew what a Nimda attack looks like. Both Nimda and Code Red passed right through Level 4 firewalls, completely undetected. You had to have employed a Level 7 firewall to have detected Code Red or Nimda. Or... an IDS protocol analyzer such as BID.
2c. Code Blue
Code Blue didn't get as much press in US but it was deemed by many security experts as deadlier than Code Red. Fortunately it did spread as widely as Code Red. Now Code Blue attempted a:
GET /.. [Encoded characters] ../winnt/system32/cmd.exe?/c+dir
BID blocks both the encoded unicode directory traversal and the IIS system32 command because it inspects the actual packet itself. Again, the vast majority of all firewall products would have let Code Blue traffic through on port 80.
If and only if you had patched your system of the specific vulnerability would you have been protected. And this assumes that said vulernability was previously discovered and patch available prior to when the attack took place! An IDS gives you an extra layer of protection.
Perhaps you remember during this period when there were so many IIS exploits being discovered, that MSFT released URLscan? What is URLscan? It's a specific type of IDS. Deals specifically only with port 80 traffic & only examines the URL request string, but it is an IDS, and it works where firewalls let traffic through.
Also, if you are an internet security professional you should know that the biggest danger is the unknown. In internet security "
you don't know what you don't know". That's why a firewall alone is not enough. You don't know what vulnerabilities have
not been made public yet. But an IDS can help you be more secure (not totally, but
more) by detecting such common exploits as buffer overflow attempts, ISAPI attacks, unicode hacks, etc.
Expecting a system administrators to timely patch their servers is a completely
reactive approach fraught with dangers (such as lag between when exploit is discovered vs. vulnerability is announced -> patch is made available -> system administrator installs patch). Why not be
proactive and consider the benefits of an IDS?
