iptables vs. DoS

iptables vs. DoS

Post by lynx » Tue, 08 May 2001 19:13:29



i'm trying to get my head around iptables firewalling, and i'd like to
write myself some protection against simple DoS attacks - ping floods,
smurf and teardrop, ping of death, that sort of thing. also, i'd like to
be a good netizen by trying to stop outgoing such attacks from any
possible compromised systems.

anybody have suggestions for how to write iptables rules against these?
are there any other DoS hacks out there i should be aware of?
on a related note, what about suspect combinations of TCP flags? i
already know to filter out xmas-tree packets, but what other sets of
flags represent impossible packets i should drop?

--
   PGP/GnuPG key (ID 1024D/BFE0D6D0) available from keyservers everywhere
    Key fingerprint = 3EBC 97FC 68AA 65F1 65E6  3D36 35F6 4213 BFE0 D6D0
       "Everything I am today, I owe to people whom it is now too late
                                   to punish."

 
 
 

iptables vs. DoS

Post by j.cooney » Tue, 08 May 2001 19:23:04


I'm just reading this file, kind of an intro to ipchains, don't know if it
is any good to you?  anyways:

     http://www.rootprompt.org/article.php3?article=922

cheers,
john.


Quote:> i'm trying to get my head around iptables firewalling, and i'd like to
> write myself some protection against simple DoS attacks - ping floods,
> smurf and teardrop, ping of death, that sort of thing. also, i'd like to
> be a good netizen by trying to stop outgoing such attacks from any
> possible compromised systems.

> anybody have suggestions for how to write iptables rules against these?
> are there any other DoS hacks out there i should be aware of?
> on a related note, what about suspect combinations of TCP flags? i
> already know to filter out xmas-tree packets, but what other sets of
> flags represent impossible packets i should drop?

> --
>    PGP/GnuPG key (ID 1024D/BFE0D6D0) available from keyservers everywhere
>     Key fingerprint = 3EBC 97FC 68AA 65F1 65E6  3D36 35F6 4213 BFE0 D6D0
>        "Everything I am today, I owe to people whom it is now too late
>                                    to punish."


 
 
 

iptables vs. DoS

Post by <elle.. » Wed, 09 May 2001 03:21:12



> i'm trying to get my head around iptables firewalling, and i'd like to
> write myself some protection against simple DoS attacks - ping floods,
> smurf and teardrop, ping of death, that sort of thing. also, i'd like to
> be a good netizen by trying to stop outgoing such attacks from any
> possible compromised systems.

The packet-filtering HOWTO actually has ping of death as an example in
section 7.3.6.4 Other Match Extensions. (
http://va.samba.org/netfilter/unreliable-guides/packet-filtering-HOWT...
) The same thing is reachable through the more typeable
http://netfilter.samba.org , which has the benefit of allowing you to
see the related documents and other formats.

For the terminally curious, the examples fromt that section are:

# syn-flood
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

# port scanning
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit \
        --limit 1/s -j ACCEPT

# ping of death
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s \
        -j ACCEPT

The usual caveats apply. The rules require maintaining state
information and hence add overhead. You should never blindly perform
commands listed in a news posting. Etc.

--

 
 
 

iptables vs. DoS

Post by lynx » Tue, 08 May 2001 23:53:13




> http://www.rootprompt.org/article.php3?article=922

thanks for the reference, but it doesn't really answer my question. for
one thing, it deals with ipchains where i'm trying to use iptables, and
it doesn't really tell me what signatures any of the more common DoS
attacks would have that i could filter out. thanks for trying to help
out, though.

--
   PGP/GnuPG key (ID 1024D/BFE0D6D0) available from keyservers everywhere
    Key fingerprint = 3EBC 97FC 68AA 65F1 65E6  3D36 35F6 4213 BFE0 D6D0
       "Everything I am today, I owe to people whom it is now too late
                                   to punish."

 
 
 

iptables vs. DoS

Post by lynx » Wed, 09 May 2001 00:06:01



[examples from the packet filtering HOWTO:]

Quote:> # syn-flood
> iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

hm, hadn't thought of that one. i am enabling syncookies, but security in
depth is a good idea, so i'll incorporate this into my schema.

Quote:> # port scanning
> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit \
>    --limit 1/s -j ACCEPT

could anybody explain the details of this - is the RST-flag-only that
this rule looks for a signature of (some kind of) TCP stealth portscan?
if so, why bother just ratelimiting it, why not just drop all such
packets - can there be such packets in a legitimate connection too? if
so, wouldn't this merely slow down a portscan?

Quote:> # ping of death
> iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit
> 1/s -j ACCEPT

um, no, that's not the ping of death; that's a ping flood. still a good
idea to filter out, and i'll have to do it - hadn't thought of that one
either - but the "ping of death" is an ICMP echo request with an oversize
payload, and i'm still unsure if iptables can easily filter that out at
all. looking through the man page i'm getting the feeling it can't be.
thanks for your suggestions, though, they have been helpful.

--
   PGP/GnuPG key (ID 1024D/BFE0D6D0) available from keyservers everywhere
    Key fingerprint = 3EBC 97FC 68AA 65F1 65E6  3D36 35F6 4213 BFE0 D6D0
       "Everything I am today, I owe to people whom it is now too late
                                   to punish."

 
 
 

iptables vs. DoS

Post by Ian Jone » Wed, 09 May 2001 09:59:01


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Quote:> > # port scanning
> > iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m
> > limit \ --limit 1/s -j ACCEPT

> could anybody explain the details of this - is the RST-flag-only
> that this rule looks for a signature of (some kind of) TCP stealth
> portscan? if so, why bother just ratelimiting it, why not just drop
> all such packets - can there be such packets in a legitimate
> connection too? if so, wouldn't this merely slow down a portscan?

The SYN,ACK,FIN,RST flags are examined and the RST is set but the
others that were examined are clear.
A RST can be found in the course of normal networking.
If I am not mistaken (I wouldn't mention it if I were sure), this
rule (limit module) does not really invoke the conntrack code so it
might be more eficient if you are not using connection tracking. If
you are using conntrack an unrelated RST would be DROPped anyway.

- -m limit is a very good thing indeed!

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: Making the world safe for geeks.

iQA/AwUBOvdE08AVSpfzXItKEQJfZQCfY9hwQro8GG4H2YRKZH+KxaGV8DgAoMPX
fUU2GiZQlN7xZxQPd53iQnbh
=caZE
-----END PGP SIGNATURE-----

 
 
 

iptables vs. DoS

Post by Michail Bachman » Fri, 11 May 2001 06:38:52




Quote:> i'm trying to get my head around iptables firewalling, and i'd like to
> write myself some protection against simple DoS attacks - ping floods,
> smurf and teardrop, ping of death, that sort of thing. also, i'd like to
> be a good netizen by trying to stop outgoing such attacks from any
> possible compromised systems.

Implement ingress and egress filtering (RFC 2827)

Quote:> anybody have suggestions for how to write iptables rules against these?
> are there any other DoS hacks out there i should be aware of? on a
> related note, what about suspect combinations of TCP flags? i already
> know to filter out xmas-tree packets, but what other sets of flags
> represent impossible packets i should drop?

Check out snort.org. Read the snort rulefiles ddos.rules and dos.rules,
there you can find the attack patterns of some dos and ddos tools you
could try to block.

HTH

CU Micha

--

Ceterum censeo ParvamMolliam esse delendam

 
 
 

1. DOS vs. Windows vs. Mac vs. Unix vs. NS

The C standard dictates that SEEK_SET, SEEK_CUR and SEEK_END (among others)  
must be #defined in stdio.h.  This is not a POSIX requirement.  The only  
POSIX constraints on stdio.h are that it must #define L_ctermid and  
STREAM_MAX and declare fdopen() and fileno() if _POSIX_SOURCE is #defined.  
It may optionally #define L_cuserid if _POSIX_SOURCE is #defined.

POSIX 1003.1 _does_ however, require that unistd.h #define SEEK_SET &c if  
_POSIX_SOURCE is #defined.  Thus, if you desire POSIX conformance, #include  
unistd.h.

Are you sure about the SunOS headers?  Here's a test I ran on my SPARC at  
work:

% fgrep SEEK_SET /usr/include/unistd.h
#ifndef SEEK_SET
#define SEEK_SET        0       /* Set file pointer to "offset" */
% uname -a
SunOS epimbe 4.1.1 1 sun4c

Perhaps they've moved unistd.h to /usr/5include since 4.1.1??

I do agree on this, and am rapidly tiring of system dependencies being  
handled by #ifdefs.

I've found the "POSIX Programmer's Guide" (Donald Lewine, O'Reilly, ISBN  
0-937175-73-0) to be priceless.  I strongly recommend this book to anyone  
using C, whether they be UNIX programmers or not (but particularly if they  
are).  It not only helps understand "what is defined where and by which  
standard", but also helps programmers to "Do the Right Thing" by clarifying  
what is POSIX conformant and what is historical baggage.

--
-----------------------------------------------------------------------------
Jim Vlcek                         UNIX for $166!
uunet!molly!vlcek                 Novell UnixWare from Information Foundation

2. Web based user creation

3. IPTables vs. DNS (or : iptables doesn't change sourceport when MASQ'ing)

4. Upgrade 2.4 to 7 & VM2.1.1 to 3.0.2

5. Linux vs OS2 vs NT vs Win95 vs Multics vs PDP11 vs BSD geeks

6. creating an empty file

7. pf vs ipf vs iptables

8. Getting WinXP or Win2000 client to authenticate against linux KDC

9. lokkit vs iptables vs me :-(

10. iptables confusion: INPUT -vs- FORWARD -vs- POSTROUTING

11. HELP CISC vs. RISC / UNIX vs. DOS

12. Linux/XFree speed vs OS/2 vs DOS/Windows

13. Linux vs Windows vs DOS future.