quote:
--------------------------------------------------------------------------------
Originally posted by Obie Thank you all for your help. I do have a couple more queries.

I flushed all my rules within iptables and have the following listed as local policy

Chain INPUT (policy DROP)
target prot opt source destination

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy DROP)
target prot opt source destination

--------------------------------------------------------------------------------

quote:
--------------------------------------------------------------------------------

1) What does "opt" refer to?
Hmm.. No idea..
--------------------------------------------------------------------------------

Does anyone know?

quote:
--------------------------------------------------------------------------------
Allow your web traffic with --dport 80 in OUTPUT chain or --source www.etc.com in your INPUT chain.. You send to port 80, but can get the resulting reply from another port.
--------------------------------------------------------------------------------

Ok. Why do certain guides mention --dport in the INPUT chain for example when blocking Port 113.

Because some of malicious program's port numbers are fixed. For example, a SubSeven lamer tries to connect port 1243 of infected computer. So you must block the traffic that has a destination of port 1243 and can do this by using a --destination-port 1243 in the INPUT chain. Also when you want to block SSH requests, again you must use --destination-port 22 for a working sshd on it's standart port. But there is no warranty for a port number in a web connection as i said before.

opt = packet "fragmentation options"

i.e. specifying to match packet fragments (-f) or not fragmented (! -f) packets

Capt_Caveman,

Thank you. When would there be any reference under "opt" or should I say when would someone match packet fragments?

barisdemiray,

Thank you.

For example if a TCP/IP packet is bigger than maximum packet size, it will be fragmented and only first one will contain the valid headers. So, when you want to block SSH traffic, you can LOG the first part (containing valid headers) and DROP the remaining part if there are any. An iptables rule like below will be shown in iptables -L output and DROP any fragment of TCP packet traffic:

PS: Thanks for the explanation Capt_Caveman!

Iptables can track packets based on these states:
NEW, ESTABLISHED, RELATED and INVALID

So if you want to be able to ping and receive ping replys you need to allow ESTABLISHED / RELATED packets. This will cover all traffic including ftp http etc...

The rule would look something like this:
$IPTABLES -A INPUT -p ALL -d eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

For forwarding it looks like this:
$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

quote:
------------------------------------------------------------------------------
Iptables can track packets based on these states:
NEW, ESTABLISHED, RELATED and INVALID

So if you want to be able to ping and receive ping replys you need to allow ESTABLISHED / RELATED packets. This will cover all traffic including ftp http etc...

The rule would look something like this:
$IPTABLES -A INPUT -p ALL -d eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

For forwarding it looks like this:
$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
------------------------------------------------------------------------------

/bin/bash,

Thanks. I read the man pages of -m state --state however don't quite get what the states "NEW, ESTABLISHED, RELATED and INVALID" are for. Would you mind giving examples of each and when I would use them. I appreciate your help.

NEW: Packets which are for opening a new connection. For example if you want to block ftp, ssh connections, then block the NEW packets.
ESTABLISHED: Packets which are belonging to already opened connection. For example when you connect to a host with ssh and give the command `ls' then this packets will have the status ESTABLISHED.
RELATED: Packets which are going to open a new connection but coming from an ESTABLISHED connection. For example when you're connected to a host with ftp and going to begin a file transfer; then your ftp client will open a ftp-data connection and these packets will have the status RELATED.
INVALID: As it's name said, they neither open a new connection nor belong to already opened one. The seem random and so they're INVALID.

barisdemiray,

Thanks. Just a few queries in relation to your reply:

"NEW: Packets which are for opening a new connection. For example if you want to block ftp, ssh connections, then block the NEW packets."
If I wish to block FTP for example why wouldn't I just block tcp port 21 rather than apply the status NEW

"ESTABLISHED: Packets which are belonging to already opened connection. For example when you connect to a host with ssh and give the command `ls' then this packets will have the status ESTABLISHED"
This I get that if a connection is successful then it has the status ESTABLISHED however how does that relate to iptables

"RELATED: Packets which are going to open a new connection but coming from an ESTABLISHED connection. For example when you're connected to a host with ftp and going to begin a file transfer; then your ftp client will open a ftp-data connection and these packets will have the status RELATED."
This I kinda get but it confuses me due to the examples above.

You must have come across documentation mentioning different firewall philosophies, for instance mostly open , mostly closed. It is my understanding that mostly closed firewalls are the most secure. The idea behind this approach is to reject all traffic that is not explicitely allowed. It is expressed in iptables by setting default policies set to DROP.

Note that if you work on your firewall box remotely it is quite possible that you will lock yourself out a few time, ie you will block your own local network traffic. This will happen more specifically if you flush your rules while the default input policy is set to drop. The solution is to log locally on the firewall box and force the default policy to accept.

You'll also discover eventually that other tables than accept, output and forward exist, namely the nat and mangle tables. You should leave these tables policies to accept. Port forwarding is insanely difficult (impossible?) otherwise.

For the input, output and forward chains, I apply drop, accept and drop default policies resp. My rationale:
- Traffic originating from the internet is considered unsafe. Since it goes through the input and forward chain, the default policy for these chains shall be drop.
- The output chain is used by the firewall box itself. I do not have a need to restrict outgoing traffic (it is a home firewall in a safe environment), so I leave this chain default policy to accept. It makes the firewall a bit less complex too.

One of the best iptables docs I have found is this one. It is very thorough.
http://iptables-tutorial.frozentux.n...-tutorial.html

Just wanted to share my 2 cents! Good luck!

I just noticed something. Everytime I restart the PC or start it up, the rules I assigned to the chains within iptables are lost and all policies are set to ACCEPT despite the fact that I had changed it earlier. Is there any reason why iptables would automatically flush itself on a reboot or start up? What can I do to prevent it from doing so?

I did manage to isolate it to me removing shorewall from the runlevels however how do I prevent it from flushing itself on every restart or power-up?

On redhat/fedora systems, you need to use the command:

iptables-save > /etc/sysconfig/iptables

This should make the changes to iptables persistant after reboots. As a side note, I'm not trying to tell you to RTFM, but most of this information is readily available in the netfilter website docs or in the iptables man page. Redhat also maintains fairly comprehensive docs on iptables/netfilter and it's Redhat-specific usage.

Capt_Caveman,

Thank you however that's wherein the problem lies. Mandrake does not have the path /etc/sysconfig/iptables not does Mandrake document it.

The file /etc/sysconfig/iptables is created the first time you use that command. After that there is a startup script at /etc/rc.d/init.d/iptables which looks for the file and if it finds the file it will load the rules from it. So you only need to run that command one time. The same thing happens if you run the command:
service iptables save