--3XA6nns4nE4KvaS/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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. =20
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=20
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
=20
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
=20
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=20
0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0
state NEW=20
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spt:500 dpt:500 state NEW=20
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
=20
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=20
0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0
state NEW=20
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spt:500 dpt:500 state NEW=20
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=20
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=20
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.
--=20
Brian J. Murrell
--3XA6nns4nE4KvaS/
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9q8UNl3EQlGLyuXARAjz8AJ4+WDXQyfIpfLnzirmUkTM3axYLugCgxkjM
qKB18ag3+I0iCGYgjrYboMw=pVVl
-----END PGP SIGNATURE-----
--3XA6nns4nE4KvaS/--
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 : LOGRATELOGBURSTLOGUNCLEANLOGFILE=/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 ?
Brian J. Murrell wrote: is an ipsec tunnel and thus trigger the above> > 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 -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Jérôme Tytgat wrote:> 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 ICQ: #60745924 \ teastep@shorewall.net
*** for 255.255.255.255 / UPNP 1900 *** Oct 13 16:34:50 shax kernel: Shorewall:rfc1918:DROP:IN=eth0 OUTMAC=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" <teastep@shorewall.net> To: "Jérôme Tytgat" <jtytgat@websurg.com> Cc: <shorewall-users@shorewall.net> Sent: Tuesday, October 15, 2002 3:26 PM Subject: Re: [Shorewall-users] Common file and logs> > > Jérôme Tytgat wrote: > > 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 > ICQ: #60745924 \ teastep@shorewall.net > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@shorewall.net > http://www.shorewall.net/mailman/listinfo/shorewall-users >
Jérôme Tytgat wrote:> *** 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 ? >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 \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
--82evfD9Ogz2JrdWZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2002 at 06:23:44AM -0700, Tom Eastep wrote:>=20 > 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. --=20 Brian J. Murrell --82evfD9Ogz2JrdWZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rJpKl3EQlGLyuXARAuh6AJ0ViozYoR7xWCjVbmA+xGmYhEcwWACgyRn0 PR56X3/ztDMQVs0PGda2z1E=t0uN -----END PGP SIGNATURE----- --82evfD9Ogz2JrdWZ--
Brian J. Murrell wrote:> On Tue, Oct 15, 2002 at 06:23:44AM -0700, Tom Eastep wrote: > >>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 >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 -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
--nO3oAMapP4dBpMZi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2002 at 03:51:08PM -0700, Tom Eastep wrote:>=20 > The source and destination can already be list-valued but it works=20 > slightly differently. Example: >=20 > ACCEPT net:192.0.2.0/24,130.252.0.0.16 $FW tcp 22,80,25 >=20 > 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. --=20 Brian J. Murrell --nO3oAMapP4dBpMZi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rJ70l3EQlGLyuXARAml/AJ4ltsc7CLHYggEzyjQu5yCid7V8MwCeIo8E 2Bkbt9kNGV2dbuJzNl+gCqI=x//z -----END PGP SIGNATURE----- --nO3oAMapP4dBpMZi--
Brian J. Murrell wrote:> On Tue, Oct 15, 2002 at 03:51:08PM -0700, Tom Eastep wrote: > >>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. > > > 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> 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.> > 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 \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Tom Eastep wrote:> > > 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 -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net