- Test - lists.nanog.org

router syn/syn-ack/ack alarming...
by Regis Donovan 17 Sep '96

17 Sep '96

um... maybe i'm missing the clue here, but if the router vendors add something that shuts down an interface if the SYN/SYN-ACK/ACK ratio becomes too bad make it *easier* for me if i'm doing a denial of service attack on a host? instead of denying service to a given host, all i have to do is drive the router into alarm mode so it shuts off the interface and then i get to deny service to an entire segment and everything downstream from that segment... here's to better bang for your cracker-kiddie buck... --regis >

5 4

SYN and Solaris
by dvv＠sprint.net 17 Sep '96

17 Sep '96

The values to play with are tcp_conn_req_max (defines the max value for listen queue), tcp_ip_notify_cinterval (makes tcp send another SYN???), tcp_ip_abort_cinterval (aborts connection and frees the slot). Note "c" in "cinterval". I understand these timer values work for both incoming and outgoing connections. Dima

2 1

Re: New Denial of Service Attack on Panix
by Justin W. Newton 17 Sep '96

17 Sep '96

At 02:51 PM 9/17/96 -0400, Dick St.Peters wrote: > >Logging denies will fill up your log anyway. Packets arriving for a >dialup user after he/she hangs up fall through to the default route >back out of the box. They are then _outbound_ packets with source >address off the network and destination address on the network. That depends how your network is setup. Ours would have the route going to Null0, so it wouldn't be shot back out via the default route. This hides any internal instability from being announced to the outside world except in /extreme/ cases. (Like we fall completely off the net). Why would you want the packet transiting back and forth across your T-1 until the TTL expires anyway? Much better to black hole the sucker. Justin Newton Internet Architect Erol's Internet Services

2 1

Re: SYN and Solaris
by Sanjay Dani 17 Sep '96

17 Sep '96

> From: dvv(a)sprint.net (Dima Volodin) > The values to play with are tcp_conn_req_max (defines the max value for > listen queue), tcp_ip_notify_cinterval (makes tcp send another SYN???), > tcp_ip_abort_cinterval (aborts connection and frees the slot). Note "c" > in "cinterval". I understand these timer values work for both incoming > and outgoing connections. On Solaris, the default for tcp_ip_abort_cinterval is 180000 ms (3 mins). You could try reducing it to a few seconds (at the risk of denying service to legit clients connecting over slow links) using #ndd -set /dev/tcp tcp_ip_abort_cinterval <value in ms> This affects ALL tcp conenctions on the system. Solaris also lets you set the parameter for a specific destination port if the SYN attacker does not use a random destination port: #include <netinet/in.h> #include <netinet/tcp.h> .... int value = <whatever>; setsockopt(fd, IPPROTO_TCP, TCP_CONN_ABORT_THERSHOLD, &value); .... Sanjay. PS. This feature may or may not be documented--I got it from a friend at SunSoft.

1 0

Re: A modest proposal
by Vadim Antonov 17 Sep '96

17 Sep '96

Robert E. Seastrom <rs(a)bifrost.seastrom.com> wrote: >Not worth the trouble. The far ends of the earth where not even the >network admins speak English are on the ends of wet strings; it isn't >worth the aggreivation to telnet through them, and launching a >source-routed synflood through them would be self-defeating. Ah. That's changing faster than you think (can you say OC-3 to places like Singapore? Not a pipe dream anymore). And most of us don't speak German either. --vadim

1 0

Re: router syn/syn-ack/ack alarming...
by Vadim Antonov 17 Sep '96

17 Sep '96

Regis Donovan <regisdo(a)microsoft.com> wrote: >um... maybe i'm missing the clue here, but if the router vendors add >something that shuts down an interface if the SYN/SYN-ACK/ACK ratio >becomes too bad make it *easier* for me if i'm doing a denial of service >attack on a host? No, you took the "anti-SYN" shut-off in opposite direction. ISPs could install the asymmetry shut-off (why stop at SYNs / SYN-ACK pairs?) enforcing rough balance of SYNs coming from customer and SYN-ACKs coming back to customer. If the traffic is legitimate, the balance will hold. Any attempt to flood by that customer (intentional, or unintentional, by a broken software) will cause massive disbalance. The equivalent filter on victim's side won't see those SYNs and SYN-ACKs, simply because thet are going in opposite direction. >instead of denying service to a given host, all i have to do is drive >the router into alarm mode so it shuts off the interface and then i get >to deny service to an entire segment and everything downstream from that >segment... Yes, the defense may be multi-staged. I.e. if a local ISP does not enable anti-flooding defenses on its own customer links, it'll risk backbone ISP shutting its entire operation. BTW, telcos use the statistical traffic analysis (bit-density monitors is the most trivial example) to isolate troubles for years. --vadim

1 0

Re: SYN floods
by Leonid Egoshin 17 Sep '96

17 Sep '96

>From: Michael Dillon <michael(a)memra.com> > [Copyrighted text was deleted] Source address checking ... hm-m, pretty idea, but it do not very large help - it is very simple to make login to some public (or not very protected) host and produce SYN flood from legitimate address. At least one day server would be blocked. And after that - force shutdown communication between server and this public host (net) BY SERVER OWNER HANDS ! - Leonid Yegoshin, LY22

1 0

Re: New Denial of Service Attack on Panix
by Leonid Egoshin 17 Sep '96

17 Sep '96

>From: "Forrest W. Christian" <forrestc(a)iMach.com> > > 5 minute SYNS: 123423 5 minute SYN-ACKS: 50000 > >Then, if the ratio got too high, it can start yelping about "Potential SYN >D-O-S Atttack in progress on Interface Serial 1" I suggest to check not only ratio (assymetric routing !), but high number of SYNs to single host. - Leonid Yegoshin, LY22

1 0

Re: New Denial of Service Attack on Panix
by Kent W. England 17 Sep '96

17 Sep '96

At 11:02 AM 9/17/96 -0400, Guy T Almes wrote: >Nathan, > I'm afraid that Kent is right about this one. > I wish that it were not so, but after reading the clever and insightful approaches to tracking down the denial-of-service perps, I am pessimistic about our ability to stay ahead in the escalation of this counter-counter- measure warfare. I think that if we were able to trace the Panix attacker that a future attacker would hit simultaneously from a half-dozen free dial-up connections with a real random number generator and synthetic SYNs to fool the router stat collector (or whatever it takes). I think we are on the short end of the technology stick here. If the fit hits the shan and the attacks begin to escalate, we need to be ready to cooperate on source address filtering at the periphery. It's one of those cases of hang together or hang separately. Should we wait, like the cell phone industry did with the cloning fiasco, until this gives us a black eye? It's just too inviting to expect that we don't have plenty of folks out there ready to pull this trigger on us. We need a general consensus in order for any one of us to justify the effort required to install source address filters. That means that representatives from major backbone ISPs must announce that they will install filters (not at the MAEs) in response to this new threat and that they expect that their peers will too. I'm not one of those major backbone ISP network engineers, but I would hope that for the sake of all of us, that those who are will roll their eyes heavenward, take a deep breath, and do what needs to be done. I know it's easy for me to say, but nevertheless ... This is an excellent example of what the NANOG and IEPG are really good for. --Kent

2 1

Re: SYN floods
by Kent W. England 17 Sep '96

17 Sep '96

At 10:47 AM 9/17/96 -0700, Michael Dillon wrote: >Some part of the discussion involves the technical details of hardening OS >kernels as well as a couple of alternate solutions for defending against >the attacks involving either a SYN proxy or a machine feeding RST's. These >technical details belong on the firewalls list because the people on that >list work with building DEFENSIVE mechanisms. Except that what we need are routers implementing traffic filtering on ISP input ports rather than firewalls defending customer premises from attacks coming from the ISPs. I think we are dealing with two different markets and two different groups of people. I don't think that ISPs will protect themselves from this denial of service attack with firewalls. This is a router requirement. > >inet-access and other ISP mailing lists are most relevant for the >PREVENTION of SYN flood attacks. This is where we need to hammer home the >need for filtering outgoing routes. Filtering incoming traffic against legitimate source addresses. The most important point is that if we all decide that defense and tracing are of limited utility and that filtering is the only way to stop these attacks, then we need a few people who read the nanog and iepg lists to stand up and say "I will filter and I expect you to do the same if you want to peer with me." Otherwise, it will be difficult for any single ISP to justify being the first to install peripheral filtering. We must have a consensus to move on this issue. Call it "peer pressure". :-) --Kent

3 2