Debian 2.1 ipmasq security bug?

Debian 2.1 ipmasq security bug?

Post by Georg Schwa » Sun, 12 Mar 2000 04:00:00



I've set up a system with Debian 2.1 Linux (kernel 2.0.38). It's acting
as a dialup/masquarading router/firewall between an internal ethernet
LAN (192.168.0.0/24) and a PPP dialup (local IP [part of a class B
network in this case] is, say, 333.333.333.333). I'm using the stock
Debian ipmasq package with default setup (which might be my fault, one
might argue). /etc/ipmasq/ppp exists.
Now when the PPP link is up, the firewall settings look as follows:

# ipfwadm -I -l -n -e
IP firewall input rules, default policy: deny
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress       source
destination          ports
    6   396 acc   all  ---- 0xFF 0x00 lo      0.0.0.0         0.0.0.0/0
0.0.0.0/0            n/a
12828  642K acc   all  ---- 0xFF 0x00 eth0    0.0.0.0
192.168.0.0/24       0.0.0.0/0            n/a
 5329 2364K acc   all  ---- 0xFF 0x00 ppp0    0.0.0.0         0.0.0.0/0
333.333.333.333      n/a
    0     0 deny  all  ---o 0xFF 0x00 ppp0    0.0.0.0
192.168.0.0/24       0.0.0.0/0            n/a

# ipfwadm -O -l -n -e
IP firewall output rules, default policy: deny
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress       source
destination          ports
    6   396 acc   all  ---- 0xFF 0x00 lo      0.0.0.0         0.0.0.0/0
0.0.0.0/0            n/a
 9776 3285K acc   all  ---- 0xFF 0x00 eth0    0.0.0.0         0.0.0.0/0
192.168.0.0/24       n/a
 7412  406K acc   all  ---- 0xFF 0x00 ppp0    0.0.0.0     333.333.0.0/16
0.0.0.0/0            n/a
    0     0 deny  all  ---o 0xFF 0x00 ppp0    0.0.0.0         0.0.0.0/0
192.168.0.0/24       n/a

I think for both incoming and outgoing ppp0 traffic at least the last
two entries should be reversed. Right now packets coming in via ppp0
claiming to be from 192.168.0.0/24 are passed through, undermining
firewall security. Also, what sense does it make to have a deny rule as
the last rule if the default policy is deny?
To me this is clearly a bug, and also a source of a potential security
problem.

The second problem, in the outgoing traffic rules, that traffic claiming
to be from any IP of 333.333.0.0/16 instead of just 333.333.333.333 is
sent out probably comes from the fact that ppp0's netmask is set to
255.255.0.0, probably because its IP is from a class B network block).
Here, I'm not sure where exactly the mistake is, whether one should
assume netmasks of point to point interfaces to always be
255.255.255.255, for example.

Any feedback, in particular suggestions for proper fixes, would be
appreciated.
--

Institut fr Theoretische Physik       +49 30 314-24254, FAX -21130
Technische Universit?t Berlin        http://home.pages.de/~schwarz/

 
 
 

Debian 2.1 ipmasq security bug?

Post by Bernd Eckenfel » Sun, 12 Mar 2000 04:00:00



Quote:>     0     0 deny  all  ---o 0xFF 0x00 ppp0    0.0.0.0         0.0.0.0/0
> 192.168.0.0/24       n/a
> Also, what sense does it make to have a deny rule as
> the last rule if the default policy is deny?

The default policy will drop the packets silently. The last rule has a -o
floag, and therefore will log them.

Greetings
Bernd

 
 
 

Debian 2.1 ipmasq security bug?

Post by Georg Schwa » Sun, 12 Mar 2000 04:00:00



>The default policy will drop the packets silently. The last rule has a -o
>floag, and therefore will log them.

OK, point taken. Still I think that the order of the two rules refering to
the external IF should be reversed to make external packets claiming to
originate from the local LAN being dropped.
--

Institut fr Theoretische Physik  +49 30 314-24254   FAX -21130  IRC kuroi
Technische Universit?t Berlin            http://home.pages.de/~schwarz/
 
 
 

Debian 2.1 ipmasq security bug?

Post by Bernd Eckenfel » Sun, 12 Mar 2000 04:00:00



Quote:> OK, point taken. Still I think that the order of the two rules refering to
> the external IF should be reversed to make external packets claiming to
> originate from the local LAN being dropped.

think so, too.. but it is not a big problem, if you use back route verify
with recent kernels. They will make sure only to accept packaets originating
from the same network as the route points too. and since your route to the
internal network points to the ethernet interface spoofed packets  will be
dropped (at least in theory and if you enable that feature like debian is
doing).

Gruss
Bernd

 
 
 

1. Debian 2.1 - Install reports: Bug! - AHA2742T

I downloaded Debian 2.1 (Slink/stable) very recently from a Sunsite
mirror to my 486/100 with 64M RAM. I have two Adaptec AHA2742T SCSI
cards installed, these are EISA devices. They have worked fine with
DOS, Windows 95/98 and NT4 for years. Other cards are an Orchid
Fahrenheit VA and a serial/parallel port card, both ISA.

I ran INSTALL.BAT from a Quantum hard disk on one of the scsi chains.
It recognised all components in the correct slots, describing them as
2740's and downloaded 423 bytes to each but a few second later went
into a loop reporting an error, that read something like:

-- Quote --

(scsi0) BUG! Driver accessed chip without first pausing controller!
illegal adr = 0x0

-- End Quote --

I am unsure of the first few characters in each line as the error is
reported repeatedly many times each second and I cannot pause it.

Changing drives, scsi chain or IRQ makes little difference - same error
different scsi device number. I have searched the news postings and
have seen a similarish report involving the 2840a device. The Hardware-
HOWTO says that the AHA 274xT has been supported since kernel 2.1.x
series.

I am downloading SuSe to see if it will make any difference. This will
take a few days but I would prefer to debian if possible.

I thank you in anticipation of your advise and wisdom :-)

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

2. mgetty + pppd: I/O error(5)

3. At 2.0 security bug; 2.1 uploaded to sunsite and tsx-11

4. Error in Red Hat 6 installation...HELP!

5. KDE in Debian 2.1 ?

6. HT use ppp with ethernet?

7. WindowMaker under Debian 2.1 - MENU PROBLEMS

8. Newbie needs help with Solaris x86 install

9. No KDE for Slink (Debian 2.1)?

10. Error with Debian 2.1 and qt-1.42-2 package

11. NFS-Root Problem in Debian 2.1??

12. Debian 2.1 - Please help.

13. AcceleratedX 2.1 and Debian 1.2.2