[j-nsp] Meaning of "except" in firewall filters

[Tore Anderson]

Hello,

* Dave Diller

> > Why not just do the boolean inverse:
>
> I use this as well, an accept term followed by a reject-all term, as
> it is easier/cleaner for someone not intimately familiar with how the
> clauses match to read this way, so I worry less abut people
> misinterpreting what I've applied on a casual run through.  Myself
> included ;-)  Much easier to debug, too, case in point.

I could've used two terms (as I wrote in the first email), like Kevin 
suggested.  However the fact that "except" didn't work as I thought 
made me curious, and I wanted to figure it out.  Besides, I personally 
prefer terse config files - why have two terms when I can have one?

> I use
>
>      from {
>          protocol tcp;
>          port ssh;
>
> Is there any particular advantage to either method?  I'm matching
> source OR destination port, and I really only need destination, so
> yours IS a bit more fine-grained...

This would allow an attacker to connect to any port on the device, by 
simply binding the source end of the TCP session to port 22.  The 
atttacker would need to have access to the SSH port to begin with, 
which makes it mostly an academic point I guess.

However, if you were to apply this to a device that was running, say, a 
load balancer with port 80 globally accessible, your way of expressing 
it would allow anyone on the internet to connect to the SSH service 
provided that they bothered to bind the source end of the TCP session 
to port 80.  This is a trivial thing to do, so in my opinion it's best 
to have a habit of always be as specific as possible.

Another thing is that «port» isn't supported on my EX series switches, 
there I have to use {destination,source}-port, so I might as well do 
that on my routers too so I can copy&paste the term from them.  Another 
thing that sucks about the EX series is that I can't figure out how to 
debug what's dropped in the firewall filters («syslog» isn't 
supported), so if I reject everything in the fallthrough term it's 
really hard to tell if I've forgot about something or not.  If anybody 
knows of a way to debug filters on the EX I'd be very grateful for any 
tips!

> >        then {
> >            log;
> >            reject tcp-reset;
>
> I've been using discard here.  Sure, it ties up MY resources as well
> as theirs, but I've also got "ssh rate-limit 10" so am not overly
> concerned (and I'm fine tying them up as long as possible).  Perhaps
> if it were a DDOS SSH attack I might start to notice...

I don't see how «discard» will tie up your resources?  «reject» (as well 
as «reject tcp-reset») will cause the router to generate a reply packet 
politely telling the client to sod off, so there's a (miniscule) 
processing overhead to it.  «discard», on the other hand, will just 
silently ignore the packet, so that's the option with the least 
overhead.  None of the alternatives will actually cause the RE to 
handle the SSH connection attempt.

> Curious about the effects of the various options, I just tried a few
> of them.
>
> 'Discard' gives a 90 second timeout and a "Connection timed out"
> error when you open an ssh connection.
> 'Reject' also gives a 90 second timeout but a "No route to host"
> error. 'Reject tcp-reset' gives an instant timeout and a "Connection
> refused", which makes sense given the RST.
>
> So I suppose it's just a philosophical difference - either way will
> keep them from opening a port, but do you want to keep them busy or
> just send them packing...

I don't think it matters much.  However, if you are only aiming to 
restrict SSH access but leave everything else open (like my example 
term), a connection attempt to a random port will yield a TCP reset.  
If a connection attempt to the SSH port yields something else (an ICMP 
destination unreachable or simply nothing), an attacker will be able to 
deduce that there most likely is an SSH service present, but that it is 
filtered.  If a connection attempt to a firewalled port yields the same 
result as a connection attempt to a closed port, you've denied the 
attacker that little piece of information.  Not saying that this is an 
effective attack mitigation strategy, but it might, depending on your 
level of paranoia, help you sleep slightly better at night.  :-)

Regards,
-- 
Tore Anderson