iptables general questions

[elovkoff]

I mostly have experience with Checkpoint....for example I cannot install checkpoint 4.1 on the machine with 1 nic.
Can I run iptables on the machine with 1 nic?
If yes, then is it possible to configure that machine to let all traffic from that machine to go outside but allow inbound only tcp 443 (I mean on machine with 1 nic)?
Thanks.

[tolstoy]

The short answer to the question is yes. Um, I guess that's the only answer. IMHO the iptables syntax is somewhat similar to Cicso's ACL, though far more extensible. All you need to do is specify which inteface to bind the rule to. It can be one interface, two interfaces, or one interface with different rules applying to all different virual interfaces (eth0:0, eth0:1, eth0:2, etc).

You can create rules for packets destined to the box, leaving the box, or being forwarded through it. If it's a stand alone box, you only need worry about your input and output rulesets. If its a true LAN firewall, then you'd be more interested in your forwarding ruleset.

As for your specific ruleset, just drop all incoming packets with the syn flag set except those destined to 443. Allow all outgoing client requests and all incoming server replies. Allow everything on the loopback.

[elovkoff]

1. " just drop all incoming packets with the syn flag set except those destined to 443." WHY SYN FLAG?
2. "Allow all outgoing client requests and all incoming server replies" - IF IT IS STATEFULL FIREWALL THEN WHY SHOULD I ALLOW REPLIES BACK? (should be allowed automatically...)
3. " Allow everything on the loopback. " - Should I use that if this is a firewall machine with 2 nics and services lan to internet connetcion?

[tolstoy]

[quote author=elovkoff link=board=4;threadid=4708;start=0#47093 date=1030387716]
1. " just drop all incoming packets with the syn flag set except those destined to 443." WHY SYN FLAG?
2. "Allow all outgoing client requests and all incoming server replies" - IF IT IS STATEFULL FIREWALL THEN WHY SHOULD I ALLOW REPLIES BACK? (should be allowed automatically...)
3. " Allow everything on the loopback. " - Should I use that if this is a firewall machine with 2 nics and services lan to internet connetcion?
[/quote]

Stateful or not stateful all depends upon they type of rules to write. You would drop incoming packets with the syn flag set in the header because these would be incoming requests for local services. (Ok, I should have been more clear. You don't want to accept incoming connections with the SYN flag set alone. ACKS and SYN-ACKS are all right).

You need to allow incoming replies to your tcp client requests in order to get an answer back from a server your client might have initiated a connection with. For instance, a mail server on your lan might send a packet with the SYN flag set from a local port ranging between 1024-65535 to a server listening on port 25. If your firewall drops all incoming packets except those to port 443, the subsequent SYN/ACk will never be recieved by the client. If you are writing a stateful ruleset then you would want to work specifically with the NEW, ESTABLISHED and RELATED flags. Stateful packet inspection only means that the firewall keeps state information about connections and can tell if packets do or do not already belong to established connections. However, you have still have to tell the firewall this in some fashion (at least in iptables you do). Usually I perform 2 checks on a packet 1) what flags are set in the header 2) is the packet initiating a new connection or part of an already established one.

In my ruleset, I have a very simple user defined target which I call "connection-tracking". All packets are checked against the rule target first, which determines if they belong to an already existing connection. Only then they are passed down the chain to the other firewall rules, which make other checks and decisions. Remember this is iptables. If you do not tell the iptables what to do, it does not do anything for you automatically. You are, in essence writing your own firewall from scratch. AFAIK, the difference between stateful and stateless (at least in iptables-speak) is that in using stateless your rules are based solely upon flags set in the header; the firewall doesn't have a clue as to whether or not the packet it is currently inspecting actually belongs to part of an already established connection. Nothing is automatic, however.

You need to allow everything on the loopback for certain local services such as X to function at all. If you have any local services running at all, they will probably not work properly from the console if you do not allow traffic on the loopback. This is safe since the loopback is used only for the box to talk to itself, and not by external clients.

[elovkoff]

Absolutely good explanation thanks, my confusion with terminology acually stems from my Checkpoint experience....
Let's say they way they describe stateful is liek this:

When connection that comes out of LAN through the firewall to some external resource then information about those packets are 'recorded' and is held in firewall's stateful inspection table. Table has the approx. the following information about the coonection:
"It comes from that tcp addresss, using this source port, goes to that ip address, and it has SYN flag (outgoing)". should be more inspection criteria but I beleive those are the basics.
So when it comes to inspecting INCOMING reply packets Checkpoints does the following;
1. If it matches information regarding the requests in the statefull connection table then reply is allowed back. From this point on the connection is considered ESTABLISHED because a) it matched stetful connection critetria b) it matches the rule created fir this type of traffic c) tcp/ip handshake is verified.
This is why when I create rule
Local_Net > www.ibm.com > http> ACCEPT
I don't have to allow replies back.

2. If reply doesn't match anything (incoming SYN flag) then it is reated as UNESTABLISHED communication and it is dropped.

This is why I think then when you say 'stateful' then you don't need to allow packets back on Checkpoint.

[tolstoy]

I have limited checkpoint experience, but have worked with a number of other turnkey solutions. Almost all of them are pretty automatic when it comes to creating rulesets. If you say something like, allow outgoing http, they automatically create all the necessary rules about state inspections, incoming replies, etc. IMO, this is good, but since a lot of the actualy implementation is hidden from you, you lose some of the understanding of what actually is going on. With iptables (if you write your rules from scratch) you have to write and accommidate for everything.

As a matter of fact, iptables are not even stateful unless you use the "state" option. Checkpoint's description of the state table is pretty correct. Iptables also keep a state table with connection information, but I think state tables also rely on tcp header fields like the sequence identifier, which identifies a single packet with the rest of its stream.

I like iptables, but I must say I would love to get more checkpoint experience, as it seems to be indemand these days. I rarely see a job posting that does say "Checkpoint experience helpful or necesary."