Aegis The future of Aegis

[HELLO_wORLD]

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.]

" 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]

" 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.

 

[blueliner]

Hello,

Hadn't seen this topic before and I don't really have an opinion on the prerouting table. My comment is probably moot with 1.7 out now.....
but as user info for you, I normally have logging off and run it only for troubleshooting, etc.

BL

 

[HELLO_wORLD]

Hello,

Hadn't seen this topic before and I don't really have an opinion on the prerouting table. My comment is probably moot with 1.7 out now.....
but as user info for you, I normally have logging off and run it only for troubleshooting, etc.

BL

One caveat using PREROUTING would also mean losing the information on the destination in the LAN (if any specific), since we would block before the routing stage. That would mean that the logging would just be able to show from or to WAN/VPN but not to or from LAN...
The routing stage also gets rid of a lot of garbage not aimed to router or LAN (multicasts, broadcasts from ISP side) that PREROUTING would intercept for nothing.

Now, the real question about these packets is which is more performant: routing triage process or iptables rule blocking?

I also use personally a rule to filter this garbage, but I am not sure it could be generalized easily as it depends on the type of connection, etc...
In my case, on the infrastructure side (ISP side), I receive my DHCP lease and all internet packets from the same device/relay. With ebtables, I only allow packets from/to this device MAC on my WAN, so I block all the garbage not for me. It works wonders and blocks at the earliest, even before IP level.
This type of blocking does not replace ip list blocking, but would be a cool addition to aegis. However, as I said earlier, this is a very powerful type of blocking and could block completely internet if not done correctly, and it is very dependent on the type of connection/setup.

Also, I am lacking time to make aegis more complex. It is a hobby, and it can be time consuming. So far, I found that less than 10 people are using it (at least since version 1.7).

1.7 reached maturity I think, and aegis is now a very simple tool, yet flexible and efficient. Beside fixing bugs and minor improvements, I am not sure I want to add too many more features at this point.

I would like to add IPv6 support at some point, because all the aegis blocking is only on IPv4, but that demands time, and I would have to create a custom version of iprange to add IPv6 support since it does not exists yet.

I probably will slow down for a while, just making sure 1.7 is bug free.
At some point, not sure when, I will probably work on 1.8 to allow multiple source lists (black and white, and per interface as well).