1

My questions are:

1.) What is a recommended "SYN PROXY SERVER" to filter bogus SYN Attacks and only forward "handshaked" valid connections to the host behind it (to be protected). I search the term, but did not find any direct hits/products,preferably open source/free?

2.) If there are not "ready built" Syn Proxy Servers, how can I build my own (with iptables?)

3.) Are Syn Proxy Servers recommended and usefull? Does anyone have any experience with it? (I otherwise might youse syncookies...)

0

A SYN proxy server is nothing more than a bastion host that are setup to handle an awful lot of incoming half-built TCP connections, and only pass-off the completed ones. I honestly have no idea why you would use one; they're still vulnerable to failure by resource exhaustion (they've still got a finite amount of state space) and hence don't scale nearly as well as a good SYN cookie implementation.

Out of interest, can you share the source of your recommendation for a SYN proxy server?

| improve this answer | |
  • Good Question: It's germanies (at least amongst the real IT geeks;-) most renowned Computer magazine called "ct". I never heard of the term "syn proxy" but as they mentioned it, I thought this must be someting very important I have to check out... – Markus Aug 27 '11 at 19:59
  • 2
    Journalists are rarely the people you want to be relying on for technology advice. – womble Aug 27 '11 at 21:50
  • 1
    I disagree with this answer. A properly implemented SYN proxy has SYN cookie support, and this makes in invulnerably to failure by resource exhaustion. A good SYN proxy probably keeps state for TCP option support, but if this state is dropped, the most important information is encoded into the TCP SYN cookies. – juhist Dec 30 '17 at 18:30
  • 1
    The ultimate goal of any traffic cleaning solution such as a SYN proxy is to improve a network's resilience to attacks - in this case state exhaustion due to tracking of half-open connections by removing the need to track state for non-established connections. Many networks require a stateful firewall to protect their most vulnerable devices (IoT, BMS, etc.) and in this case you need to provision a SYN proxy in front of the stateful devices to prevent exploitation of their flow tables, so running SYN cookies on the endpoints themselves isn't a solution. – Terry Burton Dec 1 '18 at 10:36
  • 1
    @TerryBurton That's a very valid point (hence you got my upvote), but another way is to implement the SYN proxy in the stateful firewall itself. Then you need no separate SYN proxy middlebox, as the firewall itself has the SYN proxy. – juhist Aug 10 '19 at 19:08
3

You can substitute memory for CPU time by using a syn proxy which adds a secret to the socket address and computes a hash thereof which is used as the start sequence number of the server for the tcp connection.

No entries for half open connections will be added to the state table.

If a packet comes in (with the ack flag set)the acknowledgement number sent from the client minus 1 will be compared with the hash of the socket-address concatenated to the secret.

If the numbers don't match the packet will be dropped.

There is no limit on the number of half open connections only on the connection rate which depends on the CPU power.

| improve this answer | |
1

The important thing to understand is that the SYN-cookie allows the server to respond to the initial SYN without creating a flow-table entry; it uses up way less ressources and keeps your server online; performance increases of up to 20x are common!

You should really read these background articles; SYNPROXY is really worth a try.

http://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood-attacks-with-red-hat-enterprise-linux-7-beta/ https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html

| improve this answer | |
1

When this question was asked, there probably was no TCP SYN proxy with SYN cookies that was open source (there probably was OpenBSD's PF but it uses SYN cache instead of SYN cookies). Now, however, there is the netfilter SYN proxy: https://lwn.net/Articles/563151/

As an alternative to this netfilter SYN proxy, you can code your own. I have done that. My implementation is 9000 lines of main component code and 17 000 lines of supporting library code written in the C language. The line count includes very thorough unit tests. I won't recommend this "code your own" approach for production purposes, but if you have some spare time, coding your own SYN proxy may be a good way to learn a lot about TCP. I did my implementation in a bit over a month.

The netfilter SYN proxy apparently some time ago had a bug where TCP RST packet was not properly modified to be accepted by the host that opened the connection. So, if you managed to proxy the connection to the SYN proxy, but the other endpoint didn't accept it, the connection wasn't properly closed so that the initiating endpoint would notice it. I'm not sure if they have fixed the bug now.

As for my recommendation, I would recommend running endpoint hosts that have TCP SYN cookie support. That makes SYN proxy obsolete. If you absolutely have to run endpoint hosts that have no SYN cookie support, then SYN proxy may be a good idea. Also, if you run a firewall, it creates a new target for resource exhaustion: don't exhaust the resources of the endpoint host but instead exhaust the resources of the firewall. A firewall has no other way of protecting itself than a proper SYN proxy with SYN cookies. So, if using a firewall, do consider ones that have TCP SYN proxy support. OpenBSD's PF has SYN proxy with SYN cache that is vulnerable to an attack by resource exhaustion albeit not as vulnerable as a firewall not having SYN cache. Linux's iptables can be configured with the SYN proxy module in a manner that uses SYN cookies and thus is not vulnerable to an attack by resource exhaustion.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.