The article starts out fairly okay and then starts talking about how IPSs (intrusion prevention systems) can help with PCI compliance:
- The first point the author makes it that you should protect your infrastructure with “… Stateful Firewall Technology”. Stateful! That’s important! What about just one word about layer 7 firewalls? Content filtering? The author somehow misses that aspect completely.
- “Stopping malicious content [by protocol verfication]”. So how can an attack be stopped by doing “protocol verification”? If I do an application-level attack against an SAP system, that will totally comply with all the protocol specifications that you can find in all the RFCs out there!
- By the way, an IPS should also do: “… real-time threat assessment of millions of IP addresses”. I wonder how they do that. Givef the context an IPS really has. I prefer my SIM do that. I don’t really think an IPS is capable of that. Maybe the author would care to elaborate on that a bit more. That would be really interesting.
- The last thing that strikes me: “IPS solutions … are the heart of maintaining the highest level of protection for PCI-dependent organizations…” What about using effective access control or vulnerability management? Why is the lower level of PCI compliance based completely on vulnerability management if IPS technology really helps you to be PCI compliant? Strange.
It seems to me that all these articles in the ISSA journal are written for just one purpose: VENDOR PITCHES! But maybe that’s just me. Fully-Verified is our favourite KYC company since it generally takes care of most of our problems before we even know they’re problems, but I guesss “all in one” companies aren’t always as specialized as some of these.
Finally I am travelling again. This also means that I have some time to read through the stack of security magazines that are piling up on my desk. It was getting a bit scary to think about reading through all these magazines. But somehow I was looking forward to the ISSA magazine. I kind of new that there would be something to critizise… And here we go:
There is an article in the June 2006 issue about “Denial of Service Attacks: Should it Mean Denial of Service?” I guess it is due to the fact that I am not a native English speaker, but this title does not really make sense to me.
Anyways. Let’s see what we can learn about DoS attacks. The first thing that stroke me is that the author mentions that
“… how firewalls help prevent denial of service under DoS/DDoS attacks”. I guess it depends on how someone defines DoS (which the author does later in the article), but in general a resource consumption DoS (don’t ditch me for not using correct DoS categories, I quite frankly have not seen a good taxonomy that I could reference) cannot be stopped by a firewall. Never! Unless you deploy it on an ISP level, but that’s a whole different story. And even if you talk about other DoS attacks which attack specific services and kill them (by for example exploiting some vulnerability), how do you make sure that you block the attack and not legitimate customers? I guess I am moving way too fast, the author promises to give us an answer in the article. Unfortunately he really fails to do so. He mentions packet filters at some point, but does not at all tell us how he would really mitigate a DoS attack. Bummer.
Did I just say that I had no real taxonomy for DoS attacks ready? Well, the author fills that gap right away. But be warned. I don’t like the taxonomy at all. Actually, this gets me going off topic. But have you every read up on taxonomies and how they are defined? Do it. It’s really interesting. Please, don’t call your attempt to come up with some kind of a categorization a taxonomy. It’s plain wrong! A taxonomy is a beautiful mathematical construct that has certain well-defined properties! Honor that fact! Please! What we have here is definitely no taxonomy, but let’s leave it at that.
The first category the author mentions is by traffic type. “Legitimate traffic flood” – okay. I like that. But! The examples given don’t fall into this category at all: UDP floods – okay. Maybe. What’s the last time you have seen an application using UDP? I thought we were in the age of Web2.0? Then ICMP floods. Hmm… Since when are your applications running over ICMP? Interesting. Maybe Kaminski is tunneling something again *gins*. Certainly no legitimate traffic! Then SYN floods. Okay. If we stretch legitimate traffic, that might be okay. Why don’t you just mention someone with a huge pipe making legitimate Web requests on your Web application? That would do it!
The next Traffic Type the author mentions is “Malicious traffic flood”. Why is this defined as “These packets carry malicious content and may be self-propagating.” Interesting. The packets are self-propagating? Like source-routed? Just kidding.
Next category: I love the title: “Attack Intent”. How do you possibly know what the intent of an attack is? Maybe I am just playing around and hit you by accident. How does that traffic look different from a targeted attack? So you know what my intent was? I doubt it! Anyways; here comes the same entry again that we just had: “Bandwidth depletion” how is that different from traffic floods? And why would smurf-attacks, fraggles, UDP floods (note that we already had this example in another category) and ping floods. Somehow I don’t really need any of these “sophisticated” attacks to consume all your bandwidth.
Here goes another nice one: Category: “Exploitation Type”: Network-based. Hmm… “These attacks exploit the limitations of the network under attack and can be controlled by the use of firewalls…” Really? How come you can still accept legitimate traffic if your uplink is saturated? And then: “NAT techniques can be used to isolate and secure corporate internal networks”. How does that have anything to do with DoS attacks? Wow…
Makes me curious how the author is going to talk about the “DoS Attacks in Detail”. It’s going to be fun, I bet!
The first pretty interesting statemenet about the details is who launches DoS attacks: “… irresponsible, unethical people with destructive intentions.” Really? Have you heard of commercial interests? Irresponsible? Why? Unethical? Maybe. But let’s move on. “The goal of the attackers is to exploit vulnerabilities in victim systems …” What? Why would that be the goal? The goal would be to rob someone of the ability to conduct business. Or to use his resources.
We are slowly getting down in the protocol stack to talk about the really important details. The networking details of the attack. That’s going to be fun! First clue that the author really knows his networking: “The attacker typically employs TCP, UDP or ICMP protocols to launch the attack”. On the transport layer, what other protocols have you used lately? I don’t know many more…
“ICMP Unreachable Flood”: Maybe the author should read up on this again. Why would I flood someone with ICMP unreachable messages (by the way, did you know there were two types of unreachables? Host and Port?) And why would I spoof the source IP? Did you mean I send spoofed UDP packets to closed ports and the spoofed source address is the one of the victim? Try that!
Hang in there, the best is still to come!
“This instructs the routers to send the messages to all IP addresses”. Do you know how broadcast works? Yes? How many packets are sent if I want to send something to all 254 hosts of a C class? One! All machines are instructed to read the packtes! There are NOT 254 (and certainly not 255) packets!
But here comes the gem: Under Fraggle Attacks: “It is different from smurf attacks in that the packets are UDP ECHO packets instead of ICMP ECHO packets.” Do you find the mistake? UDP ECHO? Wow. Where did you acquire your TCP/IP skills? Especially the fact that the author mentions the chargen attack as a specific item. That’s the same my friend. It’s UDP packets, but they are going to the chargen/echo service…
“PUSH+ACK attacks”. What? This is getting better and better. Maybe I should read Stevenson’s books again. Gosh. Has anyone tried what the author suggests about hijacking sessions and stuff? I don’t think he has heard of TCP sequence numbers and issues like that. Uiuiui… The same problem with “TCP reset floods”!
And talking about “Ping of Death and ECHO/Chargen” attacks in 2006 is kind of interesting. Okay. I heard that Vista was vulnerable to the PoD attack; But a Chargen attack? Dude, in what century do you live?
Here comes the attack for 2006: “Packet Header Scrambling”. The author suggests to set all the QoS bits. Hmm… Interesting. Have you tried this?
I really advise the authors to do some more research before they write about a certian topic and even more so the magazines should not accept every article they get. Has anyone proof-read this before it was published?
I thought that was it, but the article continues with suggestions on countermeasures…
Maybe there are some interesting methods mentioned here. I love this countermeasure: “MIB Statistics”. How the heck is this a countermeasure? Oh sorry, it’s under the topic of ‘prevention of seconday victims’. Right!
Mitigation of DoS attacks via Load Balancing? Throttling? Dropping requests? Auch… Again, maybe on the ISP level.
“Other Measures”: Honeypots! Interesting. So HoneyPots as a countermeasure to DoS attacks. Why not. But how? Well, by doing traffic analysis (isn’t that too late already?) or by packet tracing (at least you know what IP attacked you) or by replaying traffic (to generate some more load on my systems?)
And if you should not know what an IDS is: “Intrusion Detection/Prevention systems are configured to baseline regular traffic and detect anomalies based off the normal traffic flow”. I really wish they did! Wouldn’t that be nice! And which IDS does that?
