statefull or stateless?
 

What is the deep meaning for the above meanings (in firewall especially)

Tried google?

You should probably scan the other links for other information; next time remember how useful google is ;)

Steve

A stateful firewall is aware of the state of each individual connection. For instance, with Netfilter ("iptables"), you can configure rules, or variations of rules, based on the state of each connection, which might be:
-NEW: A brand new connection to or from the system.
-ESTABLISHED: An ongoing, previously established connection.
-RELATED: A connection that is related to another, existing connection

A stateless firewall is completely clueless about the state of each connection and, because of that, cannot handle connections differently based upon their state.

Note that both types of firewalls are aware of the basic connection info, such as port, protocol, source address, destination address, etc.

A stateful firewall enables you to increase security and/or increase functionality without a loss of security.

For instance, with a stateful firewall, you could configure several rules with the following logic:

-Allow ESTABLISHED and RELATED incoming tcp connections on port X
-Allow NEW outgoing tcp connections on port X
-Deny NEW incoming connections on port X

...effectively allowing connections through port X only if they are initiated from within your network or are incoming AND related to a connection initiated from within your network. But at the same time denying any new connection attempts that originate outside of your network (or system).

With a stateless firewall, you can't do that. It will only support rules with more limited logic, such as:
-Deny incoming tcp connections on port X
-Allow outgoing tcp connections on port X

This can be a problem because, although you can connect out through port X, the other system's response will be blocked.

Hope this helps.

-Slack

Well, could you give me an example of a RELATED connection and how it is created?

Sure.

And, just to clarify, the rules actually work on the individual packets that come in. I used the term "connection" as just general, broad term.

An example of a RELATED connection is a remote system's response to your initial connection. For instance, when you attempt to access a page on a web site, you're sending a connection request (essentially, one or more packets) to that remote system. When that remote system responds, it is sending a packet (or group of packets) that are related to your connection attempt.

In the example rules above (for the stateful firewall) the remote system's response is allowed because it is related to a connection that you initiated. But if that, or any, remote system arbitrarily attempts to make a connection, without any initiating activity on your local system, it will be denied. (Because of the "DENY" rule.)

From this example alone, you can see the huge advantage of a stateful firewall over a stateless firewall. With a stateless firewall, you'd have to just either allow or deny the connections over that port, regardless of their state. (Although you can still restrict the rules based on port, protocol, destination IP, source IP, etc.)

-Slack

I hate to nitpick here, seeing as you did a good job explaining stateless vs. stateful firewalling, but the RELATED state is a little different than how you've explained it. The examples you gave are all still parts of ESTABLISHED traffic. For traffic to be "RELATED" it has to be initiating a new connection, with the catch being that it somehow has to be "related" to another ESTABLISHED connection. One example of "RELATED" traffic would be certain ICMP messages that are generated in response to other traffic. It's not very intuitive and actually contradicts some of the TCP/IP terminology. There's a good tutorial on states available at the netfilter site here that explains it better than I could and lists a couple of examples (also see the section on states in iptables man pages) of what types of traffic would be "RELATED".

There's also a really straightforward way to prove this to yourself. Make a firewall with no rules allowing RELATED traffic or specifically block RELATED traffic and you'll find you can still make normal tcp connections. In fact, you'll find it's actually rather hard to generate RELATED traffic at all (put in a rule that logs any related traffic and see how long it takes to get any log messages).