Hi, I have been using Shorewall for about a month on a standalone internet server and have been very happy with the results. I''ve also been studying up on IPTABLES and the methods used by various scanners. As the result of my study I''ve become concerned with the two default rules below in COMMON.DEF run_iptables -A common -p tcp --tcp-flags ACK ACK -j ACCEPT run_iptables -A common -p tcp --tcp-flags RST RST -j ACCEPT Unless I''m interpreting these rules incorrectly, they will (1)Allow any packets from ANY source address to ANY destination port if the ACK flag is set on the packet and we don''t care about the other flags. (2)Allow any packets from ANY source address to ANY destination port if the RST flag is set on the packet and we don''t care about the other flags. since the script by default allows ESTABLISHED connections (nd optionally RELATED connections depending on the "Allow related" configuration in shorewall.conf) these would packets could only be in the "NEW connection" state. I believe this rule will also bypass any LIMITS set and allow a DOS of any port of ANY system behind the firewall. Some other firewalls use this rule to block such attacks on EVERY port $iptables -A INPUT -p tcp !--syn - m state --state NEW -j LOG --logprefix "new not SYN" $iptables -A INPUT -p tcp !--syn -m tate --state NEW -j DROP Please tell me I''m wrong about this and I''m missing something!
BTW, I had been using this page (which is referenced from the netfilter.org home page) for a reference about connection tracking: http://www.cs.princeton.edu/~jns/security/iptables/iptables_conntrack.html
On Sat, 3 Aug 2002, Links at Momsview wrote:> Hi, > I have been using Shorewall for about a month on a standalone internet server > and have been very happy with the results. > > I''ve also been studying up on IPTABLES and the methods used by various scanners. > > As the result of my study I''ve become concerned with the two default rules below in COMMON.DEF > > run_iptables -A common -p tcp --tcp-flags ACK ACK -j ACCEPT > run_iptables -A common -p tcp --tcp-flags RST RST -j ACCEPT > > Unless I''m interpreting these rules incorrectly, they will > > (1)Allow any packets from ANY source address to ANY destination port if the ACK flag is set on the packet > and we don''t care about the other flags. > > (2)Allow any packets from ANY source address to ANY destination port if the RST flag is set on the packet > and we don''t care about the other flags. > > since the script by default allows ESTABLISHED connections (nd optionally RELATED connections depending on the "Allow related" configuration > in shorewall.conf) these would packets could only be in the "NEW connection" state. > > I believe this rule will also bypass any LIMITS set and allow a DOS of any port of ANY system behind the firewall. > > Some other firewalls use this rule to block such attacks on EVERY port > > $iptables -A INPUT -p tcp !--syn - m state --state NEW -j LOG --logprefix "new not SYN" > $iptables -A INPUT -p tcp !--syn -m tate --state NEW -j DROP > > > Please tell me I''m wrong about this and I''m missing something! >No -- you''re hit on something that was hotly debated on the Netfilter mailing list recently. There is one school of thought that advocates the rules that you quote above. Note that these would have to be inserted after the ESTABLISHED,RELATED rule and before the rules generated by /etc/shorewall/rules file entries and NOT in the common chain. The problem with the rules that you propose is that if you ever have to reboot your firewall, connections that were active at the time of the reboot can''t continue and can''t be terminated except by the local system. This means that you reboot your firewall and then get spurious RST and ACK packets logged for the next half an hour. As to the rules that I include in the common file, experience has shown them to be necessary to avoid other cases of spurious logging - my firewall has seen 266 orphan RSTs since Friday. These seem to be caused by connection aborts. If you are willing to put up with the extra log messages then by all means copy common.def to common and change to your heart''s content. That''s the reason that I made the common rules user-replacable. For the default rules, I prefer what I have -- I get enough newbie questions already without having to try to explain why they are getting these ACK attacks or RST attacks.... -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
I never reboot my firewall except in the case of earthquake, flood, locusts, or other natural disaster. When I do, putting up with some extra log messages for a hour or two wouldn''t bother me a bit if it meant my systems were more secure. What would be the proper way to impliment these rules without screwing things up? Sincerely, Jim Hubbard ______________________________________________________> -----Original Message----- > From: shorewall-users-admin@shorewall.net > [mailto:shorewall-users-admin@shorewall.net]On Behalf Of Tom Eastep > Sent: Sunday, August 04, 2002 7:33 PM > To: Links at Momsview > Cc: shorewall-users@shorewall.net > Subject: Re: [Shorewall-users] Common Rules> > > > Some other firewalls use this rule to block such attacks on EVERY port > > > > $iptables -A INPUT -p tcp !--syn - m state --state NEW -j LOG > --logprefix "new not SYN" > > $iptables -A INPUT -p tcp !--syn -m tate --state NEW -j DROP > > > > > > Please tell me I''m wrong about this and I''m missing something! > > > > No -- you''re hit on something that was hotly debated on the Netfilter > mailing list recently. > > There is one school of thought that advocates the rules that you quote > above. Note that these would have to be inserted after the > ESTABLISHED,RELATED rule and before the rules generated by > /etc/shorewall/rules file entries and NOT in the common chain. > > > -Tom > --
On Mon, 5 Aug 2002, Links at Momsview wrote:> Therefore I would be interested in putting such rules in place. You > mentioned that they would go AFTER the ESTABLISHED,RELATED rules but before > the "RULES" entries. > Is there a preferred script name built into SHOREWALL to do this? >It really needs Shorewall support to be done correctly. The version of the ''firewall'' script in CVS implements two new parameters in shorewall.conf: NEWNOTSYN - Default is "Yes" (the current behavior). If set to "No" then Shorewall will drop all non-syn packets in the NEW state. LOGNEWNOTSYN - Default is "". If non-empty, contains the log level at which the above dropped packets will be logged. If empty, the packets will be silently dropped. There''s a note in the new shorewall.conf file that if you log these packets, I don''t want to see questions on the list about why they were logged. If you set this option, it''s assumed that you know what you are doing and that you like puzzeling messages. Take this one for example: Aug 5 07:23:47 badnew:DROP:IN=eth1 OUT=eth0 SRC=206.124.146.177 DST=61.x.x.x LEN=48 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=80 DPT=3845 WINDOW=5840 RES=0x00 ACK SYN URGP=0 That one is from my web server to some remote client!!! I''ve seen other cases with both single ACK and ACK SYN in both directions. Please run this for a while with logging turned on and see if you still think that it is a good idea. I think you''ll gain an appreciation for why the default Shorewall behavior is the way that it is... -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Mon, 5 Aug 2002, Tom Eastep wrote:> > It really needs Shorewall support to be done correctly. The version of the > ''firewall'' script in CVS implements two new parameters in shorewall.conf: > > NEWNOTSYN - Default is "Yes" (the current behavior). If set to "No" then > Shorewall will drop all non-syn packets in the NEW state. > > LOGNEWNOTSYN - Default is "". If non-empty, contains the log level at > which the above dropped packets will be logged. If empty, > the packets will be silently dropped. >I played with this a bit today and concluded that the above just doesn''t work. So I changed things a bit; the version in CVS now: a) Has moved the invocation of the ''init'' extension script until after all user chains have been deleted. This allows that script to create chains. b) Added a new ''newnotsyn'' extension script. This script is called after a chain is created and the ESTABLISHED,RELATED rule has been added to it. The name of the chain is in $CHAIN. I''m currently running with the following: /etc/shorewall/init: run_iptables -N badnew run_iptables -A badnew -p tcp --tcp-flags SYN,ACK,RST ACK -j RETURN run_iptables -A badnew -p tcp --tcp-flags SYN,ACK,RST ACK,SYN -j RETURN run_iptables -A badnew -j LOG --log-prefix "Shorewall:new_not_SYN:" run_iptables -A badnew -j DROP /etc/shorewall/newnotsyn: case $CHAIN in net2*) run_iptables -A $CHAIN -p tcp !--syn -m state --state NEW -j badnew ;; esac So far, I''ve logged: Aug 5 16:26:14 new_not_SYN:IN=eth0 OUT=eth1 SRC=195.xxx.xxx.xxx DST=206.124.146.177 LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=9957 PROTO=TCP SPT=25 DPT=43789 WINDOW=0 RES=0x00 ACK RST URGP=0 Without the first two rules in ''badnew'', some folks are experiencing connection problems. So far, I''ve seen no ill effects from dropping the "ACK RST". -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Mon, 5 Aug 2002, Links at Momsview wrote:> Tom, > Wow, thanks that''s amazing! I''ve never seen someone make enhancements so > fast. > I''ll try to try it out by this weekend. >Good. I think that I have the final implementation now. a) All "New not SYN" packets are dropped. b) These packets may be optionally logged by setting LOGNEWNOTSYN in shorewall.conf. c) You can add your own rules for dealing with "New NOT SYN" packets in /etc/shorewall/newnotsyn. For example, if you don''t want to log ACK,FIN packets: run_iptables -A newnotsyn -p tcp --tcp-flags ACK,FIN ACK,FIN -j DROP d) I''ve removed the ACK and RST rules from common.def. I think that logging these packets is not going to be something recommended for newbies so the default will be to not log. Here''s an example similar to the one that I posted the other day: Aug 6 09:41:53 newnotSYN:REJECT:IN=eth1 OUT=eth0 SRC=206.124.146.177 DST=151.x.x.x LEN=48 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=80 DPT=1234 WINDOW=5840 RES=0x00 ACK SYN URGP=0 There were a series of seven of these covering three different destination ports. I''m at a loss to explain what was happening... I want to thank you for bringing this issue to my attention -- it is something that has been nagging me for some time and you''re post was enought to "get me going". -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Do we have to download a new version?>>> Tom Eastep <teastep@shorewall.net> 8/6/02 2:33:08 PM >>>On Mon, 5 Aug 2002, Links at Momsview wrote:> Tom, > Wow, thanks that''s amazing! I''ve never seen someone make enhancements so > fast. > I''ll try to try it out by this weekend. >Good. I think that I have the final implementation now. a) All "New not SYN" packets are dropped. b) These packets may be optionally logged by setting LOGNEWNOTSYN in=20 shorewall.conf. c) You can add your own rules for dealing with "New NOT SYN" packets in=20 /etc/shorewall/newnotsyn. For example, if you don''t want to log ACK,FIN=20 packets: run_iptables -A newnotsyn -p tcp --tcp-flags ACK,FIN ACK,FIN -j DROP=20 d) I''ve removed the ACK and RST rules from common.def. I think that logging these packets is not going to be something=20 recommended for newbies so the default will be to not log.=20 Here''s an example similar to the one that I posted the other day: Aug 6 09:41:53 newnotSYN:REJECT:IN=3Deth1 OUT=3Deth0 SRC=3D206.124.146.177=20 DST=3D151.x.x.x LEN=3D48 TOS=3D0x00 PREC=3D0x00 TTL=3D63 ID=3D0 DF PROTO=3DTCP SPT=3D80=20 DPT=3D1234 WINDOW=3D5840 RES=3D0x00 ACK SYN URGP=3D0 There were a series of seven of these covering three different destination=20 ports. I''m at a loss to explain what was happening... I want to thank you for bringing this issue to my attention -- it is=20 something that has been nagging me for some time and you''re post was=20 enought to "get me going". -Tom --=20 Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net=20 ICQ: #60745924 \ teastep@shorewall.net=20 _______________________________________________ Shorewall-users mailing list Shorewall-users@shorewall.net=20 http://www.shorewall.net/mailman/listinfo/shorewall-users
On Tue, 6 Aug 2002, Godfried Duodu wrote:> Do we have to download a new version? >As soon as I get it ready, I''ll announce it. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net