Our Bogon data is used only to track > IP’s that are not yet registered for use on the Internet> .
[…]
Often we find that well-intentioned network administrators might have added our Bogon list data to (as an example) email servers, > thinking it was a list of “bad” IPs, but this is not the way the list is intended to be used> .
Because you can open this list on your own and clearly see that it contains public IPs. Those IPs aren’t issues yet to anyone but eventually will.
Bogons in a MT guide are IPs that are intended to use as private, loopback, multicast and so on. Those things are different.
Alright, suppose you are right (which may be the answer to question 1) but one still wants to use TC’s full bogon list.
What about the other questions?
The list isn’t actually “long”, it’s only 1787 entries at the moment I’ve opened it. How can it be measured? Load it into your router and test RAM and CPU usage for blocking this (try raw prerouting for that). Wouldn’t take noticeable performance on a good device.
In my opinion, appropriate way would be download it manually and revise (if you are enterprise), since list authors may change their minds and start adding bad stuff they don’t want to see in the internet for their own purpose. Usual approach is /tool fetch then add to address-list script in a scheduler.
Another thought is to not use such stuff at all and take some other security measures, but since you don’t ask about it, you can go with above.
But the CPU usage will be affected only during an actual attack. The question is how to simulate one? (from a Linux system)
In my opinion, appropriate way would be download it manually and revise (if you are enterprise), since list authors may change their minds and start adding bad stuff they don’t want to see in the internet for their own purpose.
My thoughts too.
Another thought is to not use such stuff at all and take some other security measures, but since you don’t ask about it, you can go with above.
Thank you for the answers. I am still interested to learn about those other security measures. Could you elaborate?
It depends on what you have and what you’re protecting. For me it now seems that you’re solving problems you aren’t facing in reality.
If you are facing DoS attack on your system, try to collaborate with ISP as it’s mostly their job to solve this. If you’re ISP yourself, I personally dunno what to advice you, but doubt this “bogon” list will help you in any way, because such attack can happen from real IPs.
If you want to just have your system safe and not facing excessive traffic:
-make sure you aren’t exposing any management stuff to either WAN or your users
-disable unnecessary services like api, http, btest, maybe MAC stuff or at least make sure your device is not discoverable outside of management interface
-make sure to avoid default admin user, make new one with full rights and strong password, and disable default one
-try to avoid port forwarding for remote access to internal services, use VPN whenever you can for that purpose (unless you expose your internal service for global use)
-you can use port-scan protection rules (there are also example in wiki, about 6 or 7 rules that catch port scanners and drop them in prerouting)
-you can setup honeypots for fake services like 22 for external SSH to catch undesired attempts of breaking your device
-you can setup port-knocking - a sequence of packets of predefined size that you should send to device to be whitelisted and use other services
There maybe some more, but those are general stuff that can help you protecting your device.
The last rule where all tcp flags are negated (iirc it was called nmap null scan) catches kinda a lot of IPs. Not sure if udp psd rule even works, at least I don’t notice it catches something. I think those stuff somehow negates traffic against you anyway, since bots see you drop their stuff and just start to ignore you, as port-scanners and honeypot may pump quite fast but them it’s stable in terms of numbers dropped. Numbers are still just a bunch of MiB dropped on a CHR.
There was another separate article using this approach with list, however the drop rule was in input for some reason, I just moved it to prerouting. I see there’s a similar chain, but the approach is different. Instead of parsing all bad traffic all time, you remember source of undesired traffic once and then drop it for a longer period.
TBH I dunno if that’s more optimal or less, since source list may grow fast up to 3k+ entries and the drop rule has to use some algorithm to look through it. But I personally never had issues on either CHR VPS or routers with public IPs, so I don’t care bothering with such micro-optimisations, and bots stop touching you if you say them “f*k off” once. And no one cares DDoS’ing home users or small companies, they would rather try out some mid-size enterprise which is realistic to break but can be valuable to squeeze.
And, as some already said on another topic to you, it’s not only about firewall, but also about hardware that can process all that bad traffic and don’t hang. Even blocking bad addresses on upstream switch ACL may not help.
