42 lines
1.2 KiB
Plaintext
42 lines
1.2 KiB
Plaintext
|
****************************************
|
||
|
|
IMPORTANT NOTICE
|
||
|
|
****************************************
|
||
|
|
1)
|
||
|
|
|
||
|
|
If you're using this software and have a rule which ends like this:
|
||
|
|
|
||
|
|
flags S
|
||
|
|
|
||
|
|
(for TCP), then to make it totally effective, you need to change it to appear
|
||
|
|
as follows:
|
||
|
|
|
||
|
|
flags S/SA
|
||
|
|
|
||
|
|
The problem is that the old code would compare all the TCP flags against the
|
||
|
|
rule (which just has "S") to see if that matched exactly. It is very possible
|
||
|
|
for this to not be the case and in these cases, the rule would fail to match
|
||
|
|
a 'valid' TCP SYN packet.
|
||
|
|
|
||
|
|
Why does it need to be "S/SA" and not "S/S" ?
|
||
|
|
|
||
|
|
"S/S" will match the SYN-ACK as well the SYN.
|
||
|
|
|
||
|
|
By defalt, "flags S" will now be converted to "flags S/AUPRFS".
|
||
|
|
|
||
|
|
If you have any queries regarding this, see the examples and ipf(4).
|
||
|
|
If you still have a query or suggestion, please email me.
|
||
|
|
|
||
|
|
|
||
|
|
2)
|
||
|
|
|
||
|
|
If a filter rule used, in combination port comparisons and the flags
|
||
|
|
keywords, a "short" TCP packet, if not explicitly blocked high up in
|
||
|
|
the list of packets, would actually get matched even though it would
|
||
|
|
otherwise not have been (due to the ports not). This behaviour has
|
||
|
|
subsequently been fixed.
|
||
|
|
|
||
|
|
|
||
|
|
Darren
|
||
|
|
darrenr@cyber.com.au
|
||
|
|
****************************************
|