How to stop a SYN flood
Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: How to stop a SYN flood

  1. #1
    Senior Member
    Join Date
    Jan 2003
    Posts
    274

    How to stop a SYN flood

    First, a SYN flood defined:

    A type of denial of service attack in which a large number of TCP SYN packets (the first packet in a TCP/IP connection), usually with spoofed source IP addresses, are sent to a target.

    The target system replies with the corresponding ACK packets and waits for the final packet of the TCP/IP three-way handshake. Because the source IP address of the initial packet was spoofed, the target never will receive the final packet, leaving it to hold TCP/IP sessions open until they time out.

    A SYN flood causes so many TCP/IP open sessions that the system becomes overwhelmed and cannot handle any more network traffic.
    From Denial of service: Fighting back, Network World, 09/02/02.

    Now that my one obligatory cut-n-paste is out of the way. Let's talk about stopping it.

    If you are running Foundry switches, this is a simple one line entry. It can be configured globaly, or on a per-port basis.
    That line is:

    ip tcp burst-normal xxx burst-max yyy lockup zzz

    Where xxx is defined as the 'normal' amount of SYNs you expect to see per second, yyy is the maximum amount of SYN packets (in burst) per second and zzz is defined as the number of seconds that you want to stop receiveing SYN packets on that port for.

    So ip tcp burst-normal 100 burst-max 300 lockup 600 tells your switch that if it exceeds 100 SYN packets per second, to drop all excess TCP SYNs If it exceeds 300 SYNs per second, all SYN packets will be dropped on that port for the duration of the lockup value.

    Very effective, but potentially very damaging too. If you yourself can't send SYNs through the port, the denial of service attack has been at least partially sucessful.

    With Cisco equipment, the tools are a bit more granular, but much more complicated.

    First you have to create an extended IP access list. That list syntax is:
    access-list access-list-number {deny | permit} tcp any destination destination-wildcard The reason we are filtering on any for the source, is because we don't know who is going to be SYN flooding us.

    If you don't understand the syntax of ACL's, there are lots of tutorials on them. The scope of ACL's is beyond the scope of this tutorial here.

    After the ACL is created, you have to turn a feature known as tcp intecept on. That is done with this command:

    ip tcp intercept list access-list-number

    Next we have to set the intercept mode. We have two choices here. The default is intercept, where your cisco device will actually behave like a proxy. It will recieve the SYN, send its' own SYN/ACK, and if it recieves an ACK, will then pass the data on to the protected host or network. The other option is watch mode, where it will allow the SYNs to go to the host or network, but the cisco device 'keeps an eye on' the connection until it becomes fully established. If the connection fails to become established in a certain amount of time (the default is 30 seconds, but can be configured with the ip tcp intercept watch-timeout command) Then the cisco device sends a reset to the host, clearing the embryonic TCP connection.

    Now, if your Cisco device thinks there is an attack in progress, it starts to guard a little more zealously. If 1100 partial connections exist, or if the number of partial connections in one minute exceeds 1100, the device will start closing the oldest connections. It will then also reduce the retransmission time-out value to .5 seconds, effectively cutting in half the amount of time that hosts spend trying to communicate with each other.

    If you really feel like getting crazy, you can change the mode from 'drop oldest' to 'drop random' connection. This is done with the ip tcp intercept drop-mode random command. And, as you might expect, all the timers et cetera can be tweaked to your specifications with variations of the ip tcp intercept command. I won't go into all of them here because Cisco gives you that lovely ability to type in a question mark at the CLI. Trust me, they're all self-explanatory.

    So if you accept the default times, and default (intercept) mode, your configuration would likely look like this:

    ip tcp intercept list 121
    !
    access-list 121 permit tcp any 172.16.1.0 0.0.0.255

    Which would cause the intercept feature to be enabled for all TCP servers/hosts on the 172.16.1.0/24 network.

    Since some SYN traffic will still be allowed to pass, this is often times a preferable solution to the Foundry method as it should at least give things like critical web servers some ability to communicate while tossing the DDOS packets. That's the hope at least.

  2. #2
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,883
    ...or simply add this registry key should the above method somehow fail:

    TCP SYN flood attack protection
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
    SynAttackProtect
    REG_DWORD
    2 (recommended)
    0 = default; normal protection against SYN attacks
    1 = connection times out more quickly
    2 = additional timeouts from 1; also limits certain socket options

    Setting this value to 1 or 2 will reduce the threat of TCP denial of service attacks.
    Denial of service (DoS) attacks cannot be stopped entirely, but this simple registry setting will help reduce the risk.


    --TH13
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  3. #3
    Senior Member
    Join Date
    Nov 2002
    Posts
    339
    TK: Very nice tut. I know nothing of Foundry devices but you now have me googling more info

    TH13: I had no clue you could do that as a reg entry. I'll be keeping that in mind and I am currently googling more reg entries along the same lines. Thanks to both.
    Don\'t be a bitch! Use Slackware.

  4. #4
    Senior Member
    Join Date
    Jan 2003
    Posts
    274
    Out of the 140 or so servers we have running, exactly 6 are Windows, so the regedit doesn't do much to protect the farm.

    That is a good point though horse, I rarely think in terms of hardening the servers though as I leave that to the LAN people.

  5. #5
    Senior Member
    Join Date
    Apr 2004
    Posts
    1,130
    you can do the same thing on a Netfilter firewall using "-m limit" clause.
    Linux servers have a builtin protection against (syncookies).
    Meu sítio

    FORMAT C: Yes ...Yes??? ...Nooooo!!! ^C ^C ^C ^C ^C
    If I die before I sleep, I pray the Lord my soul to encrypt.
    If I die before I wake, I pray the Lord my soul to brake.

  6. #6
    @ŢΜĮЙǐЅŦГǻţΩЯ D0pp139an93r's Avatar
    Join Date
    May 2003
    Location
    St. Petersburg, FL
    Posts
    1,694
    SynCookies is not exactly protection against syn floods... IIRC it has to be enabled on both server and client to be used?
    Real security doesn't come with an installer.

  7. #7
    Senior Member
    Join Date
    Apr 2004
    Posts
    1,130
    Originally posted here by D0pp139an93r
    SynCookies is not exactly protection against syn floods.
    so what is the purpose of syncookies?
    Meu sítio

    FORMAT C: Yes ...Yes??? ...Nooooo!!! ^C ^C ^C ^C ^C
    If I die before I sleep, I pray the Lord my soul to encrypt.
    If I die before I wake, I pray the Lord my soul to brake.

  8. #8
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,883
    That is a good point though horse, I rarely think in terms of hardening the servers though as I leave that to the LAN people.
    I wasn't sure how many *nix/Windoze machines you have so I figured that I would throw it out there and perhaps it would be of some use.

    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  9. #9
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    FYI, OpenBSD's pf also offers synproxy...


    Ammo
    Credit travels up, blame travels down -- The Boss

  10. #10
    Senior Member
    Join Date
    Jun 2003
    Posts
    723
    syncookies :
    When a TCP SYN segment is received on a port corresponding to a listen
    socket, an entry is made in the syncache, and a SYN,ACK segment is
    returned to the peer. The syncache entry holds the TCP options from the
    initial SYN, enough state to perform a SYN,ACK retransmission, and takes
    up less space than a TCP control block endpoint. An incoming segment
    which contains an ACK for the SYN,ACK and matches a syncache entry will
    cause the system to create a TCP control block with the options stored in
    the syncache entry, which is then released.

    The syncache protects the system from SYN flood DoS attacks by minimizing
    the amount of state kept on the server, and by limiting the overall size
    of the syncache.

    Transaction TCP accelerated opens (see ttcp(4)) are also supported, and
    bypass the syncache.

    Syncookies provides a way to virtually expand the size of the syncache by
    keeping state regarding the initial SYN in the network. Enabling
    syncookies sends a cryptographic value in the SYN,ACK reply to the client
    machine, which is then returned in the client's ACK. If the correspond-
    ing entry is not found in the syncache, but the value passes specific
    security checks, the connection will be accepted. This is only used if
    the syncache is unable to handle the volume of incoming connections, and
    a prior entry has been evicted from the cache.

    Syncookies have a certain number of disadvantages that a paranoid admin-
    istrator may wish to take note of. Since the TCP options from the ini-
    tial SYN are not saved, they are not applied to the connection, preclud-
    ing use of features like window scale, timestamps, or exact MSS sizing.
    As the returning ACK establishes the connection, it may be possible for
    an attacker to ACK flood a machine in an attempt to create a connection.
    While steps have been taken to militate this risk, this may provide a way
    to bypass firewalls which filter incoming segments with the SYN bit set.

    stolen from man syncookies on freebsd ,
    Do unto others as you would have them do unto you.
    The international ban against torturing prisoners of war does not necessarily apply to suspects detained in America\'s war on terror, Attorney General John Ashcroft told a Senate oversight committee
    -- true colors revealed, a brown shirt and jackboots

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •