Re: grouped tcp flags
> > Agreed, but a quick block on some of the common nmap flags on the very top > > of your ruleset can save you some time (right?) Esp. when somebody went mad, > > has a big pipe and found out about insane-nmap timeing. > > *sigh* > > And all other tcp packets (which are most likely to happen more often) > evaluate through all that shit every time? Great gain after all, eh? > I didn't test/benchmark/analyse it ... did you? It's just a bitmask afterall. max
Re: grouped tcp flags
On Tue, Apr 01, 2003 at 08:37:52AM +0200, [EMAIL PROTECTED] wrote: > > flags = flags ( flag-set / flag-set | / flag-set ) > > flag-set = [ F ] [ S ] [ R ] [ P ] [ A ] [ U ] [ E ] [ W ] > > this is wrong.. who wrote that shit? :) The first part of the RHS is the literal "flags" (the token, keyword), so that would be > flags = [ flag-set ] / flag-set flags = "flags" [ flag-set ] "/" flag-set (did we start quoting some things yet?) Daniel
Re: grouped tcp flags
On Tue, Apr 01, 2003 at 04:15:55PM +0200, Philipp Buehler wrote: > [list added again, I think this is public interest and should be archived] > > On 01/04/2003, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]: > > I just wanted to drop all nmap and/or other harmful packets... I found half > > of this list of flags @ nmap's forums by a guy saying which to block to stop > > nmap, the other half I found on a sans.org site... I'll try to dig up a link > > if you want it. Which flags do you recommend blocking? # block and log nmap OS fingerprinting attempts # block return-rst in log quick on $ext_if proto tcp all flags FP/FP block return-rst in log quick on $ext_if proto tcp all flags SE/SE
Re: grouped tcp flags
On 01/04/2003, Max Laier <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]: > > If you dont want port XYZ being reached. Block it. Completly. No > > matter what fuxxored flag ever is set. Period. > > > > Agreed, but a quick block on some of the common nmap flags on the very top > of your ruleset can save you some time (right?) Esp. when somebody went mad, > has a big pipe and found out about insane-nmap timeing. *sigh* And all other tcp packets (which are most likely to happen more often) evaluate through all that shit every time? Great gain after all, eh?
Re: grouped tcp flags
> If you dont want port XYZ being reached. Block it. Completly. No > matter what fuxxored flag ever is set. Period. > > //pb > Agreed, but a quick block on some of the common nmap flags on the very top of your ruleset can save you some time (right?) Esp. when somebody went mad, has a big pipe and found out about insane-nmap timeing. max
Re: grouped tcp flags
[list added again, I think this is public interest and should be archived] On 01/04/2003, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]: > I just wanted to drop all nmap and/or other harmful packets... I found half > of this list of flags @ nmap's forums by a guy saying which to block to stop > nmap, the other half I found on a sans.org site... I'll try to dig up a link > if you want it. Which flags do you recommend blocking? First off: nmap is dumb Furthermore, *most* people using nmap are completly clueless about what is happening - and to make it worse: nmap interprets packets coming back (or not) in a very "special" way. Let's say, it tries to think for the user. After all they see an output of closed/open/filtered ports which is *way often* not even *close* to reality. Please think it through .. all this 'hiding' is totally silly and useless. Think about they get a response (or not) which is interpreted as XYZ/tcp filtered Now what? Can they do something harmful w/ FUP on port XYZ there? Can they even create a *valid* connection to there for carrying payload UP THE STACK WHERE IT WOULD HURT? Geeez.. If you dont want port XYZ being reached. Block it. Completly. No matter what fuxxored flag ever is set. Period. //pb
Re: grouped tcp flags
On 01/04/2003, jared r r spiegel <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]:
> > will
> > the following work? Does pf syntax allow this?
> >
> > BadTCPFlags="{ FUP, FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRAU, P, \
> > FS/FS, FSRPAU, /FSRPAU }"
> >
> > block in quick proto tcp all flags $BadTCPFlags
no (geeez!).. dont overdo this flag shit, mmkay?
> flags = flags ( flag-set / flag-set | / flag-set )
> flag-set = [ F ] [ S ] [ R ] [ P ] [ A ] [ U ] [ E ] [ W ]
this is wrong.. who wrote that shit? :)
flags = [ flag-set ] / flag-set
(Daniel, ok? :) )
//pb
Re: grouped tcp flags
> will
> the following work? Does pf syntax allow this?
>
> BadTCPFlags="{ FUP, FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRAU, P, \
> FS/FS, FSRPAU, /FSRPAU }"
>
> block in quick proto tcp all flags $BadTCPFlags
hi adam.
i made only a slight modification to this: namely inserted
'on fxp0' ( external iface ) between 'quick' and 'proto',
as i didn't want to decapitate my putty session; and pfctl yelled
at me with a syntax error. ( i had a new pf.conf with only your
lines above, to keep it clean ).
i tried reducing BadTCPFlags down to = "{ S/SA }", and that
also got an error.
so, the flags thing seems to not like the '"{' '}"' action,
as i just hardcoded that also into the line ( S/SA ) and it
bailed on me too.
i tried without the braces, and got the same. checked the
manpage:
flags = flags ( flag-set / flag-set | / flag-set )
flag-set = [ F ] [ S ] [ R ] [ P ] [ A ] [ U ] [ E ] [ W ]
i've noticed the pf.conf manpage is really good about letting
you know if you can get away with braces and things like that, they're
almost always in the sytax somewhere. to me, this means that
'flags' has a syntax of :
flags flag-set/flag-set
or
flags /flag-set
( where obviously flag-set is some combination of those letters )
if braces were chill, i'd expect to see something more like how
protoset and proto-list say: 'ok, put a name or a number, or a list',
and then defines a list as a string of names/numbers and mentions the
'[ , ]'. usually if i don't see a '[ , ]' in the construct somewhere,
i assume pfctl will yell at me.
so short answer, no, didn't work from over here.
jared.
Re: grouped tcp flags
I'm not in a situation where I can test it quite yet, I'm coming up with a firewall rulelist I won't be able to implement for another month or so @ my workplace. Home dialup (aol email as you can see) isn't obsd compatable :P I live out in the sticks... no play around time work lately to test a ruleset. Sorry, but unless I can find a friend who can test it out first, I won't be able to know or report any results... frustratingly few people know about openbsd though. Any help would greatly be appreciated. Adam Wenzel
grouped tcp flags
Is it possible to explicitly deny specific incoming tcp flag possibilities as a single variable? I know I could set up ten different rules, but I understand this may run quicker, even if the difference isn't noticable it seems much cleaner. It's hard to ask the question... in other words, will the following work? Does pf syntax allow this?
BadTCPFlags="{ FUP, FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRAU, P, \
FS/FS, FSRPAU, /FSRPAU }"
block in quick proto tcp all flags $BadTCPFlags
TIA,
Adam Wenzel
