It is also a good idea to block forwarding from/to AMPR interfaces other than your own internal 44 network.
That is right! At first you filter IPIP packets in the input chain to allow only packets from the list of gateways (public addresses). In Linux this can be done with ipset and on the MikroTik using an "address list" (which is just their UI around ipset), or you can dynamically maintain a list of rules. (which allows to maintain counters per rule, also possible with recent kernels and ipset)
Then, there should be a forward chain rule on the tunnel interface that only accepts incoming packets to the net-44 subnets you have published in the portal. You don't want to accept traffic destined for other addresses and then forward that. It would also be good to filter traffic forwarded TO the tunnel interface to only accept valid source addresses (your own networks), mostly to cover one's own mistakes in handling NAT.
Both of those rulesets would have blocked the described scan.
Probably it would be a good idea to include some working firewall example on the Wiki (for the different environments desrcibed) so everyone can have a secure firewall without in-depth knowledge about this matter.
Unfortunately I have little knowledge about the particular methods used to load iptables on the different Linux distributions: the first thing I always do when installing a machine that does advanced routing is to remove their firewall maintenance packages and replace them by a init.d script that just uses iptables statements to build it at boot (or reload) time. That allows me to use variables, comments, shell constructs, etc which is much more maintainable than those "iptables-save" or automatic firewall maintenance solutions (when you install some package, corresponding ports are opened).
Rob
Ah ah ah, it's very complex to common mortals as me :)
Perhaps it is mature the time to adopt, after many years, the *SIMPLE* implementation created by Maiko VE4KLM for JNOS2, applying it to our systems:
------------ 3) Configuration -------------
When adding a 44 route, typically one uses something like this :
route add 44.0/8 encap a.b.c.d
The above command implies that IP-in-IP encapsulation should be used. If you want to force the use of IP-in-UDP encapsulation instead, then simply add the word 'udp' to the end of the route command, for instance :
route add 44.0/8 encap a.b.c.d udp
Our implementation of IP-in-UDP uses UDP port 94 (for both the source and destination ports). Just make sure your firewall or NAT router is configured properly to pass this port. It also makes sense to restrict access to that port to only those IPUDP hosts you link with. If your firewall or NAT router lets you do that, great ! If not, then you could use IPTABLES on linux to do it instead.
That's all there is to it.
Copyright (c) 2008 by Maiko Langelaar / VE4KLM -----------
73 and ciao, gus i0ojj/ir0aab Credo quia absurdum est (Tertullianus)
On 9/20/18 9:45 AM, Rob Janssen wrote:
It is also a good idea to block forwarding from/to AMPR interfaces other than your own internal 44 network.
That is right! At first you filter IPIP packets in the input chain to allow only packets from the list of gateways (public addresses). In Linux this can be done with ipset and on the MikroTik using an "address list" (which is just their UI around ipset), or you can dynamically maintain a list of rules. (which allows to maintain counters per rule, also possible with recent kernels and ipset)
Then, there should be a forward chain rule on the tunnel interface that only accepts incoming packets to the net-44 subnets you have published in the portal. You don't want to accept traffic destined for other addresses and then forward that. It would also be good to filter traffic forwarded TO the tunnel interface to only accept valid source addresses (your own networks), mostly to cover one's own mistakes in handling NAT.
Both of those rulesets would have blocked the described scan.
Probably it would be a good idea to include some working firewall example on the Wiki (for the different environments desrcibed) so everyone can have a secure firewall without in-depth knowledge about this matter.
Unfortunately I have little knowledge about the particular methods used to load iptables on the different Linux distributions: the first thing I always do when installing a machine that does advanced routing is to remove their firewall maintenance packages and replace them by a init.d script that just uses iptables statements to build it at boot (or reload) time. That allows me to use variables, comments, shell constructs, etc which is much more maintainable than those "iptables-save" or automatic firewall maintenance solutions (when you install some package, corresponding ports are opened).
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Gustavo Ponza -
Rob Janssen