/ip firewall raw
add action=drop chain=prerouting comment=“defconf: drop non global from WAN” src-address-list=not_global_ipv4 in-interface-list=WAN
add action=drop chain=prerouting comment=“not LAN” src-address-list=!lan_subnets in-interface-list=LAN
I imagine your not_global_ipv4 is the BOGON list correct? So stating drop any incoming private IPs etc. trying to reach the router!
Whereas the second rule says dont allow any LANIP outbound that is not a bonafide subnet on the local router.
No you nailed it, There is overlap. It would appear that your second rule and the blackhole are similar enough. Your rule is more definitive in that it will drop private subnets that one normally excludes on bogons because the local subnets are included in the wide swath approach of bogons.
Other than that what do you see as pluses or minuses of your rule 2 vs bogon and blackhole?
I dont mean to be silly by why is your first rule not…as precise as the second rule…??
add action=drop chain=prerouting comment=“defconf: drop private IPs from WAN” src-address-list=!lan_subnets in-interface-list=WAN
There is a substantial difference between blocking in RAW packets leaving the LAN that are not from LAN subnets existing on the router.
and RBH which is predicated on removing any traffic from the LAN to private IP addresses ( or non-valid public IPs ).
So My takeaway is that all three are distinct and useful!
First raw rule stops any incoming (private IPs or not legitimate Public IPs) on the WAN.
Second raw rule stops any outgoing traffic FROM any IPs not on the router → based on SOURCE IP outbound
RBH rule stops any outgoing traffic to private IPs or not legitimate Public IPs) → based on DESTINATION IP outbound.
One clarification needed:
add action=drop chain=prerouting comment=“not LAN” src-address-list=!lan_subnets in-interface-list=LAN
On the second raw rule above, why do you have source-address-list=!lan_subnets in-interface-list=LAN and not
( just trying to eliminate making a potentially long address list of subnets )
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
After thinking about it, I think I see why you have the list method…
Due to the fact that remote users coming in VPN will be coming from non-local interfaces and their return traffic needs not to be blocked.
Using !local will catch them and block them (bad) whereas in your list approach they can be included in the list and thus excluded from the blocking (desired).
Also can you confirm what you mean by this statement: “src-address-list=not_global_ipv4” , more specifically is that fancy way of saying BOGONs or is it a different list ???
That address list is just RFC6890. IPv4 is already exhausted eons ago, RFC6890 is the ONLY bogon in IPv4.
IPv6 is a complex and different story, that’s not covered in the OP’s blog post. You’ll need to search for other sources regarding IPv6.
iptables src and dst address types have special meanings that isn’t suitable for public consumption unless they are expertly or advanced well versed in Linux networking, that’s basically 1% of the human population. I personally wouldn’t use those parameters in production. At home, okay sure if it’s my home.
The bogons problem is overstated,
you simply have to block what comes from outside that has the same IPs you have inside…
For example, if you don’t use 10.x.x.x/8, the packet is dropped regardless (because the router doesn’t know where to deliver it) whether it gets stuck in the firewall or not…
Often some ISP already block on transit spoofed or leaked packets, so after some months you never receive packet with that address…
Indeed, usually the attacks always come from real, really assigned IPs, who don’t give a damn what you have as “bogons” or not…
So Darknates first rule should be the same as his second rule (in terms of list of local subnets)
RAW RULE 1 BLOCK ANYTHING FROM WAN WITH SAME SUBNETS ON ROUTER (instead of bogon list)
RAW RULE 2 BLOCK ANYTHING NOT FROM LOCAL SUBNETS COMING FROM LAN
Please keep it civil, disagreements/discussions regarding approaches or interpretations of networking concepts are fine, but there should be no personal attacks.
I am stiill waiting for a response on Blackhole.
Its clearly an accessible option on the routes menu.
Rextended succintly pointed out its not worth it in most cases, perhaps he meant the home user.
I was hoping darknate could explain why its used in business or if not really applicable there either.
Understanding why its used would help me decide whether or not to use the functionality.
@anav
Simply answering, and this goes for any use,
the blackhole is better because the packet just disappears without a trace OR consequences of it being gone.
Routing decision happen before firewall filter (not RAW) drop the packet,
and since, whether the firewall filter (not RAW) blocks it or not, the packet still goes through routing, it is discarded first.
Otherwise letting the packet “expire” causes (unless it can be disabled) the router to notify the host from which the packet came,
which could also be fake, the notification that the packet has “expired”, generating in the event of a targeted attack responses that contribute to DDoS.
What does that have to do with “bogons”?
The incoming packet from WAN that has a private IP of a subnet as its destination IP is obviously fraudulent,
and I wonder how it gets there, because how can the ISP route packets with private IP destinations to you?
It would mean that the ISP has in their routing tables that, for example, 192.168.88.0/24 is on your LAN…
Instead, if the packet is destined to IP of your WAN, but has as source one IP among the private ones (or public, but internal),
it is obvious that it is false (and a true ISP should have already filtered them before…)
So since blackholes only affect the destination, and not the source, of a packet,
the blackhole only prevents YOUR devices from sending attacks to the internet (when used IPs outside your LAN),
not to defend you against them.
If your ISP already do not do that, for drop incoming from WAN packet from bogon IPs,
you can drop it on firewall RAW, on Routnig Rules or on firewall filters.
Two simple rules:
1a) Do not accept packets from the WAN that have as source the IPs that are used internally,
even the public ones if the ISP has assigned them to you more than one.
1b) If the ISP doesn’t do its job, block all packets from the WAN that target the private IPs you use on your network.
Do not allow your router to send packets across the WAN that have
as their source {any private IP} or {public IP addresses that you DO NOT have in your network}.
Obviously, if the ISP only gives private IPs and does everything with a large NAT, this must be taken into account in order not to self-block the connection…
So there is alignment on
RAW RULE 1 BLOCK ANYTHING FROM WAN WITH SAME SUBNETS ON ROUTER
RAW RULE 2 BLOCK ANYhTING FROM WAN WITH DESTINATION OF PRIVATE SUBNETS
RAW RULE 2 BLOCK ANYTHING NOT FROM LOCAL SUBNETS COMING FROM LAN. No IP Routes with black hole make sense in home setting or SOHO setting.
Note: Caution Last rule does not interfere with remote subnets coming in on wireguard tunnel (with wireguard often being a member of the LAN List, and thus after being deposited on the LAN (exit the tunnel), the raw rule might disappear any attempt to reach local lan resources or even the WAN!
Not only local subnets, consider also your WAN IP (how is possible to receive one packet with your own IP?..) and the other public IPs you have (if you have any).
Also from internal subnets can’t come your WAN IP…
I use on default “unreachable” on CPEs, if some interface have some IPs on that range, count more than the unreachable…
(for prevent spoofed traffic or errors go outside), the other controls of incoming packet source are on edge router, and control of packet from CPE are on separate firewall, out of normal client scope.
With this the internal LAN device receive ICMP “host unreachable” when try to contact those networks.
As wroted before, if you have 192.168.88.1/24 on one interface, automatically a route with distance=0 is added for 192.168.88.0/24 and all 192.168.88.0/24 block work correctly.
Never put unreachable on WAN direction to not amplify or contribute to DDoS attacks…
When I use blackhole:
On incoming connection to “public.example.ip.254” if for some reason that device is offline, I drop instantly the traffic with blackhole, but never send back unreachable for the same reason I write before.
For example, if your ISP assign to your WAN 8 IPs, but you use only 2, is better put on blackole all is directed to that 6 IPs with no reply.
Your router must be a very powerful device to check all of these lists of rules or routes... this is the shortest path to choke your hardware. Isn't there any better way to do it?
to be fair, there would have been none if the causing post had been removed earlier, but concur you cannot be everywhere at once… I did resist though in both delaying response and the flavour of response, so am trying
