Aegis Aegis (simple yet effective protection)

[HELLO_wORLD]

1.5.8

It became obvious that I cannot reproduce behaviors happening in other architectures, unless having a remote access like @D3FenD3r did for me for R9000. This making debugging very difficult, I added debugging abilities to aegis as I am working on Orbi support.
No change really in this version except that a debug log can be generated. No command for it as it is not a feature, nor is it enabled by default. It if for me to have testers to enable it by PM ; I already have one person testing for me for Orbi

 

[HELLO_wORLD]

1.5.9

Code cleaning and optimizations.
Progress with orbi support (need confirmation from tester).

 

[HELLO_wORLD]

1.6.0

Correction of rare and silent bugs.
Correction of bugs occurring when not using iprange.
Improved compatibility with Orbi. Not Orbi "certified" yet, but good progress.

 

[HELLO_wORLD]

1.6.1

Minor optimizations
Logging should now be working on Orbi (system log is going in /var/log/log_message and not /var/log/log-message like for R7k and R9k)

 

[HELLO_wORLD]

1.6.2

Code cleaning and compacting.
Changed the install script to use new procedure to install iprange with Entware.

@Voxel did not include iprange in his latest Entware repo, as iprange is not in official Entware (thus making it difficult for him to maintain).
To compensate the lack of iprange in the repo, he provided a compiled ipk allowing to install it.

The aegis install script now will offer the option to install this way.

For manual install (with Entware installed):

cd /opt/tmp
wget http://voxel-firmware.com/Downloads/iprange_1.0.4-1_cortex-a15-3x.ipk
/opt/bin/opkg install iprange_1.0.4-1_cortex-a15-3x.ipk
rm iprange_1.0.4-1_cortex-a15-3x.ipk

It works for all @Voxel ‘s supported Entware devices: R7500, R7800, R8900, R9000 and Orbi.

 

[mith_y2k]

Has anyone had issues with Slack? I don’t think it’s an aegis issue, it rather the blacklist. I’m using the default ones and today Slack didn’t work. I turned aegis down and slack came back. I need to test more (I.e. figure out which list is blocking which Slack IP), but I thought I’d ask

 

[HELLO_wORLD]

Has anyone had issues with Slack? I don’t think it’s an aegis issue, it rather the blacklist. I’m using the default ones and today Slack didn’t work. I turned aegis down and slack came back. I need to test more (I.e. figure out which list is blocking which Slack IP), but I thought I’d ask

Once you find what are the IPs for Slack, just put them in the whitelist

Edit: you will be able to figure the IP easily once you will be able to use the logging feature...

 

[mith_y2k]

Once you find what are the IPs for Slack, just put them in the whitelist

Edit: you will be able to figure the IP easily once you will be able to use the logging feature...

Thanks that makes sense. I do want to understand if it's just the blacklist wrong or something else. I cleaned my logs, updated the sources to only use FireHOL level 1, ran aegis refresh and launched it. It took a couple of minutes to find at least a couple of the IPs. This is the IP that is being blocked: 54.203.112.76

I didn't find it in FireHOL and when I look it up on IBM's X-force they clearly recognize it as Slack and not a threat. See https://exchange.xforce.ibmcloud.com/ip/54.203.112.76

There are another couple of IPs that get blocked a lot and they are from a couple other legit services I use and pay for. I also looked at a couple of those IPs (and ranges) and cannot find them in FireHOL. So now I'm wondering what/where is something going wrong? Yes I can whitelist a few, but I don't want to be looking at IPs all the time, that why I hope to rely on a regularly updated list like FireHOL. I'm probably doing something wrong and I'm wondering if it's in the sources cache, I initially added a few that maybe have false positives.

 

[HELLO_wORLD]

1.6.3

Some optimizations, code cleaning and reduction.
Corrected minor cosmetic bug happening on Orbi.
Corrected the readme (traces of irrelevant commands, thanks @mith_y2k for noticing)

 

[HELLO_wORLD]

1.6.4

• Completely rewrote the shield uprearing code. Simpler, lighter and more efficient.
• Optimizations.
• Added command line aegis test -ip=IP to check if an IP is being blocked by aegis or not, and why (is it in blocklist, whitelist?)
• Corrected a bug where the whitelist file directive (master cache) would not be deleted if whitelist(s) were emptied or deleted.
• Web companion was updated to follow changes in core.

To update: through web or aegis down; aegis upgrade; aegis up

 

[h1ms3lf]

After upgrade from 1.6.2->1.6.4 using the commands aegis down; aegis upgrade; aegis up I have a problem loading the custom blacklist
Can you give me a solution to this?

The output is:
IP address *.123.41.94 is not blocked by the router.
IP address *.123.41.94 is in Aegis blocklist directives.

The current status is:
Active WAN interface is 'ppp0'.
no VPN tunnel found.
Sources cache directives update time: 2021-01-17 08:48:12
Blocklist directives generation time: 2021-01-17 08:48:12
set: firewall-start.sh is set for aegis.
set: post-mount.sh is set for aegis.
ipset: blocklist is set.
iptables: shield chains are set.
iptables: WAN interface IFO rules are set.

shield was upreared from: aegis script @ 2021-01-17 08:48:16
WAN interface was 'ppp0'.
No VPN tunnel was found.
directives: ipset blocklist was set from file.
directives: no whitelist file was found.
iptables: rules were (re)set.
iptables: rules for WAN interface in place.
log daemon: was already off.

device info: R7800 R7800 V1.0.2.80.4SF
aegis info: aegis 1.6.4-ext
status codes: ck:1047|pb:0|wn:0|wifpp0|wnt:|tif:|tnt:|blc:619551363|wlc:0|log:1
info file: 99087|ppp0|
timestamps: inf:1610866096|cch:1610866092|bld:1610866092|wld:
conf:
aegis.wan=net-iface
aegis.tun=net-iface
aegis.log=1
aegis.log.len='5000'
aegis.up=1
aegis_web.log=subsection
aegis_web.log.len='300'
aegis_web.log.basetime='1608727546'
aegis_web.log.pos='2137702000'
iptables engine rules:
-N aegis_dst
-N aegis_src
-A INPUT -i ppp0 -m set --match-set aegis_bl src -m comment --comment "incoming in aegis blocklist" -j aegis_src
-A FORWARD -i ppp0 -m set --match-set aegis_bl src -m comment --comment "incoming in aegis blocklist" -j aegis_src
-A FORWARD -o ppp0 -m set --match-set aegis_bl dst -m comment --comment "outgoing in aegis blocklist" -j aegis_dst
-A OUTPUT -o ppp0 -m set --match-set aegis_bl dst -m comment --comment "outgoing in aegis blocklist" -j aegis_dst
-A aegis_dst -m comment --comment "aegis reject outgoing" -j REJECT --reject-with icmp-admin-prohibited
-A aegis_src -m comment --comment "aegis drop incoming" -j DROP
ipset engine sets:
blocklist:
Name: aegis_bl
Type: hash:net
Revision: 6
Header: family inet hashsize 32768 maxelem 60228
Size in memory: 1619308
References: 4
Number of entries: 60228

 

[HELLO_wORLD]

1.6.5


Solves the problem encountered by @h1ms3lf
The rewritten code was not placing aegis rules on top, thus in some configurations other rules could accept traffic before reaching aegis blocking ones.

For this one, either:
aegis down; aegis upgrade; aegis up
Or
aegis upgrade; aegis up -net-wall

 

[h1ms3lf]

Thank you! Now everything runs ok!

 

[mith_y2k]

Happy to say that @HELLO_wORLD did a great job and got it to work on Orbi too

 

[HELLO_wORLD]

Happy to say that @HELLO_wORLD did a great job and got it to work on Orbi too

Yes, the essential part of aegis is working on Orbi, including logging.

Still one bug with watching the log live from aegis log -live (and probably log tab on web interface) that should be fixed soon, and the web has not been tested yet.

 

[HELLO_wORLD]

1.6.7 (yes, 1.6.6 was not released publicly)

Fixed a silent bug where aegis test -ip with a high IP could be inaccurate.
Some optimizations.

 

[HELLO_wORLD]

Aegis core is now officially supported on Orbi

The Web Companion however is not working for now, as Orbi relies on lighthttpd while R7800 and R9000 are using uhttpd. The result is that aegis cgi-bin does not work on Orbi (error 404).
If anyone knows some about that, I am interested, as I don’t have an Orbi to work on.

 

[mith_y2k]

That's right, by default Orbi's Web server doesn't allow the execution of any CGI. I edited /etc/lighttpd/conf.d/30-cgi.conf and added the following line:

"aegis_web.cgi" => "/opt/bolemo/www/cgi-bin",

This allows the CGI to be executed, but then I get an error 500.

@HELLO_wORLD as I was thinking about this I am wondering if simply the cgi fails to execute and returns an error. Is there a way that I can test the CGI from the command line or is there a way to activate the debug to file?

 

[mith_y2k]

And I figured it out! All I needed was to read how to properly edit the config file. This is the line you need to edit:

                "aegis_web.cgi" => "/opt/bolemo/www/cgi-bin/aegis_web.cgi",

So in my case the full command now looks like this:

cgi.assign                 = (
                "soapapi.cgi" => "/usr/sbin/soap-api",
                "aegis_web.cgi" => "/opt/bolemo/www/cgi-bin/aegis_web.cgi",
                "" => "/usr/sbin/net-cgi"
                )

I think 2 more steps are needed on an Orbi:

1. Add this to the overlay configuration
2. reload lighttpd post mount

@HELLO_wORLD I can send you the file if you'd like to provide it as part of the installation script. Do you also want to modify your post-mount script? If not, I'll make my own edits.

 

[mith_y2k]

Something is still not right, if anyone has experience it might help. I would say it mostly works. All menus work as expected, but the live logs I would say work 50% of the times. See below

@HELLO_wORLD I am only getting 3 entries in the Web server's logs, but I wonder if you know what this might be:

2021-01-18 16:56:36: (http-header-glue.c.1376) response headers too large for /bolemo/cgi-bin/aegis_web.cgi

It looks like lighttpd has a hardcoded limit for response headers of 65535. See https://github.com/lighttpd/lighttpd1.4/blob/master/src/http-header-glue.c#L31