IPTables filtering what should be allowed outbound traffic

Hello all,

I have a very simple firewall ruleset on a single interface which
should only be blocking everything inbound except to ports 22, 80, and
90.

My iptables rules are:

[root@ddcpq mlewis]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp
dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:90
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh

DROP tcp -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@ddcpq mlewis]#

As you can see, I have no output filters defined.

The problem is, with these exact rules above loaded, I am unable to
send any outbound traffic save for ICMP. For example, I can ping our
mail server, but I can not 'telnet mail.server.com 110', it just hangs.
I would like to allow all outbound traffic from our server with no
restrictions.

I'm running Red Hat Linux release 8.0 (Psyche) with iptables v1.2.6a.

These same symptoms are present on an entirely different virtual server
we manage as well, so I must be missing something fundamental. Anyone
know what it is?

"SmittyBroham" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) ups.com:

> Hello all,
>
> I have a very simple firewall ruleset on a single interface which
> should only be blocking everything inbound except to ports 22, 80, and
> 90.
>
> My iptables rules are:
>
> [root@ddcpq mlewis]# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> ACCEPT tcp -- anywhere anywhere tcp
> dpt:http
> ACCEPT tcp -- anywhere anywhere tcp dpt:90
> ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
>
> DROP tcp -- anywhere anywhere
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> [root@ddcpq mlewis]#
>
> As you can see, I have no output filters defined.
>
> The problem is, with these exact rules above loaded, I am unable to
> send any outbound traffic save for ICMP. For example, I can ping our
> mail server, but I can not 'telnet mail.server.com 110', it just hangs.
> I would like to allow all outbound traffic from our server with no
> restrictions.

The INPUT chain is wrong. On INPUT, port 80 for example is the source port,
not the destination. You would only specify port 80 as a destination in the
INPUT chain if you were running a web server locally such as apache. Clear
out the INPUT chain and add a rule in the INPUT chain something like:

iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED - j ACCEPT

then add the DROP rule or change the INPUT chain policy to DROP.

This means that the INPUT chain will allow any traffic that CONNTRACKING
considers to be part of an established connection. In your case you
probably don't need to specify RELATED but you would need that if you were
using ftp. It means that it will allow any traffic as long as it was part
of a connection initiated from your PC.

Klazmon.








>
> I'm running Red Hat Linux release 8.0 (Psyche) with iptables v1.2.6a.
>
> These same symptoms are present on an entirely different virtual server
> we manage as well, so I must be missing something fundamental. Anyone
> know what it is?
>
>

Hi Klazmon and thanks for your quick response.

We are indeed running a local Web server that is using ports 80 and 90.
22 of course is the port our SSH server runs on.

I want to allow incoming requests to ports 22, 80, and 90 while
blocking all other incoming traffic. I don't want any restrictions on
traffic going out.

The rules I listed previously work great as far as restricting incoming
traffic only to ports 22, 80, and 90 so I know those are right, however
it is also cutting off most outbound traffic as well which is what I
don't understand. This is why I want to prevent.

I've even put an explicit rule in the OUTPUT chain allowing all traffic
and that doesn't fix it either.

"SmittyBroham" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) ups.com:

> Hi Klazmon and thanks for your quick response.
>
> We are indeed running a local Web server that is using ports 80 and 90.
> 22 of course is the port our SSH server runs on.
>
> I want to allow incoming requests to ports 22, 80, and 90 while
> blocking all other incoming traffic. I don't want any restrictions on
> traffic going out.

Ok. I understand now. You still need the line I suggested in the INPUT
chain because although your OUTPUT chain lets anything out, the INPUT chain
will be throwing away the responses to the outbound connection you tried to
start. Add the state test rule I suggested after you check the incoming
SSH, http & tcp port 90.


>
> The rules I listed previously work great as far as restricting incoming
> traffic only to ports 22, 80, and 90 so I know those are right, however
> it is also cutting off most outbound traffic as well which is what I
> don't understand. This is why I want to prevent.
>
> I've even put an explicit rule in the OUTPUT chain allowing all traffic
> and that doesn't fix it either.

Yes because it is the INPUT chain that is causing your problem. You need a
rule in it that lets the responses to your outbound traffic get back. A
typical TCP connection goes like this:

Program tries to open a tcp connection. A tcp SYN packet is sent to try and
establish the connection - that will get through your OUTPUT rules as you
say you allow anything outbound. The remote device receives the SYN packet
and replies with a TCP SYN,ACK, when that reply hits your PC it will be
passed through the INPUT chain because it is considered to be INPUT. Your
INPUT chain as it stands will drop the TCP SYN, ACK and your email client
will not see the response and eventually timeout. The best thing to do is
add the rule checking for ESTABLISHED, RELATED - that automatically
understands messages that are part of a connection startup or established
connection.

So use this iptables command as I suggested:

iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED - j ACCEPT

It has to go before the drop rule of course.

Klazmon.








>
>

Ok, I see what you're saying. I tried adding in your rule and get:

[root@ddcpq mlewis]# iptables -A INPUT -p tcp -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables: No chain/target/match by that name

So it looks like there might be a missing module IPTables needs.

Output from lsmod is:

Module Size Used by Not tainted
ipt_limit 1688 0 (autoclean)
iptable_filter 2412 1 (autoclean)
ip_tables 16544 2 [ipt_limit iptable_filter]
loop 12440 0 (autoclean)

I modified your rule so it uses the iptable_filter by name:

iptables -t iptable_filter -A INPUT -p tcp -m state --state
ESTABLISHED,RELATED -j ACCEPT

but I get the error:

iptables v1.2.6a: can't initialize iptables table `iptable_filter':
Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

So I 'insmod iptable_filter' and get:

Using /lib/modules/2.4.24/kernel/net/ipv4/netfilter/iptable_filter.o
insmod: a module named iptable_filter already exists

Why do so many people hate computers again?

"SmittyBroham" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) oups.com:

> Ok, I see what you're saying. I tried adding in your rule and get:
>
> [root@ddcpq mlewis]# iptables -A INPUT -p tcp -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> iptables: No chain/target/match by that name
>
> So it looks like there might be a missing module IPTables needs.
>
> Output from lsmod is:
>
> Module Size Used by Not tainted
> ipt_limit 1688 0 (autoclean)
> iptable_filter 2412 1 (autoclean)
> ip_tables 16544 2 [ipt_limit iptable_filter]
> loop 12440 0 (autoclean)
>
> I modified your rule so it uses the iptable_filter by name:
>
> iptables -t iptable_filter -A INPUT -p tcp -m state --state
> ESTABLISHED,RELATED -j ACCEPT
>
> but I get the error:
>
> iptables v1.2.6a: can't initialize iptables table `iptable_filter':
> Table does not exist (do you need to insmod?)
> Perhaps iptables or your kernel needs to be upgraded.
>
> So I 'insmod iptable_filter' and get:
>
> Using /lib/modules/2.4.24/kernel/net/ipv4/netfilter/iptable_filter.o
> insmod: a module named iptable_filter already exists
>
> Why do so many people hate computers again?
>
>

Hello,

This stuff has been around for a while so I would have thought most distros
would load the necessary modules assuming you selected that you wanted a
firewall when you did the initial install. Anyhow my distro set everything up
for me when I installed it - you may want to read the docs at netfilter.org.
From memory for full functionality you need:

ip_tables
ip_conntrack
ip_conntrack_ftp
ip_conntrack_irc
iptable_filter
iptable_mangle
iptable_nat
ipt_LOG
ipt_limit
ipt_state
ipt_owner
ipt_REJECT
ipt_MASQUERADE
ip_nat_ftp
ip_nat_irc


Doing state matching id pretty standard stuff these days but you do need the
conntracking modules of course.

Klazmon.

"SmittyBroham" <(E-Mail Removed)> said:
>I have a very simple firewall ruleset on a single interface which
>should only be blocking everything inbound except to ports 22, 80, and
>90.
....
>The problem is, with these exact rules above loaded, I am unable to
>send any outbound traffic save for ICMP. For example, I can ping our
>mail server, but I can not 'telnet mail.server.com 110', it just hangs.
> I would like to allow all outbound traffic from our server with no
>restrictions.
....
>These same symptoms are present on an entirely different virtual server
>we manage as well, so I must be missing something fundamental. Anyone
>know what it is?

Well, for this you already got your reply. You blocked any return packets
that might be coming. So, when you connect somewhere, whatever you see
as coming from the other host will arrive in return packets, and you
blocked these.

Then to the reason why your "ping" worked, even though telnet to the
same destination didn't: your firewall was leaking. You had instructed
your firewall to block all incoming TCP packets -- leaving a gaping hole
for anything non-TCP to just walk in and say "Hello!". UDP, ICMP,
just whatever, but TCP was blocked.

To improve, you could pretty much drop the DROP rule, and instead
use a DROP policy on the INPUT chain. Works the same, but you don't
have to worry about possibly appending rules beyond the "terminal"
DROP rule - as with policy, the DROP is what the packet faces after
all the INPUT rules have been processed.

Then to tell how you could've got at least some indication to the
problem you had: by using "iptables -vL" instead of "iptables -L"
and looking at the packet counters of your DROP rule. You'd have
seen the number of dropped packets increase at each connection
attempt. By placing a LOG rule before the DROP you might have
been able to correlate these packets to the tests you were
making.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)