3

Many common firewall rules include a number of lines that block specific inbound traffic. Take this from ipfw for example:

# Fragments
$cmd 00420 deny all from any to any frag in via $pif

# ACK packets that did not match the dynamic rule table
$cmd 00430 deny tcp from any to any established in via $pif

At the end, however, one typically blocks anything that does not match any of the rules:

# Deny any other inbound traffic, with logging
$cmd 00998 deny log all from any to any in via $pif

# Deny any other traffic, with logging
$cmd 00999 deny log all from any to any

How would including the first set of rules bring any benefit if we are blocking all other traffic anyway as shown above?

Xen
  • 468
  • Related: BCP 38 – Michael Hampton Mar 15 '17 at 07:29
  • @MichaelHampton Thank you for your comment. I removed the rules with IP addresses quickly after posting since they were not meant to be there. I was already aware of source address spoofing. – Xen Mar 15 '17 at 07:41
  • Eh? I see that they are gone. Now the question isn't as clear. Are they not the rules you were asking about? – Michael Hampton Mar 15 '17 at 07:42
  • @MichaelHampton I wish to find out why many firewall rules include lines that block specific inbound traffic even though we drop all traffic that does not match at the end. – Xen Mar 15 '17 at 07:49

1 Answers1

6

I can't speak to ipfw, but in iptables it makes a lot of sense, as first dispositive match wins, and there are usually permissive rules between the explicit denies at the top and the blanket deny at the bottom (unless you're building a very, very quiet device!).

So eg if you explicitly want to exclude all Martians, you need to have lines like

iptables -A INPUT -s 10.0.0.0/8     -j DROP
iptables -A INPUT -s 172.16.0.0/12  -j DROP
iptables -A INPUT -s 192.168.0.0/16 -j DROP

before lines like

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP

because otherwise the ACCEPT line for ssh will permit the Martians before they ever see the blanket DENY.

Thanks to Michael Hampton for establishing that the same logic applies to ipfw rulesets.

MadHatter
  • 80,590
  • ipfw is similar, though it gives each rule a number, and the rules are matched in numeric order by the assigned number. – Michael Hampton Mar 15 '17 at 07:37
  • @MichaelHampton thanks for that! But having established the order, it also use first-dispositive-match-wins, yes? – MadHatter Mar 15 '17 at 07:39
  • That's correct. – Michael Hampton Mar 15 '17 at 07:41
  • Thank you, but this does not answer my question. It makes sense to block IP addresses that way since such rules would be ignored otherwise. I wish to find out why many firewall rules include lines that block specific inbound traffic even though we drop all traffic that does not match at the end. – Xen Mar 15 '17 at 07:48
  • 1
    That's exactly what this answer is about. Don't focus on the specific choice of rule used as an example; that matches the rules you first posted, then deleted, but the argument is not specific to those rules. It's that anything you want to blanket-ban you have to ban before you start permitting traffic in. Otherwise, traffic you'd prefer to ban, whether Martians or frags or whatever, that also matches any of your ACCEPT rules, will never make it to the blanket ban at the end, because that ACCEPT rule will let it in. – MadHatter Mar 15 '17 at 07:50
  • 1
    You could add also another use of the first few lines: block some things "quickly", ie without the fw having to evaluate a lot of rules on the same ip paquet before discarding it. (some attacks try to do denial lf services. they can often be blocked by having in the first line(s) a rule to discard their typical packets, as quicly as possible. (trivial exemple: you are flooded by 1 specific ip, you could add at the top of the list a line discarding any packet with that ip as source while the attack lasts) – Olivier Dulac Mar 15 '17 at 07:58
  • @MadHatter If a firewall (without specific denies) would let that kind of evil traffic through somehow, then I am genuinely surprised how it has not been documented properly anywhere (according to my knowledge). I would assume that only legitimate traffic that matches the allows is let through by default. Once traffic turns evil, it would no longer match these allows and end up denied (by final rule) regardless; you seem to believe that this is not the case, however? – Xen Mar 15 '17 at 08:05
  • @OlivierDulac Now, that would make sense! I wonder how much difference of an impact it would make in real world. – Xen Mar 15 '17 at 08:06
  • 1
    @Xen : it is really much faster to discard a packet with the first rule than the last one, as the packet infos don't have to be evaluated against any other rules. in practice it is not often easy to do (and dos is usually done from "random" ips, making my exemple moot. but some rule that specifically target only the attacking pattern (if there is one) can be put on top, and usually for efficiency (and d.o.s.) reason of course do not log and just drop those packets) – Olivier Dulac Mar 15 '17 at 08:12
  • @OlivierDulac I see that it would definitely serve a purpose then. I will consider it an answer to my question for now. – Xen Mar 15 '17 at 08:15
  • @xen: well, that and of course MadHatter's answer (for example indicating that you need to "narrowly"(/specifically) allow[or deny] some things before "broadly"(/globally) denying[or allowing] them. ex: allow incoming port xyz from specific ip, before closing all ports (or all port xyz) from all ips.B ecause packets are evaluated against each rule up to the first one that matches that packet (the following rules are not reached then, for that packet. only 1 line will be used for it, the first that matches) – Olivier Dulac Mar 15 '17 at 08:20
  • 3
    @Xen "I would assume that only legitimate traffic that matches the allows is let through by default" well, there's your problem: no such thing is true. A rule that says, eg, iptables -A INPUT -p tcp --dport 22 -j ACCEPT lets through all packets that reach it and match it, whether they're martians, unwanted frags, whatever. You're assuming the firewall logic is doing something it's not, which is why you're confused when people explicitly set rules to prevent "evil" traffic. – MadHatter Mar 15 '17 at 08:33
  • @OlivierDulac "it is really much faster to discard a packet with the first rule than the last one" do you have some kind of an up-to-date reference for that? I run iptables firewalls in production with several hundred rules, and we've never noticed this being a problem. – MadHatter Mar 15 '17 at 08:37
  • @MadHatter Thanks for your input. So, it would also be an addition to security by blocking the traffic before it even reaches the app. Now, I really wish there would be a list with rules such as these (that block fragments, et cetera) for me to study on. – Xen Mar 15 '17 at 08:47
  • @Xen yes, that is something like what I'm saying. I agree that such a list would be interesting to study, but one man's evil traffic is another's bread-and-butter (for example, internal firewalls I build often need to permit certain Martians, because they're inside networks where RFC1918 addressing is legitimately used). So it's quite hard to lay down hard-and-fast rules about what traffic is desirable, and what is not, why is why we have network administrators. – MadHatter Mar 15 '17 at 08:59