Aegis The future of Aegis

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

HELLO_wORLD

Senior Member
Hello all,

I have several ideas for Aegis, but I don’t know when and if I will implement them.
One is IPv6 support, but there are not many block lists yet, so not a priority.

I also experimented with filtering incoming packets from the PREROUTING mangle table, so very early after they hit the router.
The advantage is that it catches and drop packets from blocked IPs before the router tries to route them, and we gain theoretically in safety (in the very unlikely case where the router would be infected with something that would listen to packets before the routing process*) and little on CPU load (mostly softirq), but with logging on, the softirq load is higher as we can catch more packets (as the routing process is dropping some).
I don’t know if you use logging all the time, but for the ones who are looking for performance, I don’t recommend to leave it on. Logs IMHO are useful punctually, to identify what is blocked often and troubleshoot, but not left on permanently.
If you do agree on that, I might change the rules to block incoming packets from mangle PREROUTING, but maybe not.

For outgoing packets (LAN or router trying to send to blocked addresses), I will keep the in the filter table, as it allows to REJECT (and inform local devices that we refuse the connection to blocked IP). I could make simpler and block in mangle br0 PREROUTING (but would need to bypass LAN network range to not block LAN to LAN traffic) or on mangle POSTROUTING, just before it leaves the router, but I then could not REJECT, only DROP.
I think it REJECTING is a better design, as using the filter table to filter outgoing packets.

* more on theoretical improved safety if blocking at PREROUTING: a malware could still listen to blocked incoming packets like tcpdump does.
Anyway, for a malware to be in the router, it would have to be in NG and/or @Voxel code, and I think we are very safe on this side, or it would have to be introduced by anything installed by the user like @kamoj addon or Aegis. We can trust @kamoj
About Aegis: it is 100% open source and shell script based, so no secrets.
So using PREROUTING for safety is not a real argument. Only a little performance gain can justify it, but is less than 0.5% CPU gain worth it?
 

KW.

Regular Contributor
" more on theoretical improved safety if blocking at PREROUTING: a malware could still listen to blocked incoming packets like tcpdump does." Very interesting information that I did not know about that only the firmware in router itself could be a malware. That makes me really safe as I have no doubt on the firmwares on my router.

But just for curiosity Im off topic a bit. All the shirt you place on a hdd or usb to the router like things for streaming and so on. Is that not a potential source for malware in the router. In that case maybewhat you call prerouting could help?
 

HELLO_wORLD

Senior Member
" more on theoretical improved safety if blocking at PREROUTING: a malware could still listen to blocked incoming packets like tcpdump does." Very interesting information that I did not know about that only the firmware in router itself could be a malware. That makes me really safe as I have no doubt on the firmwares on my router.

But just for curiosity Im off topic a bit. All the shirt you place on a hdd or usb to the router like things for streaming and so on. Is that not a potential source for malware in the router. In that case maybewhat you call prerouting could help?
Only executables binaries (by the router) and scripts can be dangerous, so it is very important to be cautious of what is installed or executed on it (that’s why NG removed telnet access in latest firmware).
Any data on HDD, even containing viruses for Windows or another OS will be harmless to the router.
Telnet or better ssh access should be secured, because a malware out of the router on a host that has telnet or ssh access could potentially do serious damage to the router. I don’t know if such malwares exist, but better safe than sorry, so:
1) always be sure of what is installed and run on the router,
2) disables telnet when not needed, and use ssh instead,
3) use a trusted ssh client, avoid by all means ssh (and more so telnet) access from WAN.

To come back to the topic, PREROUTING blocking would not make a valuable security improvement ; even if the routing process was corrupted, the INPUT and FORWARD filter tables are blocking.
The only point would be performance: blocking at the earliest entry point in the tables process and sparing the router to have to make routing decisions on packets coming from blocked IPs. But again, so early on, the router sees packets not aimed at itself that are not routed, but would be blocked by aegis, and if logging is on, the load can be significantly higher that filtering after routing.
 
  • Like
Reactions: KW.
Similar threads

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top