iptables newbie

There's an enormous amount of documentation on iptables -- I
need a little less of it, so to speak. I just want to know
if there are any plausible attacks on my setup, which I have
set, if I understand it correctly, to reject all incoming
TCP packets that attempt to start a connection, all
packets that want to be forwarded, and all ip6 packets
whatsoever. For example, can connections be started
via *non*-TCP packets? (Dropping all non-TCP packets
seems to break the internet completely.) Or, can non-SYN
TCP packets do mischief? Or, have I just misunderstood
the syntax somewhere? Thanks for any help.

Output of iptables-save:

# Generated by iptables-save v1.2.9 on Sat May 15 14:57:39 2004
*filter
:INPUT ACCEPT [2676:2951669]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2268:192717]
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j REJECT
--reject-with icmp-port-unreachable
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Sat May 15 14:57:39 2004

Output of ip6tables-save:

# Generated by ip6tables-save v1.2.9 on Sat May 15 15:00:11 2004
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:232]
-A INPUT -s ::/0 -d ::/0 -j DROP
-A FORWARD -s ::/0 -d ::/0 -j DROP
COMMIT
# Completed on Sat May 15 15:00:11 2004

A horsie named Mike Oliver demonstrated surprising intellligence and
its ability to use morse code on Sat, 15 May 2004 15:00:54 -0500, when it
tapped <2gnb7mF4k9hdU1@uni-berlin.de> with its hoof:

> [...]
> to reject all incoming
> TCP packets that attempt to start a connection, all
> packets that want to be forwarded, and all ip6 packets
> whatsoever. For example, can connections be started
> via *non*-TCP packets? (Dropping all non-TCP packets
> seems to break the internet completely.) Or, can non-SYN
> TCP packets do mischief? Or, have I just misunderstood
> the syntax somewhere? Thanks for any help.
>

I'm only slightly less of an iptables newbie than you
are, but this is something like what I did:

# Disable everything by default.
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Start with a new, empty table.
# Clear all rules and delete all user defined chains.
iptables -F
iptables -X

# Enable output to a few selected ports and established
# connections.
iptables -A OUTPUT -m multiport -p tcp -j ACCEPT --destination-port \
www,smtp,ftp,ftp-data,pop3,nameserver,domain,443,netbios-ssn
iptables -A OUTPUT -m multiport -p udp -j ACCEPT --destination-port \
domain,netbios-ns
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Enable input for established connections only.
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


My actual firewall code is quite a bit more complicated because
there are other services that I want to use, and I want to see
who's probing me.

> Output of iptables-save:
>
> # Generated by iptables-save v1.2.9 on Sat May 15 14:57:39 2004
> *filter
> :INPUT ACCEPT [2676:2951669]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [2268:192717]
> -A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j REJECT
> --reject-with icmp-port-unreachable

It's safer to reject everything by default and enable only
those ports that you want to. Although I used to, I no longer
REJECT packets; I just drop 'em.

If someone is trying to telnet into my computer, there's no
reason for me to let them know that there even is a computer at
my IP address.

> -A FORWARD -j REJECT --reject-with icmp-port-unreachable
> COMMIT
> # Completed on Sat May 15 14:57:39 2004
>
> Output of ip6tables-save:
>
> # Generated by ip6tables-save v1.2.9 on Sat May 15 15:00:11 2004
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [4:232]
> -A INPUT -s ::/0 -d ::/0 -j DROP
> -A FORWARD -s ::/0 -d ::/0 -j DROP

Hmm, interesting. I hope that my code disables IPv6 by default,
or I might be in for a surprise!

Gary Petersen wrote:

> I'm only slightly less of an iptables newbie than you
> are, but this is something like what I did:
>
> # Disable everything by default.
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -P OUTPUT DROP
>
> # Start with a new, empty table.
> # Clear all rules and delete all user defined chains.
> iptables -F
> iptables -X
>
> # Enable output to a few selected ports and established
> # connections.
> iptables -A OUTPUT -m multiport -p tcp -j ACCEPT --destination-port \
> www,smtp,ftp,ftp-data,pop3,nameserver,domain,443,netbios-ssn
> iptables -A OUTPUT -m multiport -p udp -j ACCEPT --destination-port \
> domain,netbios-ns
> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> # Enable input for established connections only.
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

OK, so I started with this and got something working, I think.
I had to accept input packets with source 127.0.0.1 and output
packets with destination 127.0.0.1 or KDE wouldn't let me
login. Also I added a rule to accept all ICMP output packets;
otherwise I couldn't use ping. Is that last one too liberal,
do you think? Before I hadn't had any controls on outgoing
packets at all; I guess it's not a bad idea to add them, although
I'm not convinced they do that much good -- by my logic they
help only if you've got some sort of trojan code on your system
sending out passwords or something, and in that case I'm sure
it could be arranged to send it to one of the ports being allowed.

Mike Oliver <mike_lists@verizon.net> said:
>Gary Petersen wrote:
>> I'm only slightly less of an iptables newbie than you
>> are, but this is something like what I did:

And that's a pretty good starting point!

>> # Disable everything by default.
>> iptables -P INPUT DROP
>> iptables -P FORWARD DROP
>> iptables -P OUTPUT DROP
>>
>> # Start with a new, empty table.
>> # Clear all rules and delete all user defined chains.
>> iptables -F
>> iptables -X
>>
>> # Enable output to a few selected ports and established
>> # connections.
>> iptables -A OUTPUT -m multiport -p tcp -j ACCEPT --destination-port \
>> www,smtp,ftp,ftp-data,pop3,nameserver,domain,443,netbios-ssn
>> iptables -A OUTPUT -m multiport -p udp -j ACCEPT --destination-port \
>> domain,netbios-ns
>> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>> # Enable input for established connections only.
>> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
>OK, so I started with this and got something working, I think.
>I had to accept input packets with source 127.0.0.1 and output
>packets with destination 127.0.0.1 or KDE wouldn't let me
>login.

Rather than addresses, use interfaces. It's possible to use faked sender
addresses (I even see some packets occasionally with 127.0.0.1 as the sender
address), but interfaces cannot be faked, so you might consider allowing
everything that arrives from 'lo':
iptables -A INPUT -i lo -j ACCEPT

>Also I added a rule to accept all ICMP output packets; otherwise I
>couldn't use ping.

If you want to maintain the strict policy used by Gary, you might
limit that to only allow icmp echo request.

>Is that last one too liberal, do you think? Before I hadn't had any
>controls on outgoing packets at all; I guess it's not a bad idea to add
>them, although I'm not convinced they do that much good -- by my logic
>they help only if you've got some sort of trojan code on your system
>sending out passwords or something, and in that case I'm sure it could
>be arranged to send it to one of the ports being allowed.

It's pretty much your call -- the input rules written by Gary are pretty
equivalent to what I've been using for couple of years now, without
incidents. I seem to agree pretty much with your opinion on limiting
the outgoing traffic, but nevertheless, Garys solution is "the complete
one".

About IPv6, if you're not using it, disable it and stop worrying.
Check with f.ex. "ip -f inet6 addr".
--
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)

A horsie named Mike Oliver demonstrated surprising intellligence and its
ability to use morse code on Sun, 16 May 2004 02:50:03 -0500, when it
tapped <2gokp8F508qaU1@uni-berlin.de> with its hoof:


> OK, so I started with this and got something working, I think. I had to
> accept input packets with source 127.0.0.1 and output packets with
> destination 127.0.0.1 or KDE wouldn't let me login. Also I added a rule
> to accept all ICMP output packets; otherwise I couldn't use ping. Is
> that last one too liberal, do you think?

I don't know enough about ICMP to say, except that you probably want to
limit the number of outgoing ICMP packets to prevent yourself from
becoming an unwitting participant in a DDoS attack.

Refer to this,

From: Brad Olin <bwo@bwo1.com>
Newsgroups: comp.os.linux.security
Subject: Re: ipchains question
Message-ID: <cue7a05omtnvq8adn4l97nrr41eobbfn1r@4ax.com>

> Before I hadn't had any controls on outgoing packets at all; I guess
> it's not a bad idea to add them, although I'm not convinced they do that
> much good -- by my logic they help only if you've got some sort of
> trojan code on your system sending out passwords or something, and in
> that case I'm sure it could be arranged to send it to one of the ports
> being allowed.

You're right. I hadn't thought about that. I imagine that output
restrictions might stop badly written trojans that use specific, odd
ports, but what if they connect to remote port 80? I wonder under what
conditions output restriction does any good?

Juha Laiho wrote:
> Mike Oliver <mike_lists@verizon.net> said:
>>OK, so I started with this and got something working, I think.
>>I had to accept input packets with source 127.0.0.1 and output
>>packets with destination 127.0.0.1 or KDE wouldn't let me
>>login.
>
>
> Rather than addresses, use interfaces. It's possible to use faked sender
> addresses (I even see some packets occasionally with 127.0.0.1 as the sender
> address), but interfaces cannot be faked, so you might consider allowing
> everything that arrives from 'lo':
> iptables -A INPUT -i lo -j ACCEPT

Thanks. How much do you think that opened up my system when I was
accepting everything from 127.0.0.1? If, say, someone tried
to open an ssh session masquerading as 127.0.0.1, then the
return packets would go to 127.0.0.1 and not to the attacker,
right?

I've looked through /var/log/auth.log and seen no suspicious
ssh sessions (and I *think* ssh is the only service I've got
running that would even respond to connection requests). I
suppose if an attacker got root access, /var/log/auth.log is
the first thing he'd change, but I kind of doubt anyone managed
to match me up with my root pword in the time my machine's
been up.

>>Also I added a rule to accept all ICMP output packets; otherwise I
>>couldn't use ping.
>
>
> If you want to maintain the strict policy used by Gary, you might
> limit that to only allow icmp echo request.

How do I allow traceroute?

A horsie named Mike Oliver demonstrated surprising intellligence and
its ability to use morse code on Sun, 16 May 2004 02:50:03 -0500, when it
tapped <2gokp8F508qaU1@uni-berlin.de> with its hoof:

>
> OK, so I started with this and got something working, I think.
> I had to accept input packets with source 127.0.0.1 and output
> packets with destination 127.0.0.1 or KDE wouldn't let me
> login. Also I added a rule to accept all ICMP output packets;
> otherwise I couldn't use ping. Is that last one too liberal,
> do you think?

Limit the number of possible pings if you can.
See this to find out why:

----- From: Brad Olin <bwo@bwo1.com>
----- Newsgroups: comp.os.linux.security
----- Subject: Re: ipchains question
----- Message-ID: <cue7a05omtnvq8adn4l97nrr41eobbfn1r@4ax.com>

> Before I hadn't had any controls on outgoing
> packets at all; I guess it's not a bad idea to add them, although
> I'm not convinced they do that much good -- by my logic they
> help only if you've got some sort of trojan code on your system
> sending out passwords or something, and in that case I'm sure
> it could be arranged to send it to one of the ports being allowed.

Now that I think about it, you are right. Badly written trojans
that use strange addresses such as 5554 might be blocked, but what
if they go out to port 80?

A horsie named Mike Oliver demonstrated surprising intellligence and its
ability to use morse code on Sun, 16 May 2004 02:50:03 -0500 when it
tapped <2gokp8F508qaU1@uni-berlin.de> with its hoof:

>
> OK, so I started with this and got something working, I think. I had to
> accept input packets with source 127.0.0.1 and output packets with
> destination 127.0.0.1 or KDE wouldn't let me login. Also I added a rule
> to accept all ICMP output packets; otherwise I couldn't use ping. Is
> that last one too liberal, do you think?

Brad Olin showed us a way to control outgoing icmp packets
by controlling incoming icmp packets. Refer to this:

----- From: Brad Olin <bwo@bwo1.com>
----- Newsgroups: comp.os.linux.security
----- Subject: Re: ipchains question
----- Message-ID: <cue7a05omtnvq8adn4l97nrr41eobbfn1r@4ax.com>

> Before I hadn't had any
> controls on outgoing packets at all; I guess it's not a bad idea to add
> them, although I'm not convinced they do that much good -- by my logic
> they help only if you've got some sort of trojan code on your system
> sending out passwords or something, and in that case I'm sure it could
> be arranged to send it to one of the ports being allowed.

Now that I've thought about it, you're right. While the restricted
output rules will stop badly written trojans that use strange
ports like 5554, what if it goes out to port 80?

I've collected some of the thoughts of the people in this thread
and combined them into a script that might be useful for
"iptables newbies" :)

Here it is:

#!/bin/sh
# Disable everything by default.
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Start with a new, empty table.
# Clear all rules and delete all user defined chains.
iptables -F
iptables -X

# This enables ftp in active mode.
# Without this, ftp will still work in passive mode.
modprobe ip_conntrack_ftp

# Allow anything to go out.
iptables -A OUTPUT -j ACCEPT

# Enable input for established connections and the
# loopback interface.
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow certain inbound ICMP types, but limit echo requests
# to prevent DoS attacks.
iptables -A INPUT -p icmp --icmp-type echo-request \
-m limit --limit 10/second -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

# This allows you to get onto IRC.
iptables -A INPUT -p tcp --dport auth -j REJECT \
--reject-with tcp-reset


What do you guys think about this?
Is this a good script for newbies to use?
Does it do enough to teach them about iptables?

A horsie named Gary Petersen demonstrated surprising intellligence and its
ability to use morse code on Sun, 16 May 2004 17:09:55 -0500 when it
tapped <pan.2004.05.16.20.48.54.361636.1015@DELETE.THISea rthlink.NOSPAM>
with its hoof:

> # Allow anything to go out.
> iptables -A OUTPUT -j ACCEPT

Whenever I look at this I shudder. This makes me feel better:

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m multiport -p tcp -j ACCEPT --destination-port \
www,smtp,ftp,ftp-data,pop3,nntp,nameserver,domain,443,netbios-ssn
iptables -A OUTPUT -m multiport -p udp -j ACCEPT --destination-port \
domain,netbios-ns
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Yes, I know that a properly written trojan would go out on the
www port, but even a badly written trojan can ruin your entire day.