Mailing List Archive

Re: SYN floods continueg
> On Wed, 11 Sep 1996, Alexis Rosen wrote:
>
> > Anyway. Point is this: We can't take too much more of this, nor can our
> > customers. I have yet to hear *anyone* come up with any ideas even remotely
> > reasonable for how to deal with this situation, long term, except for the
> > filtering that Avi, Perry, and I have been promoting these last few days.
> >
> > Whether or not existing equipment can handle the job is *IRRELEVANT*. If
> > it won't, new equipment must be bought. The net won't survive without it.
>
> Did you ever track down the source of the attacks? If not, why not?
>
> Michael Dillon - ISP & Internet Consulting

Without saying too much, I think I can say tat the attacks did go on for hours
a few times, but stopped before too much tracing could be done.

Initially I thought Panix was being attacked by a random attacker; Voicenet
in Philadelphia was attacked for almost a day on their mail ports, and another
provider in Philly was attacked for 4-6 hours on news ports (pretty
ineffective). But Panix has been attacked a few times now.

I've actually got a kernel built for sun4c that is pretty good/resistant,
but only to the attacks I can *think of*. I and panix are trying to get it
working on sun4m.

Bottom line, it would be good if everyone who could would filter incoming
on customers or outgoing on borders. While you're at it, if your network
is relatively simple (compared to, say, MCI's or UUNET's or Sprint's), you
might want to filter incoming on borders at exchange points to prevent others
from using you for transit.

Avi

- - - - - - - - - - - - - - - - -
Re: SYN floods continueg [ In reply to ]
> Could you provide sample CISCO syntax ACL filters to perform the above?
> I'm not clear how you filter out these kind of attacks.
> Thanks,
>
> --curtis

This is actually an incoming filter...

'sho access-list 102' shows you counts on hits for each line;
pretty interesting, actually.

Each line says permit any kind of ip data from anywhere, from any IP
address, to the network specified.

For an outgoing filter you'd reverse it so it looked like
'acc 102 permit ip <our-net> <inverted-mask> any'.

no acc 102
acc 102 permit ip any 198.138.103.0 0.0.0.255
acc 102 permit ip any 205.199.164.0 0.0.0.255
acc 102 permit ip any 204.193.157.0 0.0.0.255
acc 102 permit ip any 199.171.193.0 0.0.0.255
acc 102 permit ip any 199.67.58.0 0.0.0.255
acc 102 permit ip any 205.160.86.0 0.0.0.255
acc 102 permit ip any 192.135.189.0 0.0.0.255
acc 102 permit ip any 198.133.170.0 0.0.0.255

! not all of these are /16s, I was just lazy yesterday
! eventually the 0.0.0.255.255s should become more specific
acc 102 permit ip any 206.42.0.0 0.0.255.255
acc 102 permit ip any 137.239.0.0 0.0.255.255
acc 102 permit ip any 198.69.0.0 0.0.255.255
acc 102 permit ip any 206.161.0.0 0.0.255.255
acc 102 permit ip any 205.164.128.0 0.0.255.255
acc 102 permit ip any 170.115.0.0 0.0.255.255
acc 102 permit ip any 207.106.0.0 0.0.255.255
acc 102 permit ip any 199.234.208.0 0.0.255.255
acc 102 permit ip any 207.8.128.0 0.0.255.255

acc 102 permit ip any 192.157.69.47 0.0.0.0
acc 102 permit ip any 192.41.177.87 0.0.0.0
! acc 102 permit ip any 198.32.136.82 0.0.0.0

acc 102 deny ip any any

Avi

- - - - - - - - - - - - - - - - -
Re: SYN floods continueg [ In reply to ]
>>>>> "Avi" == Avi Freedman <freedman@netaxs.com> writes:

Avi> This is actually an incoming filter...
Avi> acc 102 permit ip any 198.138.103.0 0.0.0.255

Ummmm.... disclaimer, I'm not an expert on this, but according to my
understanding of how Cisco access lists work, the incoming filter you
showed actually does nothing at all. The normal situation is that
packets are coming in from random addresses, destined for your
internal network. There is nothing in this filter that prevents your
own source addresses from being spoofed outside your border.

It seems to me that you want something more like this, which is what
we have in place:

acc 102 deny ip 198.138.103.0 0.0.0.255 any
...
acc 102 permit any any

It seems to work for us. Please let me know if I'm missing something here!

--
Bruce Robertson, President/CEO
Great Basin Internet Services, Inc.
+1-702-348-7299 fax: +1-702-348-9412
- - - - - - - - - - - - - - - - -
Re: SYN floods continueg [ In reply to ]
I was talking about a different filter.

The one I listed was designed to prohibit someone at an exchange point
from using our network for transit.

I agree, you'd want to do what you describe to prevent IP spoofing.

Avi

> >>>>> "Avi" == Avi Freedman <freedman@netaxs.com> writes:
>
> Avi> This is actually an incoming filter...
> Avi> acc 102 permit ip any 198.138.103.0 0.0.0.255
>
> Ummmm.... disclaimer, I'm not an expert on this, but according to my
> understanding of how Cisco access lists work, the incoming filter you
> showed actually does nothing at all. The normal situation is that
> packets are coming in from random addresses, destined for your
> internal network. There is nothing in this filter that prevents your
> own source addresses from being spoofed outside your border.
>
> It seems to me that you want something more like this, which is what
> we have in place:
>
> acc 102 deny ip 198.138.103.0 0.0.0.255 any
> ...
> acc 102 permit any any
>
> It seems to work for us. Please let me know if I'm missing something here!
>
> --
> Bruce Robertson, President/CEO
> Great Basin Internet Services, Inc.
> +1-702-348-7299 fax: +1-702-348-9412
>

- - - - - - - - - - - - - - - - -
Re: SYN floods continueg [ In reply to ]
> On Wed, 11 Sep 1996, Avi Freedman wrote:
> > and another provider in Philly was attacked for 4-6 hours on news ports
> > (pretty ineffective).
>
> Hi. Why was this ineffective?
>
> Thanks,
> Chris Caputo
> President, Altopia Corporation

Because most providers only let their customers connect to their nnrp/nntp
servers. And you can easily build a filter which allows just port-119
connects from your news peers and denies all others...

Of course, that wouldn't work as well for alt.net (you guys) if you're
still selling off-site nnrp access to hundreds of people.

Avi

- - - - - - - - - - - - - - - - -
Re: SYN floods continueg [ In reply to ]
On Wed, 11 Sep 1996, Bruce Robertson wrote:

==>It seems to me that you want something more like this, which is what
==>we have in place:
==>
==> acc 102 deny ip 198.138.103.0 0.0.0.255 any
==> ...
==> acc 102 permit any any
==>
==>It seems to work for us. Please let me know if I'm missing something here!

This works for stopping the spoofing of your own internal hosts from
getting packets into your network.

To stop the problem that's presented here (of packets flowing out of your
network with random IP addresses (as one can do on a Linux-box dial-up)),
you need an outbound filter based on source-address, like the following:

access-list 102 permit ip 205.166.195.0 0.0.0.255 any
access-list 102 permit ip 205.166.254.0 0.0.0.255 any
interface Serial0
ip access-group 102 out

This will allow packets sourced from hosts in the
205.166.195.0-205.166.195.255 and 205.166.254.0-205.166.254.255 range out,
but other packets will be stopped at that router, including those SYN
floods with random source IP's.

Depending upon your network architecture, the optimal placement of these
lines varies.

/cah

----
Craig A. Huegen CCIE #2100 || ||
Network Analyst, IS-Network/Telecom || ||
cisco Systems, Inc., 250 West Tasman Drive |||| ||||
San Jose, CA 95134, (408) 526-8104 ..:||||||:..:||||||:..
email: chuegen@cisco.com c i s c o S y s t e m s


- - - - - - - - - - - - - - - - -