[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Iptables + Squid



On Fri, Aug 03, 2007 at 01:05:52PM +0200, Ansgar -59cobalt- Wiechers wrote:
> On 2007-08-02 Franck Joncourt wrote:
> > On Thu, Aug 02, 2007 at 10:49:51PM +0200, Ansgar -59cobalt- Wiechers wrote:
> >> On 2007-08-02 Franck Joncourt wrote:
> >>> -m state --state NEW --syn rather than --syn
> >> 
> >> "--syn" is kinda redundant when using "--state NEW". ;)
> > 
> > You are wrong. Try to send a packet with the ACK flag sets and the
> > others cleared ; therefore you will be able to match those packets with
> > this rule :
> > 
> > iptables -A INPUT -p tcp -m state --state NEW \
> > 	--tcp-falgs SYN,FIN,RST,ACK ACK -j RETURN
> > 
> > http://iptables-tutorial.frozentux.net/iptables-tutorial.html#SYNACKANDNEW
> 
> Instead of adding a --syn to the ACCEPT rule I'd rather add a REJECT
> rule as described in the article you mentioned to protect against
> spoofing.
> 

The above link discribes protection against spoofing in the
"SYN/ACK and NEW packets" section.
As a matter of fact sending a SYN/ACK packet to my server is known to be
in the INVALID state and not in the NEW state as they mention. However,
I do not know anything about sequence number.
Assuming it works on the NEW state, it is fine to prevent our ip from being
spoofed.

In the other section, just above the last one (State NEW packets but no
SYN bit set), they talk about :

iptables -A INPUT ! --syn -m state NEW -j DROP

So, packets with only the ACK flag set will match the rule, and
therefore will be dropped (or rejected).

As you said, it would be better to work this way, rather than using the
_--syn_ option for every NEW TCP connection I want to allow.
I do not do this because I did not want to play with flags before,
except with the syn option, but I will do :p!

So we put the syn option into the bin, and add a new rule to drop NEW
not SYN packets, avoiding useless processing. It looks good !

-- 
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

Attachment: signature.asc
Description: Digital signature


Reply to: