@ -4,14 +4,16 @@ A Linux netfilter module to help filter ts3init floods on TeamSpeak 3 servers
@@ -4,14 +4,16 @@ A Linux netfilter module to help filter ts3init floods on TeamSpeak 3 servers
TeamSpeak 3 servers are a popular (D)Dos target. They are harder to protect than
other servers because the TeamSpeak 3 protocol is based on UDP. A popular
method, that is hard to combat by hosters are called *init floods*. This is
method, which is hard to mitigate by hosters is called *init floods*. This is
where the attacker sends many connection request to the server, usually spoofing
the source address to make it harder to block them. The TeamSpeak 3 protocol has
an anti spoof check as the first stage of the connection, but the server program
can not keep up with the flood of packets.
the source address, to make it harder to block them. The TeamSpeak 3 protocol
has an anti spoof check as the first stage of the connection, but the server
program can not keep up with the flood of packets.
This set of plugins is designed to let the Linux kernel, or rather netfilter,
handle the anti spoofing stages of a new TeamSpeak 3 connection.
handle the anti spoofing stages of a new TeamSpeak 3 connection. This could be
done on a different machine than the one the TeamSpeak 3 server is executing
on.
How to install
==============
@ -29,14 +31,14 @@ When a TeamSpeak 3 client attempts to connect to a TeamSpeak 3 server, it sends
@@ -29,14 +31,14 @@ When a TeamSpeak 3 client attempts to connect to a TeamSpeak 3 server, it sends
out a *get cookie* packet. The server then replies with a *set cookie* packet.
This packet has some secret information about the connection details. The client
then response with a *get puzzle* packet. This packet includes the cookie that
it got previously. The server now validates this cookie and if its correct
continues with the rest of the connection packets.
it got previously. The server now validates this cookie and if it is valid, the
server continues with the rest of the connection packets.
This software packages comes with two netfilter match extensions, and three
netfilter target extensions which we will discuss next. Combined these
extensions and some other netfilter modules, can handle the initial connection
phase for a TeamSpeak 3 server. This prevents that any packet, with a spoofed
source ip address, to reach the TeamSpeak 3 server.
phase for a TeamSpeak 3 server. This prevents any packet, with a spoofed source
ip address, to reach the TeamSpeak 3 server.
Match extensions
================
@ -56,7 +58,7 @@ ts3init_get_cookie match options:
@@ -56,7 +58,7 @@ ts3init_get_cookie match options:
```
* `min-client` checks that the client version in the packet is at least the
version specified.
* `check-time` compares the UTC timestamp in the client packet to the UTC time
* `check-time` compares the unix-timestamp in the client packet to the unix-time
on the server. If they differ too much, the packet is not matched.
ts3init_get_puzzle
@ -67,7 +69,7 @@ from the client. There are additional parameters that can be set:
@@ -67,7 +69,7 @@ from the client. There are additional parameters that can be set:
$ iptables -m ts3init_get_puzzle -h
<..>
ts3init_get_puzzle match options:
--min-client n The sending client needs to be at least version.
--min-client n The client needs to be at least version n.
--check-cookie Check that the cookie was generated by same seed.
--random-seed <seed> Seed is a 60 byte hex number.
A source could be /dev/random.
@ -77,12 +79,12 @@ ts3init_get_puzzle match options:
@@ -77,12 +79,12 @@ ts3init_get_puzzle match options:
version specified.
* `check-cookie` matches if it matches the cookie that was generated in the
netfilter target extension `TS3INIT_SET_COOKIE`. To match the seed needs to be
exactly the same of course. It is possible to check cookies that were
generated on a different machine, provided that those machines have the same
date and time, and the same seed specified. In other words: The cookie is
created in a deterministic way, depending only on the current time and the
seed. If `check-cookie` is specified, either `random-seed` or
`random-seed-file` need to be specified too.
exactly the same. It is possible to check cookies that were generated on a
different machine, provided that those machines have the same date and time,
and the same seed specified. In other words: The cookie is created in a
deterministic way, depending only on the current time and the seed. If
`check-cookie` is specified, either `random-seed` or `random-seed-file` needs