Hi, I have a few problems with my shorewall configuration. First of all, the option maclist seems no to be recognized. I have this: ghostwheel /etc/shorewall # cat interfaces | grep -v ''^#'' - eth1 detect dhcp,tcpflags,routefilter loc eth0 detect tcpflags,maclist When I look at shorewall-init.log, I found out: ghostwheel /etc/shorewall # grep MAC /var/log/shorewall-init.log Setting up MAC Verification on eth0... But, then even with a non-existent or empty /etc/shorewall/maclist, I can ping and use host that are on eth0. I''m using: ghostwheel /etc/shorewall # shorewall version 2.0.15 Does anyone has any idea why mac verification is not working. My other problem, (which is not as much a problem as a question about how to do that) is that I want to add the norfc1918 for traffic that comes through eth1, but there is an ipsec tunnels there, so somme non routable traffic is going through this interface (but only via the ipsec tunnel). Should I put the norfc1918 option in the host file ? Because in the documentation, it is said that it has interest only for a bridge... Thanks in advance. -- Benjamin Lerman
Benjamin Lerman wrote:> I have this: > > ghostwheel /etc/shorewall # cat interfaces | grep -v ''^#'' > - eth1 detect dhcp,tcpflags,routefilter > loc eth0 detect tcpflags,maclist > > When I look at shorewall-init.log, I found out: > > ghostwheel /etc/shorewall # grep MAC /var/log/shorewall-init.log > Setting up MAC Verification on eth0... > > But, then even with a non-existent or empty /etc/shorewall/maclist, I > can ping and use host that are on eth0. > > I''m using: > > ghostwheel /etc/shorewall # shorewall version > 2.0.15 > > Does anyone has any idea why mac verification is not working.What is the setting of MACLIST_DISPOSITION in shorewall.conf? What is the output of "shorewall show eth0_mac"? What does "shorewall status" | grep eth0_mac" give you?> > My other problem, (which is not as much a problem as a question about > how to do that) is that I want to add the norfc1918 for traffic that > comes through eth1, but there is an ipsec tunnels there, so somme > non routable traffic is going through this interface (but only via the > ipsec tunnel). Should I put the norfc1918 option in the host file ? > Because in the documentation, it is said that it has interest only for a > bridge...rfc1918 will not affect IPSEC tunnel traffic on an Ethernet interface. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> What is the setting of MACLIST_DISPOSITION in shorewall.conf?ghostwheel /etc/shorewall # grep MACLIST_DISPOSITION shorewall.conf # empty (MACLIST_DISPOSITION="") then REJECT is assumed MACLIST_DISPOSITION=REJECT> What is the output of "shorewall show eth0_mac"?ghostwheel /etc/shorewall # shorewall show eth0_mac Shorewall-2.0.15 Chain eth0_mac at ghostwheel - Tue Feb 8 16:44:42 CET 2005 Counters reset Tue Feb 8 16:44:31 CET 2005 Chain eth0_mac (2 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- * * 10.66.17.1 10.66.17.255 0 0 RETURN all -- * * 10.66.17.0/24 255.255.255.255 0 0 RETURN all -- * * 10.66.17.0/24 224.0.0.0/4 0 0 RETURN all -- * * 192.168.1.1 192.168.1.255 0 0 RETURN all -- * * 192.168.1.0/24 255.255.255.255 0 0 RETURN all -- * * 192.168.1.0/24 224.0.0.0/4 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/hour burst 5 LOG flags 0 level 6 prefix `Shorewall:eth0_mac:REJECT:'' 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0> What does "shorewall status" | grep eth0_mac" give you?ghostwheel /etc/shorewall # shorewall status | grep eth0_mac 0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW Chain eth0_mac (2 references) 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/hour burst 5 LOG flags 0 level 6 prefix `Shorewall:eth0_mac:REJECT:''> rfc1918 will not affect IPSEC tunnel traffic on an Ethernet interface.Well, I don''t understand this statement. If I put norfc1918 in the interfaces file, or in the host file (for the 0.0.0.0/0 network which is defined after the vpn network), I get those in my logs: Feb 8 16:47:42 ghostwheel kernel: Shorewall:rfc1918:DROP:IN=eth1 OUT= MAC=00:30:1b:3e:0d:0e:00:07:cb:05:e9:10:08:00 SRC=10.66.42.2 DST=10.66.17.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=3 DF PROTO=ICMP TYPE=8 CODE=0 ID=49683 SEQ=4 or Feb 8 16:49:03 ghostwheel kernel: Shorewall:rfc1918:DROP:IN=eth1 OUT= MAC=00:30:1b:3e:0d:0e:00:07:cb:05:e9:10:08:00 SRC=10.66.42.2 DST=82.230.54.63 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=49939 SEQ=1 which tend to show that rfc1918 is taken into account for ipsec tunnel... Or there is something I did not understand... -- Benjamin Lerman
Would you PLEASE post in plain text and configure your mailer to fold long lines at an appropriate length? Each of your paragraphs is ONE LONG LINE!> > What does "shorewall status" | grep eth0_mac" give you? > > ghostwheel /etc/shorewall # shorewall status | grep eth0_mac > 0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW > 0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW > Chain eth0_mac (2 references) > 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/hour burst 5 LOG flags 0 level 6 prefix `Shorewall:eth0_mac:REJECT:'' >No traffic has yet been passed to the MAC verification chain -- which means that no new inbound connections from eth0 have been attempted since you configured ''maclist''.> > which tend to show that rfc1918 is taken into account for ipsec tunnel... Or there is something I did not understand... >You are using the Native IPSEC implementation in Kernel 2.6 apparently. Shorewall 2.0.15 has no support for that implementation -- such support is the centerpiece of the recent 2.2.0 release. So if you are running 2.0.15 with native IPSEC then I don''t guarantee that ANYTHING will work. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep a écrit :> Would you PLEASE post in plain text and configure your mailer to fold long > lines at an appropriate length? Each of your paragraphs is ONE LONG LINE!Well, I post in plain text. And my paragraphs have one line for each line of the command output. It was intentional, but if you prefer to have the lines folded, I can do that. I thought having the raw output was easier for people to read...> > > What does "shorewall status" | grep eth0_mac" give you? > > > > ghostwheel /etc/shorewall # shorewall status | grep eth0_mac > > 0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW > > 0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW > > Chain eth0_mac (2 references) > > 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/hour burst 5 LOG flags 0 level 6 prefix `Shorewall:eth0_mac:REJECT:'' > > > > No traffic has yet been passed to the MAC verification chain -- which > means that no new inbound connections from eth0 have been attempted since > you configured ''maclist''.Well, there were plenty. This is the output I get after ping flooding 10.66.17.253 which is accessible via eth0.> You are using the Native IPSEC implementation in Kernel 2.6 apparently. > Shorewall 2.0.15 has no support for that implementation -- such support is > the centerpiece of the recent 2.2.0 release. So if you are running 2.0.15 > with native IPSEC then I don''t guarantee that ANYTHING will work.Ok. Thanks for the information, I''ll install the last shorewall version then... -- Benjamin
Benjamin Lerman wrote:> Tom Eastep a écrit : > > > >>>>What does "shorewall status" | grep eth0_mac" give you? >>> >>>ghostwheel /etc/shorewall # shorewall status | grep eth0_mac >>> 0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW >>> 0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW >>>Chain eth0_mac (2 references) >>> 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/hour burst 5 LOG flags 0 level 6 prefix `Shorewall:eth0_mac:REJECT:'' >>> >> >>No traffic has yet been passed to the MAC verification chain -- which >>means that no new inbound connections from eth0 have been attempted since >>you configured ''maclist''. > > > Well, there were plenty. This is the output I get after ping flooding > 10.66.17.253 which is accessible via eth0. >Output? What output? Are you sure that traffic from the client to 10.66.17.253 goes through the firewall? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> > Well, there were plenty. This is the output I get after ping flooding > > 10.66.17.253 which is accessible via eth0. > > > > Output? What output?The output of "shorewall status | grep eth0_mac"> Are you sure that traffic from the client to 10.66.17.253 goes through > the firewall?Well, the client is the firewall, so yes it goes though it.
I think I found where the problem is...
ghostwheel ~ $ sudo shorewall show eth0_in eth0_mac
Shorewall-2.0.15 Chains eth0_in eth0_mac at ghostwheel - Tue Feb 8 19:04:13 CET
2005
Counters reset Tue Feb 8 18:49:53 CET 2005
Chain eth0_in (1 references)
pkts bytes target prot opt in out source destination
9 2064 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID,NEW
3 1728 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:67:68
6 579 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 eth0_mac all -- * * 0.0.0.0/0 0.0.0.0/0
state NEW
20 1587 loc2fw all -- * * 0.0.0.0/0 0.0.0.0/0
Chain eth0_mac (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 10.66.17.1
10.66.17.255
0 0 RETURN all -- * * 10.66.17.0/24
255.255.255.255
0 0 RETURN all -- * * 10.66.17.0/24 224.0.0.0/4
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
limit: avg 1/hour burst 5 LOG flags 0 level 6 prefix
`Shorewall:eth0_mac:REJECT:''
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
We can see that some packets went through the loc2fw rules without
entering the eth0_mac rules. That explains quite well why mac filtering
is not working, but why those packets did not enter the eth0_mac rule ?
--
Benjamin Lerman
Benjamin Lerman wrote:> I think I found where the problem is... >> > We can see that some packets went through the loc2fw rules without > entering the eth0_mac rules. That explains quite well why mac filtering > is not working, but why those packets did not enter the eth0_mac rule ? >MAC filtration only occurs on NEW INCOMING CONNECTIONS! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> Benjamin Lerman wrote: > >> I think I found where the problem is... >> > > >> We can see that some packets went through the loc2fw rules without >>entering the eth0_mac rules. That explains quite well why mac filtering >>is not working, but why those packets did not enter the eth0_mac rule ? >> > > > MAC filtration only occurs on NEW INCOMING CONNECTIONS! >I just reread the MAC filtration documentation and see that the article is not clear on that point. I''ve reworded key parts of the article and hopefully have cleared up this confusion. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> > MAC filtration only occurs on NEW INCOMING CONNECTIONS! > > > > I just reread the MAC filtration documentation and see that the article > is not clear on that point. I''ve reworded key parts of the article and > hopefully have cleared up this confusion.Yes. Now I understand why it won''t work, but would it be easy to modify shorewall so that all connections are subject to maclist filtering ? -- Benjamin Lerman
Benjamin Lerman wrote:>>>MAC filtration only occurs on NEW INCOMING CONNECTIONS! >>> >> >>I just reread the MAC filtration documentation and see that the article >>is not clear on that point. I''ve reworded key parts of the article and >>hopefully have cleared up this confusion. > > > Yes. Now I understand why it won''t work, but would it be easy to modify > shorewall so that all connections are subject to maclist filtering ? >Netfilter ''mac'' match is only capable of matching on the source MAC address. Hence, only incoming packets may be matched. You can cause all incoming packets on ''maclist'' interfaces to be checked by removing "-m state --state NEW" from line 2079 (version 2.2.0). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> Netfilter ''mac'' match is only capable of matching on the source MAC > address. Hence, only incoming packets may be matched. You can cause all > incoming packets on ''maclist'' interfaces to be checked by removing "-m > state --state NEW" from line 2079 (version 2.2.0).Thank you very much, it works perfectly.
Andrea Galmacci - awd wrote:> Tom, I''ve downloaded the Shorewall version 2.2.0, LRP flavour, and I''ve > noticed that the file shorewall.conf is corrupted - the first line is > missing the first #, procuring an almost immediate error during the startup. >Thanks, Andrea. I''ve corrected the problem in CVS and I''ve place a corrected file in the errata/LRP sub-directory at the primary download site.> I don''t think to be original at all but let me thank you for your effort on > Shorewall. >You are most welcome. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Benjamin Lerman wrote:>>Netfilter ''mac'' match is only capable of matching on the source MAC >>address. Hence, only incoming packets may be matched. You can cause all >>incoming packets on ''maclist'' interfaces to be checked by removing "-m >>state --state NEW" from line 2079 (version 2.2.0). > > > Thank you very much, it works perfectly.The goal of Shorewall MAC filtration is to prevent unknown systems from attaching to a LAN segment then connecting to services at or through the firewall. The current implementation meets that goal at a fraction of the cost of the code that you are now running. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> The goal of Shorewall MAC filtration is to prevent unknown systems from > attaching to a LAN segment then connecting to services at or through the > firewall. The current implementation meets that goal at a fraction of > the cost of the code that you are now running.You have a point. I did not think about it enough...