On 9/20/18 9:17 PM, Rob Janssen wrote:
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
But does that automatically add the two levels of firewalling that we are
discussing here? If not, it does not seem very relevant. It is quite easy
to make a configuration that basically works (especially when using RIP
which
makes route statements like the above unnecessary), but the point is
that it
is not secure against abuse by malicious people. That is why additional
work is needed.
Rob
About this last statement, it is true that any project
must be continuously improved to challenge something.
Now beginning with the subject "beware of IPIP scanner..."
I understand that (until a contrary proof) the use of
IP-in-UDP is more 'resilient' than IO-in-IP per se,
against the malicious, in general.
Everyone of us don't forget, on our projects, only
the little rich parts of the globe, but consider the
whole situations where many internet service providers
block outgoing traffic originating from within their
network IF the IP address is not from within their
own allocation of numbers - meaning that IP packets
having a source address of 44 will never make it out.
And then consider the new (poor) generation of home user,
even IPIP will not work, since most home users are now
behind a cheep consumer firewall or NAT router of some
type.
About the RIP: if it is exposed to attacks, and if
convenient, we can coming back to source the encap.txt
or process it to source into the linux machine, i.e
on the following format:
44.x.x.x/y via x.x.x.x. dev tunl0 proto 44 onlink window 840
and so on. All made by hourly or even on minutes
by using cronjob or other kinda scrips :)
About the security there are several technical
approach, what is the best?
Perhaps one of them is that using the 'black lists'
or by using the 'tcp deny' methods, etc, together
with the basic firewalling... but :)
--
73 and ciao, gustavo i0ojj/ir0aab
Credo quia absurdum est (Tertullianus)