Very Computer

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/

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

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/

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