Patrique Wolfrum
2002-Mar-21 18:36 UTC
[Shorewall-users] Problem with packages from outside
Hello,
My computer here, which servers as a Internet-Gateway for our private LAN,
works with Redhat 7.2 and RPPPOE 3.3(configured for "dial on demand")
and
Shorewall 1.2.10.
Two network-cards are used, one Realtek 8139 (eth0), which is connected with
the LAN, and a Realtek 8029 (eth1) which is connected to the DSL-Modem.
My problem now is:
Sometimes there come packages from the Internet, which are directed (more or
less) to the gateway-computer and the packages are directed to sometimes
nonexistent or blocked ports. But when such a package comes, PPPD (or
RPPPOE) thinks, that there is traffic, so it keeps the connection open
(sometimes for several hours).
These packages are logged in the Log-File (/var/log/messages) that way:
"kernel:Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=xxx.xxx.xxx.xxx
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=xxx DF PROTO=TCP
SPT=xxxx DPT=xxxx WINDOW=16384 RES=0x00 SYN URGP=0"
Note: ppp0 is the device over which the DSL-traffic runs.
I checked these packages with ethereal, they aren''t from computers I
had
connections with before, so they aren''t responses to connections from
my
side. One system is, according its DNS-entry located in Russia.
Since these long connections are quite annoying, my question is: Is there a
way, to prevent this ?
My Shorewall-configuration looks like this:
The hosts file:
loc eth0:192.168.0.1/24 routestopped
The interfaces file:
loc eth0: 192.168.0.255 routestopped
net ppp+ detect
noping,dhcp
The masq file:
ppp+ eth0
The policy file:
loc net ACCEPT
net all DROP info
all all DROP info
all all DROP info
The rules file looks that way:
# Allow SSH from the local network
#
ACCEPT loc $FW tcp ssh
ACCEPT $FW net tcp ssh
#
# Dont Allow SSH and Auth from the internet
#
DROP net $FW tcp ssh,auth
#
# Run an NTP daemon on the firewall that is synced with outside sources
#
# ACCEPT $FW net udp ntp
#
# Newsserver
#
ACCEPT $FW net tcp nntp
ACCEPT $FW net udp nntp
ACCEPT loc $FW tcp nntp
ACCEPT loc $FW udp nntp
#
# DNS
#
ACCEPT loc $FW tcp 53
ACCEPT loc $FW udp 53
ACCEPT:info $FW net udp 53
ACCEPT:info $FW net tcp 53
#
# LDAP-Server
#
ACCEPT loc $FW tcp 389
ACCEPT loc $FW udp 389
#
# Squid + Junkbuster + Dante
#
ACCEPT loc $FW tcp 3128
ACCEPT loc $FW udp 3128
ACCEPT loc $FW tcp 8080
ACCEPT loc $FW udp 8080
ACCEPT loc $FW tcp 1080
ACCEPT loc $FW udp 1080
#
# Web + Apache
#
ACCEPT loc $FW tcp 80
ACCEPT loc $FW udp 80
ACCEPT $FW net tcp 80
ACCEPT $FW net udp 80
ACCEPT loc net tcp 443
ACCEPT loc net udp 443
ACCEPT $FW net tcp 443
ACCEPT $FW net udp 443
#
# FTP
#
ACCEPT $FW net tcp 20
ACCEPT $FW net udp 20
# ACCEPT loc net tcp 21
ACCEPT $FW net tcp 21
ACCEPT $FW net udp 21
#
# Mailserver
#
ACCEPT loc $FW tcp smtp
ACCEPT loc $FW udp smtp
ACCEPT loc $FW tcp pop3
ACCEPT loc $FW udp pop3
ACCEPT loc $FW tcp 110
ACCEPT loc $FW udp 110
ACCEPT $FW net tcp smtp
ACCEPT $FW net udp smtp
ACCEPT $FW net tcp pop3
ACCEPT $FW net udp pop3
ACCEPT $FW net tcp 995
ACCEPT $FW net udp 995
#
#Samba
#
#ACCEPT loc $FW tcp 137:139
ACCEPT loc $FW tcp 137
ACCEPT loc $FW tcp 138
ACCEPT loc $FW tcp 139
#ACCEPT loc $FW udp 137:139
ACCEPT loc $FW udp 137
ACCEPT loc $FW udp 138
ACCEPT loc $FW udp 139
#ACCEPT $FW loc tcp 137:139
ACCEPT $FW loc tcp 137
ACCEPT $FW loc tcp 138
ACCEPT $FW loc tcp 139
#ACCEPT $FW loc udp 137:139
ACCEPT $FW loc udp 137
ACCEPT $FW loc udp 138
ACCEPT $FW loc udp 139
ACCEPT loc $FW udp 135
#DROP $FW net tcp 137:139
DROP $FW net tcp 137
DROP $FW net tcp 138
DROP $FW net tcp 139
#DROP $FW net udp 137:139
DROP $FW net udp 137
DROP $FW net udp 138
DROP $FW net udp 139
DROP $FW net tcp 135
DROP $FW net udp 135
#
# Cups
#
DROP:info $FW net tcp 631
DROP:info $FW net udp 631
#ACCEPT loc $FW tcp 631
#ACCEPT loc $FW udp 631
#
# Additions
#
DROP loc net tcp 59
DROP loc net udp 59
DROP loc $FW tcp 59
DROP loc $FW udp 59
DROP loc net tcp 79
DROP loc net udp 79
DROP loc $FW tcp 79
DROP loc $FW udp 79
#
#Webmin
#
ACCEPT:info $FW loc tcp 10000
ACCEPT:info $FW loc udp 10000
DROP:info $FW net tcp 10000
DROP:info $FW net udp 10000
DROP:info net $FW tcp 10000
DROP:info net $FW udp 10000
The file zones:
net Net Internet
loc Local Local networks
All other config-files aren''t modified and in
"delivery-state".
I have tried for some days, to get this fixed, but till now, no success. Any
help would be greatly appreciated.
Thank you in advance.
With best regards,
Patrique Wolfrum
Patrique Wolfrum wrote:> ... > My problem now is: > Sometimes there come packages from the Internet, which are directed (more or > less) to the gateway-computer and the packages are directed to sometimes > nonexistent or blocked ports. But when such a package comes, PPPD (or > RPPPOE) thinks, that there is traffic, so it keeps the connection open > (sometimes for several hours).(BTW: "packet", not "package". :-)> These packages are logged in the Log-File (/var/log/messages) that way: > "kernel:Shorewall:net2all:DROP:IN=ppp0 OUT= MAC= SRC=xxx.xxx.xxx.xxx > DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=xxx DF PROTO=TCP > SPT=xxxx DPT=xxxx WINDOW=16384 RES=0x00 SYN URGP=0" > Note: ppp0 is the device over which the DSL-traffic runs.With all those xxxs, it''s a bit hard to know which rule your problem might be in. How about providing the source and destination ports?> ... > I checked these packages with ethereal, they aren''t from computers I had > connections with before, so they aren''t responses to connections from my > side. One system is, according its DNS-entry located in Russia. > > Since these long connections are quite annoying, my question is: Is there a > way, to prevent this ? > > My Shorewall-configuration looks like this: > > The hosts file: > loc eth0:192.168.0.1/24 routestoppedIf you have a fairly simple setup (which it appears you do), there is probably no need to use the hosts file. It only complicates matters.> The interfaces file: > loc eth0: 192.168.0.255 routestopped > net ppp+ detect > noping,dhcpSome more general comments (not related to the problem at hand): - use the routefilter on all interfaces unless you have a good reason not to - use detect as the broadcast address unless you have a good reason not to> ... > The policy file: > loc net ACCEPT > net all DROP info > all all DROP info > all all DROP infoHave you typed that wrongly? Presumably one of your all -> all policies should be something else (e.g. $FW -> all).> The rules file looks that way: > ... > # > # Dont Allow SSH and Auth from the internet > # > DROP net $FW tcp ssh,authThis rule is redundant given your net -> all policy above.> ... > # DNS > # > ACCEPT loc $FW tcp 53 > ACCEPT loc $FW udp 53 > ACCEPT:info $FW net udp 53 > ACCEPT:info $FW net tcp 53Are those infos in there to help you debug this problem?> ... > ACCEPT loc net tcp 443 > ACCEPT loc net udp 443Again, redundant given your loc -> net policy.> ... > ACCEPT $FW net tcp 443 > ACCEPT $FW net udp 443 > # > # FTP > # > ACCEPT $FW net tcp 20 > ACCEPT $FW net udp 20 > ... > ACCEPT $FW net tcp 21 > ACCEPT $FW net udp 21 > # > # Mailserver > # > ACCEPT loc $FW tcp smtp > ACCEPT loc $FW udp smtp > ACCEPT loc $FW tcp pop3 > ACCEPT loc $FW udp pop3 > ACCEPT loc $FW tcp 110 > ACCEPT loc $FW udp 110 > ACCEPT $FW net tcp smtp > ACCEPT $FW net udp smtp > ACCEPT $FW net tcp pop3 > ACCEPT $FW net udp pop3 > ACCEPT $FW net tcp 995 > ACCEPT $FW net udp 995I don''t know why you have all these udp/tcp pairs, but all of the protocols you''ve listed in the above block use TCP only. You shouldn''t be putting in udp rules if you don''t need them.> ... > # Additions > # > ... > DROP loc $FW tcp 59 > DROP loc $FW udp 59 > ... > DROP loc $FW tcp 79 > DROP loc $FW udp 79Redundant - covered by all -> all policy.> ... > All other config-files aren''t modified and in "delivery-state". > > I have tried for some days, to get this fixed, but till now, no success. Any > help would be greatly appreciated.I don''t know whether i''ve covered your problem above, but it looks like there are a number of improvements to your configuration that could be made. However, to really solve your problem, we''ll need more information about the packets that are being dropped. Paul http://paulgear.webhop.net
Scott Merrill wrote:> > Some more general comments (not related to the problem at hand): > > - use the routefilter on all interfaces unless you have a good reason not > to > > - use detect as the broadcast address unless you have a good reason not to > > Paul, could you share a few "good reasons" for each of these items? > I''ve been manually supplying broadcast addresses, and I''m curious why I > ought not to.The only one i can think of is that shorewall doesn''t detect it correctly. The main reason i say this is that you don''t want to change your broadcast address on your LAN for whatever reason, forget that it''s also specified in your firewall, and spend half a day trying to work out why your internet access doesn''t work anymore. Redundant information is dangerous to system administrators. My philosophy with many such things is: If you don''t have to specify it, don''t. Make the system work it out and it will be more resilient to change. That''s why i suggest using detect, and also why i say don''t use the hosts file if you don''t need to. *** BTW, in my last message, i said that a few of the lines in Patrique''s configs were redundant. That wasn''t true - a couple of them were used to suppress the info log messages that would have been created by the policies. *** Paul http://paulgear.webhop.net
----- Original Message ----- From: "Paul Gear" <paulgear@bigfoot.com> To: "Scott Merrill" <smerrill@finelinegraphics.com>; "Shorewall Users" <shorewall-users@shorewall.net> Sent: Friday, March 22, 2002 5:13 AM Subject: Re: [Shorewall-users] Problem with packages from outside> Scott Merrill wrote: > > > > > - use detect as the broadcast address unless you have a good reasonnot to> > > > Paul, could you share a few "good reasons" for each of these items? > > I''ve been manually supplying broadcast addresses, and I''m curious why I > > ought not to. > > The only one i can think of is that shorewall doesn''t detect it correctly.Or that you don''t want to bring up any of your interfaces without Shorewall being already started. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
----- Original Message ----- From: "Paul Gear" <paulgear@bigfoot.com> To: "Scott Merrill" <smerrill@finelinegraphics.com>; "Shorewall Users" <shorewall-users@shorewall.net> Sent: Friday, March 22, 2002 5:13 AM Subject: Re: [Shorewall-users] Problem with packages from outside> Scott Merrill wrote: > > *** > BTW, in my last message, i said that a few of the lines in Patrique''sconfigs> were redundant. That wasn''t true - a couple of them were used to suppressthe> info log messages that would have been created by the policies. > ***Although the ''common'' chain will silently drop all NETBIOS noise anyway so silent DROP rules for ports 135,137-139 from firewall to net are redundant in Patrique''s rules file. -Tom
Patrique Wolfrum wrote:> ... > (Note to myself: Don''t write messages in English, when you''re tired ;-)).You should hear my Deutsch. :-)> ... > Mar 22 09:21:03 saturn kernel: Shorewall:all2all:DROP:IN= OUT=ppp0 > SRC=217.1.2.232 DST=207.246.138.137 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5123 > PROTO=TCP SPT=4645 DPT=81 WINDOW=5808 RES=0x00 SYN URGP=0This is probably someone trying to access a web server on port 81 via your squid proxy server. This is a fairly common occurrance and probably should be allowed if you are allowing general web traffic.> Mar 22 07:51:34 saturn kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC> SRC=80.129.88.135 DST=217.1.2.240 LEN=34 TOS=0x00 PREC=0x00 TTL=123 ID=1245 > PROTO=UDP SPT=1523 DPT=4665 LEN=14This seems to be eDonkey2000 file sharing (i''ve not seen it before). I suggest blocking it in both directions.> Mar 22 07:44:15 saturn kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC> SRC=217.0.37.245 DST=217.1.2.240 LEN=48 TOS=0x00 PREC=0x00 TTL=124 ID=37423 > DF PROTO=TCP SPT=63514 DPT=1214 WINDOW=8192 RES=0x00 SYN URGP=0 > ... > Especially the packets with "DPT=1214" are logged very often.This is KaZaA file sharing - same deal: block it both ways. KaZaA seems to have gained a lot of popularity due to the demise of Napster.> ... > Mar 18 09:53:01 saturn kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC> SRC=203.180.145.26 DST=217.1.2.82 LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=15466 > DF PROTO=TCP SPT=3317 DPT=2072 WINDOW=8192 RES=0x00 SYN URGP=0 > ...Nearly all of these are explainable attempts - i don''t think there is anything fundamentally wrong with your configuration. I suggest if you want to know what they are, search Google. For this example, i would use the search string "tcp port 2072". That is what i did to find out about eDonkey2000 above.> Mar 17 17:41:14 saturn kernel: Shorewall:all2all:DROP:IN= OUT=ppp0 > SRC=217.80.177.48 DST=210.51.21.49 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1 > PROTO=TCP SPT=3119 DPT=8000 WINDOW=5808 RES=0x00 SYN URGP=0Squid trying to access a web server on port 8000, i''d say.> Mar 17 14:01:55 saturn kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC> SRC=65.205.114.136 DST=217.1.2.150 LEN=48 TOS=0x00 PREC=0x00 TTL=110 ID=3210 > DF PROTO=TCP SPT=3140 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0Someone trying to access a web server on your system.> Mar 17 10:34:43 saturn kernel: Shorewall:net2all:DROP:IN=ppp0 OUT= MAC> SRC=80.131.102.28 DST=217.1.2.154 LEN=48 TOS=0x00 PREC=0x00 TTL=124 ID=42355 > DF PROTO=TCP SPT=1209 DPT=6699 WINDOW=32767 RES=0x00 SYN URGP=0Probably Napster - block.> ... > > Some more general comments (not related to the problem at hand): > > - use the routefilter on all interfaces unless you have a good reason not > to > > - use detect as the broadcast address unless you have a good reason not to > > I tried to modify it the way you suggested. For eth0 it works fine, but ppp+ > (ppp0) doesn''t accept routefilter.I think that''s a known limitation - Tom can probably provide more details.> ... > > I don''t know why you have all these udp/tcp pairs, but all of the > protocols > > you''ve listed in the above block use TCP only. You shouldn''t be putting > in udp > > rules if you don''t need them. > > According to my /etc/services file, there are for that services TCP as well > as UDP ports listet. In order, to be on the safe side, I included this > pairs.It is standard practice for all protocols listed in /etc/services to register both TCP and UDP, regardless of whether they actually are used. You need to find out which ones are really used and only enable them. Opening more ports than you need increases the likelihood of your system being exploited. That''s not the safe side, it''s the unsafe side. Paul http://paulgear.webhop.net
----- Original Message ----- From: "Paul Gear" <paulgear@bigfoot.com> To: "Patrique Wolfrum" <patrique_wolfrum@web.de>; "Shorewall Users" <shorewall-users@shorewall.net> Sent: Friday, March 22, 2002 8:21 PM Subject: Re: [Shorewall-users] Problem with packages from outside> Patrique Wolfrum wrote: > > ... > > > Some more general comments (not related to the problem at hand): > > > - use the routefilter on all interfaces unless you have a good reasonnot> > to > > > - use detect as the broadcast address unless you have a good reasonnot to> > > > I tried to modify it the way you suggested. For eth0 it works fine, butppp+> > (ppp0) doesn''t accept routefilter. > > I think that''s a known limitation - Tom can probably provide more details. >It should work if you put ppp0 in the interfaces file rather than ppp+. As an alternative, you can "echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter" in /etc/shorewall/init. -Tom