[Shorewall-users] need more rules when using IPSEC

[Brian J. Murrell]

I am just trying out Shorewall for the first time and am impressed
with all of the scenarios it handles. I did find out one it does not
handle terribly gracefully (which is asked about over and over again
in the archives, but a definate succinct explanation is never given of
the problem and solution, so here goes). I have an IPSEC connection
between an IPSEC gateway + lan and a stand-alone host (here comes the
ascii art):


+---------+ +-------+
10.1.1.0/24 Lan | IPSEC | | IPSEC |
----------------------| Gateway |---- Internet ----| Host |
+---------+ +-------+

This setup is comprised of _two_ tunnels (not just the obvious one).
The obvious tunnel is between the 10.1.1.0 Lan and the IPSEC Host and
the other is between the IPSEC Gateway and the IPSEC Host. Once the
latter tunnel is set up, all subsequent traffic (including IPSEC
maintenance traffic) between the gateway and the host is carried over
the tunnel, not over the clear channel.

The Shorewall I am trying to configure is on the IPSEC Host. I have
configured a tunnels entry:

ipsec net 0.0.0.0/0

I also have the zones defined:

net Net Internet
vpn VPN VPN over FreeS/WAN interfaces (ipsecN)

and interfaces:

net ppp0 - norfc1918
vpn ipsec0 -

Given all of this, I get the following (relevant) netfilter rules:

INPUT:
2473 536K ppp0_in all -- ppp0 * 0.0.0.0/0 0.0.0.0/0

ppp0_in:
pkts bytes target prot opt in out source destination
2473 536K net2fw all -- * * 0.0.0.0/0 0.0.0.0/0

net2fw:
pkts bytes target prot opt in out source destination
0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:500 dpt:500 state NEW

OUTPUT:
pkts bytes target prot opt in out source destination
1563 498K fw2net all -- * ppp0 0.0.0.0/0 0.0.0.0/0

fw2net:
pkts bytes target prot opt in out source destination
0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:500 dpt:500 state NEW

Which is good for the initial (i.e. before any tunnels are set up) IPSEC
handshake and setup, but once the tunnels are up and running, any
further IPSEC traffic between the gateway and the host is transmitted
and arrives on the ipsec0 interface, not the ppp0 interface.

May I suggest a further set of (automatic) rules be added when ipsec
tunnels are defined:

ipsec0_in:
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:500 dpt:500 state NEW

ipsec0_out:
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:500 dpt:500 state NEW

In other words, always allow the IPSEC setup traffic (udp:500<->udp:500)
on ipsec tunnelling interfaces.

Perhaps the "interfaces" entry for ipsec interfaces could have a flag
added to specify that it is an ipsec tunnel and thus trigger the above
two new rules.

Or perhaps there is a way that this already works in Shorewall and I am
just missing it presently?

b.

[Jérôme Tytgat]

Hello,

I have this in my common file :

run_iptables -A common -p udp --dport 137:139 -j DROP
run_iptables -A common -p udp --dport 445 -j DROP
run_iptables -A common -p tcp --dport 135 -j DROP
############################################################################
# UPnP
#
run_iptables -A common -p udp --dport 1900 -j DROP
############################################################################
# BROADCASTS
#
run_iptables -A common -d 255.255.255.255 -j DROP
run_iptables -A common -d 224.0.0.0/4 -j DROP
############################################################################
# AUTH -- Silently reject it so that connections don't get delayed.
#
run_iptables -A common -p tcp --dport 113 -j reject

# Port Scan Detector
run_iptables -A common -m psd -j LOG --psd-hi-ports-weight
3 --psd-lo-ports-weight 5
run_iptables -A common -m psd -j DROP --psd-hi-ports-weight
3 --psd-lo-ports-weight 5

# Drop silently late UDP resolutions
run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP

Surprisingly I still get logs for dest 255.255.255.255, dport 1900 udp,
sport 53 udp.
I thought I can suppress logs using this file.

My policy def is like that :
loc fw ACCEPT
wol fw DROP
net fw DROP info
fw loc ACCEPT
fw wol ACCEPT
fw net ACCEPT
all all DROP info

In my shorewall.conf I have this about logging :

LOGRATE=
LOGBURST=
LOGUNCLEAN=
LOGFILE=/var/log/kernel
BLACKLIST_LOGLEVEL=6
LOGNEWNOTSYN=6

and an iptables-saves|grep LOG gives this :

# iptables-save |grep LOG
-A logdrop -j LOG --log-prefix "Shorewall:man1918:DROP:" --log-level 6
-A INPUT -j LOG --log-prefix "Shorewall:INPUT:DROP:" --log-level 6
-A FORWARD -j LOG --log-prefix "Shorewall:FORWARD:DROP:" --log-level 6
-A OUTPUT -j LOG --log-prefix "Shorewall:OUTPUT:DROP:" --log-level 6
-A all2all -j LOG --log-prefix "Shorewall:all2all:DROP:" --log-level 6
-A common -m psd --psd-weight-threshold 21 --psd-delay-threshold
300 --psd-lo-ports-weight 5 --psd-hi-ports-weight 3 -j LOG
-A fw2net -p tcp -m multiport --dports 6666,ircd,6668 -m state --state
NEW -j LOG --log-prefix "Shorewall:fw2net:REJECT:" --log-level 6
-A loc2net -p tcp -m multiport --dports 6666,ircd,6668 -m state --state
NEW -j LOG --log-prefix "Shorewall:loc2net:REJECT:" --log-level 6
-A logdrop -j LOG --log-prefix "Shorewall:rfc1918:DROP:" --log-level 6
-A net2fw -p icmp -j LOG --log-prefix "Shorewall:net2fw:DROP:" --log-level 6
-A net2fw -j LOG --log-prefix "Shorewall:net2fw:DROP:" --log-level 6
-A newnotsyn -j LOG --log-prefix "Shorewall:newnotsyn:DROP:" --log-level 6

and finaly an iptables-save|grep common gives this :

-A INPUT -j common
-A FORWARD -j common
-A OUTPUT -j common
-A all2all -j common
-A common -p icmp -j icmpdef
-A common -p tcp -m state --state INVALID -j DROP
-A common -p udp -m udp --dport 137:139 -j DROP
-A common -p udp -m udp --dport 445 -j DROP
-A common -p tcp -m tcp --dport 135 -j DROP
-A common -p udp -m udp --dport 1900 -j DROP
-A common -d 255.255.255.255 -j DROP
-A common -d 224.0.0.0/240.0.0.0 -j DROP
-A common -p tcp -m tcp --dport 113 -j reject
-A common -m psd --psd-weight-threshold 21 --psd-delay-threshold
300 --psd-lo-ports-weight 5 --psd-hi-ports-weight 3 -j LOG
-A common -m psd --psd-weight-threshold 21 --psd-delay-threshold
300 --psd-lo-ports-weight 5 --psd-hi-ports-weight 3 -j DROP
-A common -p udp -m udp --sport 53 -m state --state NEW -j DROP
-A common -d 10.10.10.255 -j DROP
-A common -d 212.95.85.255 -j DROP
-A net2fw -j common
-A wol2fw -j common

Any idea why I keep logging these dropped packets ?

[Tom Eastep]

Post by Jérôme Tytgat
Hello,
Any idea why I keep logging these dropped packets ?

Which rule is logging them?

[Jérôme Tytgat]

*** for 255.255.255.255 / UPNP 1900 ***

Oct 13 16:34:50 shax kernel: Shorewall:rfc1918:DROP:IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:a0:24:5c:ba:86:08:00 SRC=192.168.2.15
DST=255.255.255.255 LEN=160 TOS=0x00 PREC=0x00 TTL=128 ID=58603 PROTO=UDP
SPT=3107 DPT=1900 LEN=140

in my rfc1918 logs I have :

255.255.255.255 RETURN # We need to allow limited broadcast
...
240.0.0.0/4 logdrop # Reserved

ok Has I see for this it's "logic" :

chain rfc1918 is called from chain eth0_in
chain eth0_in is called from chain INPUT
chain eth0_in comes BEFORE chain common in chain INPUT :

-A eth0_in -j dynamic
-A eth0_in -p udp -m udp --dport 67:68 -j ACCEPT
-A eth0_in -j rfc1918
-A eth0_in -j blacklst
-A eth0_in -j net2fw

-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j eth1_in
-A INPUT -i eth2 -j eth2_in
-A INPUT -i eth0 -j eth0_in
-A INPUT -j common
-A INPUT -j LOG --log-prefix "Shorewall:INPUT:DROP:" --log-level 6
-A INPUT -j DROP


Ok what can I do to suppress these messages ?

----- Original Message -----
From: "Tom Eastep" <***@shorewall.net>
To: "Jérôme Tytgat" <***@websurg.com>
Cc: <shorewall-***@shorewall.net>
Sent: Tuesday, October 15, 2002 3:26 PM
Subject: Re: [Shorewall-users] Common file and logs

Post by Tom Eastep

Post by Jérôme Tytgat
Hello,
Any idea why I keep logging these dropped packets ?

Which rule is logging them?
--
Tom Eastep \ Shorewall - iptables made easy
AIM: tmeastep \ http://www.shorewall.net
_______________________________________________
Shorewall-users mailing list
http://www.shorewall.net/mailman/listinfo/shorewall-users

[Tom Eastep]

Post by Jérôme Tytgat
*** for 255.255.255.255 / UPNP 1900 ***
Oct 13 16:34:50 shax kernel: Shorewall:rfc1918:DROP:IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:a0:24:5c:ba:86:08:00 SRC=192.168.2.15
DST=255.255.255.255 LEN=160 TOS=0x00 PREC=0x00 TTL=128 ID=58603 PROTO=UDP
SPT=3107 DPT=1900 LEN=140
255.255.255.255 RETURN # We need to allow limited broadcast
...
240.0.0.0/4 logdrop # Reserved
chain rfc1918 is called from chain eth0_in
chain eth0_in is called from chain INPUT
-A eth0_in -j dynamic
-A eth0_in -p udp -m udp --dport 67:68 -j ACCEPT
-A eth0_in -j rfc1918
-A eth0_in -j blacklst
-A eth0_in -j net2fw
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j eth1_in
-A INPUT -i eth2 -j eth2_in
-A INPUT -i eth0 -j eth0_in
-A INPUT -j common
-A INPUT -j LOG --log-prefix "Shorewall:INPUT:DROP:" --log-level 6
-A INPUT -j DROP
Ok what can I do to suppress these messages ?

Why is there a station with IP address 192.168.2.15 on a lan segment that
has 'norfc1918' specified on its interface? If the segment connected to
eth0 uses RFC 1918 addresses then remove 'norfc1918' from the interface.

If there are some stations on that segment using RFC 1918 addresses then
you can whitelist them in the rfc1918 file:

192.168.2.15 RETURN

Be sure that these whitelist entries come before the entry that logs and
drops them.

-Tom

[Tom Eastep]

Brian J. Murrell wrote:
is an ipsec tunnel and thus trigger the above

Post by Brian J. Murrell
Or perhaps there is a way that this already works in Shorewall and I am
just missing it presently?

Place 'vpn' in the fourth column of the tunnels file entry.

-Tom

[Brian J. Murrell]

Post by Tom Eastep
Place 'vpn' in the fourth column of the tunnels file entry.

Indeed! I had tried another (incorrect) zone there due to some
misunderstanding of the docs and it didn't work, but putting vpn there
works just peachy! :-)

On another note, it would be nice to be able to put a comma list of
sources and destinations in the rules file. It would be nice if I
could weed:

ACCEPT net $FW tcp 22,80,25
ACCEPT vpn $FW tcp 22,80,25
ACCEPT net $FW udp 53
ACCEPT vpn $FW udp 53
ACCEPT net $FW udp 123 123
ACCEPT vpn $FW udp 123 123

down to:

ACCEPT net,vpn $FW tcp 22,80,25
ACCEPT net,vpn $FW udp 53
ACCEPT net,vpn $FW udp 123 123

That being said, having been in the firewalling game for many years
now and having used a number of products from mind-numbingly simple
Firewall-1 to as complicated as writing my own stateful packet filter
engine for ipchains, I am impressed with Shorewall. It turns a simple
set of config files into a nice set of rules and does not let too much
leak with too much generalization. It is also seems to be quite
feature rich in the situations it will handle.

My next project will be to convert my own custom
[S|N]NAT/IPSEC/firewall config to use Shorewall. That should prove
more interesting now that I have done a fairly simple stand-alone
system config.

Thanx for the great work!

b.

[Tom Eastep]

Post by Brian J. Murrell

Post by Tom Eastep
Place 'vpn' in the fourth column of the tunnels file entry.

Indeed! I had tried another (incorrect) zone there due to some
misunderstanding of the docs and it didn't work, but putting vpn there
works just peachy! :-)
On another note, it would be nice to be able to put a comma list of
sources and destinations in the rules file. It would be nice if I
ACCEPT net $FW tcp 22,80,25
ACCEPT vpn $FW tcp 22,80,25
ACCEPT net $FW udp 53
ACCEPT vpn $FW udp 53
ACCEPT net $FW udp 123 123
ACCEPT vpn $FW udp 123 123
ACCEPT net,vpn $FW tcp 22,80,25
ACCEPT net,vpn $FW udp 53
ACCEPT net,vpn $FW udp 123 123

The source and destination can already be list-valued but it works
slightly differently. Example:

ACCEPT net:192.0.2.0/24,130.252.0.0.16 $FW tcp 22,80,25

So the list qualifies a single zone rather than listing a set of zones.

-Tom

[Brian J. Murrell]

Post by Tom Eastep
The source and destination can already be list-valued but it works
ACCEPT net:192.0.2.0/24,130.252.0.0.16 $FW tcp 22,80,25
So the list qualifies a single zone rather than listing a set of zones.

Indeed, but that does not really allow for a single "rules" rule to
specify the same permissions for multiple zones though does it? The
alternative to being able to list-specify zones is to allow the
definition of zones which just group other zones.

The real world example is that I have a "net" and a "vpn" zone (the
latter is an IPSEC tunnel), but I don't entirely trust the vpn zone
(and have zero trust in the net zone of course). I want to allow the
same access to the VPN as I do the net (ssh, http, smtp) but in
addition allow lpd service to the VPN (which is why I can't just put
the net and vpn into one zone). Being able to list-specify the
services that are allowed both would be nice. But, indeed, it is
a "gravy" item so I will drop it here. :-)

b.

[Tom Eastep]

Post by Brian J. Murrell

Post by Tom Eastep
The source and destination can already be list-valued but it works
ACCEPT net:192.0.2.0/24,130.252.0.0.16 $FW tcp 22,80,25
So the list qualifies a single zone rather than listing a set of zones.

Indeed, but that does not really allow for a single "rules" rule to
specify the same permissions for multiple zones though does it?

No -- but constructing a super-zone does. See below.

The

Post by Brian J. Murrell
alternative to being able to list-specify zones is to allow the
definition of zones which just group other zones.

You can effectively do that today with the hosts file. Just be sure to
list the super zone after its component zones in the zones file. And by
using a "CONTINUE" policy, you can have specific rules for the subzones
and more general rules for the super zone.

Post by Brian J. Murrell
The real world example is that I have a "net" and a "vpn" zone (the
latter is an IPSEC tunnel), but I don't entirely trust the vpn zone
(and have zero trust in the net zone of course). I want to allow the
same access to the VPN as I do the net (ssh, http, smtp) but in
addition allow lpd service to the VPN (which is why I can't just put
the net and vpn into one zone). Being able to list-specify the
services that are allowed both would be nice. But, indeed, it is
a "gravy" item so I will drop it here.

I don't intend any additions in this area although in "Shorewall 2", I'm
going to rethink the way that zones are defined to make aggregating zones
more straightforward.

-Tom

[Tom Eastep]

Post by Tom Eastep
You can effectively do that today with the hosts file. Just be sure to
list the super zone after its component zones in the zones file. And by
using a "CONTINUE" policy, you can have specific rules for the subzones
and more general rules for the super zone.

The rule about ordering in the zones file need not be so hard and fast as
I've stated it above.

/etc/shorewall/zones

netx
net
vpn

/etc/shorewall/interfaces

net eth0
vpn ipsec0

/etc/shorewall/hosts

netx eth0:0.0.0.0/0,ipsec0:0.0.0.0/0

/etc/shorewall/policy

netx all CONTINUE
vpn all REJECT
net all DROP

You can now have in your rules file:

ACCEPT netx $FW tcp 22,80,25
ACCEPT netx $FW udp 53
ACCEPT netx $FW udp 123 123

ACCEPT vpn $FW ...

ACCEPT net $FW ...

In this case, since netx comes first in the zones file, netx->* rules will
be evaluated before vpn->* and net->*

-Tom