lkml.org 
[lkml]   [1997]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SYN flooding....

Thinking this needs to leav ethe kernel list.....

On Mon, 26 May 1997, Jon Lewis wrote:
> On Mon, 26 May 1997, Rogier Wolff wrote:
>
> > My personal opinion is that logging useless information is less
> > harmful than throwing information away. If the stupid fools didn't
> > forge their source address, or are behind a router that correctly only
> > allows "internal IP addresses" to go out, you would at least have
> > the ISP that they operate from....
>
> I wonder how many ISP's and NSP's enforce that kind of filtering? I do
> that on our internet gateway router in our Gainesville POP, but in
> Tallahassee, Sprint provides our T1 and router and gives me 0 access to
> it. They were doing no such filtering until I emailed their NOC a few
> times and then started sending unusual packets to their NOC.

I did this kind of filtering on a network I used to administer, with T1
connection via UUNET. We had control of the router on our side of the
pipe so I setup filters that both stopped spoof attemtps form upstream on
the pipe (if you arn't doing thing, please put down this mailing list and
shoot yourself in the head) and also filters to stop those addresses not
sepcifically under my control from going upstream.

I also had a set of dialups and a core router that I configured in much
the same way. I had some Livingston portmasters and used RADIUS to
assign filters to various logins. What really sucked tho is that I could
not dynamically create the filters in the POrtmaster, I wish there was a
language so I could say "deny unless SRC = $CURRENT_IP" or something on a
port. I think you get my drift. Anyways I was stuck with just filtering
on the 'Class C' an address was from, which emant I would have a little
harder time tracking the problem down if there was one.

The core router did alot of the same, filters against spoofing, filters
against improper IP addresses originating on a given network segment.
And of course throught all of this, NO traffic on ports 137-139 8)

> Recently, I made some holes in the filter in GNV, so I could send presents
> to/from certain netblocks, and it appears UUNet (our provider in GNV)
> doesn't do such filtering either.

UUnet in Chicago does no filtering either. I was able to shoot packets
of any design up that pipe. I suppose for them filtering at the more
central routers is akin to making a high speed runner doing marathon
stints present a report to the Environmental Protection Agency regading
the consequences of each of his footfalls for each step.

> Do any of the NSP's do such sensible filtering, or do they all leave it up
> to the customer, which in most cases means no filtering?

It's prolly very intensive for them to do such filtering. I'm thankful
they even have their routers still running. I had enough problems with
routers disappearing off the net.

> Back to the point...I've patched my kernel to display the synflood info
> liek this:
> Warning: possible SYN flood from 199.185.131.45 on port 25. Sending cookies.
> validated probe(199.185.131.45:2285, 205.229.48.20:25, -149058382)
>
> figuring, some info, even if it's forged, is better than not having a clue
> where it came from if I wasn't able to do a netstat at the time. Note
> that the default behavior is to not log any source addresses if a possible
> SYN flood failed to be validated. This way, if there is a real one, I'll
> know the source address used.

Kewl.


Craig Brozefsky craig@onshore.com
onShore Inc. http://www.onshore.com/~craig
Development Team p_priority=PFUN+(p_work/4)+(2*p_cash)


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.078 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site