One of the key give aways can also be the total packet length: http://www.incidents.org/papers/OSfingerprinting.php
The first document a good read if you want to try to mimick another os. Active fingerprinting: http://www.l0t3k.org/security/documents/fingerprinting/ http://www.insecure.org/nmap/nmap-fingerprinting-article.html > Though you're right regarding what happens when a SYN+FIN for example > packet comes in...It would currently create state on a later rule as it's > not blocked with these ones. Of course such a SYN+FIN packet might be > valid according to the RFC's, which is why I wrote the rules the way I > did. I also used the flags in the block rules rather than the pass rules > to save having to add flags to each pass rule later on. Of course, if I > wanted to expand my flag blocking then I would need to add more block > rules like my flags A/A rule. i'm not sure how a syn+fin that isn't related to a current state is valid. If you keep state on all your (valid) connections then it's a matter of the timeout values. Sure you might end up blocking a syn+fin that is x seconds after the state was expired, in that case you adjust the timeout values. For an inbound connection only the S flag should be set (or perhaps ECN related flags.) For outbound if another more than than S is set chances are someone is up to no good ie a port scan. (This assumes you keep state.)
