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:
- 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 :)