Hi Tom,

Tom Eastep schrieb am 10.10.2018 18:08:

> 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.

thank you! Everything works as expected now.

The packets are dropped without logging. Actually, my net->all drop
policy was sufficient here after adding the routeback option to the
interfaces file. I don't remember where I where I deviated from the
defaults, but unless I explicitly specifiy a log level in my policy
file, no logging is performed.

>> 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.

Ah, right. Identifying the involved destinations would be possible but
I can't be sure about the latter. While it seems unlikely, who knows
whether they start hosting other relevant services on their server at
some point or reassign the IPv6 preifx to some other service.

So the solution with the routeback option seems to be the best.

Thanks again!

Kind regards,

Timo


_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to