Re: Babysitting on iptables requested :-)
From: Juha Laiho (Juha.Laiho_at_iki.fi)
Date: Fri, 25 Apr 2003 19:12:01 GMT
Carlos Moreno <email@example.com> said:
>Juha Laiho wrote:
>> firstname.lastname@example.org (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
Here's the list of ports that I see probed then I take the "Probe my
ports" at GRC ShieldsUp:
While these cover the most common services, much could be run outside these.
For example, it's not uncommon to see WWW servers at port 8080 - and that is
not probed. All in all, TCP and UDP allow for 65535 (or 65536?) distinct
ports - and GRC checks 13 of them.
Additionally, this was a friendly probe; all packets were TCP SYNs -
nothing "special" was attempted. This definitely wasn't someone _really_
wanting to find a way to get through. For example, TCP source ports for
all the packets were "regular".
>> 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
They are -- I just like to drop known bad data as soon as possible.
>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?)
As it's in an invalid protocol stage, apparently it would drop to the
floor at some point anyway. But until that it'll consume your resources.
And there's always the possibility of a software bug letting a "correctly"
crafted invalid packet do some harm. So, if you can recognise it as
bad, just drop it.
>>>>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)
SYN is a packet that is used to initiate a TCP connection. So, the
computer initiating a connection will send a SYN packet to the
destination, telling there the destination port number etc. The
"destination" will respond to this with SYN-ACK, and after this
the initiating computer will finally be able to open the connection
by sending an ACK packet. "TCP/IP Illustrated" by Stevens should be
one of the best references for these, but it's rather expensive.
The problem here is that iptables has it's own concept of "connection",
not compatible with the TCP connection. unless you specifically require
SYN packet in the above rules, then from the iptables point-of-view just
any packet will open a connection (though the "INVALID" rule should
drop some of these). And with a connection open from the iptables
point-of-view, more packets can be sent; mostly to analyse how your
computer reacts to bad packets. Specifying the --syn will make it so
that iptables will open connection for further packets only upon seeing
a TCP SYN packet - as no other TCP packet can be used for initiating a
connection. So, definitely not a major problem, but perhaps a bit more
than mere cosmetics.
>>>>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
Here, to keep on the safe side, drop the "-i eth1" from the REJECT
rules, so the packets are dropped in both directions. The internal
network will still be ok, as these are only used for packets travelling
from the other machines within your LAN to the Internet.
>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?
It is correct -- but this is again one more set of handcuffs.
So, this as a rule is simple enough that it more or less cannot fail,
even if some other problem was found.
>>>> # 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 :-))
Putting your Apache onto a non-default port will slow down finding it.
But in whichever port you have it, it is possible that someone will
just point some real scanner (like nmap) at your machine and tell it
to go through all those 64k ports where a program might be listening.
At that point at least the scanner will notice that on port 1234 there
is _some_ program listening. After that it'd be possible to test some
of the more common protocols to that (HTTP certainly would be one of
the first) to see if it generates any understandable responses.
But then, these full-blown scans are rare occurrences. Most of what I
see in my logs are various Windows worms looking for new targets.
Perhaps once a month I see something "interesting". But then, the
machine must look very dull indeed, as it doesn't provide any network
services to the general public (the services it offers are at iptables
level restricted to IP ranges). So, if you happen to connect from
somewhere outside that range, you don't see anything.
>> 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)
it took me some time to gather this info on iptables (it mostly
was on the Web, but not in a single place). Now that I have it,
I'll try to share it as a set - and also develop that base config
I previously posted in case I learn something new.
Perhaps I should set up a web page on these, but at least currently
a certain form of laziness wins.
-- 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)