iptables woes on woody, not accepting inbound connections

[Mark C]

Hi,

I'm in the middle of trying to build a secure webserver, using stock
woody (2.4.18-bf2.4),
the box is completely updates from last night. I install just the base
(never used deselect or taskselect) during the install,
Once it was installed, I have installed:

apache
php4
ssh
dnsutils
lynx
iptables (choose not to run the init.d script)

The machine can surf the web no problem and accept inbound port 80 and
22 connections from other boxes on the same subnet.
(the box is at present not locked down, as I'm making sure certain
configurations work, then I will reinstall off the network and build it
up that way.)

I decided to test iptables, using a very,very basic script below:

#/bin/bash

/sbin/modprobe iptables
/sbin/modprobe ipt_state
/sbin/modprobe ip_conntrack

/sbin/iptables -F
/sbin/iptables -X

/sbin/iptables -P INPUT DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -P FORWARD DROP

/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

/sbin/iptables -A OUTPUT -p udp -o eth0 --dport 53 --sport 1024:65535 -j
ACCEPT
/sbin/iptables -A INPUT -p udp -i eth0 --sport 53 --dport 1024:65535 -j
ACCEPT

/sbin/iptables -A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED -j
ACCEPT

/sbin/iptables -A INPUT -p tcp -i eth0 --dport 22 --sport 1024:65535 -m
state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp -i eth0 --dport 80 --sport 1024:65535 -m
state --state NEW -j ACCEPT

I can do outbound nslookup requests no problem, but it now fails to
allow inbound connections at all, to either port 80 or port 22.

I have another box (this one is running redhat 8), which I'm replacing
with debian woody, so I killed that and loaded on a bloat riddled basic
rh install, ran the same script and that works as expected, allowing
inbound connections, all the same modules are loaded.

Just for the record, I'm running a woody/sarge/sid mix on my laptop and
that does the same as my test woody box, it just refused to accept
inbound connections

This is driving my mad, can anyone possibly point me in the right
direction, as it seems there may be something debian specific that I'm
missing.

cheers in advance

Mark


--
To UNSUBSCRIBE, email to [email]debian-user-request@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

[Mark C]

Just to confirm, if I do not use state connections, and use static
instead i.e:

/sbin/iptables -A INPUT -p tcp -i eth0 --dport 22 \
--sport 1024:65535 -j ACCEPT

/sbin/iptables -A OUTPUT -p tcp -o eth0 --sport 22 \
--dport 1024:65535 -j ACCEPT

It works perfectly.

Mark


--
To UNSUBSCRIBE, email to [email]debian-user-request@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

[Shaul Karl]

On Tue, Jul 22, 2003 at 11:56:48PM +0100, Mark C wrote:

>
> I decided to test iptables, using a very,very basic script below:
>

[ ... ]

> This is driving my mad, can anyone possibly point me in the right
> direction, as it seems there may be something debian specific that I'm
> missing.
>

I would have add LOG rules in order to try and found out what happens
to those inbound packets. Maybe this is not the firewall but something
else, like tcpwrappers?
--

Shaul Karl, shaulka@bezeqint.n e t


--
To UNSUBSCRIBE, email to [email]debian-user-request@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

[John Hedge]

Have a look at Shorewall ([url]http://www.shorewall.net[/url]).

It's a lot easier than struggling directly with iptables and Tom Eastep
is a great manager of his list at [email]shorewall-users@lists.shorewall.net[/email].

John





On Wed, 2003-07-23 at 13:30, Shaul Karl wrote:

> On Tue, Jul 22, 2003 at 11:56:48PM +0100, Mark C wrote:

> >
> > I decided to test iptables, using a very,very basic script below:
> >

>
>
> [ ... ]
>
>

> > This is driving my mad, can anyone possibly point me in the right
> > direction, as it seems there may be something debian specific that I'm
> > missing.
> >

>
>
> I would have add LOG rules in order to try and found out what happens
> to those inbound packets. Maybe this is not the firewall but something
> else, like tcpwrappers?
> --
>
> Shaul Karl, shaulka@bezeqint.n e t
>
>
> --
> To UNSUBSCRIBE, email to [email]debian-user-request@lists.debian.org[/email]
> with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
>

--
To UNSUBSCRIBE, email to [email]debian-user-request@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

[Mark C]

Once upon a time Shaul Karl was quoted as saying:

> would have add LOG rules in order to try and found out what happens
> to those inbound packets.

Sorry I missed that off the post, logging does actually drop inbound
packets on eth0 to ssh or apache, it would seem after banging my head on a
wall, that using statefull inspection is not working or I missunderstood
something,
In hte past I have always used static rules, as these are very similar to
the old ipchans way, using static tunles work fine, the connections are
received etc, but with statefull they are dropped...

> else, like tcpwrappers?

Nope my system works fine with my hosts.allow/hosts.deny setup,
adding a firewalll to this equation would not effect this issue at all.


--
To steal ideas from one person is plagiarism,
to steal ideas from many is research.



--
To UNSUBSCRIBE, email to [email]debian-user-request@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

[Mark C]

Once upon a time John Hedge was quoted as saying:

> Have a look at Shorewall ([url]http://www.shorewall.net[/url]).

I really want to only use standard debian packages, apart from using LIDS
on a 2.4.21 kernel latter on, I have my main standalone firewall (Cisco
Pix 515e), and I really want to setup a basic firewall on each server
(both on hte DMX and SIN), to make sure that only those connections that I
want specific to each server can get in and out of the servers.

> It's a lot easier than struggling directly with iptables and Tom Eastep
> is a great manager of his list at [email]shorewall-users@lists.shorewall.net[/email].

I'm not struggling with iptables, I have always been able to set it up
perfectly ok, understand the way it works without having to rack my
brains,
the only thing I cannot get working is using the -m state --state ? way of
working, working with the old way (i.e ipchans way of doing stiff, static
rules) I have no problem with


Mark

--
To steal ideas from one person is plagiarism,
to steal ideas from many is research.



--
To UNSUBSCRIBE, email to [email]debian-user-request@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

[Richard Downer]

Hi Mark,

On Tue, 22 Jul 2003 23:56:48 +0100, Mark C wrote:

> I can do outbound nslookup requests no problem, but it now fails to
> allow inbound connections at all, to either port 80 or port 22.

At a quick look I think the problem is here.....

> /sbin/iptables -A INPUT -p tcp -i eth0 --dport 22 --sport 1024:65535 -m
> state --state NEW -j ACCEPT
> /sbin/iptables -A INPUT -p tcp -i eth0 --dport 80 --sport 1024:65535 -m
> state --state NEW -j ACCEPT

These rules will allow incoming connections to ports 22 and 80, BUT the
--state rule limits this to only new connections. Once the connection is
established, this rule is ignored. So your external clients can connect
to the server, but cannot send any actual data to it!

I think you need an additional rule which looks like this:

iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

(I haven't tried any of this out btw; it's just some educated guesswork
after looking at your firewall rules.)

--
rd.


--
To UNSUBSCRIBE, email to [email]debian-user-request@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]