20 Sep
2018
20 Sep
'18
8:45 a.m.
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
20 Sep
20 Sep
1:01 p.m.
New subject: beware of IPIP scanner...
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2052
days inactive
2052
days old
1 comments
2 participants
participants (2)
-
Gustavo Ponza -
Rob Janssen