Re: Babysitting on iptables requested :-)
From: Carlos Moreno (moreno_at_mochima_dot_com_at_xx.xxx)
Date: Fri, 25 Apr 2003 12:40:00 -0400
Juha Laiho wrote:
> email@example.com (Peet Grobler) said:
>>On Wed, 23 Apr 2003 17:30:01 -0400, Carlos Moreno
>>>Shields Up reports my machine 100% stealth, and I do have the
>>>usual functionality (i.e., I can do whatever I want from my LAN).
> Actually Shields Up isn't testing that thoroughly..
What kind of limitations does it have? Anything one should be
> have "-m state --state INVALID -j DROP" always just before the
> "-m state --state ESTABLISHED,RELATED -j ACCEPT".
Allow me to double check if I understood correctly; it first
confused me, since the states should be mutually exclusive, and
so, if it is invalid, it should not be accepted by the EST,REL
But I guess you mean that an invalid packet could slip through
this and be accepted later because it matches the other criteria
for acceptance? (e.g., an invalid packet to port 22 might be
accepted and get me in trouble?)
>>>iptables -A INPUT -p tcp --dport 22 -j ACCEPT
>>>iptables -A INPUT -p tcp --dport 10112:10115 -j ACCEPT
>>> # Ports 10112 to 10115 are used by a custom application that I
>>> # developed, and I often use my home machine for debugging tests.
>>You should specify it like this:
>>iptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPT
>>iptables -A INPUT -p tcp -i eth0 --dport 10112:10115 -j ACCEPT
>>e.g. add the source interface aswell. Makes it simpler to manage.
> If I read his set-up correctly, the interface is redundant here;
> everything else but eth0 is already handled. However, what is missing
> is that here you should only accept SYN packets, i.e. "--syn" should
> be added to flags. This is to prevent some forms of not-so-visible
Didn't understand that part. What are SYN packets, and why should
I only allow those? (just a pointer to where to read some more about
that subject would be great)
>>>iptables -A FORWARD -i eth1 -j ACCEPT
> This depends on what kind of machines you have in your local LAN, but
> if there's anything from Microsoft, you might like to block anything
> that is destined to port range 137-139, tcp as well as udp, incoming
> as well as outgoing. These ports are used for authentication services
> between Windows machines, so without this a Windows machine in your
> internal network might leak sensitive data to outside your network.
> However, this also prevents the Windows file/printer sharing protocols
> across your firewall machine, so if this is something you're depending
> on, you'll have to reconsider.
I do have dual-boot machines (both mine and my wife's), and we do
share files and printers across the Windows machines. Should I
then place rules to the forward chain only? (that is, because I
want the internal "Microsoft network" to keep its functionality).
Would something like this suffice?
iptables -A FORWARD -i eth1 -p tcp --dport 137:139 -j REJECT # or DROP
iptables -A FORWARD -i eth1 -p udp --dport 137:139 -j REJECT
iptables -A FORWARD -i eth1 -j ACCEPT
After all, *any* incoming packet requesting a connection from
the outside world to my gateway will be rejected, right? So,
even if some day I decide to fire up Samba on my gateway, my
current script (with the added couple of lines above) should
still be safe, right? MS packets from my LAN to the gateway
will be accepted, from my LAN to the outside world will be
rejected (by the above rules), and from the outside world to
the gateway, will be rejected by default (unless they're
related, but they can't be related, since no connection from
the LAN to the outside world (on those ports) was ever allowed.
Is my reasoning correct?
>>> # This one seemed necessary, or apache would not respond (is there
>>> # a way to set it up such that it would accept it, but only if it
>>> # came through port 1234, and not if it came directly to port 80?)
> Haven't tried this, but would it work to drop or reject packets destined
> to port 80 in nat PREROUTING table before you do the redirect?
Interesting... Sounds like it should work. I'm going to try it
(shouldn't be necessary, since my ISP is firewalling incoming
requests to port 80 anyway... But just in case they change that
in the future, I wouldn't like outsiders to know that I'm running
apache, if I ever neglect/forget to upgrade my version of apache
when a vulnerability was found -- and changing apache's config to
have it run in another port seems much more complicated than a
simple line in the iptables script :-))
> No major problems; my suggestions can be considered to be fine-tuning.
I greatly appreciate your comments (Peet's messages too!!) and
your advice! This stuff scares me, because it is the kind of
thing in which beginner's mistakes are extremely dangerous!!
(they can easily go unnoticed and put your machines in danger)