Hi, When deploying a BSD with IPF in at the network perimeter and using rules like these: pass in .. proto tcp ... keep state(strict) it's possible to refuse tcp packets which arrive out of order. This would increase the difficulty doing blind attack resets and blind data injection attack, cause then you'd have to "guess" the exact expected number. Checpoint has a similar feature (is that right?) which is described here as the answer to the mentioned attacks: http://www.checkpoint.com/techsupport/alerts/tcp_dos.html Allthough this is nice, there is also the risk of breaking connection because it's not unlikely that packets arrive out of order. At least, that's what i think, any thoughts upon this? Bye, Mipam.
On Fri, Apr 23, 2004 at 03:17:32PM +0200, Mipam wrote:> Hi, > > When deploying a BSD with IPF in at the network perimeter > and using rules like these: > > pass in .. proto tcp ... keep state(strict) > > it's possible to refuse tcp packets which arrive out of order. > This would increase the difficulty doing blind attack resets and blind > data injection attack, cause then you'd have to "guess" the exact expected > number. Checpoint has a similar feature (is that right?) which is > described here as the answer to the mentioned attacks: > > http://www.checkpoint.com/techsupport/alerts/tcp_dos.html > > Allthough this is nice, there is also the risk of breaking > connection because it's not unlikely that packets arrive out of order. > At least, that's what i think, any thoughts upon this?IMHO, in the world of multihomed ISP's, BGP and multipath routing, no, it is definitely *not* unlikely that packets should arrive out of order. G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20040423/bcd91217/attachment.bin
In some mail from Mipam, sie said:> > Hi, > > When deploying a BSD with IPF in at the network perimeter > and using rules like these: > > pass in .. proto tcp ... keep state(strict) > > it's possible to refuse tcp packets which arrive out of order. > This would increase the difficulty doing blind attack resets and blind > data injection attack, cause then you'd have to "guess" the exact expected > number. Checpoint has a similar feature (is that right?) which is > described here as the answer to the mentioned attacks: > > http://www.checkpoint.com/techsupport/alerts/tcp_dos.html > > Allthough this is nice, there is also the risk of breaking > connection because it's not unlikely that packets arrive out of order. > At least, that's what i think, any thoughts upon this?My thoughts are that if the TCP on both ends is having trouble, it will eventually fall back and get packets through that match the state entries for "strict". I would not, for example, advise using "strict" for state connections where you intend on sending 100s of megabytes over fast networks,. In IPFilter, the "strict" applies to all TCP packets for a connection, not just the SYNs or RSTs. Darren