Lets talk about firewalls - what do we as a group think a firewall should be/have?

A FW should be able to filter traffic based on the OSI model.

A FW should be able to set protocol filtering rules beyond TCP or UDP. It should be able to filter both inbound or outbound traffic by protocol numbers given.

If its a host based network FW solution, then it must be using two NIC's. One NIC must face the WAN the untrusted zone and the other NIC must face the LAN the trusted zone.

This holds true for a FW solution that is an appliance I believe. That in its Admin interface, it must show the untrusted and trusted zones.

Duane :)

After seeing what you are wanting as defaults, I think we should keep in mind that fire walling devices are targeted at different market segments. Thus I propose that we come up with an agreed upon definition of what a firewall should be based on different levels of security provided. I.e.

Level I - Basic SOHO firewall - open defaults Level II - Moderate firewall - open defaults Level III - Moderate firewall - closed defaults Level IV - Advanced firewall - closed defaults Level V - Level IV plus special security considerations

That is just a suggestion, but I think it will help us come to agreements easier if we classify firewall definitions based on what their target market might be.

These are the features that I would EXPECT to see in a basic firewall.

- (for all applicable rules) The ability to allow / drop / reject packets. - (for all applicable rules) The ability to allow / drop / reject packets based on previous state of a flow. - Filter based on direction of flow. - Filter based on the physical interface the packet came in / is going out. - Filter Layer 2 data at Layer 2 of the OSI model. (MAC) - Filter Layer 3 data at Layer 3 of the OSI model. (IP) - Filter Layer 4 data at Layer 4 of the OSI model. (Protocol) - Filter Layer 5 data at Layer 5 of the OSI model. (Session / State) - Filter Layer 7 data at Layer 7 of the OSI model. (Blocked URL) - Clear concise logging. - In band communications with firewall.

These are the features that I would WANT to see in a basic or better firewall.

- (for all applicable rules) The ability to allow / drop / reject packets. - (for all applicable rules) The ability to allow / drop / reject packets based on previous state of a flow. - (for all applicable rules) The ability to allow / drop / reject packets based on recent history (sliding window). - Filter based on direction of flow. - Filter based on the physical interface the packet came in / is going out. - Filter based on the logical sub-interface the packet came in / is going out. - Filter any layers data at any layer. - Clear concise logging. - In band communications with firewall. - Out of band communications with firewall. - The ability to capture traffic for later analysis. - Good default configurations for multiple types of environments. - The ability to alter a packet as it passes through. - The ability to transparently bridge packets. - Redundancy - Clustering / hot fail over.

(more to come)

Let's also reserve thought's opinions about what other people expect / want until later.

Grant. . . .

I like the idea, but I think we'll get off on to many tangents instead of the definitions of what we want. I expect that we'll get into to many (to may posters) will argue about what makes level 1,2,3,4... instead of what we want as a firewall.

I'm sure that we'll get to a few layers of basic devices:

I think that home users fall into a category below SOHO, as many SOHO users are also home users, they also have many security needs that Home users don't have/need.

Ok, agreed. I'll change my suggested level definitions to be:

Level I - Basic (self explanatory) Level II - Intermediary (any thing that is not basic or advanced) Level III - Advanced (self explanatory)

This can all be filtered out after we collectively what we want to be in a firewall.

Grant. . . .

Yes.

Not necessarily. If the firewall is supposed to filter on layers above OSI layer 4 it should, otherwise it shouldn't, so I'd consider this optional rather than required.

Only if the firewall is supposed to provide VPN endpoint functionality. Not everyone needs this, so I'd consider this optional as well.

I agree to a point. Each interface of a firewall should be distinct from each other. However, a firewall does not necessarily need more than two interfaces, so a "DMZ interface" is not a requirement.

I'd rather summarize this with points 1) and 2) to "A firewall should by default deny all traffic between all interfaces."

Yes.

Intrusion detection is a two-edged sword as it may consume a considerable amount of resources. I wouldn't consider this a requirement for any firewall. Even if a firewall included an IDS it should IMHO be disabled by default. And automatic network shunning ("block those attack origination locations") is still a REALLY BAD IDEA and should NOT be done AT ALL, much less be a default.

See above. I'll agree that a firewall admin should be able to create such rules, but they're dangerous and should be used with caution.

I'm not sure I understand what you mean by that.

Make that "any service on any interface". One reasonable exception may be a service providing a (secure) configuration frontend on one distinct interface, that is marked as such (see also below).

That only helps your legal department. If you think you need that: fine, but it's most definitely not a technical requirement for a firewall.

I'd like to add:

cu

We're talking a firewall, strictly a firewall, something that can be used in all cases. We'll brake down the features into Home/SOHO/etc... later.

We're talking a firewall, strictly a firewall, something that can be used in all cases. We'll brake down the features into Home/SOHO/etc... later.

I would too, but you know that someone would have an issue if I didn't state it - since too many of the devices on the market don't have real DMZ's and are just a IP in the same network as the LAN.

I wasn't thinking of IDS when I wrote the above, but it should be able to detect various threads (Spoofing, DOS, DDOS, etc...) and it should block the source of those on any interface. I did not include IDS at all, as there are other products for that.

I like the adds, lets get through what a firewall should have before we start taking things away from what a firewall shoud have in different cases.

A firewall, and we're not defining Home/SOHO/Business/Medical, just what a firewall for all cases should have.

We're talking a firewall, strictly a firewall, something that can be used in all cases. We'll brake down the features into Home/SOHO/etc... later.

They are not dangerous, they are great at helping block intruders. We setup all our firewalls to detect traffic on select ports, when detected we block that source IP for 20 minutes. When the SQL slammer hit it was easy to see it start, our block list increased hundreds of times in size.

In my networks I have multiple networks behind each network in many cases. As an example, I might have a DMZ with a network with servers in it (say 192.168.16.1/24) and then inside that network I might have classrooms with their own isolated networks (10.1.0.1/24,

Yes, but I was specifically thinking about Drop-In devices like the household NAT appliances that come with DHCP Service enabled to make it easy for users.

But, if it's not certified, then anyone can call an appliance a firewall and the public will buy it as a firewall - See all the residential devices out on the market.

Perhaps names that hint more at what we are dealing with technically and practically, are more appropriate.

Firewall appliance

I am not impressed.

To an extent, that's an awfully large stretch. A Home/SOHO is going to be quite a bit different compared to something used at a .edu with even 500 students. Yes, one would hope that the admins on that .edu had a lot more knowledge at choosing/configuring the network as well as the firewall, but your certification requirement (your item 12) is going to attract the attention of the Pointy-Haired crowd. The fact that there might be a difference between a POTS/?DSL/OC-3 would be a detail they'd ignore or at least not notice.

I'd also prefer to analyze the separate requirements, rather than slow them down. (break != brake)

I'll definitely agree with this one. IF it claims to have the capability of a DMZ, then this MUST (using the capitalization in the same way as in RFCs [see RFC2119]) provide this on a separate physical connection. If this separate connection is not provided, the supplier/vendor/what-ever MUST NOT claim a DMZ capability.

This should be configurable. I _really_ don't want to see a mile long list of "packet allowed/disallowed" every ten minutes. On my home system, I purposely do not log 'disallowed inbound'. So what if some klown in South Whatiz scanned the box - the firewall blocked it (or there was nothing running on that port or protocol), and that's the end of that. Logging the source of UDP to ports in the range 1024 - 1050 is a waste of time/bandwidth/CPU-cycles, as most of that is messenger spam, and the last time I looked at it, most of the IPs were faked (wrong TTLs were the most obvious, IPs that haven't even been issued by the RIRs was another).

It also doesn't "fit" the normal use of the WAN side.

Not mentioned before - NAT, and perhaps 'port forwarding'. As regards the multiple networks, I could see this done with the rule associating network address (range) and a specific interface. This would be a part of RFC3704 filtering anyway.

Your use of the DMZ is different from what I see to be normal. The only things we put in the DMZ are those hosts that need to be reachable from the WAN side. These would be the public DNS, mail, web, FTP servers and the like. Hosts that are not offering services to the WAN do not belong in the DMZ. In your example, the classrooms would likely not be offering such services, and probably should be isolated on their own NATing firewall - to allow (probably controlled) access OUT to the Internet, and limited (if any) access to the rest of the internal networks.

I'd agree with this

What do you propose instead? No DHCP - so it's static or LinkLocal? Or is it some other box separate from the firewall/user systems?

I can see your point, but what do you define as a reputable authority? ANSI? IEEE? IETF? NIST? NSA? Some supra-national entity from the EU, or similar? Good Housekeeping magazine? ;-)

Old guy

Sorry, sometimes my fingers type faster than my brain.

Yes, I should be been cleared and not stated ANY, should have been LAN/DMZ interfaces. Many firewalls have more than one or two interfaces.

Same here, but I have a number of clients with multiple DMZ's where the training centers have access to the internet, but they also isolate teach room from the others.

That's one way to do it, but, we can look at things in different methods. I would rather have my classrooms behind a firewall, not just a NAT, and the DMZ, since it's already secured, is a good place to tack them on to, so that they don't have LAN access by mistake anywhere.

It can offer DHCP, but it should not be enabled by default. I've seen too many people install devices called firewalls and never learn another thing about them - and many times they are wide open (wireless units). Having them not offer DHCP as a default, meaning it's not enabled, would mean that users would have to configure them before using them.

I'll start with CERT and go with places like that.

My objection wasn't meant to imply a classification of any sort. However, I do believe that any security device should run as little code as possible. Thus I do not believe that we should establish a definition of an "all-purpose-firewall", but rather distinguish between core functionality and optional features. Optional features could be defined like this:

But this discussion is - like you said - not (or not yet) about "real- world" devices. We are talking about the features a firewall is supposed to implement. Therefore I think we should not refer to specific implementations within these specifications.

I was referring to the concept of an IDS, not to specific implementations. "Detection of threats" is what an IDS does, so you described the functionality of an IDS (or at least Proto-IDS) here.

And no, it should NOT automatically block the source of an attack, because an attacker could use this for a DoS attack. Simple example:

hping -1 -c 1 -a 198.41.0.4 -d 80000 $TARGET

The firewall detects a "Ping of Death" and blocks the (spoofed) source address: *BANG* - no access to a.root-servers.net for you.

That's why automatic network shunning is a really stupid thing to do.

cu

On Tue, 22 Aug 2006, in the Usenet newsgroup comp.security.firewalls, in article , Leythos wrote:

I hear you. This tool has a Spell Chequer, but it lacks it grammar checker and despite re-reading the post before hitting 'Send'...

Well, the client is always right. Isolating the classrooms is correct, but this is more a semantics issue.

^^^^^^^^^^^^^^^^^^^

If the "company" is not offering services to the Internet, then the otherwise unused DMZ would be a good place. If they are offering any service - to me, that means any application that is accepting new connections from outside (receiving mail, DNS, web service), then I prefer these servers to be isolated in the DMZ without access from inside. Administration, and connections to the internal LAN should be by means of a second interface on the server. By this, I means that (example) mail gets received by the mail server on a DMZ interface on the "public" server. An "internal" server then connects to a second (isolated) interface, and extracts the mail for delivery. (The external mail server needs to have a copy of a list of valid users it will accept mail for - but that's a trivial server configuration issue.) Systems in the DMZ are not allowed to _initiate_ connections to the internal LAN, and only accept connections from a limited set of internal hosts. Thus, in the worst case when a host in the DMZ is subverted, it can't reach into the internal network. Those who would complain about the added complexity (true, but a one-time setup) or cost (how much are you paying for NICs and a small hub/switch?) need to think how much this mechanism adds to security.

As regards the classroom setup - again, are any of the system in the classroom serving to the Internet (other than perhaps 113/tcp)? If no, then a relatively simple ruleset is needed to block incoming SYN packets while allowing SYN/ACK. As for blocking "inter-classroom" traffic, and traffic to/from the classrooms and the rest of the network, this can be done with any competent router by simply not supplying routing rules between those networks.

Personally, I prefer static addressing, but I can see where you are coming from. I just don't know if this is a viable solution. Many home entertainment systems are now picking up time-of-day information from remote sources automagically because most users can't be bothered to read the manual to see how to set the clock manually. How many of your customers would know what an RFC1918 address[1] is (or if they have real addresses, what they are, what the netmask is, and what is the next-hop router address[es])? Not enabling stuff by default is an established procedure (look at OpenBSD, which claims an out-of-box install has never been r00ted - mainly because nothing is enabled out-of-box), but this requires knowledge on the user's side (a rare commodity), or that the user gets (at least temporary) outside help. Given the current customer expectations (have you actually read the "Instruction Book" that comes with most consumer goods today), I suspect this might be a non-starter. People expect that you need only plug it in, turn it on, and "it works". Read some manual??? Why? (Of course, this is also helped by the fact that most so-called "Instruction Books" are really just filled with legal notices telling the user not to immerse the product in the bath tub while it's plugged in, and the actual "how to use it" stuff is limited to a half page written by a poorly configured artificial [lack of] intelligence program.)

Isn't that a bit off their turf? Certainly "Good Housekeeping magazine" was offered in jest, but I'd think the other organizations would be somewhat more appropriate.

Old guy

No.

Yes.

It depends. Usually yes.

Optional.

A DMZ is part of a concept, not of a firewall.

No.

Yes.

It depends. IDS with service denying implies vulnerability for DoS attacks.

It depends. IDS with service denying implies vulnerability for DoS attacks.

Yes.

Yes.

Who is this authority? In doubt: no.

Really? Why not 4 layers IP only for IP based firewall implementations?

Yes.

Many NICs, of course, not only two.

Yours, VB.

I don't think so. Not blocking outbound traffic as default enables it to be used for security concepts, which don't block outbound, but have an IDS.

But: we can talk about that (maybe you want to argue, that blocking everything is correct, because a firewall admin is forced to configure something then before she/he can use the device at all, while I think, we don't need to force the admin to do something, but have a handy default config, because she/he has to know what she/he does).

Yes.

Yes.

Yours, VB.

Yes.

Yes.

Of course the latter.

Yours, VB.