Question about firewall rule and RFC6092

A default policy (to drop) is a "rule" in itself because it describes behavior.

You're refering to configured behaviors - but I essentially agree.

That's where I kept loosing the other gentleman. Not design (e.g. on chip/code/firmware - modules add confusion, and I think that's the contention here).

So as far as you're concerned the functionality of filtering packets to determine whether to allow, drop, or reject them cannot be termed a 'firewall'?

I've read RFC2979 and it's not saying what you think it's saying. At no point does it say that a firewall is only a firewall if it passes no traffic. The point of the RFC is to discuss how firewalls should operate to maintain a suitable trade off between security and usability. The comment about firewalls being disabled is a reference to poorly designed firewalls still only being in use at that time because people were disabling them, rather than fixing the flaws in their design.

That doesn't sound like it blocks all traffic by default to me... Maybe it's not a firewall then??

What's the difference in final functionality between a rule that's configured and one that's hardcoded in firmware or in the SoC design?

And you keep 'loosing' me by insisting implementing a recommendation about how you should configure firewalls to filter traffic is something that could only be done by altering the IP stack or low level firmware coding. As if firewalls (of whatever type you think they are) can't be configured once they have been built/flashed. Oh, and the insistence that somehow OpenWRT doesn't have a firewall.

Yes, I'm lost why you quote the page then claim the opposite. We can all see it, you know.

  • Did you forget nothing is defined on the ASA, so that doesn't work by default, you need to say what interfaces, what's higher, etc.?
  • You ignored:

That's a firewall.

I'm lost why you had to make the firewall a router to attempt a point. Maybe that's because of misunderstanding what a firewall is. :wink:

  • So you switch to Layer 2 examples when it's clear we were discussing Layer 3?

I'm specifically referring to making a Linux device with IP Forwarding Enabled (i.e. a router), make the RFC recommended replies (or lack thereof). Yes, these are coded there.

Regarding firmware etc. - I'm refrencing how firewalls don't pass traffic, an opposite analogy is how the hardware switch in consumer routers acts dumb and passes traffic if there is software failure (e.g. bricked).

That would be horrible and unacceptable in a real firewall, yet it's seems livable if it happens in the forums.

Are you intentionally being dense? So now a firewall is only a firewall because it doesn't allow any traffic through because it's not been configured? If I deleted the interfaces or forwardings from OpenWRT it wouldn't pass traffic either.

And I didn't ignore that. It was irrelevant to the point I was making. Which is that the Cisco ASA (a true firewall according to you) has default functionality which passes traffic from a low security zone to a high security zone. The only difference is that you have to manually configure the interfaces first which is something OpenWRT is able to do on most (although not all devices) because they have 'specific' defined LAN ports and WAN ports.

No, it's just in the section I quoted.

What? Do you even understand what the recommendation in the RFC is? I appreciate it's quite a way up in the thread now but what do you think the recommendation is actually saying?

You mean like how OpenWRT doesn't pass traffic from the WAN to the LAN (unless you tell it otherwise)?

Unless it's programmed by Cisco it would seem.. But you haven't really answered the question. If I were to build my own OpenWRT image removing all the default UCI firewall rules apart from the default input/output/forward policies and removing any pre-configuration of interfaces, how in real usability terms would that be different to your fabled hardware firewall appliances? I'd still have to configure the interfaces, I'd still have to tell it in which direction is secure -> non-secure, and it'd still pass traffic from the LAN to the WAN but not the other way.

So, what is the difference?

  • Have you not been following? I guess not.
  • Now you're just being rude because you misunderstand, wow
  • Again, you're ignoring that your example requires you set it as a router for your point to be true, notwithstanding your remaining rant

OK, I see you're literally giving as an example: "imma set a firewall as a router just to disprove @lleachii "

If that makes you feel wiser and smarter after debaing a router was a firewall. Just seems silly to me you can't clealy see the error and irony in that juxtaposition.

Including the part you conveniently ignored to "prove your point" - whatever it may be.


No, again I'm lost why you keep reverting on things that were discussed, almost verbatim.

I literally provided suggestions to jow and explained how to make it more like a firewall. You offered the ASA documentation as an [poor] example that I failed to understand (aside you wanted it to be a router to prove your point). SonicWall is a another, I beleive they're owned and programed by D$ll.

I didn't get this chide.

Your question is unqualified, so I have no clue what you're asking about, unless the preceeding paragraph ranting about only Cisco (which you made up BTW) mean you discounted my post.

This has taken it's course. I don't see the reason to have been rude. But I thank you for the otherwise level discussion (aside from the discounts, this "now firewall is a router" game here, etc.)

You mentioned usability

  • for a router or firewall?
  • consumer devices or something else?
  • for a consumer or security engineer?

I'm lost at your term "fabled" - unless its another indication of your discount and rudeness.

Set what? OpenWRT? The ASA? If it's the latter then the default policy for transparent mode, i.e. when it's not routing, also allows traffic flows from a higher security interface to a lower security interface. It's got nothing to do with the ASA being a router.

I mean Cisco themselves even disagrees with your 'definition' that firewalls don't route:

For the avoidance of doubt, the important bit in that quote is Traditionally, a firewall is a routed hop and acts as a default gateway for hosts that connect to one of its screened subnets. I.e. the bit where Cisco is saying firewalls are traditionally routers...

How exactly do you think the fact you need to add additional rules to allow traffic flow from low security to high security supports your 'definition'? You said firewalls block all traffic. You then confirmed the ASA is a firewall by your 'definition' and as such it should block all traffic. My point was that it doesn't, by default, block all traffic because it implicitly allows traffic flows from high security to low security. That it doesn't allow it in the other direction doesn't change the fact it doesn't block all traffic.

Well then please tell me.

I'm asking you what would be the difference to an end user between using an ASA device with it's implicit permit rules and an OpenWRT device that only had the default LAN -> WAN forwarding and no other rules. Would there be a difference in what traffic is allowed into and out of their network? If so, what would that be? What would be the cause of that difference?

What did I make up? It's all taken from Cisco's own documentation.

Clearly you're playing games. So I'll answer- what you posted and we were discussing when I mentioned it and highlighted your error (kinda a duh moment to me, I cant see how that inquiry was genuine).

I didn't say that. It helps when you consider everything and don't ignore. Read clearly:

This is why I said just use one, berner literally said they were a stress to use, you bring up usability, but you're still lost?

I feel all firewalls are difficult to work with honestly, but its for security' sake. Your singleing out of Ci$co was confusing.

I'm also lost at why you relying on the IP Forwarding features (i.e. router) and their set directions on chip - but ignore the same nature.of the hardware, which is higher/lowered is not defined, etc. then ask how they're different, and even worse trying to act like that somehow disproves what I clearly explained twice now.

You acknowledged you understood then immediately started to be rude and insultuious and say ASAs arent firewalls and firewalls are myths or fables???

That confused me.

:spiral_notepad: if you were being facetious or sarcastic at some point to lead me into a response, maybe that's the confusing issue here, I was just honestly answering

You don't need to set the ASA as a router for it to pass traffic by default. I never said you did. If you think I did then you've misread/misunderstood.

Ok, let's assume you have just bought an ASA device. You want to put it in your network as a firewall. You don't want it to route, you just want to put it between your router and the internet so it's operating in transparent mode.

So you buy it, you connect an ethernet cable from your router to it and then another from the ASA to, let's just say, a ONT. It's now sat there doing nothing with no traffic flowing across it because it's completely unconfigured. Are we agreed on that?

Now we go into the ASA, presumably through serial as the ethernet interfaces aren't configured, and we configure the ethernet interfaces. We tell it the router side is high security and the ONT side is low security, but other than that we do the bare minimum. We don't add any firewall rules, policies, ACLs. We just leave it as close to default as is possible. Are we happy that is something we can do?

If we were to have done that, would hosts on the high security side be able to access hosts on the low security side? I.e. in this scenario would they be able to connect to the internet?

Thank you for nothing you have to enumerate an interface...but I think you're "going Cisco" on me.

:spiral_notepad: (I should note, there's a company, or used to be, named Adtran, thier firewalls were FW3/and perhaps UCI-based the last I experienced one, that's a much better example here!)

Your sarcasm implies a misuse of my RFC2979 quote, but of course!

I'm not sure of the reasoning for a Cisco-related question here, based proprietary Ci$co hardware level abstractions.

I honestly would feel uncomfortable giving a vendor-specific example. As you and everyone here would be - I too have more professional experience with FW3-based firewalls and other Zone-based ones (e.g. $onicWall).

(On a device thats not just some dumb switch - I hope this somehow doesn't imply some other vendor you now) I'm sure we should all kno how make the "interface", name zones, apply to zones, config forward direction, set any sysctrl or kernel parameters (e.g. IPv4 and IPv6 forwarding enabled, various IP timeouts), etc.

Because the device in the example is an Cisco device. One you were previously happy to state is a firewall and one of few models that meets standards.

Well could you give it a go anyway. Either traffic can flow because it has default rules or it meets your definition of a firewall and there will be no flow. So which is it?

But if you're really uncomfortable answering the question when it relates to a Cisco appliance could you suggest a SonicWall device that would meet your definition of a firewall and that we can use in place of the ASA for this example?

Although given that SonicWall's help documents also suggest default firewall rules are in place once interfaces have been configured (in this case LAN and WAN) I don't think it's really going to make much of a difference to the example.

And just to be really clear, the whole point of these examples and the questions I've asked is to hopefully get to the point where there's an acceptance that firewalls (from all sorts of vendors) do not, by default, block ALL traffic.

I accept they do if you haven't configured any interfaces, but that's not a realistic scenario or reason to call something a firewall. By that logic you could argue any device with two or more network interfaces is a firewall as long as you don't configure the interfaces.

However, once you've configured the interfaces (or zones in a zone-based firewalls) they have default or implicit rules to allow traffic to flow from LAN to WAN, or high security to low security, or trusted to untrusted. You can then add additional rules to allow or block specific traffic flows. And this isn't me saying that ALL firewall devices, software, appliances (whatever you want to call them) will have these default rules, but there are plenty out there (again from all sorts of vendors) which do.

Ok, so should the firewall take state into account? Maybe something like:

	chain forward_wan {
		icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, parameter-problem . admin-prohibited }   jump icmpv6_errors

	chain icmpv6_errors {
		ct state new                     drop
		limit rate 1000/second counter   accept

Closing this thread at the request of the OP.

1 Like