LAN pass, but not loopback

LAN pass, but not loopback

[un_brice]

Hi,
I'm currently trying to discover iptables. In that aim I created a little 
script to "protect" my lan (4 computers).
It became pretty complex with the time, but remain clean... and should work, 
at least I think.
The problem is it doesn't : it contain, among other things
#Loopback interface
iptables -A INPUT -o lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
[..]
#Apache
iptables -A INPUT -p tcp --dport http -m connlimit ! --connlimit-above 40 \
-j ACCEPT

From the inside, wget http://my_server works as it should, from outside also, 
but not from the computer himself !
For the same reason (i think) Samba cannot connect to CUPS... and I've many 
other problems.
I've tried as I could to understand this problem but failed. On the other 
hand, each time I suspected a bug in a complex software (iptables here), I 
was wrong.
So, if one would have time to tell me were... mummy would be very happy as she 
could print again -_^.

Sorry for my bad english. You can read the whole script at 
http://98111.free.fr/serv/served/iptables.en.sh , I tried to traduce comments 
in english but I'm not sure of the result.

By the way, what do you think of the way I tried to reduce the overload due to 
TARPIT ? Would it work ?

Thanks !
Brice

-- 
"Emacs is my operating system, and Linux its device driver."
 -- Bake Timmons

Re: LAN pass, but not loopback

[Taylor, Grant]

> The problem is it doesn't : it contain, among other things
> #Loopback interface
> iptables -A INPUT -o lo -j ACCEPT
> iptables -A OUTPUT -o lo -j ACCEPT
> 
> From the inside, wget http://my_server works as it should, from outside also, 
> but not from the computer himself !
> For the same reason (i think) Samba cannot connect to CUPS... and I've many 
> other problems.
> I've tried as I could to understand this problem but failed. On the other 
> hand, each time I suspected a bug in a complex software (iptables here), I 
> was wrong.
> So, if one would have time to tell me were... mummy would be very happy as she 
> could print again -_^.

What interface / IP do you have Apache, Samba, and CUPS listening on?  I am willing to bet that they are not listening on lo (127.0.0.1).  The reason that I ask is that I'm betting that your services are trying to talk to each other on your internal LAN interface (eth1).  You might also want to try setting a filter:FORWARD policy of ACCEPT for testing to see if things start working again.

> By the way, what do you think of the way I tried to reduce the overload due to 
> TARPIT ? Would it work ?

I like the way that you are using a subchain to do your possible TARPITing and jumping to that chain from all your other chains that you want to TARPIT the traffic from.  However I think you might want to emulate this functionality in the raw table so that you can send the traffic that you would want to send to the TARPIT target to the NOTRACK state to prevent the connection tracking subsystem form consuming resources tracking said traffic.  The basic idea behind this is laid out below:

iptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
iptables -t filter -A INPUT -p tcp --dport 80 -j TARPIT
iptables -t filter -A FORWARD -p tcp --dport 80 -j TARPIT

This will cause any web traffic (Code Red, etc.) that would be destined to your firewall to be sent to the TARPIT target with out consuming any connection tracking resources as they are told to not be tracked via the NOTRACK target in the raw:PREROUTING table and chain.



Grant. . . .