If you didn't believe in strict OUTPUT filtering

If you didn't believe in strict OUTPUT filtering

Post by Ian Jone » Fri, 10 May 2002 09:34:11



A recently released security advisory for netfilter/iptables might
convince you that it is a good idea. From the netfilter list:

----------------------------------------------------------------------
               Cartel Scurit --- Security Advisory

Advisory Number: CARTSA-20020402
Subject:         Linux Netfilter NAT/ICMP code information leak

Discovered:      2002, April 2
Published:       Not yet
----------------------------------------------------------------------

NOTE: Do not release in public before May 8, 2002.

Problem description
===================

The following bug exists in the netfilter NAT implementation: When the
first packet of a connection is hitting a NAT rule, and this packet
causes the NAT box itself to reply with an ICMP error message, the
inner IP packet inside the ICMP error message is not un-NAT'ed
correctly.  This leads to the ability to discover which ports of a
host are NATed and where the packet will really go. This can also lead to
those ICMP error packets being dropped by stateful firewalls not
recognizing
the related connection.

Vulnerable versions
===================

All kernel patches from iptables package < ipables-1.2.6a are vulnerable.
All versions of kernel >= 2.4.4 and up to (at least) 2.4.19-pre6 use a
vulnerable version.

Vendor status
=============

The netfilter team has solved this bug with a patch that has been refused
for inclusion in the linux kernel. They are working on a new patch.

Solutions
=========

* Use the attached patch
* Upgrade your kernel using the patch at
  http://www.netfilter.org/security/2002-04-02-icmp-dnat.html
  (link active starting with May 8)
* Use a workarround until the final solution to this bug is implemented
  and included in the linux kernel source

Workarounds
===========

Filter out untracked local packets:
iptables -A OUTPUT -m state -p icmp --state INVALID -j DROP

Example
=======

Let's take a machine (172.16.1.40) that DNAT port 666 to 172.16.3.26:22 :
iptables -t nat -A PREROUTING -p tcp --dport 666 -j DNAT --to
172.16.3.26:22

Then if a host sends a packet that will die on 172.16.1.40 :
hping  -t 1 --syn -p 666  172.16.1.40

This is the icmp packet we'll get from 172.16.1.40 :
17:07:46.709230 172.16.1.40 > 172.16.1.28: icmp: time exceeded in-transit
0x0000   45c0 0044 eaa6 0000 ff01 75f1 ac10 0128        E..D......u....(
0x0010   ac10 0118
                   0b00 516d 0000 0000
                                       4500 0028        ......Qm....E..(
0x0020   b0f3 0000 0106 ac8a ac10 0118 ac10 031a <-+    ................
0x0030   04bd 0016 3206 3ec0 0490 00b4 5002 0200   |    ....2.>.....P...
0x0040   d6b2 00^0                                 |    ....
                |                            172.16.3.26
                +-- port 22

You can also try a patch to nmap that does that and much more :
http://www.cartel-info.fr/pbiondi/nmap/

# ./nmap -sS -P0 xxx.xxx.xxx.xxx -p 22,23,666,667 -t 9

Starting nmap V. 2.54BETA32 ( www.insecure.org/nmap/ )
Interesting ports on xxx.xxx.xxx.xxx:
Port       State       Service
22/tcp     open        ssh
23/tcp     filtered    telnet
666/tcp    UNfiltered  unknown                  DNAT to 192.168.8.10:22
667/tcp    UNfiltered  unknown                  DNAT to 192.168.26.10:22

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

 
 
 

1. Odd 'w', 'who' and 'tty' output

Please forgive me if I'm just being thick and missing a simple OS "normal
thing" but I don't remember this in any of my *nix training years back...(it
was 16 years ago we covered this basic stuff and X wasnt around then, least
not in my industry)

The scene: I'm on my home LAN with a remote X session open in X-Win32 and
"as far as I know" there's no other logons or sessions or anything anywhere
else. All my other home machines are switched off and they ended their last
sessions cleanly, my firewall is showing normal operations and there doesn't
seem to be anything else strange anywhere. I've both nmap'd and nessus'd the
box from both inside and outside and I've hackerwhacker'd it. Clean. even
traffic on external NIC is "normal" (arps and bootp).

In my X session all I've got running is my firewall GUI and an Xterm window.

What I'm seeing:
I can do a 'tty' in my xterm window it shows me (e.g.) /dev/pts/1

If I do a 'who' it shows me two logons,

root on pts/0
(me) on pts/1

Now it's showing (me) as not root (even though I am on as root for the
moment) but as another name and that name happens to be the windows logon
name. I thought the name shown was the name you're logged on as in Linux. I
logged directly onto root not su via this other name (you can't do this from
the external NIC on my box before anyone tries!)

More odd, when I do a 'w' it shows just one line, root running 'cat', on
pts/0.

So, why doesn't 'w' show me running what I'm running? Why does 'who' show a
logon on a console that I'm not on, and why might 'cat' be running? This
happens a lot so I thought I'd best check it out on this NG to see if I'm
either being extremely thick and misunderstanding a very simple core Linux
basic thing and should go back to school and not come out until I can use an
ls command, OR, is something whacky going on?

Oh, and now you know so much about my IP address and my box I'm going to get
another DHCP lease and exit all my "known" root sessions, and change the
passwords! ;)

TIA
Doc
---
registered Linux user #223480

2. Netgear NIC FA311 and SUSE Linux 7.0 Professional

3. Why does 'ls' give '/' as the output?

4. 2.1.8: syn_recv: too many retransmits

5. How to 'flush' output of 'C' cgi-program

6. Kernel 1.3.7 problem: setterm

7. 'top' output -> High CPU consumption when thread is in 'sleep' state

8. Florida School Deploys KDE/GNU/Linux On Thin Clients

9. What's 'side effects' of Ksh built-ins?

10. Why does 'ls' give '/' as the output?

11. filter output of /dev/console ?

12. Output Filters for lpsched?

13. anyone have ditroff output filter for Epson printers?