> > I don't see where control of the SYN bit helps in getting rid of
> > doubleclick,
>
> Consider this:
>
> ipchains -A output -y -d ad.doubleclick.net -j DENY
>
> or, in plain english (for anyone not familiar with IPchains syntax):
> deny all outgoing packets to ad.doubleclick.net that have the SYN bit
> set.
>
There's no need to specify the SYN bit, though, since you don't want any
connection to doubleclick. Hence my statement. I should have better said,
"...control of the SYN bit specifically helps..."
> > The sender completes the three-way handshake with a 'standard' TCP
> > segment,
>
> This third packet in the three-way handshake is ACK SYN ACK (though I'm
> not 100% sure how it differs from the second packet [ACK SYN]), after
> which, like you said, the actual data traffic begins.
>
How can it be ACK SYN ACK, when there is only one ACK bit in the TCP header?
And I'd like to refer you to chapter 3.4 and figure 7 in RFC 793, which
depicts the basic three-way handshake. Only the first two TCP segments have
the SYN bit set, i.e. the first one going from A to B and the first
response, travelling from B to A. After that, the SYN bit is seen no more.
> > Now, the second segment in this sequence, i.e. the first one
> > travelling from connection recipient to original sender *has the SYN
> > bit set*. So, [snip] then you'd effectively block this second segment
> > of the three-way handshake [snip]
>
> Ah, true. Didn't think all the way through it. So, to make (rational)
> use of denying packets with SYN bit set you really should make the rules
> based on IP/netmask and/or traffic direction instead of denying to/from
> everywhere.
>
I believe it is good practise to make rules as specific as they can be, and
that it helps in achieving maximum effect.
Cheers,
Tobias
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
