The Computer Communication Lab (236340)
Winter 2004/2005
Denial of Service attack protection
First Report
Submitted by:
Aviram Naama
034432781
snaviram@t2
Koyfman Oleg
308827351
skoyfman@t2
Shmerlin Boris
308900075
sbshmerl@t2
1.Introduction
Denial of Service attack attempt to prevent legitimate users of a network
service from using that service. DoS techniques include variants such as the
Teardrop and TCP SYN Attack.
Teardrop attack uses overlapping offset fields in the IP fragmentation. A TCP
connection starts by a SYN packet sent from a host to a destination, a SYN
ACK that is sent back and finally an Ack of the last SYN again from the host
to the destination. This is referred to as the "TCP 3 way handshake". While
waiting for the last 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 very quickly after the
SYN ACK. The TCP SYN 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 TCP SYN packets from random IP addresses at a rapid rate, the
connection queue is blocked and any TCP services cannot be served.
Figure
1.a
Ethernet
Internet
Firewall
2.Firewall Description
2.1.
SYN attack protection description:
The firewall works as proxy. When it gets the first packet (the syn
packet) in three way handshake process the firewall stores it in current
connection oriented buffer and sends client second packet ( syn + ack
packet) and waits for third packet (client ack packet). If client ack
packet arrives in defined period of time, firewall opens connection to
server using client previous packets so it stops to function as proxy.
Figure 2.a
Client
Firewall
Msg1
:SYN(C
lie
+A
SYN
nt.IP,S
erver.I
P)
lie
r.IP,C
erve
CK(S
ACK(
Server
Clien
t.IP, S
e
)
nt.IP
rver.I
P)
SYN(M
sg1)
+A
SYN
t.IP)
Clien
r.IP,
e
v
r
e
CK ( S
ACK(
TCP p
a
cket
TCP p
a
2.2.
Clien
t.IP, S
erv
er.IP)
cket
TCP packe
t
TCP packe
t
Teardrop attack protection description:
As in case of SYN attack firewall functions as proxy and gets
fragmented packets. On each fragment arrival firewall checks if arrived
packet offset field does not overlap previous fragment of the same
packet. In case it does overlap the firewall realizes that it's under attack
and closes the connection, otherwise sends the fragment to the server,
keeps needed information in order to perform next check and waits for
next fragment. If next fragment does not arrive in timeout the packet is
dropped.
3.Firewall modules
Firewall is build from three main modules: sender, receiver and inspector.
Figure 3.a
Firewall module
Sender module
Receiver module
Input buffer
Output buffer
Inspector module
Input buffer
Sender module
Data
Base
Data
Base
Data
Base
Output buffer
Receiver module
3.1. Sender module
This is a thread that samples the output buffer. When the packet is in the
buffer, the thread takes it, and sends it on the NIC (network card), on
which it is running. In our system there are two such modules: one is
running on internal NIC (for incoming messages for server) and one on
external NIC (for outgoing messages from server).
3.2. Receiver module
This is a thread that receives packets from a NIC, on which it is running.
The thread is listening on the specified TCP port, and when the packet is
sent to that port, the receiver module receives it, and enters it to the input
buffer.
3.3. Inspector module
This module is in charge of two tasks:
 Detecting SYN attack
 We define suitable granularity of measurement time period T.
Each T seconds we sample the number of pending
connections – f(T)
 Establishing a connection
 Acts as a proxy on establishing a connection. For each
incoming SYN packet, answers with SYN+ACK and waits for
ACK from a client. That’s way it protects the server against
SYN attack. When the connection with the client is
established, it is establishing the connection with a server (see
figure 2.a). The connection from firewall module to server is
performed as it was the connection establishing from client to
server, so it will be transparent for both sides (neither the
client, nor the server will know that the firewall intermediate).
 Detecting Teardrop attack
 Performs inspection of incoming fragmented packets. For
each fragmented packet, ensures that fragments are not
overlapping with each other.
4.Algorithms
Syn attack protection
There is an IP database, the "Black IP list", which holds all the ip addresses
that are suspected as SYN attackers. For each address entered the database, it
is removed from it after one minute. Each time the attack detected from the IP
from the database, the timeout is initialized. If SYN packet arrives from the IP
from this database, the packed is discarded.
Statistics:
 Formula
F (ti )   * f (ti 1 )  (1   ) * F (ti 2 )
 Definitions:
1. ti - time period between two inspections of pending
connections.
2. f (ti ) - number of pending connections in current
inspection.
3. F (ti ) - expected value of pending connections for current
inspection.
4.  - weight of last inspection in total computation.
 Explanation:
Each ti we compute f (ti ) . If f (ti ) is much bigger than
F (ti ) we understand that we are under attack and enter
“defense SYN attack” mode. In this mode, we reduce timeout
of waiting for third ACK in three way handshake, we stop
calculating the new F (ti ) until we exit this mode by reaching
number of pending connections compatible with previous
F (ti ) . When we exit the “defense SYN attack” mode we
increase the third ACK timeout, back to its original value.
 Remarks:
1.  and ti will be defined experimentally and may be
changed by user.
2. Statistic calculations and SYN protection algorithm will be
implemented by different threads.
SYN protection algorithm:
1. SYN packet arrives – receiver module enters the packet to input buffer.
2. The inspector module takes the packet from the input buffer and detects
that this is a SYN packet
3. If this is a SYN message: saves it in its database and answers with
SYN+ACK in order to establish a connection with a client. SYN+ACK
packets destination IP is client's IP, and source IP is servers IP (the firewall
is faking the response)
4. Firewall waits for ACK from client during defined time out period.
4.1. If the ACK arrives during time out period – connection established. For
5.
6.
7.
8.
9.
each incoming packet from a client, destined for the server we will
save it in the database and after a connection with a server will be
established, we will send them to server.
4.2. Else:
4.2.1. We suspect this to be a SYN attack – so we check source IP
against “suspected SYN attackers” database.
4.2.1.1. If this IP in the database: we increase a counter of received
SYN without ACK packets.
4.2.1.2. Else we enter it to the database with initialization of it’s
counter to 1
4.2.1.3. If the counter reached Z – we say that this IP is an attacker,
and enter it to the “Black IP list” and SYN packet that
belongs to this connection dropped from the buffer.
The firewall takes the original SYN that arrived form client and sends it to
the server (now the firewall faking the initiation of connection)
The server will respond with the SYN+ACK of his own.
The firewall will generate ACK for the server, with source IP of clients IP,
and destination IP of servers IP. The connection between firewall and
server is established. Now we can say that a connection between client and
server is established.
Any packet that arrives to firewall after a connection has been established,
is inspected, and then passed to the other side (for example, if the packet
from server to client is arrived, the firewall will send it to client and vice
versa)
When server or client sends FIN – the database is cleared of all data from
this connection
Teardrop denial
Database description:
For each "source IP" we will hold all the fragmented packets, so when the
packet arrives we can easily find the rest of the fragments.
1. When a fragmented packet arrives, the packet saved in a database,
according to a connection.
2. The timeout is set to be X minutes: after X minutes, if not all fragmented
packets arrived, the packets are dropped.
3. For each additional fragmented packet that comes from this connection:
a. Verify that the offsets are not overlapping
i. If the overlapping is detected:
1. The database is cleared
2. The connection is closed in both sides (client and
server)
3. The IP of the attacker is entered into the "Black IP
list"
b. Verify that you have all the fragmented packets
i. If you have all packets – assemble the packets into one TCP
packet and send it to the server
ii. Else enter the packet into the database
4. After timeout – if we still have fragmented packets and we can't
reassemble them:
a. The packets are dropped
b. The database is cleared
c. The IP of the sender is entered the database of "suspected
Teardrop attackers"
d. If counter of IP in the "suspected Teardrop attackers" is reached
value of Y attacks:
i. The IP is entered to the "Black IP list"
ii. Removed from the "suspected Teardrop attackers"
iii. Connection closed in both sides (client and server)
5. Database
In our algorithms we use several databases:
1. Suspected Teardrop attackers
2. Black IP list
3. Suspected SYN attackers
This is an example of suspected databases:
IP address
Entrance
timestamp
203.0.2.1
12:04:23 PM
This is an example of black IP list database:
IP address
Entrance
timestamp
203.0.2.1
12:04:23 PM
Counter
3
In each of the databases we have a timeout, after which we remove the entry
from the database.
6. Timetable
21.11.2004 – 1.12.2004 – Design of classes (Low level design)
2.12.2004 – 2.1.2005 – Implementation + Unit tests
3.1.2005 – 15.1.2005 – Testing
16.1.2005
– Project presentation
16.1.2005 – 30.1.2005 – Final report preparation
30.1.2005
– Final report submission