What's new

Aegis aegis: a firewall blocklist

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I think it was @Tom Brough that has the issue, not me.

(but I indeed uname -p for my R7800 returns IPQ8065)
You are right, I meant @Tom Brough
Having a R7800, it should return IPQ8065 for him as well (my install script was testing that to figure out if the device is a R7800), but apparently it failed for him.

Anyway, the new method should work for him as well, and is simpler.
With former method, uname -p returns ‘unknown’ on R9000 and I had to make more tests based on device name (that might not even be R9000 if user changed it).
The cat /module_name is way simpler.
 
Good work! :)
You are doing amazing stuff. :cool:
Here are some ways I used through the years ... :eek:
Code:
ROUTER="$(cat /module_name)"
ROUTER="$(cat /hardware_version)"
ROUTER="$(artmtd -r board_model_id | cut -d: -f2)"
ROUTER="$(system get model_name)"
ROUTER="$([ -n "$(nvram get cgi_ctl_mod)" ] && echo "R9000" || echo "R7800")"
Updated install script.
Now identifying the model number differently.

That should solve the problem encountered by @R. Gerrits

I’m using this
Code:
cat /module_name
As it should be on every NG routers and is not dependent on router name or uname -p (that is not always reliable to identify the model).

@R. Gerrits : I’m still curious to know what ‘
/bin/uname -p’ returns for you... should be IPQ8065
 
Last edited:
Good work! :)
You are doing amazing stuff. :cool:
Here are some ways I used through the years ... :eek:
Code:
ROUTER="$(cat /module_name)"
ROUTER="$(cat /hardware_version)"
ROUTER="$(artmtd -r board_model_id | cut -d: -f2)"
ROUTER="$(uname -n)"
ROUTER="$([ -n "$(nvram get cgi_ctl_mod)" ] && echo "R9000" || echo "R7800")"

oh, I can so relate to that... Great tricks.
Which one are you using now and is most reliable according to your experience?

uname -n is no good if user changed router name.

module_name or hardware_version should be always working as long as NG does not change that (and even if, Voxel could still leave those on his firmwares). Any preference between module_name and hardware_version? Any situation where they are different?

I believe artmtd method might be the strongest, but if hardware_version or module_name are reliable, reading one of them is simpler and faster.
 
  • Like
Reactions: KW.
I've not refactored the code for ages.:oops:, but:
Currently after a search in the code:
  1. module_name (shell scripts)
  2. artmtd (for producing the .ipk install files, and other production)
  3. cgi_ctl_mod (html/java scripts)
uname -p is good for R7500/XR450/XR500/R7800 and XR700/R8900/R9000 if you are interested in those.

For my Entware install script I included usage for R7500 (Oops! awk instead of cut...:cool:) :
Code:
..
ROUTER=$(artmtd -r board_model_id | awk -F":" '{print $2}')
[ "$ROUTER" = "R7500" ] && SIZE=524288
[ "$ROUTER" = "R7800" ] && SIZE=1048576
[ "$ROUTER" = "R8900" ] && SIZE=2097152
[ "$ROUTER" = "R9000" ] && SIZE=2097152
..


The good thing with "nvram get cgi_ctl_mod" is that it is valid also for R8900. (Tip from @Voxel the great)
Even Netgear uses different ones... E.g. this during boot which gives us yet another option...
Code:
/sbin/artmtd -r board_model_id | cut -f 2 -d ":" > /tmp/board_model_id

I vote for "module_name"! :D

When @Voxel is back again, I sure he can advice what to use!
 
feature request / suggestion:
make aegis status also show date of last update

It is already there, in verbose mode ;)
aegis status -v

The line to look is
Blocklist generation time
 
Thanks
All installed ok and running ver 1.02.says log on but when I ask to see log nothing there.
 
Thanks
All installed ok and running ver 1.02.says log on but when I ask to see log nothing there.

When you do
Code:
aegis status -v

Do you see that:
Code:
- Logging is active:
     iptables -A aegis_DROP -j LOG --log-prefix "[aegis] "

If so, logging is working. If aegis log does not show anything, it is because there was no event to log.
You can try to ping a blocked ip like:
Code:
ping 1.19.0.0
Then in the log, you should see something like:
Code:
[aegis] IN= OUT=brwan SRC=ROUTER-WAN-IP DST=1.19.0.0 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=25536 DF PROTO=ICMP TYPE=8 CODE=0 ID=35884 SEQ=0
 
It is already there, in verbose mode ;)
aegis status -v
Thnx!

This does caused me to notice another bug (or missing feature):

You only add the iptables rules to brwan -> people who have OpenVPN client or WireGuard active, are currently not protected.

So you should check during iptables generation, whether either OpenVPN client or WireGuard is active, and then also add the rules to those interfaces.
(you could look in /usr/sbin/net-wall to see how to detect that.)

(perhaps @jrbmw is also using OpenVPN client or WireGuard ??)
 
  • Like
Reactions: KW.
When you do
Code:
aegis status -v

Do you see that:
Code:
- Logging is active:
     iptables -A aegis_DROP -j LOG --log-prefix "[aegis] "

If so, logging is working. If aegis log does not show anything, it is because there was no event to log.
You can try to ping a blocked ip like:
Code:
ping 1.19.0.0
Then in the log, you should see something like:
Code:
[aegis] IN= OUT=brwan SRC=ROUTER-WAN-IP DST=1.19.0.0 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=25536 DF PROTO=ICMP TYPE=8 CODE=0 ID=35884 SEQ=0

This is what I get


Status:
- 'aegis' version: 1.0.2
- 'iprange' is installed: iprange 1.0.4
- Something is not right! Use 'aegis -v status' for more details
- Logging is on.
Detailed status:
- 'aegis' is in $PATH.
- 'firewall-start.sh' exists with correct settings.
- Actual router time: 2020-05-17 11:03:20
- Blocklist generation time: 2020-05-17 03:15:04
- Router firewall was last started 2020-05-17 07:54:23:
egis 1.0.2 - Verbose mode
Status:
- 'aegis' version: 1.0.2
- 'iprange' is installed: iprange 1.0.4
- Something is not right! Use 'aegis -v status' for more details
- Logging is on.

Detailed status:
- 'aegis' is in $PATH.
- 'firewall-start.sh' exists with correct settings.
- Actual router time: 2020-05-17 11:11:10
- Blocklist generation time: 2020-05-17 03:15:04
- Router firewall was last started 2020-05-17 07:54:23:
ipset blocklist was already loaded and was kept.
logging rules were added to iptables.
blocklist rules were added to iptables.
- iptables rules are not set properly:
iptables -N aegis_DROP
iptables -A INPUT -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A INPUT -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A INPUT -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A INPUT -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A OUTPUT -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A OUTPUT -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A OUTPUT -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A OUTPUT -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A aegis_DROP -j DROP
iptables -A aegis_DROP -j DROP
iptables -A aegis_DROP -j DROP
iptables -A aegis_DROP -j DROP
- Logging is active:
iptables -A aegis_DROP -j LOG --log-prefix "[aegis] "
-A aegis_DROP -j LOG --log-prefix "[aegis] "
-A aegis_DROP -j LOG --log-prefix "[aegis] "
- ipset filter (blocklist) is set:
Name: aegis_BL
Type: hash:net
Revision: 6
Header: family inet hashsize 32768 maxelem 62731
Size in memory: 1609080
References: 17
- ipset bypass (whitelist) is not set.
root@R7800:/$
root@R7800:/$
 
Ok, two things:
1) the logging is in place for you, now, as @R. Gerrits pointed out (I will get to that), are you using Open VPN or Wireguard?

2) for some reason, you have multiple duplicate aegis rules in your iptables. This is not bad (meaning it does not prevent your router to work), but it is certainly not clean and it should not happen.
aegis is supposed to prevent this, and I don’t know how this happened to your setup. I will have to implement a stronger duplicates check on that as I don’t want this to happen.
For now, you should do
Code:
aegis restart
and status should be ok. If not, please report and use
Code:
aegis clean; aegis restart
Next release will definitely have stronger check of duplicates during creation of rules to avoid that.

This is what I get


Status:
- 'aegis' version: 1.0.2
- 'iprange' is installed: iprange 1.0.4
- Something is not right! Use 'aegis -v status' for more details
- Logging is on.
Detailed status:
- 'aegis' is in $PATH.
- 'firewall-start.sh' exists with correct settings.
- Actual router time: 2020-05-17 11:03:20
- Blocklist generation time: 2020-05-17 03:15:04
- Router firewall was last started 2020-05-17 07:54:23:
egis 1.0.2 - Verbose mode
Status:
- 'aegis' version: 1.0.2
- 'iprange' is installed: iprange 1.0.4
- Something is not right! Use 'aegis -v status' for more details
- Logging is on.

Detailed status:
- 'aegis' is in $PATH.
- 'firewall-start.sh' exists with correct settings.
- Actual router time: 2020-05-17 11:11:10
- Blocklist generation time: 2020-05-17 03:15:04
- Router firewall was last started 2020-05-17 07:54:23:
ipset blocklist was already loaded and was kept.
logging rules were added to iptables.
blocklist rules were added to iptables.
- iptables rules are not set properly:
iptables -N aegis_DROP
iptables -A INPUT -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A INPUT -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A INPUT -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A INPUT -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A FORWARD -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A FORWARD -i brwan -m set --match-set aegis_BL src -j aegis_DROP
iptables -A OUTPUT -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A OUTPUT -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A OUTPUT -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A OUTPUT -o brwan -m set --match-set aegis_BL dst -j aegis_DROP
iptables -A aegis_DROP -j DROP
iptables -A aegis_DROP -j DROP
iptables -A aegis_DROP -j DROP
iptables -A aegis_DROP -j DROP
- Logging is active:
iptables -A aegis_DROP -j LOG --log-prefix "[aegis] "
-A aegis_DROP -j LOG --log-prefix "[aegis] "
-A aegis_DROP -j LOG --log-prefix "[aegis] "
- ipset filter (blocklist) is set:
Name: aegis_BL
Type: hash:net
Revision: 6
Header: family inet hashsize 32768 maxelem 62731
Size in memory: 1609080
References: 17
- ipset bypass (whitelist) is not set.
root@R7800:/$
root@R7800:/$

Now, to answer @R. Gerrits : I did not design aegis to work after a VPN or Wireguard but rather the traffic coming to and from the router to the internet gateway.
The principle of a VPN is to escape this and tunnel a connection not visible by middle men.
That being said, it is probably not hard to do and studying iptables chains and find some that could be common (maybe loc2net and net2loc or fw2net, etc...),. I can look into that (I am not using VPN or WG, so if I do that, I will need some beta testing from users using it).
Also, bear in mind that aegis would then filter traffic going through VPN or WG initiated from the router, but would not filter any traffic going through a VPN or WG initiated behind the router (if a computer in the local network is using a VPN, it won’t be filtered as it is hidden in the VPN tunnel, and that is the purpose...).
So using a VPN is good for anonymity, but is also an open door. I would suggest to always use a trusted VPN and if you want to filter, choose one that allow to do so from their servers.
 
Ok, two things:
1) the logging is in place for you, now, as @R. Gerrits pointed out (I will get to that), are you using Open VPN or Wireguard?

2) for some reason, you have multiple duplicate aegis rules in your iptables. This is not bad (meaning it does not prevent your router to work), but it is certainly not clean and it should not happen.
aegis is supposed to prevent this, and I don’t know how this happened to your setup. I will have to implement a stronger duplicates check on that as I don’t want this to happen.
For now, you should do
Code:
aegis restart
and status should be ok. If not, please report and use
Code:
aegis clean; aegis restart
Next release will definitely have stronger check of duplicates during creation of rules to avoid that.



Now, to answer @R. Gerrits : I did not design aegis to work after a VPN or Wireguard but rather the traffic coming to and from the router to the internet gateway.
The principle of a VPN is to escape this and tunnel a connection not visible by middle men.
That being said, it is probably not hard to do and studying iptables chains and find some that could be common (maybe loc2net and net2loc or fw2net, etc...),. I can look into that (I am not using VPN or WG, so if I do that, I will need some beta testing from users using it).
Also, bear in mind that aegis would then filter traffic going through VPN or WG initiated from the router, but would not filter any traffic going through a VPN or WG initiated behind the router (if a computer in the local network is using a VPN, it won’t be filtered as it is hidden in the VPN tunnel, and that is the purpose...).
So using a VPN is good for anonymity, but is also an open door. I would suggest to always use a trusted VPN and if you want to filter, choose one that allow to do so from their servers.

Aegis cleaned and restarted
root@R7800:/$ /opt/bolemo/scripts/aegis status
Status:
- 'aegis' version: 1.0.2
- 'iprange' is installed: iprange 1.0.4
- 'aegis' is set and active.
- Filtering 620106676 IP adresses.
- Logging is on.
root@R7800:/$
The problem may have been caused by me. I updated Kamoj addon.I have Aegis on a usb stick which I removed (safely) while I updated Kamoj addon also by usb.Im using PIA vpn
 
HELLO wORLD said
Now, to answer @R. Gerrits : I did not design aegis to work after a VPN or Wireguard but rather the traffic coming to and from the router to the internet gateway.
The principle of a VPN is to escape this and tunnel a connection not visible by middle men.
That being said, it is probably not hard to do and studying iptables chains and find some that could be common (maybe loc2net and net2loc or fw2net, etc...),. I can look into that (I am not using VPN or WG, so if I do that, I will need some beta testing from users using it).

I use Wireguard vpn and happy to beta test for you. But as you know my knowledge ends with copy and paste commands:)

Just a question does the VPN connection loose any of its functions/anonymity with a block-list on?

EDIT: I also can use Open VPN if that helps.
 
I use Wireguard vpn and happy to beta test for you. But as you know my knowledge ends with copy and paste commands:)

Just a question does the VPN connection loose any of its functions/anonymity with a block-list on?

EDIT: I also can use Open VPN if that helps.

Thank you.

aegis is not compromising your anonymity. I don’t know how WG and OVPN rules are defined in the chains. I don’t know for exemple if it routes only FORWARD to the VPN or OUTPUT and INPUT as well.
It is a little simplistic, but to explain:
FORWARD is all traffic between internet and local network (except the router).
OUTPUT is all traffic from router only to internet
INPUT is all traffic from internet to router only

So the only time aegis might reveal your real IP would be to github servers during an update or upgrade, and only if INPUT and OUTPUT are not going through the VPN.

In no way aegis is altering your traffic. All it does is block traffic to or from IP adresses/ranges in the list going through the wan interface (internet side plug of the router). It does not analyse the traffic, reroute it or revealing it to anything else.

It does not block traffic going through a tunnel (VPN), as the only IP involved is the VPN server.

The idea of filtering (blocking) traffic going through the router’s VPN (or WG) tunnel is very interesting as it would allow the aegis protection using VPN or WG.

I will study that.
 
  • Like
Reactions: KW.
If you would like a Wireguard vpn confiriguation for testing yourself I can provide you one under the testing period:)
 
If you would like a Wireguard vpn confiriguation for testing yourself I can provide you one under the testing period:)
Thank you!

I do have a PIA VPN account that I use with KODI and part of my Synology DiskStation as well as my phone when outside the house.
When I will start to work on that, I might not even need to setup VPN on the router. It all depends on how VPN (and WG) are working.

I am sure someone here, like @kamoj can tell me how VPN and WG is routed in iptables.
 
  • Like
Reactions: KW.
Now, to answer @R. Gerrits : I did not design aegis to work after a VPN or Wireguard but rather the traffic coming to and from the router to the internet gateway.

And with OpenVPN client or WireGuard, effectively that internet gateway no longer is called brwan, but is called tun21 or wg0.
So it is a very simple change to add. I'll PM you the details.

Also (but here my knowledge falls a little bit short), depending on the "modem" you have in front of the router, the internet gateway would be called ppp0 -> in that case also aegis currently would not block anything.


But you are right in stating that a you cannot protect the a PC that is running a local VPN client.
 
Yes this is what I found when I started with VPN:

The gateway is only named brwan if PPP is not used
All other: PPTP, L2TP, PPPoE gives ppp0 instead.

So use e.g. this to get gateway:
Code:
WAN_GWAY="$(ip route | awk '/^default/{print $3}')"
And with OpenVPN client or WireGuard, effectively that internet gateway no longer is called brwan, but is called tun21 or wg0.
So it is a very simple change to add. I'll PM you the details.

Also (but here my knowledge falls a little bit short), depending on the "modem" you have in front of the router, the internet gateway would be called ppp0 -> in that case also aegis currently would not block anything.

But you are right in stating that a you cannot protect the a PC that is running a local VPN client.
 

Latest threads

Sign Up For SNBForums Daily Digest

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