ipfw deny or reject - not just a matter of taste?

Hi,

  I think this is worth a note.
It was generally said the decision between deny and reject (aka
unreach) could be taken lightly - and most people seem to prefer
"deny", which complicates things for an attacker, because packets
just vanish without any report and tasks timeout.
But from my viewpoint, this argument falls into the category
"security by obscurity", and I found by preferring "unreach" I get
the advantage of intellegible errormessages appearing fastly, which
helps at least while developing and modifying. And so I am really
honest and put "unreach filter-prohib" in, which is just the truth
and ends in a "permission denied" message on the application side.

But now there is another matter here, and that should be taken more
serious. When, while developing/modifying the ruleset, applications
accidentally run into a "deny" rule, they will not notice it - the
packet is then just one that disappeared in transit, as it can happen
on the network, and the usual retry actions will apply or at least
the service should continue as soon as the ruleset is corrected.

But, when applications accidentally run into an "unreach" rule,
they may react in maybe unexpected ways. 

So I just noticed that syslogd, when configured for remote logging,
in this case logs an error of "sendto: Permission denied" locally with
severity syslog.err, and then CEASES TO SEND MESSAGES to that host
until it receives a kill -HUP.
And this is not funny, because we do not think we have trouble
when we do NOT get messages - just the opposite...

Maybe such things may already happen when reloading rules - that depends
on their sequence and individual layout. So it really is a good thing that
ipfw provides the atomic functions for shifting sets of rules.
Take care!

PMc
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"