LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
How strictly do your users obey your security policies?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
Emily Ratliff: OS Security
DanWalsh LiveJournal
Security Bloggers Network
Latest Newsletters
Linux Advisory Watch: November 21st, 2008
Linux Security Week: November 17th, 2008
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
IPv6 approach for TCP SYN Flood attack over VoIP, Part III Print E-mail
User Rating:      How can I rate this item?
Source: Suhas Desai - Posted by Benjamin D. Thomas   
Features When a normal TCP connection starts, a destination host receives a SYN (synchronize/start) packet from a source host and sends back a SYN ACK (synchronize acknowledge). The destination host must then hear an ACK (acknowledge) of the SYN ACK before the connection is established. This is referred to as the "TCP three-way handshake."

While waiting for the ACK to the SYN ACK, a connection queue of finite size on the destination host keeps track of connections waiting to be completed. This queue typically empties quickly since the ACK is expected to arrive a few milliseconds after the SYN ACK.

The TCP SYN flood attack exploits this design by having an attacking source host generate TCP SYN packets with random source addresses toward a victim host. The victim destination host sends a SYN ACK back to the random source address and adds an entry to the connection queue. Since the SYN ACK is destined for an incorrect or nonexistent host, the last part of the "three-way handshake" is never completed and the entry remains in the connection queue until a timer expires, typically for about one minute.

By generating phony TCP SYN packets from random IP addresses at a rapid rate, it is possible to fill up the connection queue and deny TCP services such as e-mail, file Transfer or WWW to legitimate users.

There is no easy way to trace the originator of the attack because the IP address of the source is forged.

5.1 TCP SYN flood

A TCP SYN flood is an attack based on bogus TCP connection requests, created with a spoofed source IP address, sent to the attacked system. Connections are not completed, thus soon it will fill up the connection request table of the attacked system, preventing it from accepting any further valid connection request.

The source host for the attack sends a SYN packet to the target host. The target hosts replies with a SYN/ACK back to the legitimate user of the forged IP source address.

Since the spoofed source IP address is unreachable, the attacked system will never receive the corresponding ACK packets in return, and the connection request table on the

Attacked system will soon be filled up.The attack works if the spoofed source IP address is not reachable by the attacked system. If the spoofed source IP address where reachable by the attacked system, then the legitimate owner of the source IP address would respond with a RST packet back to the target host, closing the connection and defeating the attack.

TCP SYN flood is a denial of service attack that sends a host more TCP SYN packets than the protocol implementation can handle.

This is a resource starvation DoS attack because once the connection table is full; the server is unable to service legitimate requests.

5.2 TCP SYN flood protection

5.2.1 Apply Operating System fixes

Systems periodically check incomplete connection requests, and randomly clear connections that have not completed a three-way handshake. This will reduce the likelihood of a complete block due to a successful SYN attack, and allow legitimate client connections to proceed.

  • Configure TCP SYN traffic rate limiting
  • Install IDS (Intrusion Detection Systems) capable of detecting TCP SYN flood attacks

5.2.2 Filter network traffic

Use circuit level firewalls (stateful inspection) to monitor the handshake of each new connection and maintain the state of established TCP connections. The filtering system must be able to distinguish harmful uses of a network service from legitimate uses.

Static packet filtering (stateless) does not protect from TCP SYN flood attacks.


About the Author: Suhas A Desai

  • Undergraduate Computer Engineering Student,Walchand CE,Sangli,INDIA.

  • Previous Publications in area "Linux Based Biometrics Security with Smart Card" are include:ISA EXPO 2004,InTech Journal,TX,USA,IEEE Real Time and Embedded System symposium 2005,CA,USA.,e-Smart 2005,France.

  • Writes security newsletters and features for many security sites.

Comments
ddos helpWritten by Tom on 2008-02-24 07:51:43
Can you help me protect from ddos , smekeriamare@aol.com

Write Comment
  • Please keep the topic of messages relevant to the subject of the article.
  • Personal verbal attacks will be deleted.
  • Please don't use comments to plug your web site.. Such material will be removed.
Name:
Title:
Comment:

Code:* Code

Powered by AkoComment!

 
< Prev   Next >
    
Partner:

 

Latest Features
A Secure Nagios Server
Never Installed a Firewall on Ubuntu? Try Firestarter
Review: Hacking Exposed Linux, Third Edition
Security Features of Firefox 3.0
Review: The Book of Wireless
April 2008 Open Source Tool of the Month: sudo
Open Source Tool of March: ZoneMinder
Yesterday's Edition
Plaintext Recovery Attack Against SSH

QuickLinks: Comunity , HOWTOs , Blogs , Features , Book Reviews , Networking ,
  Security Projects ,   Latest News ,  Newsletters ,  SELinux ,  Privacy ,  Home,
 Hardening ,   About Us,   Advertise,   Legal Notice,   RSS,   Guardian Digital

(c)Copyright 2008 Guardian Digital, Inc. All rights reserved.