On 10/10/2018 01:54 AM, Timo Sigurdsson wrote: > Hi Tom, > > Tom Eastep schrieb am 09.10.2018 23:42: >> On 10/09/2018 01:34 PM, Timo Sigurdsson wrote: >>> Hi, >>> >>> I use shorewall 5.0.15.6 on Debian Stretch in a dual stack setup. On a >>> reugular basis, I get a bunch of the following messages in my log files (my >>> shorewall log prefix is just FW): >>> kernel: [102654.492757] FW:FORWARD:REJECT:IN=ppp0 OUT=ppp0 MAC= >>> SRC=2001:4ca0:0108:0042:0000:0080:0006:0009 >>> DST=2001:14c9:1131:1320:8b80:2765:3c6a:2f19 LEN=80 TC=0 HOPLIMIT=244 >>> FLOWLBL=0 >>> PROTO=TCP SPT=50625 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 > <SNIP> >>> The relevant lines in shorewall6/interfaces and shorewall6/policy look like >>> this: >>> shorewall6/interfaces: >>> net ppp0 >>> dhcp,accept_ra=2,tcpflags,nosmurfs,rpfilter,sourceroute=0 >>> >>> shorewall6/policy: >>> $FW net ACCEPT >>> [...] >>> net all DROP >>> # THE FOLLOWING POLICY MUST BE LAST >>> all all REJECT info >>> >>> So basically, these packets hit the all-all reject policy. What I would like >>> to do however, is to drop these packets without logging (and I do not want >>> to >>> change my default policy for that). How can I match these packets? I have >>> tried several approaches that all didn't work: >>> >>> 1) I added a policy that said: >>> net net DROP >>> Didn't work and also should be redundant due to the net-all drop rule. >>> > <SNIP> >>> I'd aprreciate if someone could point me in the right direction on how to >>> get >>> rid of these log messages. Thank you! >>> >> >> a) Set the 'routeback' option on ppp0 in /etc/shorewall/interfaces. >> b) Add your proposed net->net DROP policy BEFORE your current net->all >> policy. > > thanks for the tip. It sounds a bit counter-intuitive, but I'll give it > a try. I have two follow-up questions, though: > > 1) Wouldn't my net-all drop policy already imply net-net drop?
Yes -- but your net->all policy specifies logging which you don't want. > > 2) If I add the routeback option to my ppp0 interface, are there any > drawbacks to be aware of or security risks attached? No. > > The man page suggests adding the routefilter option when routeback is > enabled. As routefilter is IPv4-only, am I correct to assume the > rpfilter option that I have set serves this purpose just as well? Yes. > In addition, the man page suggests to enable route filtering on *all* > interfaces which I currently don't have. So, should I set rpfilter > on my other interfaces when I set routeback on ppp0? I don't have have > bridge interfaces or so, so I don't expect issues on my internal > network with rpfilter. Yes, rpfilter is advisable on all interfaces. > > And one more question that is not strictly related to shorewall, but > it occured to me this morning: Would it be possible to filter away > these packets with a blackhole route via 'ip route'? Or do > iptables/netfilter rules come into play before the blackhole route > would be applied? > Blackhole routes are applied before Shorewall filter rules. They would be a solution if: a) You can identify the full set of destination networks involved; and b) You have no reason to access these networks yourself. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
