Very Computer

Hello!
I've been doing some research into network attacks and it's amazing how simple
it is to SYN flood a machine. I've started toying with a couple of ideas for an
antiflood programme taht would detect and counter a SYN flood attack on a
network. Before I waste my time and energy on it I was wondering if there is
any such software available (i'm not thinking of firewalls) out there (for
free:) ? I haven't found any but that doesn't mean anything..
Thanks for th input,
Nessim

ps. could you please cc posts to my email address, i'm stuck with slow ppp for
another week and it would make my life a lot easier, thanks!

--

        Check out the latest Linux kernal source which includes "syn cookies".

for example the Linux kernel uses SYN cookies, an encryption challenge. i also use
a patch from jesse off in my 2.0.36 kernels to count SYN's per second and then
firewall out for a predefined period of time. works well. read the CERT advisory on
SYN flooding and look at the various vendor responses. most were quick once
Phrack's note on SYN flooding, ie stupid trick of the season (got tired real
quick), was issued and script kiddie/dumbasses played with it. nearly everyone is
immune.

what's worse, though, is the inetd process tables attack (move to xinetd, for
example, and you can avoid it). that was covered recently, too.

some web searches on these and similar topics are easily done, and you'll see that
fixes for these problems are well established. old tricks, my friend, and still
annoying. DoS attacks, unless they blow into a trust relationship, are just plain
dumb.

SYN cookies are explained in http://pobox.com/~djb/syncookies/archive.

Quote:> i also use a patch from jesse off in my 2.0.36 kernels to count SYN's per
> second and then firewall out for a predefined period of time. works well.

So if an attacker is flooding you with SYNs, trying to force you to drop
legitimate connections, then you respond by cutting off all connections?

Could you explain what you mean by ``works''?

---Dan

no. it firewalls their IP, not all. not perfect, as spoofing could
easily disrupt stuff like, oh.. DNS resolutions or gateway access... but
it's pretty good nonetheless.

Quote:> Could you explain what you mean by ``works''?

port scans, probes, SYN floods or inetd process table attacks.. all
fail. and fail miserably. with things obscured, they're less likely to
find holes. keeps the dumbass script kiddies away. configure the value
to something higher if you run a high performance web server... ie lots
of small graphics to grab. the multiple SYNs sent from the client will
also fail on this.

i used it on my thinkpad at defcon on the capture the flag network. all
normal scans (which work quickly) thwarted. only slow, progressive
scans, which most people don't like (a lot of hopped up caffine junkies
on the CTF network) would work, ie SYN to a port... wait 3 min... SYN to
next port... wait... repeat. it'd take all day to get a portscan in...

Quote:> > So if an attacker is flooding you with SYNs, trying to force you to drop
> > legitimate connections, then you respond by cutting off all connections?
> no. it firewalls their IP,

What do you mean by ``their IP''? A standard SYN flood comes from an
unpredictable sequence of forged IP addresses. How do you distinguish
the attacker's packets from legitimate packets?

What if the attacker instead generates SYNs from the IP address of a
legitimate machine? Do you cut off connections from that IP address?

---Dan

you don't. it's a limitation of the patch/method due to a flaw in IPv4. youcan
go to various convolutions to limit the damage, though, outside of the patch.

Quote:> What if the attacker instead generates SYNs from the IP address of a
> legitimate machine? Do you cut off connections from that IP address?

yes. again, a limitation of IPv4 and the spoofing that can occur, and i noted,
as you may have noticed, that yes, it can be used as a DoS attack. what if, for
instance, i SYN flood you pretending to be your nameserver(s)... ok, you
firewall them out. fair enough, now you can't communicate with your nameservers.
name your machine you want to block communications with and it's done. (and
don't forget that attacks from within the network, where you don't protect as
well against spoofing internal, important IP's, are a worse security problem.
disgruntled employees are worse than high school kids.) it's a hack, not a magic
bullet, and it thwarts a lot of otherwise easily performed attacks, probes and
scans.

my original point still stands, though, that the author of the post that started
this thread is working on a problem that has solutions of various levels. unless
the author has some radical solution, i suggest he finds a new problem. and if
he does have a new solution, please share the solution (i'm with
rain.forrest.puppy on openness in faults and solutions).

Wouldn't a better solution to be to automatically turn on syn cookies as soon
as you detected something funny going on, and/or to implement a list of none
trusted hosts from whom any syn flood would be assumed to be spoofing and syn
cookie those, while firewalling the rest?  Regardless, I think that the known
host list would be a very good idea, as it automatically prevents the DoS
attack from working, or at least it keeps you from DoS'ing yourself, although
it does allow the attack to continue.  An alternative might be to do a one
minute lockout on that IP to try and stave off the attack and then restore
service.  Really, any added configurability in this area helps a lot.

/P.
--
This is a test of the emergency context generation system.  Had this been
an actual emergency, you would have been experiencing actual context.

Quote:>Wouldn't a better solution to be to automatically turn on syn cookies as soon
>as you detected something funny going on, and/or to implement a list of none
>trusted hosts from whom any syn flood would be assumed to be spoofing and syn
>cookie those, while firewalling the rest?

If you go back to the original post, you'll see that he's trying to do this
on the router, not on the individual hosts.  I can appreciate this; the
whole reason we have firewalls is because it's difficult to ensure that all
hosts have good security setups.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

the trusted hosts which can't be firewalled is the start of a good idea...
but has other grave implications. i DoS your trusted nameserver and assume
it's IP. now i can abuse your machine. :) or worse, if you soft code the
list, i can abuse that and add myself (or other IP) to it. hardcoding is a
better idea, but still has weaknesses.

but this gets to trust relationship abuse, which you know, paul, i've been
investigating, and have been pondering improved trust validation.

Quote:> An alternative might be to do a one
> minute lockout on that IP to try and stave off the attack and then restore
> service.

it is configurable to lock out for a predefined period of time. you can
make it anywhere from 1 sec to ... several minutes or hours, i think. it's
all up to you. 1-2 minutes thwarts most probes and scans. the patch is
jesse off's strobe masking patch, available on the LinuxMama site. it's
also ben incorporated itnto the nmrcOS patch, for example (www.nmrc.org)
for the 2.0.36 kernels. you should really address thee issues with jesse,
i'm just poiting out that the issue of SYN floods and all has been
addressed.

PGP 2.6.2 key fingerprint: 89 B0 81 DA 5B FD 7E 00  99 C3 B2 CD 48 A0 07 80
Public key available at http://biocserver.cwru.edu/~jose/pgp-key.asc

What is solaris 7's default behavior regarding SYN flooding
attacks and how if at all is it configurable?  Where is it
documented (besides the original note that alludes to
"adaptive" approaches being considered for the future)?

Solaris 7 has two queues to deal with incoming connections, one of them for incoming
but not established connections ( from now on first queue) and the other for incoming
and established connections (from now on second queue).
When Solaris 7 receives a SYN packet it queues it in the first queue until the
connection is finally established (it passes to the second queue). If someone is
trying to attack you using 'SYN flooding' the first queue will be filled but when a
new SYN packet is received Solaris 7 deletes the older entry in the queue and places
the new one. So although the first queue could be full Solaris 7 can always establishs
the connections when it is needed.

You can view the number of entries in each queue using the command:

# ndd /dev/tcp -get \?

and modify them using

# ndd /dev/tcp -set <name of the parameter> <value>

I think the parameters are:

tcp_conn_req_max_q0 (first queue)
and
tcp_conn_req_max_q (second queue)

carlos.garcia-del-pozo.vcf < 1K Download