"Juergen P. Meier" wrote:
>
> fw-1 does not store seq numbers, therefor it can easily be fooled
> to believe that malicious packets are part of the connection (see below)
Humm, so if this is so "easy" why is it not a wide spread problem?
Theory and practice and all of that. I've banged a few holes through
FW-1 myself, this has not been one of them. ;)
> Lets take the following scenario: a DoS attack against your SMTP servers
> in your DMZ: FIN/RST connection interruption by the attacker.
Sounds like a good example.
> (if the SMTP host checks sequence numbers on FIN or RST packets,
> the dumb packetfilter is as good as the sophisticated SPF ;)
Hummm, are you aware of an IP host that _ignores_ sequence numbers
during a connection? I ask because a good perimeter is layered, not
monolithic. If the host deals with this in a safe manner than where's
the value add of burdening the firewall that will see a constant hit to
resources and performance? Heck I could have the firewall verify the CRC
but why bother if it does not add value and the host will deal with it?
Just because you _can_ do something does not make it a good idea. ;)
> Lets also assume the attacker wants to disrupt mail traffic to a
> frequent other host (i.e. MX of gmx.net or hotmail.com or the like) so
> he already knows both pairs of IP addresses.
The attacker also needs to know the Window of time when the mail will be
transferred between the two hosts. The size of this window will vary
depending on the mail server. For example my mail server completes
connects (on average) in less than 2 seconds. Pretty small window to try
and hit. Other domains like hotmail.com typically have a heavy load so
the time window is longer. This would be slightly easier to hit.
However:
[cbrenton@mail cbrenton]$ nslookup
> set type=mx
> hotmail.com
Non-authoritative answer:
hotmail.com preference = 10, mail exchanger = mc5.law5.hotmail.com
hotmail.com preference = 10, mail exchanger = mail.hotmail.com
hotmail.com preference = 10, mail exchanger = mc2.law5.hotmail.com
hotmail.com preference = 10, mail exchanger = mc4.law5.hotmail.com
So which mail server do you hit to disrupt a specific connection? All
have equal preference. In this case you don't necessarily know which
host to target. Granted you are talking a small enough number of hosts
that you could hit each equally but you've increased the required amount
of traffic by a factor of 4x which makes hitting the required time
window even harder.
> On a dumb packetfilter the attacker only has to guess one port number
> do get a faked FIN or RST packets to the SMTP server (what the server
> does with it depends on the IP stack used).
Actually, to get it though all they have to do is set FIN or RST with a
valid destination IP. To have it be _effective_ as a DoS they need:
Source IP
Source Port
Destination IP (have it if a single MX, maybe not as above)
Destination Port (a gimmie, TCP/25)
Time window of delivery
The SMTP server to ignore sequence numbers
Also, what happens next depends on which packet is used. If RST the
attacker could continue the DoS because the servers will keep the same
port numbers open. If FIN the connection will be re-established using a
new source port and the attackers is back where they started.
Now, with that said, what's the relative risk of this attack taking
place?
The attacker needs:
All of the above info
Needs it in real time (compromised sniffing host?)
Needs to respond before the window closes (specifically crafted tool)
I think we can agree that your concept of an attacker "guessing" which
source port to use is a bit absurd. There are too many ports to choose
from in too small a window. They would have better odds playing a
lottery. While an attacker could try and flood the wire with packets
using incremental source port numbers, this will probably DoS the
circuit before it gets lucky and resets the SMTP connection (you would
have to do a constant flood in the hopes that the delivery window will
open while the attack is taking place). Any IDS, QoS or non static
firewall would clue into this traffic pattern.
IMHO SMURF or a SYN flood would be far easier. The attacker could simply
flood the connection and get the mail session to reset on a time out or
block the connection attempt. No need to worry about pesky port or
sequence numbers.
With this in mind their only shot in launching this specific attack
pattern is a sniffing host which can actually see which data it needs to
use as well as when to use it.
A quick check of Packet Storm & a number of other archives shows zero
tools to launch this exploit. This rules out all the script kiddies from
launching this attack.
So we are talking a knowledgeable attacker who can go O-Day and write
their own tool. This attacker would also need access to a sniffing host
in the middle of the connection. They can see the connection get
established and grab the port info they need so it can be fed into their
DoS tool. They now have a chance at stopping a single e-mail message.
Gee they're cool...
So is this possible? Sure it is. I would rate this risk as being
extremely low. One small point however. While they are sniffing the
wire, what's to stop them from reading the sequence numbers out of the
stream and feeding this info into their DoS tool as well? If they do
this even a SPF that watches this value will get fooled and pass the
traffic.
So we're back to the value add thing. If the only method of effectively
launching this exploit would allow me to grab sequence numbers just as
easily as port numbers, what do I gain by adding this info to the state
table? I'm not saying it has zero value, I just don't see proof that it
buys you enough to warrant a performance hit.
Cheers,
Chris
--
**************************************
[EMAIL PROTECTED]
* Mastering Cisco Routers
http://www.amazon.com/exec/obidos/ASIN/078212643X/
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
