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
Dag-Erling Smørgrav
2005-Feb-28 15:34 UTC
ipfw deny or reject - not just a matter of taste?
Peter Much <pmc@citylink.dinoex.sub.org> writes:> 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.Look for 'ipfw set' in the ipfw man page. DES -- Dag-Erling Sm?rgrav - des@des.no