iptables newbie

Mike Oliver <mike_lists@verizon.net> wrote in message news:<2gpl4sF59fujU1@uni-berlin.de>...
....
> How do I allow traceroute?

Hi,

to allow traceroute, on a Linux box (Fedora Core 1, and I use/used
the same rule under Red Hat 8 and 9), that acts only as a client
(I can "traceroute" anywhere I want, but I don't know wether other
can "traceroute" too this client), here's what I have to allow
traceroute :


$IPT -A INPUT -p icmp --icmp-type 30 -j ACCEPT30

$IPT -A OUTPUT -p udp --sport 32769:65535 --dport 33434:33523 \
-m owner --uid-owner root -m state --state NEW -j ACCEPT

and some "related" traffic alowed rule somewhere else.

Traceroute use the UDP protocol on a variety of ports (it is
possible to refine the ports used according to your Unix version).

The traceroute command, on Red Hat / Fedora (and I suppose many
other Unixes), even when lauched as a non-privileged user, is
generating traffic belonging to "uid-owner root" (in iptables
parlance). So I have this rule to prevent normal users from generating
unwanted UDP traffic to too many ports...

There's somewhere else a rule allowing established traffic to come
in.

ICMP type 30, as specified in RFC 1393, seems to be mandatory for
traceroute (I never tried without this rule though).


Cya,

Jean

Mike Oliver <mike_lists@verizon.net> writes:

>> 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?

Depends if you have rp_filter enabled, and whether the packets had
localhost as source *and* were source-routed or not, and if so whether
you're dropping source-routing, too.

In general, it's unlikely to pose a major threat, but that's no reason not
to tighten-down on it, especially since the rp_filter and source-routing
screws do more than influence just 127.0.0.1.

[snip]

~Tim
--
Crossing the river, caught in the rain |piglet@stirfried.vegetable.org.uk
Crossing the rhythm, caught in the rain. |http://pig.sty.nu/Pictures/

Gary Petersen <garyp1492@delete.thisearthlink.nospam> writes:

[snip]
>> 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?

Rate-restrict them? Actually, I have rate-limiting on all outgoing UDP and
should probably check that I have it on ICMP as well.

There are one or two concerns - it breaks traceroute / mtr if you exceed
the rate (e.g. 5 packet/s might be too much), but also you couldn't really
get used as an amplifier if someone on your network starts broadcasting
invalid packets around, either. And if you get a local trojan / infestation
of some sort, it restricts the public humiliation/risk as well, assuming
you notice it in time (so READ YOUR LOGFILES! ;) .

~Tim
--
Our moments are rush and gone |piglet@stirfried.vegetable.org.uk
All our pictures incomplete |http://pig.sty.nu/Pictures/

Mike Oliver <mike_lists@verizon.net> said:
>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?

Right abount where the response packets go -- so there's not much one can
do with 127.0.0.1 source address -- with TCP you couldn't complete a session
handshake; with UDP something nasty might be within possibilities, but
not probable. 127.0.0.1 is something I see on my firewall perhaps
twice a month.

>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).

"netstat -l" will show all listening sockets on your machine.

>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.

Yep, if it really is so that you only have ssh available to the
outside, then pretty much all attempts are visible in auth.log
(and it would make sense to clean it as one of the first jobs
once a system is compromised).

>>>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?

For this I think you already got a response, so you'll need to allow
a certain range of outgoing UDP ports (but hey, you already allowed
all outgoing), and you'll need to allow inbound ICMP destination
unreachable and ICMP time exceeded subtypes (best way to allow these
ICMP subtypes is the RELATED,ESTABLISHED rule in the input chain,
that way only such ICMP messages that are related to outbound session
attempts are accepted).
--
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)

Gary Petersen <garyp1492@delete.thisearthlink.nospam> said:
>> # 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.

I'd consider it strange for a trojan author to use something else than
a commonly-used port. Also, the icmp types you listed should be already
covered by the RELATED,ESTABLISHED rule (as those would be things that
your host send out in response to some earlier inbound traffic).
--
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)

Juha Laiho wrote:
> Mike Oliver <mike_lists@verizon.net> said:
>>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).
>
>
> "netstat -l" will show all listening sockets on your machine.

Once again, the command outputs a lot of information that I don't
know how to interpret. What's .ICE-unix? What's ksocket-oliver (oliver
is my userid)? What's mcop-oliver? Why does ssh-agent
need to be listening (I'm using only outbound ssh)? Why
do .font-unix, .X11-unix and /dev/printer need to be listening
at ports? I think that's all the ones that showed up.

A horsie named Mike Oliver demonstrated surprising intellligence and its
ability to use morse code on Mon, 17 May 2004 13:51:25 -0500 when it
tapped <2gsfteF6b9pfU1@uni-berlin.de> with its hoof:

> Juha Laiho wrote:
>> Mike Oliver <mike_lists@verizon.net> said:
>>>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).
>>
>>
>> "netstat -l" will show all listening sockets on your machine.
>
> Once again, the command outputs a lot of information that I don't know
> how to interpret. What's .ICE-unix? What's ksocket-oliver (oliver is
> my userid)? What's mcop-oliver? Why does ssh-agent need to be
> listening (I'm using only outbound ssh)? Why do .font-unix, .X11-unix
> and /dev/printer need to be listening at ports? I think that's all the
> ones that showed up.

..ICE-unix is used by XWindows (locally)
ksocket-oliver -> means that you are a KDE user.
mcop-oliver -> another kde unix socket

netstat -l gives you too much information. To get a list of only TCP
listening sockets, do

netstat -tl

But first, I'd advise "man netstat"

command action
------- ---------
netstat -tl show TCP listening sockets
netstat -ul show UDP listening sockets
netstat -xl show unix domain listening sockets

Unix domain sockets are limited to the local machine--ignore them.

Good luck

Gary Petersen wrote:

> netstat -l gives you too much information. To get a list of only TCP
> listening sockets, do
>
> netstat -tl

Ah, seems I had ignored the actual internet sockets. The
TCP listening sockets are

localhost:738
*:printer
*:time
*:discard
*:877
*:daytime
*:sunrpc
*:auth
localhost:smtp

The UDP ones are

*:discard
*:bootpc
*:871
*:874
*:sunrpc

Not clear to me whether any of these are cause
for concern.

Mike Oliver wrote:
> Gary Petersen wrote:
>> netstat -l gives you too much information. To get a list of only TCP
>> listening sockets, do
>>
>> netstat -tl
>
> Ah, seems I had ignored the actual internet sockets. The
> TCP listening sockets are
>
> localhost:738
> *:printer
> *:time
> *:discard
> *:877
> *:daytime
> *:sunrpc
> *:auth
> localhost:smtp

So can anyone tell me what these ports 738 and 877 are for? (My system
is Debian Sarge). nmap shows them as well, and says the
service is "unknown".

run netstat -tlp
you will be able to see the program which opened that port.
According to my services file, there is no well known service for port 738
and 877.

Andrew

"Mike Oliver" <mike_lists@verizon.net> wrote in message
news:2i4t6cFja8plU1@uni-berlin.de...
> Mike Oliver wrote:
> > Gary Petersen wrote:
> >> netstat -l gives you too much information. To get a list of only TCP
> >> listening sockets, do
> >>
> >> netstat -tl
> >
> > Ah, seems I had ignored the actual internet sockets. The
> > TCP listening sockets are
> >
> > localhost:738
> > *:printer
> > *:time
> > *:discard
> > *:877
> > *:daytime
> > *:sunrpc
> > *:auth
> > localhost:smtp
>
> So can anyone tell me what these ports 738 and 877 are for? (My system
> is Debian Sarge). nmap shows them as well, and says the
> service is "unknown".