Re: Syncookie firewall

Re: Syncookie firewall

[Don Cohen]

 > From: Henrik Nordstrom <hno@marasystems.com>
 > In my opinion, If you do "syncookie" in a firewall then the TCP should be 
 > terminated there, with another TCP in to the real server. I.e. a proxy 
 > solution.
Why do you think that's better than simply forwarding packets with
sequence/ack# translation?  Surely it's less efficient.  And it raises
questions about how much data to buffer between the two and how that
can be controlled.

Re: Syncookie firewall

[Henrik Nordstrom]

Don Cohen wrote:

> Why do you think that's better than simply forwarding packets with
> sequence/ack# translation?  Surely it's less efficient.  And it raises
> questions about how much data to buffer between the two and how that
> can be controlled.

Because there is no good way to know the servers TCP options before you have 
opened the TCP connection to the server, and you do not want to open the TCP 
connection to the server before the client has acknowledged the connection...

Adjusting the sequence numbers is the simple part of the picture. Does not 
worry me.. this is what the NAT engine is doing.

What worries me is

  * Window scaling
  * Timestamp
  * ECN

and a number of other end-to-end TCP options that depend on correct 
negotiation during SYN.

Sure, window scaling and ECN can be set by configuration if you know your 
server, but there is no good way to deal with the timestamp option short of 
forcibly filter it out entirely from the TCP stream.

Regards
Henrik

Re: Syncookie firewall

[Michel Banguerski]

Henrik Nordstrom wrote:
[...]

>What worries me is
>
>  * Window scaling
>  * Timestamp
>  * ECN
>
>and a number of other end-to-end TCP options that depend on correct 
>negotiation during SYN.
>
>Sure, window scaling and ECN can be set by configuration if You know Your 
>server, but there is no good way to deal with the timestamp option short of 
>forcibly filter it out entirely from the TCP stream
>

I agree that this is far from being trivial. And in fact, I'm almost interested inprotecting servers  known to me. That's why it seems mandatory to me to use a mach/target approach that allows one to define a fine graned policy about 
SynCooking, but this approach also allows to  implement a fallback policy: if
You don't know how to handle a particular TCP option, You pass the connection to 
the transparent proxying daemon (then You will need to stick with it, but CONNMARK 
will do the job ;o).

Thus hardconding tcp options in the ruleset seems aceptable to me.
 
Additionally it may be possible to have some autolearning behaviour 
using an
approach similar to "recent" match module: You start with no SynCookies, 
but
when You see a SYN-ACK packet from an inside machine You  add it to a 
list of
hosts with known TCP capabilities. The drawback of this approach is when You
have NAT inside Your own network: the same inside address seen by Your FW
may show different behaviours depending on who is behind, once agan, for now
I cant see other solutions than to hardcode in Your rulset the fact that we
dont want learn about this address.

In fact we can combine fallback/autolearn approaches: The daemon that 
 relays
connections unhandled by SynCookie, can BTW track servers capabilities and
install appropriate rules, this would avoid the complexity of automodifying
ruleset.


The timestamp case: I must confess, I'm not sure to fully understand how it
works, but it seems to me that the important decision to take at SYN packet
reception is to agree ot not on timestamping. Would it be really 
harmfull if
the first timestamp is not accurate (if You answer to the timestamp from 
the
firewall the RTT value calculated by the peer will be shortened be the RTT
inside your private net with is commonly short) ? If we can accept that, 
then
let's just do like for other options: setup rules where you accept 
timestamp
for particular hosts and reject for the rest.

Well, all this works if you protect your inside network from outside 
attacks,
but protecting outside from inside is way more difficult because you can't
gather and keep information about all servers that your users will 
potentially
connect to. But precisely because you better control on inside, may be 
outgoing
SynCookies are not such important: because it's easier to avoid 
spooffing on
your corporate network, throttling outgoing SYNs may be suffisent...


What are other TCP options that You think of ?

Regards
Michel


BTW: I'm not 100% sure but it seems to me that at least inversion 4.1
Checkpoint FW1 was rejecting by default packets with *ANY* TCP
option , and people were "happy" with that  :-)
(of course vendors lasyness is ont a good reason for doing bad design)

Re: Syncookie firewall

[Michel Banguerski]

Michel Banguerski wrote:
[....]

>
> BTW: I'm not 100% sure but it seems to me that at least inversion 4.1
> Checkpoint FW1 was rejecting by default packets with *ANY* TCP
> option , and people were "happy" with that  :-)
> (of course vendors lasyness is ont a good reason for doing bad design)
>
Ooops ! It was *IP* options, not *TCP*.
I'm sorry, plz don't falme ...

Regards
Michel

Re: Syncookie firewall

[Henrik Nordstrom]

Michel Banguerski wrote:

> The timestamp case: I must confess, I'm not sure to fully understand how it
> works, but it seems to me that the important decision to take at SYN packet
> reception is to agree ot not on timestamping. Would it be really
> harmfull if
> the first timestamp is not accurate (if You answer to the timestamp from
> the
> firewall the RTT value calculated by the peer will be shortened be the RTT
> inside your private net with is commonly short)

There is nothing "accurate" about TCP timestamps, but they MUST have the 
property that each new timestamp (per direction) must be >= the previous one, 
and not with a too big difference.

> If we can accept that, then let's just do like for other options: setup
> rules where you accept timestamp for particular hosts and reject
> for the rest.

Nope. What you can do is to

a) Not use it.
b) Make the connection to the real server, having it do all the option 
processing and generating a correct timestamp
c) Use a TCP proxy, terminating the original TCP at the firewall, allowing the 
firewall to do full timestamp processing.
d) Assuming you can hardcode in the ruleset that your server support TCP 
timestamping and it in fact does, Implement a TCP timestamp translation in 
conntrack/nat, having the firewall generate the original timestamp option and 
translate any future server timestamp options (including echo from client) to 
match the startingpoint set by the firewall.. a matter of simply learning the 
offset between the firewall generated timestamp and the SYNACK timestamp 
value from the server and then translate all server timestamps with this 
offset.

> Well, all this works if you protect your inside network from outside
> attacks, but protecting outside from inside is way more difficult
> because you can't gather and keep information about all servers
> that your users will potentially connect to.

And using a TCP proxy works just as good in both directions, and does not need 
to be very inefficient about it.. but is a bit costly in memory requirements 
due to TCP windows and reassembly.. but on the other hand it makes your 
firewall as strict as it's TCP implementation and fully protects servers from 
any kind of TCP abuse (your firewall TCP takes the hit).

Regards
Henrik

Re: Syncookie firewall

[Don Cohen]

 > Don Cohen wrote:
 > 
 > > Why do you think that's better than simply forwarding packets with
 > > sequence/ack# translation?  Surely it's less efficient.  And it raises
 > > questions about how much data to buffer between the two and how that
 > > can be controlled.
 > 
 > Because there is no good way to know the servers TCP options before
 > you have opened the TCP connection to the server, and you do not
 > want to open the TCP connection to the server before the client has
 > acknowledged the connection... 
Fortunately, all of these options are ... optional, so the firewall 
can, if it doesn't know better, simply not use them.

 > Adjusting the sequence numbers is the simple part of the picture. Does not 
 > worry me.. this is what the NAT engine is doing.
 > 
 > What worries me is
 > 
 >   * Window scaling
It would be unfortunate to lose this in some cases, but those are the
cases where the firewall is likely to know what sort of window scaling
is supported by the server.

 >   * Timestamp
 >   * ECN
 > 
 > and a number of other end-to-end TCP options that depend on correct 
 > negotiation during SYN.
 > 
 > Sure, window scaling and ECN can be set by configuration if you know your 
 > server, but there is no good way to deal with the timestamp option short of 
 > forcibly filter it out entirely from the TCP stream.

The timestamp option is not a problem in this case.  The firewall only
responds to a few packets and for those it can supply its own
timestamp (or not).  After it establishes both halves of the
connection it just forwards the packets and the timestamps (seems to
me) should work out fine.

Re: Syncookie firewall

[Henrik Nordstrom]

Don Cohen wrote:

>  > Because there is no good way to know the servers TCP options before
>  > you have opened the TCP connection to the server, and you do not
>  > want to open the TCP connection to the server before the client has
>  > acknowledged the connection...
>
> Fortunately, all of these options are ... optional, so the firewall
> can, if it doesn't know better, simply not use them.

To ensure interoperability you must also filter out any options on future 
packets of that TCP not known to be 100% compatible with your SYN+ACK.

> The timestamp option is not a problem in this case.  The firewall only
> responds to a few packets and for those it can supply its own
> timestamp (or not).  After it establishes both halves of the
> connection it just forwards the packets and the timestamps (seems to
> me) should work out fine.

The timestamp option must be real all the time, or never. You cannot suddently 
switch TCP timestamp source in the middle of a TCP connection. Doing so will 
serverely break PAWS.

Note: The TCP timestamp option is not the same as the IP timestamp option. TCP 
timestamps has nothing to do with time, only the progress of relative time 
within a TCP.

Regards
Henrik

Re: Syncookie firewall

[Mark Atwood]

Henrik Nordstrom <hno@marasystems.com> writes:
> 
> To ensure interoperability you must also filter out any options on future 
> packets of that TCP not known to be 100% compatible with your SYN+ACK.

Widespread deployment of this advice will condemn every future TCP
improvement to the hell that ECN is in today.

-- 
Mark Atwood   | Well done is better than well said.
mra@pobox.com | 
http://www.pobox.com/~mra

Re: Syncookie firewall

[Don Cohen]

Henrik Nordstrom writes:

 > > Fortunately, all of these options are ... optional, so the firewall
 > > can, if it doesn't know better, simply not use them.
 > 
 > To ensure interoperability you must also filter out any options on future 
 > packets of that TCP not known to be 100% compatible with your SYN+ACK.

There is no need to do anything but send syn and syn/ack without any
options that might be incorrect for the other participant.
Then it's incorrect for the other side to send them in later packets
so there's nothing for you to filter.  If the participants want to
violate the spec it's not the responsibility of the firewall to
prevent them.

 > > The timestamp option is not a problem in this case.  The firewall only
 > > responds to a few packets and for those it can supply its own
 > > timestamp (or not).  After it establishes both halves of the
 > > connection it just forwards the packets and the timestamps (seems to
 > > me) should work out fine.
 > 
 > The timestamp option must be real all the time, or never. You
 > cannot suddently switch TCP timestamp source in the middle of a TCP
 > connection. Doing so will serverely break PAWS.

Now that I reread rfw1323 I see that timestamps also are not allowed
unless they appear in the first segment.  So again the general
solution is not to send it.
(Once again I think the "solution" is to change the spec.)

In any case it's sufficient for the firewall to simply not send any 
timestamp options at all.

Syncookie firewall

[Don Cohen]

 > From: Michel Banguerski <Michel.Banguerski@laposte.net>

 > I came across your posing on netfilter-dev
I must have missed it, but I assume the idea is that firewalls should
reply to syn's with cookies and forward the connection only when it
gets the ack. 
I also have thought this would be a good idea.  
You'll see my lines of thinking below.  

First, a problem:
There are some tcp options that have to be sent in the syn packet, 
e.g., window scale.  These become unusable if this packet is supplied 
by the firewall, unless the firewall somehow knows how the original
destination host "would have" answered.  This seems unfortunate, and 
I don't see a good solution.
(Actually, I think the solution is to change the protocol to allow 
those options in later packets!)

Now on to the interesting stuff.

You're probably thinking in terms of defense against syn flooding
here, but I'm also interested in defenses against some more subtle
attacks.  In particular, I want to prevent packet floods from going 
through the firewall.  Here's an initial solution:

rate limit all packets other than tcp packets that are part of
established connections 

The rate limit can be quite small, just enough to accomodate normal
syn, icmp and udp traffic.

This limits both incoming and outgoing floods to the rate limit above.

But here's a way to defeat that defense.  Suppose the attacker
controls a zombie on the inside that he wants to use to flood someone
on the outside.  He also controls a machine on the outside.(*)  He can
use the outside machine to send a packet to the zombie with the
spoofed source address of the victim.  Now the zombie replies to the
victim.  Furthermore, the outside machine, knowing what the zombie
will do, can send the ack to convince the firewall that the connection
is established and now the zombie can send to the victim without the
rate limit.

(*)Yes, he could use that outside machine to attack directly, but
this solution causes the attack to come from your network and also
requires very little bandwidth from the outside machine, so that one
outside machine could allow lots of different zombies to attack. 

If instead the firewall replied to the first syn, the outside machine
wouldn't be able to send the correct ack in order to establish the
connection.  (The attacker presumably can't predict the sequence
number the firewall will use, and he can't observe it since it's sent 
to the victim.)

However, it turns out this is not good enough.  Here's a similar
attack.  Again the outside machine and the zombie are in cahoots.
This time the zombie sends the syn to the victim.  The firewall
replies with the cookie and the zombie replies.  Now the firewall
forwards the syn to the victim.  (I don't want to deal with any
replies from the victim here.  Suppose it's not replying to these 
packets.)  But now the outside attacker can spoof the syn-ack
since it knows the zombie's sequence number!  And again, it can
send more spoofed acks if the firewall is checking for that sort
of thing.

The solution is a slight extension to your scheme.  You're already
keeping one sequence number offset.  You just have to keep two, one 
in each direction.  That is, instead of

client			 FW		     server
       -> seq#A
       ack#A, seq#B <-
       -> seq#A, ack#B
				-> seq#A
make this last one
				-> seq#C

Here C is a random number generated by the firewall.  The important 
thing is that B can only be observed on one side of the firewall and
C can only be observed on the other.  Now the outside attacker again
does not know what sequence number went to the victim and can no
longer send the right ack.

 > Questions that i have no answered yet:
 >  -  What to do if the server is down
That's a good question.

 >  -  How to avoid breaking nat
Clearly can be done, even if the best way is not obvious

 >  -  Is there a trick that could allow us to not to store context before
 >     receiving the third ack from the server
Isn't this just what happens now?  The syn simply elicits a cookie,
all else is done when the ack arrives.
The changes I see are
- for some reason syn cookies now seem to be used only when there's a
long syn queue - should be always
- they're used (I think) only for the local machine, have to be used
also for forwarded packets (which seems to break the boundary between
IP and TCP, doesn't it)
I'd be interested in delaying the processing of the syn-ack (and other
conntrack stuff) to even later - when it's apparent that the packet is
actually going to be forwarded.  This matters to me because of my rate
limiting.  You may recall I raised that issue on this list before.

 >  -  What are pitfalls i've missed.
The problem at the top is one.

Re: Syncookie firewall

[Henrik Nordstrom]

Don Cohen wrote:

> There are some tcp options that have to be sent in the syn packet,
> e.g., window scale.  These become unusable if this packet is supplied
> by the firewall, unless the firewall somehow knows how the original
> destination host "would have" answered.  This seems unfortunate, and
> I don't see a good solution.

Not to mention that there is TCP options a firewall cannot know, such as the 
timestamp option.

In my opinion, If you do "syncookie" in a firewall then the TCP should be 
terminated there, with another TCP in to the real server. I.e. a proxy 
solution.

Regards
Henrik Nordström

Syncookie firewall

[Michel Banguerski]

Hi Frank,
Hi all

I came across your posing on netfilter-dev of and i share your
opinion that it would be a cool feature for linux-based firewall.

I'd be glad to hear from you that you still want to implement
this and i'd like to participate.

As I didn't fond anything about your proposal being developped
in the list, i'll continue from this old one

Here are my ideas about to how to do it.

- This should be implemented as target/matching module to allow
people to select connections they want to protect with this feature.

- The modules we could use as examples are the REJECT target
because it generates a new packet and the CONNMARK target
because it stores data in the connection context. Window tracking
patch because it deals with SYN and ACK values.


Working principle(with variations):

0) we match the new incomming syn packet with conventional syntax

1) The COOKIE target will drop the incomming SYN packet and
    generate the reply synack packet with the cookie.
    usage: -j COOKIE --syn

2) The  cookie match module (-m cookie) or the extention of the
   state module (-m state --state COOKIE) will match the third packet
   of the handshake.

        Possible feature: several classes of cookies using different
        "salt" in the crypto funtion allowing following
        "-j COOKIE --syn --class xx" and then "-m cookie  --class xx yy"

        where xx is an integer and yy is a mask.  This feature would
        probabely require a separate matching module.
        Beware that lots of classes will weaken cookies.

3) The COOKIE --synack  target will register the connection and store
the
   cookie we sent (which came came back), we need this because the
server
   will answer with it's own ACK number that has to be incremented by
the
   cookie-offset. Then this same target will generate the syn packet
sent
   to the targeted server.

2)+3) usage:
    -m cookie --state SYN -j COOKIE --synack
or
    -m state --state COOKIE -j COOKIE --synack

4) Now we need either a couple of module/target  to match the synack
packet
   comming back from the server to send it back  the ack:
    -m cookie --state  SYNACK -j COOKIE --ack
  (and in this case the cookie module would get the option --syn in step
2).

  or extend the conntrack/ACCEPT code to do this silently and declare
the
  server's synack packet as established:
    -m state --state ESTABLISED -j ACCEPT (this one would be good for
                                performance, but see unanswered quetions
below)
  or
    -m state --state COOKIE2 -j COOKIE --ack

5) Remaining packets will need to fix their SYN/ACK values because of
the
   initial cookie. Again we need to decide between extending conntrack
   and creating dedicated match/target.
   Extending module would lead to simply have
       -m state --state ESTABLISED -j ACCEPT
   Using dedicated match/target
       -m cookie --state ACK  -j COOKIE --fix


Questions that i have no answered yet:
 -  What to do if the server is down

 -  How to avoid breaking nat

 -  How to handle the ACCEPT target if we extend conntrack code to
        deal with the third packet from the server and declare it
ESTABLISHED

 -  Is there a trick that could allow us to not to store context before
        receiving the third ack from the server

 -  What are good(clear) names for matches/targets options: the sequence

        (--syn), (SYN => --synack), (SYNACK => --ack), (ACK=> --fix)
        is logical, but may be misleading

 -  What are pitfalls i've missed.


Sorry for my poor english

Best regards,
Michel