Hello, I''ve recently signed up for probe service through pingdom. They have many probe servers all over the world. Currently I''m not allowing ping from the net zone to my firewall. I''d like to track response time so I''d like to allow ping from the probe servers to my firewall. There are about 30 probe servers and that list changes from time to time. Anyway I know that I could do through directly through the rules file but I was wondering if there was a better approach? I could have sworn there was a whitelist file somewhere but the documentation ( http://shorewall.net/blacklisting_support.htm ) suggests it''s only through the rules file. Is the proper way to do this through the rules file and just a big list of IP''s? Thanks for your help! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Thu, Aug 16, 2012 at 9:46 AM, Aaron St. Pierre <asp@p0v.net> wrote:> Hello, > > I''ve recently signed up for probe service through pingdom. They have many > probe servers all over the world. Currently I''m not allowing ping from the > net zone to my firewall. I''d like to track response time so I''d like to > allow ping from the probe servers to my firewall. There are about 30 probe > servers and that list changes from time to time. Anyway I know that I could > do through directly through the rules file but I was wondering if there was > a better approach? I could have sworn there was a whitelist file somewhere > but the documentation ( http://shorewall.net/blacklisting_support.htm ) > suggests it''s only through the rules file. > > Is the proper way to do this through the rules file and just a big list of > IP''s? > > Thanks for your help! > > -- > > Aaron >I ended up creating two variables in the /etc/shorewall/params file one with the comma separated list of IP''s and the other describing the zone:IPs. Then I just added a simple rule in the rules file like so: PING(ACCEPT) $NET_PINGDOM_PROBE_IPS $FW_PUB And below this I have my PING(DROP)''s. Things seems to be working fine and I''m able to get responses to the probe servers. I''m new to shorewall so if this isn''t the proper way please let me know! Thanks again! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 08/16/2012 07:54 AM, Aaron St. Pierre wrote:> On Thu, Aug 16, 2012 at 9:46 AM, Aaron St. Pierre <asp@p0v.net > <mailto:asp@p0v.net>> wrote: > > Hello, > > I''ve recently signed up for probe service through pingdom. They have > many probe servers all over the world. Currently I''m not allowing > ping from the net zone to my firewall. I''d like to track response > time so I''d like to allow ping from the probe servers to my > firewall. There are about 30 probe servers and that list changes > from time to time. Anyway I know that I could do through directly > through the rules file but I was wondering if there was a better > approach? I could have sworn there was a whitelist file somewhere > but the documentation ( > http://shorewall.net/blacklisting_support.htm ) suggests it''s only > through the rules file. > > Is the proper way to do this through the rules file and just a big > list of IP''s? > > Thanks for your help! > > -- > > Aaron > > > I ended up creating two variables in the /etc/shorewall/params file one > with the comma separated list of IP''s and the other describing the > zone:IPs. Then I just added a simple rule in the rules file like so: > > PING(ACCEPT) $NET_PINGDOM_PROBE_IPS $FW_PUB > > And below this I have my PING(DROP)''s. > > Things seems to be working fine and I''m able to get responses to the > probe servers. > > I''m new to shorewall so if this isn''t the proper way please let me know! > > Thanks again!Hi Aaron, While what you did works file, there is a more efficient way to handle this. Add this entry in /etc/shorewall/actions: Pings # Handle ping from the net Create /etc/shorewall/action.Ping with this single rule: ACCEPT $PINGDOM_PROBE_IPS Replace your entry in /etc/shorewall/rules with: Pings net $FW_PUB icmp echo-request The advantage with this approach is that only pings packets are passed through the 30 rules that each compare one source ip address while your approach requires all new connection requests from the net to pass through those rules (unless they have been handled by a rule earlier in the file). An even more efficient way would be to use an ipset to define the Pingdom IP addresses, but unless you are running a quite recent kernel, that requires that you install the xtables-addons package. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 08/16/2012 09:39 AM, Tom Eastep wrote:> While what you did works fine, there is a more efficient way to handle this. > > Add this entry in /etc/shorewall/actions: > > Pings # Handle ping from the net > > Create /etc/shorewall/action.Pings with this single rule: > > ACCEPT $PINGDOM_PROBE_IPS > > Replace your entry in /etc/shorewall/rules with: > > Pings net $FW_PUB icmp echo-request > > The advantage with this approach is that only pings packets are passed > through the 30 rules that each compare one source ip address, while your > approach requires all new connection requests from the net to pass > through those rules (unless they have been handled by a rule earlier in > the file). > > An even more efficient way would be to use an ipset to define the > Pingdom IP addresses, but unless you are running a quite recent kernel, > that requires that you install the xtables-addons package.I corrected a couple of typos in the quoted text above. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Thu, Aug 16, 2012 at 1:13 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 08/16/2012 09:39 AM, Tom Eastep wrote: > > > While what you did works fine, there is a more efficient way to handle > this. > > > > Add this entry in /etc/shorewall/actions: > > > > Pings # Handle ping from the net > > > > Create /etc/shorewall/action.Pings with this single rule: > > > > ACCEPT $PINGDOM_PROBE_IPS > > > > Replace your entry in /etc/shorewall/rules with: > > > > Pings net $FW_PUB icmp echo-request > > > > The advantage with this approach is that only pings packets are passed > > through the 30 rules that each compare one source ip address, while your > > approach requires all new connection requests from the net to pass > > through those rules (unless they have been handled by a rule earlier in > > the file). > > > > An even more efficient way would be to use an ipset to define the > > Pingdom IP addresses, but unless you are running a quite recent kernel, > > that requires that you install the xtables-addons package. > > I corrected a couple of typos in the quoted text above. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >Hi Tom, Thanks a lot for the reply! I''m trying to apply the ipsets method as I have a recent kernel. I''m running 3.4.2. I''ve figured out how to create an ipset with the ipset create command. What I''ve done is created the ipset called PINGDOM_PROBE_IPS shown here: # ipset list Name: PINGDOM_PROBE_IPS Type: hash:ip Header: family inet hashsize 1024 maxelem 65536 Size in memory: 8284 References: 0 Members: 188.138.118.184 188.138.124.110 What I don''t understand if I can just reference this list directly in the rules file? In other words is it as simple as: Ping(ACCEPT) net:+PINGDOM_PROBE_IPS $FW_PUB Thanks again for your help! Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 8/16/12 1:35 PM, Aaron St. Pierre wrote:> On Thu, Aug 16, 2012 at 1:13 PM, Tom Eastep <teastep@shorewall.net > <mailto:teastep@shorewall.net>> wrote: > > On 08/16/2012 09:39 AM, Tom Eastep wrote: > > > While what you did works fine, there is a more efficient way to > handle this. > > > > Add this entry in /etc/shorewall/actions: > > > > Pings # Handle ping from the net > > > > Create /etc/shorewall/action.Pings with this single rule: > > > > ACCEPT $PINGDOM_PROBE_IPS > > > > Replace your entry in /etc/shorewall/rules with: > > > > Pings net $FW_PUB icmp echo-request > > > > The advantage with this approach is that only pings packets are passed > > through the 30 rules that each compare one source ip address, > while your > > approach requires all new connection requests from the net to pass > > through those rules (unless they have been handled by a rule > earlier in > > the file). > > > > An even more efficient way would be to use an ipset to define the > > Pingdom IP addresses, but unless you are running a quite recent > kernel, > > that requires that you install the xtables-addons package. > > I corrected a couple of typos in the quoted text above. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > <mailto:Shorewall-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > Hi Tom, > > Thanks a lot for the reply! I''m trying to apply the ipsets method as I > have a recent kernel. I''m running 3.4.2. I''ve figured out how to create > an ipset with the ipset create command. What I''ve done is created the > ipset called PINGDOM_PROBE_IPS shown here: > > # ipset list > Name: PINGDOM_PROBE_IPS > Type: hash:ip > Header: family inet hashsize 1024 maxelem 65536 > Size in memory: 8284 > References: 0 > Members: > 188.138.118.184 > 188.138.124.110 > > What I don''t understand if I can just reference this list directly in > the rules file? In other words is it as simple as: > > Ping(ACCEPT) net:+PINGDOM_PROBE_IPS $FW_PUB > > Thanks again for your help!It''s as simple as that. One more thing though - you should set SAVE_IPSETS=Yes in shorewall.conf and restart Shorewall. Otherwise, your ipset will disappear at the next reboot. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Thu, Aug 16, 2012 at 4:54 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 8/16/12 1:35 PM, Aaron St. Pierre wrote: > > On Thu, Aug 16, 2012 at 1:13 PM, Tom Eastep <teastep@shorewall.net > > <mailto:teastep@shorewall.net>> wrote: > > > > On 08/16/2012 09:39 AM, Tom Eastep wrote: > > > > > While what you did works fine, there is a more efficient way to > > handle this. > > > > > > Add this entry in /etc/shorewall/actions: > > > > > > Pings # Handle ping from the net > > > > > > Create /etc/shorewall/action.Pings with this single rule: > > > > > > ACCEPT $PINGDOM_PROBE_IPS > > > > > > Replace your entry in /etc/shorewall/rules with: > > > > > > Pings net $FW_PUB icmp echo-request > > > > > > The advantage with this approach is that only pings packets are > passed > > > through the 30 rules that each compare one source ip address, > > while your > > > approach requires all new connection requests from the net to pass > > > through those rules (unless they have been handled by a rule > > earlier in > > > the file). > > > > > > An even more efficient way would be to use an ipset to define the > > > Pingdom IP addresses, but unless you are running a quite recent > > kernel, > > > that requires that you install the xtables-addons package. > > > > I corrected a couple of typos in the quoted text above. > > > > -Tom > > -- > > Tom Eastep \ When I die, I want to go like my Grandfather who > > Shoreline, \ died peacefully in his sleep. Not screaming like > > Washington, USA \ all of the passengers in his car > > http://shorewall.net\________________________________________________ > > > > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today''s security and > > threat landscape has changed and how IT managers can respond. > > Discussions > > will include endpoint security, mobile security and the latest in > > malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Shorewall-users mailing list > > Shorewall-users@lists.sourceforge.net > > <mailto:Shorewall-users@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > > > > > Hi Tom, > > > > Thanks a lot for the reply! I''m trying to apply the ipsets method as I > > have a recent kernel. I''m running 3.4.2. I''ve figured out how to create > > an ipset with the ipset create command. What I''ve done is created the > > ipset called PINGDOM_PROBE_IPS shown here: > > > > # ipset list > > Name: PINGDOM_PROBE_IPS > > Type: hash:ip > > Header: family inet hashsize 1024 maxelem 65536 > > Size in memory: 8284 > > References: 0 > > Members: > > 188.138.118.184 > > 188.138.124.110 > > > > What I don''t understand if I can just reference this list directly in > > the rules file? In other words is it as simple as: > > > > Ping(ACCEPT) net:+PINGDOM_PROBE_IPS $FW_PUB > > > > Thanks again for your help! > > It''s as simple as that. One more thing though - you should set > SAVE_IPSETS=Yes in shorewall.conf and restart Shorewall. Otherwise, your > ipset will disappear at the next reboot. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >Just Awesome! I created my list and added the rule and everything is working great! Yes I did turn on SAVE_IPSETS in the configuration file. One thing I noticed is that there are some ''fooTMPID'' hanging around with no members. I''m assuming that shorewall created them but not sure: Name: fooX25739 Type: hash:ip Header: family inet hashsize 1024 maxelem 65536 Size in memory: 8252 References: 0 Members: Are they needed for anything? What is great about this solution is that I can check for changes in the IP''s and simply update the ipset accordingly-very cool! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 8/16/12 2:02 PM, Aaron St. Pierre wrote:> Just Awesome! I created my list and added the rule and everything is > working great! Yes I did turn on SAVE_IPSETS in the configuration file. > > One thing I noticed is that there are some ''fooTMPID'' hanging around > with no members. I''m assuming that shorewall created them but not sure: > > Name: fooX25739 > Type: hash:ip > Header: family inet hashsize 1024 maxelem 65536 > Size in memory: 8252 > References: 0 > Members: > > Are they needed for anything?No -- Which shorewall version are you using?> > What is great about this solution is that I can check for changes in the > IP''s and simply update the ipset accordingly-very cool! >Yes -- it''s a good way to go. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Thu, Aug 16, 2012 at 5:24 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 8/16/12 2:02 PM, Aaron St. Pierre wrote: > > > Just Awesome! I created my list and added the rule and everything is > > working great! Yes I did turn on SAVE_IPSETS in the configuration file. > > > > One thing I noticed is that there are some ''fooTMPID'' hanging around > > with no members. I''m assuming that shorewall created them but not sure: > > > > Name: fooX25739 > > Type: hash:ip > > Header: family inet hashsize 1024 maxelem 65536 > > Size in memory: 8252 > > References: 0 > > Members: > > > > Are they needed for anything? > > No -- Which shorewall version are you using? >4.5.4 on centos 6.3> > > What is great about this solution is that I can check for changes in the > > IP''s and simply update the ipset accordingly-very cool! > > > > Yes -- it''s a good way to go. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >-- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 08/16/2012 02:35 PM, Aaron St. Pierre wrote:> On Thu, Aug 16, 2012 at 5:24 PM, Tom Eastep <teastep@shorewall.net > <mailto:teastep@shorewall.net>> wrote: > > On 8/16/12 2:02 PM, Aaron St. Pierre wrote: > > > Just Awesome! I created my list and added the rule and everything is > > working great! Yes I did turn on SAVE_IPSETS in the configuration > file. > > > > One thing I noticed is that there are some ''fooTMPID'' hanging around > > with no members. I''m assuming that shorewall created them but not > sure: > > > > Name: fooX25739 > > Type: hash:ip > > Header: family inet hashsize 1024 maxelem 65536 > > Size in memory: 8252 > > References: 0 > > Members: > > > > Are they needed for anything? > > No -- Which shorewall version are you using? > > > 4.5.4 on centos 6.3I''m not seeing this problem on any of my systems. Can you determine what command is causing these sets to be left behind? BTW: They are created when Shorewall is determining the capabilities of your system. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Fri, Aug 17, 2012 at 11:21 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 08/16/2012 02:35 PM, Aaron St. Pierre wrote: > > On Thu, Aug 16, 2012 at 5:24 PM, Tom Eastep <teastep@shorewall.net > > <mailto:teastep@shorewall.net>> wrote: > > > > On 8/16/12 2:02 PM, Aaron St. Pierre wrote: > > > > > Just Awesome! I created my list and added the rule and everything > is > > > working great! Yes I did turn on SAVE_IPSETS in the configuration > > file. > > > > > > One thing I noticed is that there are some ''fooTMPID'' hanging > around > > > with no members. I''m assuming that shorewall created them but not > > sure: > > > > > > Name: fooX25739 > > > Type: hash:ip > > > Header: family inet hashsize 1024 maxelem 65536 > > > Size in memory: 8252 > > > References: 0 > > > Members: > > > > > > Are they needed for anything? > > > > No -- Which shorewall version are you using? > > > > > > 4.5.4 on centos 6.3 > > I''m not seeing this problem on any of my systems. Can you determine what > command is causing these sets to be left behind? > > BTW: They are created when Shorewall is determining the capabilities of > your system. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >Tom, I''ll make some time to take a look at this today. -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sat, Aug 18, 2012 at 9:26 AM, Aaron St. Pierre <asp@p0v.net> wrote:> On Fri, Aug 17, 2012 at 11:21 AM, Tom Eastep <teastep@shorewall.net>wrote: > >> On 08/16/2012 02:35 PM, Aaron St. Pierre wrote: >> > On Thu, Aug 16, 2012 at 5:24 PM, Tom Eastep <teastep@shorewall.net >> > <mailto:teastep@shorewall.net>> wrote: >> > >> > On 8/16/12 2:02 PM, Aaron St. Pierre wrote: >> > >> > > Just Awesome! I created my list and added the rule and >> everything is >> > > working great! Yes I did turn on SAVE_IPSETS in the configuration >> > file. >> > > >> > > One thing I noticed is that there are some ''fooTMPID'' hanging >> around >> > > with no members. I''m assuming that shorewall created them but not >> > sure: >> > > >> > > Name: fooX25739 >> > > Type: hash:ip >> > > Header: family inet hashsize 1024 maxelem 65536 >> > > Size in memory: 8252 >> > > References: 0 >> > > Members: >> > > >> > > Are they needed for anything? >> > >> > No -- Which shorewall version are you using? >> > >> > >> > 4.5.4 on centos 6.3 >> >> I''m not seeing this problem on any of my systems. Can you determine what >> command is causing these sets to be left behind? >> >> BTW: They are created when Shorewall is determining the capabilities of >> your system. >> >> -Tom >> -- >> Tom Eastep \ When I die, I want to go like my Grandfather who >> Shoreline, \ died peacefully in his sleep. Not screaming like >> Washington, USA \ all of the passengers in his car >> http://shorewall.net \________________________________________________ >> >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today''s security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> > > > Tom, I''ll make some time to take a look at this today. > -- > > Aaron >Tom, It appears that even though the rule is being deleted ipset believes there is still a reference to the set. I added some line numbers so I may be off a bit: lib.cli 2162 if [ -n "$have_ipset" ]; then 2163 if qt $g_tool -A $chain -m set --match-set $chain src -j ACCEPT; then 2164 qt $g_tool -D $chain -m set --match-set $chain src -j ACCEPT 2165 IPSET_MATCH=Yes 2166 elif qt $g_tool -A $chain -m set --set $chain src -j ACCEPT; then 2167 qt $g_tool -D $chain -m set --set $chain src -j ACCEPT 2168 IPSET_MATCH=Yes 2169 OLD_IPSET_MATCH=Yes 2170 fi 2171 echo "--------------------- $chain" 2172 ipset list 2173 iptables -L -n 2174 ipset -X $chain 2175 fi When the ipset in line 2174 is invoked on my system I get the standard ipset error: ipset v6.11: Set cannot be destroyed: it is in use by a kernel component If I move the ipset -X command to the end of the capabilities function ~line 2244: ipset -X $chain The fooXdddd ipset is then removed. I''ve gotta run now but I''ll do a bit more testing later tonight! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 8/18/12 12:02 PM, Aaron St. Pierre wrote:> > Tom, > > It appears that even though the rule is being deleted ipset believes > there is still a reference to the set. I added some line numbers so I > may be off a bit: > > lib.cli > > 2162 if [ -n "$have_ipset" ]; then > 2163 if qt $g_tool -A $chain -m set --match-set $chain > src -j ACCEPT; then > 2164 qt $g_tool -D $chain -m set --match-set $chain > src -j ACCEPT > 2165 IPSET_MATCH=Yes > 2166 elif qt $g_tool -A $chain -m set --set $chain src > -j ACCEPT; then > 2167 qt $g_tool -D $chain -m set --set $chain src -j > ACCEPT > 2168 IPSET_MATCH=Yes > 2169 OLD_IPSET_MATCH=Yes > 2170 fi > 2171 echo "--------------------- $chain" > 2172 ipset list > 2173 iptables -L -n > 2174 ipset -X $chain > 2175 fi > > When the ipset in line 2174 is invoked on my system I get the standard > ipset error: > > ipset v6.11: Set cannot be destroyed: it is in use by a kernel component > > If I move the ipset -X command to the end of the capabilities function > ~line 2244: > > ipset -X $chain > > The fooXdddd ipset is then removed.Something must be broken with your kit -- that code works as expected on my systems. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sat, Aug 18, 2012 at 5:42 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 8/18/12 12:02 PM, Aaron St. Pierre wrote: > > > > > Tom, > > > > It appears that even though the rule is being deleted ipset believes > > there is still a reference to the set. I added some line numbers so I > > may be off a bit: > > > > lib.cli > > > > 2162 if [ -n "$have_ipset" ]; then > > 2163 if qt $g_tool -A $chain -m set --match-set $chain > > src -j ACCEPT; then > > 2164 qt $g_tool -D $chain -m set --match-set $chain > > src -j ACCEPT > > 2165 IPSET_MATCH=Yes > > 2166 elif qt $g_tool -A $chain -m set --set $chain src > > -j ACCEPT; then > > 2167 qt $g_tool -D $chain -m set --set $chain src -j > > ACCEPT > > 2168 IPSET_MATCH=Yes > > 2169 OLD_IPSET_MATCH=Yes > > 2170 fi > > 2171 echo "--------------------- $chain" > > 2172 ipset list > > 2173 iptables -L -n > > 2174 ipset -X $chain > > 2175 fi > > > > When the ipset in line 2174 is invoked on my system I get the standard > > ipset error: > > > > ipset v6.11: Set cannot be destroyed: it is in use by a kernel component > > > > If I move the ipset -X command to the end of the capabilities function > > ~line 2244: > > > > ipset -X $chain > > > > The fooXdddd ipset is then removed. > > Something must be broken with your kit -- that code works as expected on > my systems. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >Tom, I may have accepted that but I just setup a completely fresh install of centos 6.3 final, installed shorewall and the *same* things is happening. One thing that may be worthy of noting is that these are VPS(es) running over at linode so the kernels are linode kernels. This one happens to be running 3.0.18-linode43. I suppose it''s not the end of the world as I do have a work around, but I certainly don''t think I''m the only person that is going to face this problem. Another nasty side effect of the problem would be the lists being preserved if you have ipset save turned on. Moving the ipset -X $chain to the bottom of the function seemed to take care of the problem. I''ll do some more testing and report back. -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sat, Aug 18, 2012 at 7:03 PM, Aaron St. Pierre <asp@p0v.net> wrote:> On Sat, Aug 18, 2012 at 5:42 PM, Tom Eastep <teastep@shorewall.net> wrote: > >> On 8/18/12 12:02 PM, Aaron St. Pierre wrote: >> >> > >> > Tom, >> > >> > It appears that even though the rule is being deleted ipset believes >> > there is still a reference to the set. I added some line numbers so I >> > may be off a bit: >> > >> > lib.cli >> > >> > 2162 if [ -n "$have_ipset" ]; then >> > 2163 if qt $g_tool -A $chain -m set --match-set $chain >> > src -j ACCEPT; then >> > 2164 qt $g_tool -D $chain -m set --match-set $chain >> > src -j ACCEPT >> > 2165 IPSET_MATCH=Yes >> > 2166 elif qt $g_tool -A $chain -m set --set $chain src >> > -j ACCEPT; then >> > 2167 qt $g_tool -D $chain -m set --set $chain src -j >> > ACCEPT >> > 2168 IPSET_MATCH=Yes >> > 2169 OLD_IPSET_MATCH=Yes >> > 2170 fi >> > 2171 echo "--------------------- $chain" >> > 2172 ipset list >> > 2173 iptables -L -n >> > 2174 ipset -X $chain >> > 2175 fi >> > >> > When the ipset in line 2174 is invoked on my system I get the standard >> > ipset error: >> > >> > ipset v6.11: Set cannot be destroyed: it is in use by a kernel component >> > >> > If I move the ipset -X command to the end of the capabilities function >> > ~line 2244: >> > >> > ipset -X $chain >> > >> > The fooXdddd ipset is then removed. >> >> Something must be broken with your kit -- that code works as expected on >> my systems. >> >> -Tom >> -- >> Tom Eastep \ When I die, I want to go like my Grandfather who >> Shoreline, \ died peacefully in his sleep. Not screaming like >> Washington, USA \ all of the passengers in his car >> http://shorewall.net \________________________________________________ >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today''s security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >> > Tom, > > I may have accepted that but I just setup a completely fresh install of > centos 6.3 final, installed shorewall and the *same* things is happening. > > One thing that may be worthy of noting is that these are VPS(es) running > over at linode so the kernels are linode kernels. This one happens to be > running 3.0.18-linode43. > > I suppose it''s not the end of the world as I do have a work around, but I > certainly don''t think I''m the only person that is going to face this > problem. > > Another nasty side effect of the problem would be the lists being > preserved if you have ipset save turned on. > > Moving the ipset -X $chain to the bottom of the function seemed to take > care of the problem. I''ll do some more testing and report back. > > -- > > Aaron >Hi Tom, Here is some more info: # shorewall show capabilities /sbin/iptables -A fooX29429 -m set --match-set fooX29429 src -j ACCEPT 1 *********here@@@@@@@@@@@@@@@@ /sbin/iptables -D fooX29429 -m set --match-set fooX29429 src -j ACCEPT iptables: Bad rule (does a matching rule exist in that chain?). ipset v6.11: Set cannot be destroyed: it is in use by a kernel component after IPset section Chain fooX29429 (0 references) ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 match-set fooX29429 src Chain fooX294291 (0 references) So the problem appears to be with $g_tool -D $chain -m set --match-set $chain src -j ACCEPT Since that fails so does the ipset -X $chain Changing the iptables command to flush the chain does in fact get rid of the rules and then I''m able to remove the ipset as expected. Again this is happening on a vanilla system so I mustn''t have my system configured properly. Is there anything I need to do on my end to be able to have iptables delete these rules? I''m running the same everything on both boxes but one is a completely fresh install and the other is a host I''ve been using for awhile. Thanks again Tom your help is greatly appreciated! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 8/18/12 6:20 PM, Aaron St. Pierre wrote:> Hi Tom, > > Here is some more info: > > # shorewall show capabilities > /sbin/iptables -A fooX29429 -m set --match-set fooX29429 src -j ACCEPT > 1 *********here@@@@@@@@@@@@@@@@ > /sbin/iptables -D fooX29429 -m set --match-set fooX29429 src -j ACCEPT > iptables: Bad rule (does a matching rule exist in that chain?). > ipset v6.11: Set cannot be destroyed: it is in use by a kernel component > after IPset section > Chain fooX29429 (0 references) > ACCEPT all -- 0.0.0.0/0 <http://0.0.0.0/0> 0.0.0.0/0 > <http://0.0.0.0/0> match-set fooX29429 src > Chain fooX294291 (0 references) > > So the problem appears to be with > > $g_tool -D $chain -m set --match-set $chain src -j ACCEPT > > Since that fails so does the > > ipset -X $chain > > Changing the iptables command to flush the chain does in fact get rid of > the rules and then I''m able to remove the ipset as expected. > > Again this is happening on a vanilla system so I mustn''t have my system > configured properly. Is there anything I need to do on my end to be able > to have iptables delete these rules? I''m running the same everything on > both boxes but one is a completely fresh install and the other is a host > I''ve been using for awhile.While you were doing this, I was installing Foobar Linux 6.3; like Centos, Foobar is a RHEL derivative. Foobar 6.3 shows the same result. I think that the best patch is to substitute: $g_tool -F for the existing ''$g_tool -D'' commands. Patch against the current 4.5.7 branch attached (should apply with offset to you configuration). This iptables/Netfilter bug is fixed in Fedora 17, so the fix should make it into RHEL and CentOS/Foobar eventually. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sat, Aug 18, 2012 at 9:48 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 8/18/12 6:20 PM, Aaron St. Pierre wrote: > > > Hi Tom, > > > > Here is some more info: > > > > # shorewall show capabilities > > /sbin/iptables -A fooX29429 -m set --match-set fooX29429 src -j ACCEPT > > 1 *********here@@@@@@@@@@@@@@@@ > > /sbin/iptables -D fooX29429 -m set --match-set fooX29429 src -j ACCEPT > > iptables: Bad rule (does a matching rule exist in that chain?). > > ipset v6.11: Set cannot be destroyed: it is in use by a kernel component > > after IPset section > > Chain fooX29429 (0 references) > > ACCEPT all -- 0.0.0.0/0 <http://0.0.0.0/0> 0.0.0.0/0 > > <http://0.0.0.0/0> match-set fooX29429 src > > Chain fooX294291 (0 references) > > > > So the problem appears to be with > > > > $g_tool -D $chain -m set --match-set $chain src -j ACCEPT > > > > Since that fails so does the > > > > ipset -X $chain > > > > Changing the iptables command to flush the chain does in fact get rid of > > the rules and then I''m able to remove the ipset as expected. > > > > Again this is happening on a vanilla system so I mustn''t have my system > > configured properly. Is there anything I need to do on my end to be able > > to have iptables delete these rules? I''m running the same everything on > > both boxes but one is a completely fresh install and the other is a host > > I''ve been using for awhile. > > While you were doing this, I was installing Foobar Linux 6.3; like > Centos, Foobar is a RHEL derivative. Foobar 6.3 shows the same result. I > think that the best patch is to substitute: > > $g_tool -F > > for the existing ''$g_tool -D'' commands. > > Patch against the current 4.5.7 branch attached (should apply with > offset to you configuration). > > This iptables/Netfilter bug is fixed in Fedora 17, so the fix should > make it into RHEL and CentOS/Foobar eventually. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >Awesome! Thanks Tom! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 8/18/12 6:48 PM, Tom Eastep wrote:> While you were doing this, I was installing Foobar Linux 6.3; like > Centos, Foobar is a RHEL derivative. Foobar 6.3 shows the same result. I > think that the best patch is to substitute: > > $g_tool -F > > for the existing ''$g_tool -D'' commands. > > Patch against the current 4.5.7 branch attached (should apply with > offset to you configuration). > > This iptables/Netfilter bug is fixed in Fedora 17, so the fix should > make it into RHEL and CentOS/Foobar eventually.This is the correct patch -- the last one cleared the running firewall :-/ -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sat, Aug 18, 2012 at 10:07 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 8/18/12 6:48 PM, Tom Eastep wrote: > > > While you were doing this, I was installing Foobar Linux 6.3; like > > Centos, Foobar is a RHEL derivative. Foobar 6.3 shows the same result. I > > think that the best patch is to substitute: > > > > $g_tool -F > > > > for the existing ''$g_tool -D'' commands. > > > > Patch against the current 4.5.7 branch attached (should apply with > > offset to you configuration). > > > > This iptables/Netfilter bug is fixed in Fedora 17, so the fix should > > make it into RHEL and CentOS/Foobar eventually. > > This is the correct patch -- the last one cleared the running firewall :-/ > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >Yep just found that out the hard way :) -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sat, Aug 18, 2012 at 10:07 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 8/18/12 6:48 PM, Tom Eastep wrote: > > > While you were doing this, I was installing Foobar Linux 6.3; like > > Centos, Foobar is a RHEL derivative. Foobar 6.3 shows the same result. I > > think that the best patch is to substitute: > > > > $g_tool -F > > > > for the existing ''$g_tool -D'' commands. > > > > Patch against the current 4.5.7 branch attached (should apply with > > offset to you configuration). > > > > This iptables/Netfilter bug is fixed in Fedora 17, so the fix should > > make it into RHEL and CentOS/Foobar eventually. > > This is the correct patch -- the last one cleared the running firewall :-/ > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >Tom, I confirm this patch is working as expected on my systems! Thanks again, -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 08/18/2012 07:25 PM, Aaron St. Pierre wrote:> Tom, > > I confirm this patch is working as expected on my systems! >Aaron, Here is a compiler workaround for this problem; the compiler can also leave an empty ipset behind. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sun, Aug 19, 2012 at 9:18 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 08/18/2012 07:25 PM, Aaron St. Pierre wrote: > > Tom, >> >> I confirm this patch is working as expected on my systems! >> >> > Aaron, > > Here is a compiler workaround for this problem; the compiler can also > leave an empty ipset behind. > > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \_____________________________**___________________ > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >Tom, I couldn''t for the life of me figure out why when I ''restarted'' shorewall I still had a ipset hanging around. It was only happening on one of my boxes so I figured it was just a one-off. I figured it was in the compiler, but didn''t check. I''ve installed the patch and now there is no more fooXdddd list hanging around after restart! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/