Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1059679 - RFE: Synproxy: auto detect TCP options
Summary: RFE: Synproxy: auto detect TCP options
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Jesper Brouer
QA Contact: xmu
URL:
Whiteboard:
Depends On:
Blocks: 1197809
TreeView+ depends on / blocked
 
Reported: 2014-01-30 10:51 UTC by Jesper Brouer
Modified: 2017-08-13 03:34 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-26 11:47:41 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jesper Brouer 2014-01-30 10:51:42 UTC
The iptables synproxy module, need to know the TCP options, of the backend-server, it is proxying TCP connection for.

This setup is currently a manual process, and only a single setting is supported per iptables rules.  This obviously suboptimal, as its it prone to errors, needs adjustments when changing backend-server, and does not scale to many hosts.  Most importantly it makes the synproxy module unusable in dynamic environment, like hosts using DHCP.

The task in the BZ is to implement automatic detection of the TCP options for each backend-server the module is proxying TCP connection for.

The solution; is actually quite simple.  I imagine that we simply extract the TCP options, based on the first seen 3WHS.  E.g. with the following flow:

 1. If TCP options of dest IP not in lookup-table
 2. then allow the SYN directly through, and listen for SYN-ACK response
 3. extract TCP options from SYN-ACK packet, and update lookup-table

Comment 2 Ramil Khantimirov 2014-07-10 08:16:13 UTC
Yes I have this problem and want it to be fixed.

Overmore, speed behind SYNPROXY is about 3 times slower even when all the parameters are matched manually.

Comment 3 Craig 2015-01-14 21:44:29 UTC
Hi,

Thanks for the SYN-Proxy! :)

I think this is a really important feature to have and probably not too hard to implement. Is there any timeline on this one? :)

Comment 4 Oguz Yilmaz 2015-02-12 07:50:40 UTC
Hi, 
I value this also as important. However, possible performance degradation of overall synproxy function should in minds. If performance degragation is possible this issue should be enabled by a sysctl.

Comment 5 Fred 2015-03-31 19:34:41 UTC
Very necessary, any timeline on this one ?

Comment 8 Saverio Giuntini 2015-04-28 10:06:34 UTC
This is really important, we are interested too.

Comment 9 Pavel Y Odintsov 2015-06-01 13:55:17 UTC
So interesting in this too!

Comment 10 Hannes Frederic Sowa 2016-07-22 14:17:13 UTC
We consider this bz obsolete since the upstream listener rewrite, which seems to unfortunately not hitting RHEL7 for the moment.

Comment 11 Steffen Weber 2016-08-11 11:29:02 UTC
Just out of curiosity: Are you referring to the TCP listener refactoring in Linux 4.4?

https://kernelnewbies.org/Linux_4.4#head-7c34e3af145ac61502d1e032726946e9b380d03d

Comment 12 Jesper Brouer 2016-08-11 11:55:59 UTC
(In reply to Steffen Weber from comment #11)
> Just out of curiosity: Are you referring to the TCP listener refactoring in
> Linux 4.4?
> 
> https://kernelnewbies.org/Linux_4.4#head-
> 7c34e3af145ac61502d1e032726946e9b380d03d

Yes, exactly.

This BZ would only be relevant if you are using synproxy on a firewall protecting servers behind it, what cannot be upgraded to use the listener scalability improvements, like Windows servers or old RH servers.

Comment 16 Fred 2016-08-26 14:13:44 UTC
It would be pretty nice if this could be improved/fixed, because exactly of this statment:

"This BZ would only be relevant if you are using synproxy on a firewall protecting servers behind it, what cannot be upgraded to use the listener scalability improvements, like Windows servers or old RH servers."

Which is our case for example, and from many other people as well. :)

Comment 17 Hannes Frederic Sowa 2016-08-26 17:04:28 UTC
The problem is that the backend servers (in case of old RH servers, probably also windows servers) will reconfigure their TCP options at will (e.g. syncookies or based on the tcp buffer sizes). So you end up in very strange to debug situations because the options of the synproxy don't fit to the options the backend server would assume.

Notice, that setting those options in case you know what options are supported by the backend is already supported.

Comment 18 Fred 2016-08-26 17:10:31 UTC
TCP Syn Cookies are great to know whether an IP source is valid or not, but TCP Contains "retransmission" of SYN Packets, so after you've tested it and it works good, why not letting the next syn retransmission to be direct sent or processed ? It would be a logical decision, considering it is a valid source IP that past the 3WH :) (So all options are preserved just fine).

Comment 19 Fred 2016-08-26 17:15:48 UTC
Just to be sure you've got it:

1) Are you under attack ? 
No. -> Pass the SYN Packet to the system.
Yes. -> Test the SRC IP w/ Syn Cookies challenge.
2) Did the IP pass the challenge test ?
No. -> Discard further processing/drop packets.
Yes. -> Allocate the IP into a hashtable, let the next SYN Packet pass direct (no proxying or intervention). So the options are preserved.

Just an example, since the IP has past the 3-way handshake, then you can safely store it somewhere and whitelist it in a way the IP can communicate with the local server or a remote server through forwarding... :)

Comment 20 Hannes Frederic Sowa 2016-08-26 17:42:25 UTC
In general your idea might flight. A few more questions:

(In reply to Fred from comment #19)
> Just to be sure you've got it:
> 
> 1) Are you under attack ?

Who determines if we are under attack? If the request queues on the backend system(s) are full? How do you check for that without holding state on the synproxy? Do you hold state per 2-tuple for the backend? How to determine the request queue is full?

> No. -> Pass the SYN Packet to the system.
> Yes. -> Test the SRC IP w/ Syn Cookies challenge.
> 2) Did the IP pass the challenge test ?
> No. -> Discard further processing/drop packets.
> Yes. -> Allocate the IP into a hashtable, let the next SYN Packet pass
> direct (no proxying or intervention). So the options are preserved.

In case of IPv6 I just can now list huge address spaces as trusted and then start a syn attack from those trusted IPs? In the end you end up in syncookie situation on the backend systems, which you could have done in the first place, no?

> Just an example, since the IP has past the 3-way handshake, then you can
> safely store it somewhere and whitelist it in a way the IP can communicate
> with the local server or a remote server through forwarding... :)

Thanks for your idea! If we can come up with a design on how to do that this could very well be interesting to implement. But so far I still have some doubts.

Comment 21 Fred 2016-08-26 17:47:24 UTC
>Who determines if we are under attack? If the request queues on the backend >system(s) are full? How do you check for that without holding state on the >synproxy? Do you hold state per 2-tuple for the backend? How to determine the >request queue is full?

Defined Request Rate or Forced Mode. (Since synproxy will handle this, the backend server will have no trouble at this mode).

>In case of IPv6 I just can now list huge address spaces as trusted and then >start a syn attack from those trusted IPs? In the end you end up in syncookie >situation on the backend systems, which you could have done in the first >place, no?

No, this must be stored per IP and if necessary to avoid small spoofed attacks using validated IPs, you can always use rate limiting in a firewall, that's not really an issue, except for packet intensive attacks, which aren't the issue here of course.

> Thanks for your idea! If we can come up with a design on how to do that this > could very well be interesting to implement. But so far I still have some > > doubts.

I've already done this myself in my own network stack using Intel DPDK, so yes this concept works fine, and preserves all the tcp options. :) (Thanks for RFC and for the TCP protocol design support this method).


Note You need to log in before you can comment on or make changes to this bug.