Beta 1 had some significant issues, so I''ve uploaded Beta 2.
1) When the new shorewallrc file was installed (such as from the RPM),
VARDIR was being interpreted the same as VARLIB in the CLI. In
a generated script, VARDIR was being set to $VARDIR/$PRODUCT.
2) If the CONFIG_PATH setting required variable expansion and the
"-e" compiler option was specified, the settings in the export
shorewallrc were being used rather than those from the local
shorewallrc.
3) The new stoppedrules files contained a bogus ''FORMAT 2''
directive
that caused compilation to fail.
Known Issues:
1) Both the "routestopped" and "stoppedrules" file are
being processed
currently and in that order. It would be more appropriate to
process "stoppedrules" first and then process
"routestopped" only
if "stoppedrules" contained no rules.
New Features:
When "-e" is specified and no output script is named on the
run-line, the default script is now "firewall" in the current
working directory.
Thank you for testing,
-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 09/04/2012 10:11 AM, Tom Eastep wrote:> New Features: > > When "-e" is specified and no output script is named on the > run-line, the default script is now "firewall" in the current > working directory.In my enthusiasm for providing this default, I managed to disallow specifying a directory name with -e. Patch attached. -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/
> 1) When the new shorewallrc file was installed (such as from the RPM), > VARDIR was being interpreted the same as VARLIB in the CLI. In > a generated script, VARDIR was being set to $VARDIR/$PRODUCT.This now works as expected. However, when I execute "shorewall compile" or "shorewall compile test" both routestopped and stoppedrules files are ignored. In the resulting filrewall script I have this instead: # # Generated by Shorewall 4.5.8-Beta2 - Tue Sep 4 22:49:20 2012 # *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -i lo -j ACCEPT -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT COMMIT Again, I *do* have rules in the new stoppedrules file, though my routestopped file is non-existent. My config path is "${CONFDIR}/shorewall:${SHAREDIR}/shorewall" (routestopped isn''t present in either of these locations, only stoppedrules is in ${CONFDIR}/shorewall).> 2) If the CONFIG_PATH setting required variable expansion and the > "-e" compiler option was specified, the settings in the export > shorewallrc were being used rather than those from the local > shorewallrc.That works as expected when your patch is applied.> 3) The new stoppedrules files contained a bogus ''FORMAT 2'' directive > that caused compilation to fail.That''s also fixed.> Known Issues: > > 1) Both the "routestopped" and "stoppedrules" file are being processed > currently and in that order. It would be more appropriate to > process "stoppedrules" first and then process "routestopped" only > if "stoppedrules" contained no rules.That is indeed the case, with a bit of a twist! For the purpose of testing this, I have the following files: routestopped ~~~~~~~~~~~~ eth0 10.1.1.1 - tcp 22 stoppedrules ~~~~~~~~~~~~ ACCEPT $FW:+source-port +mickey-mouse-net[dst,dst] ACCEPT +destination-port $FW:+my-net[dst,dst] In the resulting script, I see the following section: # # Generated by Shorewall 4.5.8-Beta2 - Tue Sep 4 22:58:34 2012 # *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -p 6 --dport 22 -s 10.1.1.1 -i eth0 -j ACCEPT -A INPUT -m set --match-set destination-port src -m set --match-set my-net dst,dst -j ACCEPT -A INPUT -i lo -j ACCEPT -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A OUTPUT -m set --match-set source-port src -m set --match-set mickey-mouse-net dst,dst -j ACCEPT -A OUTPUT -o lo -j ACCEPT COMMIT What is interesting here (apart from the fact that both files were processed) is that for routestopped only INPUT was altered even though I specified a dash (-) - is that how it is supposed to work? My own opinion is that you should adopt the same approach you did with blacklist/blrules - issue a warning if both files are present (and process only stoppedrules) or simply process routestopped if stoppedrules isn''t present.> New Features: > > When "-e" is specified and no output script is named on the > run-line, the default script is now "firewall" in the current > working directory.That''s also functional. Apart from the above issues, from my previous list, I am not sure whether issue 5 has been fixed. The outstanding issues are how you decide to tackle the ''dhcp'' option in interfaces, specifying multiple UIDs separated with commas within a rule, as well as including an option in shorewall-init to compile the shorewall script prior to executing it. I think that''s about it. Have I missed anything? ------------------------------------------------------------------------------ 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 09/04/2012 03:30 PM, Mr Dash Four wrote:> >> 1) When the new shorewallrc file was installed (such as from the RPM), >> VARDIR was being interpreted the same as VARLIB in the CLI. In >> a generated script, VARDIR was being set to $VARDIR/$PRODUCT. > This now works as expected. However, when I execute "shorewall compile" or "shorewall compile test" both routestopped and stoppedrules files are ignored. In the resulting filrewall script I have this instead:this is very hard to explain: Here''s the output that I get, with or without the "routestopped" file present: # # Generated by Shorewall 4.5.8-Beta2 - Tue Sep 4 15:49:41 2012 # *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A PREROUTING -p 41 -i eth1 -j NOTRACK -A OUTPUT -p 41 -o eth1 -j NOTRACK COMMIT *rawpost :POSTROUTING ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -s 172.20.1.0/24 -i eth2 -j ACCEPT -A INPUT -p 41 -i eth1 -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p udp --dport 67:68 -i eth2 -j ACCEPT -A INPUT -p udp --dport 67:68 -i eth0 -j ACCEPT -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A FORWARD -p udp --dport 67:68 -i eth2 -o eth2 -j ACCEPT -A FORWARD -p udp --dport 67:68 -i eth0 -o eth0 -j ACCEPT COMMIT> > Again, I *do* have rules in the new stoppedrules file, though my routestopped file is non-existent. My config path is "${CONFDIR}/shorewall:${SHAREDIR}/shorewall" (routestopped isn''t present in either of these locations, only stoppedrules is in ${CONFDIR}/shorewall). >When compiling, do you see the line of output flagged below: Optimizing Ruleset... Creating iptables-restore input... Compiling /etc/shorewall/stoppedrules... <==============Shorewall configuration compiled to /var/lib/shorewall/firewall>> >> 1) Both the "routestopped" and "stoppedrules" file are being processed >> currently and in that order. It would be more appropriate to >> process "stoppedrules" first and then process "routestopped" only >> if "stoppedrules" contained no rules. > That is indeed the case, with a bit of a twist! For the purpose of testing this, I have the following files:I''ve attached the patch that implements the above behavior. See what happens with that patch applied.> > routestopped > ~~~~~~~~~~~~ > eth0 10.1.1.1 - tcp 22 > > stoppedrules > ~~~~~~~~~~~~ > ACCEPT $FW:+source-port +mickey-mouse-net[dst,dst] > ACCEPT +destination-port $FW:+my-net[dst,dst] > > In the resulting script, I see the following section: > > # > # Generated by Shorewall 4.5.8-Beta2 - Tue Sep 4 22:58:34 2012 > # > *raw > :PREROUTING ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > COMMIT > *nat > :PREROUTING ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > :POSTROUTING ACCEPT [0:0] > COMMIT > *mangle > :PREROUTING ACCEPT [0:0] > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > :POSTROUTING ACCEPT [0:0] > COMMIT > *filter > :INPUT DROP [0:0] > :FORWARD DROP [0:0] > :OUTPUT DROP [0:0] > -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT > -A INPUT -p 6 --dport 22 -s 10.1.1.1 -i eth0 -j ACCEPT > -A INPUT -m set --match-set destination-port src -m set --match-set my-net dst,dst -j ACCEPT > -A INPUT -i lo -j ACCEPT > -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT > -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT > -A OUTPUT -m set --match-set source-port src -m set --match-set mickey-mouse-net dst,dst -j ACCEPT > -A OUTPUT -o lo -j ACCEPT > COMMIT > > What is interesting here (apart from the fact that both files were processed) is that for routestopped only INPUT was altered even though I specified a dash (-) - is that how it is supposed to work?No. I may have broken the processing of routestopped; I''ll take a look.> > My own opinion is that you should adopt the same approach you did with blacklist/blrules - issue a warning if both files are present (and process only stoppedrules) or simply process routestopped if stoppedrules isn''t present.If both are present, then routestopped must be the one processed. Otherwise, an upgrade can''t install stoppedrules.> > Apart from the above issues, from my previous list, I am not sure whether issue 5 has been fixed.It''s not yet fixed.> > The outstanding issues are how you decide to tackle the ''dhcp'' option in interfaces, specifying multiple UIDs separated with commas within a rule, as well as including an option in shorewall-init to compile the shorewall script prior to executing it. I think that''s about it. Have I missed anything? >Part of the shorewall-init work is complete. The init scripts all compile the firewall if it doesn''t exist; not so yet with the ifupdown script. I''m going to be out of town for the rest of the week but I''ll get back to this over the weekend. -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/
> When compiling, do you see the line of output flagged below: > > Optimizing Ruleset... > Creating iptables-restore input... > Compiling /etc/shorewall/stoppedrules... <==============> Shorewall configuration compiled to /var/lib/shorewall/firewallThis is what I get: [root@test1 shorewall]# shorewall compile test Compiling... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... WARNING: Option EXPORTPARAMS=Yes is deprecated /etc/shorewall/shorewall.conf (line 253) Loading Modules... Compiling /etc/shorewall/zones... Compiling /etc/shorewall/interfaces... Determining Hosts in Zones... Locating Action Files... Compiling /usr/share/shorewall/action.Drop for chain Drop... Compiling /usr/share/shorewall/action.Reject for chain Reject... Compiling /etc/shorewall/policy... Running /etc/shorewall/initdone... Adding Anti-smurf Rules Compiling TCP Flags filtering... Compiling ARP Filtering... Compiling Kernel Route Filtering... Compiling Martian Logging... Compiling /etc/shorewall/tcdevices... Compiling /etc/shorewall/tcclasses... Compiling /etc/shorewall/tcrules... Compiling /etc/shorewall/secmarks... Compiling MAC Filtration -- Phase 1... Compiling /etc/shorewall/blrules... Compiling /etc/shorewall/rules... Compiling /etc/shorewall/conntrack... Compiling MAC Filtration -- Phase 2... Applying Policies... Generating Rule Matrix... Optimizing Ruleset... Creating iptables-restore input... Compiling /etc/shorewall/stoppedrules... Shorewall configuration compiled to /etc/shorewall/test Even though it says that it has been "processed", it isn''t. Here is my stoppedrules file: [root@test1 shorewall]# cat stoppedrules # # Shorewall version 4 - Stopped Rules File # # For information about entries in this file, type "man shorewall-stoppedrules" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-stoppedrules.html # # See http://shorewall.net/starting_and_stopping_shorewall.htm for additional # information. # ############################################################################### #TARGET SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(S) ACCEPT $FW:+mickey-mouse-port[dst] +mickey-mouse-net tcp Bizarre! If you can''t reproduce it, should I prepare a test case for you? I''ll respond to the other issues separately when I finish testing your patchlet... ------------------------------------------------------------------------------ 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/
> If both are present, then routestopped must be the one processed. > Otherwise, an upgrade can''t install stoppedrules.If both files are present the new stoppedrules gets processed *only*. That is after I applied your patchlet (which is perfect as this is what I wanted). At least that''s what I am getting with "shorewall compile -T -p -e".> I''m going to be out of town for the rest of the week but I''ll get back > to this over the weekend.No problem, let me know if/when you need me to test this. I''ll have some more time on Saturday and a bit on Sunday as well, so I could do some more testing then. ------------------------------------------------------------------------------ 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 9/4/12 4:20 PM, Mr Dash Four wrote:>> When compiling, do you see the line of output flagged below: >> >> Optimizing Ruleset... >> Creating iptables-restore input... >> Compiling /etc/shorewall/stoppedrules... <==============>> Shorewall configuration compiled to /var/lib/shorewall/firewall > This is what I get: > > [root@test1 shorewall]# shorewall compile test > Compiling... > Processing /etc/shorewall/params ... > Processing /etc/shorewall/shorewall.conf... > WARNING: Option EXPORTPARAMS=Yes is deprecated /etc/shorewall/shorewall.conf (line 253) > Loading Modules... > Compiling /etc/shorewall/zones... > Compiling /etc/shorewall/interfaces... > Determining Hosts in Zones... > Locating Action Files... > Compiling /usr/share/shorewall/action.Drop for chain Drop... > Compiling /usr/share/shorewall/action.Reject for chain Reject... > Compiling /etc/shorewall/policy... > Running /etc/shorewall/initdone... > Adding Anti-smurf Rules > Compiling TCP Flags filtering... > Compiling ARP Filtering... > Compiling Kernel Route Filtering... > Compiling Martian Logging... > Compiling /etc/shorewall/tcdevices... > Compiling /etc/shorewall/tcclasses... > Compiling /etc/shorewall/tcrules... > Compiling /etc/shorewall/secmarks... > Compiling MAC Filtration -- Phase 1... > Compiling /etc/shorewall/blrules... > Compiling /etc/shorewall/rules... > Compiling /etc/shorewall/conntrack... > Compiling MAC Filtration -- Phase 2... > Applying Policies... > Generating Rule Matrix... > Optimizing Ruleset... > Creating iptables-restore input... > Compiling /etc/shorewall/stoppedrules... > Shorewall configuration compiled to /etc/shorewall/test > > Even though it says that it has been "processed", it isn''t. Here is my stoppedrules file: > [root@test1 shorewall]# cat stoppedrules > # > # Shorewall version 4 - Stopped Rules File > # > # For information about entries in this file, type "man shorewall-stoppedrules" > # > # The manpage is also online at > # http://www.shorewall.net/manpages/shorewall-stoppedrules.html > # > # See http://shorewall.net/starting_and_stopping_shorewall.htm for additional > # information. > # > ############################################################################### > #TARGET SOURCE DEST PROTO DEST SOURCE > # PORT(S) PORT(S) > ACCEPT $FW:+mickey-mouse-port[dst] +mickey-mouse-net tcp > > Bizarre! If you can''t reproduce it, should I prepare a test case for you? I''ll respond to the other issues separately when I finish testing your patchlet...I''ll bet you have ADMINISABSENTMINDED=Yes. That setting accepts all output from the firewall so the above output rule is redundant and therefore suppressed. -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/
> I''ll bet you have ADMINISABSENTMINDED=Yes.Indeed I have (not that I am, mind). That has now been corrected and as a bonus I get this: Compiling /etc/shorewall/stoppedrules... WARNING: The ''dst'' ipset flag is used in a Source column /etc/shorewall/stoppedrules (line 15) WARNING: Ipset mickey-mouse-port does not exist /etc/shorewall/stoppedrules (line 15) WARNING: Ipset mickey-mouse-net does not exist /etc/shorewall/stoppedrules (line 15) Shorewall configuration compiled to /etc/shorewall/test which shows me that it works. Close inspection of "test" confirms it. Maybe you should place a warning when this happens to avoid other "absentminded" stragglers like me falling into the same trap. ------------------------------------------------------------------------------ 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 9/4/12 4:58 PM, Mr Dash Four wrote:>> I''ll bet you have ADMINISABSENTMINDED=Yes. > Indeed I have (not that I am, mind). That has now been corrected and as a bonus I get this: > Compiling /etc/shorewall/stoppedrules... > WARNING: The ''dst'' ipset flag is used in a Source column /etc/shorewall/stoppedrules (line 15) > WARNING: Ipset mickey-mouse-port does not exist /etc/shorewall/stoppedrules (line 15) > WARNING: Ipset mickey-mouse-net does not exist /etc/shorewall/stoppedrules (line 15) > Shorewall configuration compiled to /etc/shorewall/test > > which shows me that it works. Close inspection of "test" confirms it. Maybe you should place a warning when this happens to avoid other "absentminded" stragglers like me falling into the same trap. >Good idea. Thanks, -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 9/4/12 3:30 PM, Mr Dash Four wrote:> > The outstanding issues are how you decide to tackle the ''dhcp'' option > in interfaces, specifying multiple UIDs separated with commas within > a rule, as well as including an option in shorewall-init to compile > the shorewall script prior to executing it. I think that''s about it. > Have I missed anything? >Regarding the ''dhcp'' option, I wonder if it should be deprecated in favor of new ''dhcpclient'' and ''dhcpserver'' options; both of the new options would optionally accept an address list. Without knowing whether an interface gets its IP address via DHCP or whether a DHCP server on the router provides DHCP services to the network connected to an interface, unneeded rules must to be generated. I suppose that an alternative would be to assume that the router is a DHCP client when an IP list is specified to the existing ''dhcp'' option. Opinions welcome. -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/
> Regarding the ''dhcp'' option, I wonder if it should be deprecated in > favor of new ''dhcpclient'' and ''dhcpserver'' options; both of the new > options would optionally accept an address list. Without knowing whether > an interface gets its IP address via DHCP or whether a DHCP server on > the router provides DHCP services to the network connected to an > interface, unneeded rules must to be generated.The more I look into this, the more convinced I get that the ''dhcp'' option should be deprecated and confined to history, without introducing any new options at all. Even if you somehow add the 2 new options, that still won''t secure the firewall as much as a rules statement will (owner id as well as secmark can''t be specified to start with, which means that the firewall still won''t be fully secured). I am guessing that you originally introduced this option to allow dhcp traffic even when the firewall was closed/stopped, but shorewall these days is much more flexible and dhcp traffic rules can now be defined in "rules" as well as the new "stoppedrules" files - with all bells and whistles attached. Having written all that, yesterday I found something extremely annoying - even if I design the most beautifully crafted iptables rules and "restrict" DHCP traffic to/from the firewall, this, as it turns out, is completely *futile* as the DHCP client I am using - ISC DHCP - uses raw sockets, which means that the whole netfilter malarkey is completely bypassed [1] and the client goes trough my firewall like the proverbial knife through butter! I''ve personally tested this today and saw it with my own eyes! So, any suggestions on how to restore control over my DHCP traffic is mostly welcome. Whoever invented DHCP should be rounded up and dragged back to the asylum s/he came from or shot on site! [1] - Why DHCP uses raw sockets: https://deepthought.isc.org/article/AA-00378/0/Why-does-DHCP-use-raw-sockets.html ------------------------------------------------------------------------------ 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 9/6/12 4:10 PM, Mr Dash Four wrote:> The more I look into this, the more convinced I get that the ''dhcp'' > option should be deprecated and confined to history, without > introducing any new options at all. > > Even if you somehow add the 2 new options, that still won''t secure > the firewall as much as a rules statement will (owner id as well as > secmark can''t be specified to start with, which means that the > firewall still won''t be fully secured). I am guessing that you > originally introduced this option to allow dhcp traffic even when the > firewall was closed/stopped, but shorewall these days is much more > flexible and dhcp traffic rules can now be defined in "rules" as well > as the new "stoppedrules" files - with all bells and whistles > attached. > > Having written all that, yesterday I found something extremely > annoying - even if I design the most beautifully crafted iptables > rules and "restrict" DHCP traffic to/from the firewall, this, as it > turns out, is completely *futile* as the DHCP client I am using - ISC > DHCP - uses raw sockets, which means that the whole netfilter > malarkey is completely bypassed [1] and the client goes trough my > firewall like the proverbial knife through butter! > > I''ve personally tested this today and saw it with my own eyes! So, > any suggestions on how to restore control over my DHCP traffic is > mostly welcome. Whoever invented DHCP should be rounded up and > dragged back to the asylum s/he came from or shot on site! > > [1] - Why DHCP uses raw sockets: > https://deepthought.isc.org/article/AA-00378/0/Why-does-DHCP-use-raw-sockets.html >At least some DHCP clients use regular datagram sockets for lease renewal. So your rules may not be totally wasted. -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/
> At least some DHCP clients use regular datagram sockets for lease > renewal. So your rules may not be totally wasted. >Unfortunately, I am stuck with this one, at least for the time being. Is there any way I could control this flow? Use the raw table to define rules? Use ebtables even? ------------------------------------------------------------------------------ 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 9/7/12 6:54 AM, Mr Dash Four wrote:> >> At least some DHCP clients use regular datagram sockets for lease >> renewal. So your rules may not be totally wasted. >> > Unfortunately, I am stuck with this one, at least for the time being. Is > there any way I could control this flow? Use the raw table to define > rules? Use ebtables even?Not that I''m aware of. -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/