Aegis Aegis 1.7.x

[blueliner]

Upgraded from 1.6.12 to 1.7.2 via terminal and all is well! Many thanks!

EDIT: I see a slighlty increased RAM Usage. Is there a way we can clear ram cache?

EDIT2: Just noticed that on LOGS traffic "from" to "to" appear with big space between them. Also, clicking on an IP does not open an IP Lookup page. (thought this was added as feature to 1.7.0 and later)

Hello,

Running 1.7.2...I see normal RAM/CPU usage that goes up a little with logging on (although it would need to be a fair amount more for me to notice).

I had logging off and changed it to "on" via the Command Tab's "Refresh directives then start Aegis with logging enabled". It worked but the message only stated that the process started and then nothing but this again (this is an old screenshot from a failed 1.7.0 upgrade but same pop-up message):

However, the refresh/start with logging completed successfully as I was able to view the log. I tried the "refresh directives" a second time and then I got the full list of successful actions as expected - maybe its something with my browser, beats me. Anyway, the ip lookup works on my R9000 (if this is what you are referring to?):

Clicking on the port number will also bring you to: https://www.speedguide.net/port.php?port=

Best wishes,
BL

 

[Warlord1981]

Hello,

Running 1.7.2...I see normal RAM/CPU usage that goes up a little with logging on (although it would need to be a fair amount more for me to notice).

I had logging off and changed it to "on" via the Command Tab's "Refresh directives then start Aegis with logging enabled". It worked but the message only stated that the process started and then nothing but this again (this is an old screenshot from a failed 1.7.0 upgrade but same pop-up message):
View attachment 31506
However, the refresh/start with logging completed successfully as I was able to view the log. I tried the "refresh directives" a second time and then I got the full list of successful actions as expected - maybe its something with my browser, beats me. Anyway, the ip lookup works on my R9000 (if this is what you are referring to?):

View attachment 31508
Clicking on the port number will also bring you to: https://www.speedguide.net/port.php?port=

Best wishes,
BL

Made Refresh Directives and now logging page appears as it should. IP Lookup as well! uBlock Origin is just blocking it in Firefox. Many thanks!

 

[HELLO_wORLD]

Upgraded from 1.6.12 to 1.7.2 via terminal and all is well! Many thanks!

EDIT: I see a slighlty increased RAM Usage. Is there a way we can clear ram cache?

EDIT2: Just noticed that on LOGS traffic "from" to "to" appear with big space between them. Also, clicking on an IP does not open an IP Lookup page. (thought this was added as feature to 1.7.0 and later)

RAM usage should be similar, unless using custom lists for specific interfaces.
Aegis itself is not using any ram since it does not keep running. The log daemon is using very little ram and CPU, and it did not change much between 1.6 and 1.7
Then there are the loaded ipsets that are using ram, depending on how many entries there are in the lists (from sources and custom ones). That depends strictly on ipset.

About the logs on web GUI:
1) IP addresses (from, then to) are aligned, so this create spaces. It was a design choice. Could have been without spaces but not aligned.

2) IP info clicking on it has been a feature since before 1.6. I think it does not work on some specific navigator or setting, but works for most of them.

 

[NetBytes]

just did command line upgrade, performing all three steps each time.
first time went from 1.6.10 to 1.7.0 - all ok but the final version reported was 1.7.1
next from 1.7.1 to 1.7.2 all ok

web companion should say 1.7.3 available? but does not.
re-run of aegis upgrade -repo=stable asks if I want to reapply 1.7.2

Thanks for all the hard work on this amazing system for use on my R7800

 

[HELLO_wORLD]

1.7.3

Now, at each refresh, aegis will create a default custom VPN whitelist. It is ok if you don’t use VPN, aegis will just ignore it.

If you do use VPN, this whitelist prevents the VPN handshake to be blocked when VPN renews its certificate.
@kamoj did a lot of research on that, and suggested this default whitelist that is covering most (if not all) VPNs.
So you don’t really need to do anything and leave this alone.

For power users and informatively, it contains this:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

If you know more exactly what needs to be whitelisted for your specific VPN, you can of course change this list (possible from web GUI).

you empty it, it will be recreated, so if you don’t need to whitelist anything for your VPN provider, just comment these three lines (adding a # at the beginning of each line), like this:

#10.0.0.0/8
#172.16.0.0/12
#192.168.0.0/16

Again, if you don’t use VPN (the one inside the router), you can just leave this list alone, commented or not, as it won’t be loaded.

If you use a VPN on the router, this default list should work as is, so nothing for you to do unless you want to fine tune it (and you know what you are doing).

If you use a VPN on your LAN (from your computer, tablet, phone...), this does not use the router’s VPN, so this list does not apply.

 

[HELLO_wORLD]

just did command line upgrade, performing all three steps each time.
first time went from 1.6.10 to 1.7.0 - all ok but the final version reported was 1.7.1
next from 1.7.1 to 1.7.2 all ok

web companion should say 1.7.3 available? but does not.
re-run of aegis upgrade -repo=stable asks if I want to reapply 1.7.2

Thanks for all the hard work on this amazing system for use on my R7800

Yes, I had the nasty bug back, so removed 1.7.3 to avoid problems.
It was on for a few minutes.

To be sure you don’t have problems (during next web upgrade), I suggest you redo upgrade from terminal, and say yes to reapply.

The 1.7.3 available now is ok, I completely changed the post install process.

 

[R. Gerrits]

I just upgraded via Web companion from 1.7.2 to 1.7.3 without issues.

 

[NetBytes]

I just upgraded via Web companion from 1.7.2 to 1.7.3 without issues.

Based upon this I tried the web companion upgrade route to 1.7.3 and it completed correctly.
Running 1.7.3. Thanks Again.

 

[HELLO_wORLD]

I just upgraded via Web companion from 1.7.2 to 1.7.3 without issues.

Yep, 1.7.2 to up is working because it does not trigger the post install.
1.7.3 (the one that was there for a few minutes) fixed that but reintroduced the bug (no matter how hard I tried to go around it).
The actual 1.7.3 (the one you downloaded) has a totally different post-install process for web GUI. It is now a separate script loaded online in RAM with curl|sh.
For now, all that script is doing is setting up aegis settings for Orbi lighttpd if needed, it does nothing for R7800 and R9000.

 

[kamoj]

Really amazing application and fast development.
Update and function all perfect.
Thank you sir (@HELLO_wORLD) for all hard work and super duper application!!!

 

[blueliner]

I just upgraded via Web companion from 1.7.2 to 1.7.3 without issues.

Ditto here.
The Aegis web page informed me of the available upgrade to 1.7.3. I upgraded from 1.7.2 to 1.7.3 via the web interface. The VPN whitelist loaded OK and all went well. Thank you!

 

[HELLO_wORLD]

Good

Precision: once the vpn whitelist is downloaded once, unless it is emptied or deleted, it won’t be downloaded again at each refresh. Like the sources files, any change you make to it will be kept between and after refreshes.

 

[mith_y2k]

Upgraded to 1.7.3 and went smoothly. It looks like the maxLogLen in aegis.htm is still 300, but your new workaround makes it work well in the Web companion.

 

[HELLO_wORLD]

Upgraded to 1.7.3 and went smoothly. It looks like the maxLogLen in aegis.htm is still 300, but your new workaround makes it work well in the Web companion.

It is the same workaround used since we had aegis working on Orbi
I think for 1.7.2, you had problems because of the post install that was not called, so lighttpd was not properly setup for aegis.

Glad 1.7.3 is making aegis working fine again on Orbi.

 

[sppmaster]

@HELLO_wORLD
I've upgraded to 1.7.3 - all OK.
I've decided to make several probes.
First of all I've opened ShieldsUp site to see if the NG DoS and Port Scan protection works. I've scanned wit DoS enabled and the ShieldsUp reported a TruStealth result Passed. During the scan I saw the following record in system log - [DoS Attack: SYN/ACK Scan] from source: 4.79.142.192, port... So far so good.
I've disabled NG DoS and Port Scan protection (I've disabeled SIP ALG too) from R7800 WAN settings. I've repeated the scan and received TruStealth result Passed once again. Just there wasn't any record in system log and that is to be expected.
After that I've decided to add ShieldsUp IP addresses to the global block-list of Aegis and try to scan one more time. I've expected that no communication would be possible and to see the IPs in the Aegis log. Several log records appeared but I was still able to open the site (very slowly though) and perform a port scan. So probably the communication to the site was not fully blocked as I expected.

 

[HELLO_wORLD]

@HELLO_wORLD
I've upgraded to 1.7.3 - all OK.
I've decided to make several probes.
First of all I've opened ShieldsUp site to see if the NG DoS and Port Scan protection works. I've scanned wit DoS enabled and the ShieldsUp reported a TruStealth result Passed. During the scan I saw the following record in system log - [DoS Attack: SYN/ACK Scan] from source: 4.79.142.192, port... So far so good.
I've disabled NG DoS and Port Scan protection (I've disabeled SIP ALG too) from R7800 WAN settings. I've repeated the scan and received TruStealth result Passed once again. Just there wasn't any record in system log and that is to be expected.
After that I've decided to add ShieldsUp IP addresses to the global block-list of Aegis and try to scan one more time. I've expected that no communication would be possible and to see the IPs in the Aegis log. Several log records appeared but I was still able to open the site (very slowly though) and perform a port scan. So probably the communication to the site was not fully blocked as I expected.
View attachment 31630

Aegis does fully block the IP provided (4.79.142.192)

However, ShieldsUp is more than one IP. The domain name is probably resolving to more than one IP (tries first the one blocked, then switches to another server, explaining the very slow resolution).
The port scanning server is probably yet another IP...

EDIT: according to ShieldsUp Wikipedia page:
The scanning servers have the static IP addresses of 4.79.142.192 to 4.79.142.207.
So to block the scanning servers, you need to block: 4.79.142.192/28

 

[sppmaster]

Aegis does fully block the IP provided (4.79.142.192)

However, ShieldsUp is more than one IP. The domain name is probably resolving to more than one IP (tries first the one blocked, then switches to another server, explaining the very slow resolution).
The port scanning server is probably yet another IP...

EDIT: according to ShieldsUp Wikipedia page:
The scanning servers have the static IP addresses of 4.79.142.192 to 4.79.142.207.
So to block the scanning servers, you need to block: 4.79.142.192/28

I sincerely apologize for my stupid mistake. I've mistakenly blocked only two IPs instead of the whole range.
I've done this really late last night. I didn't put the correct (4.79.142.192/28) IP set in the custom blocklist. Just tried it with the right record and it's OK.
Is there a way using aegis to block only incoming communication from different IPs.
I have IGMP packets blocked every few seconds and wonder where these IGMP packets might come from.

 

[HELLO_wORLD]

I sincerely apologize for my stupid mistake.
I've done this really late last night. I didn't put the correct (4.79.142.192/28) IP set in the custom blocklist. Just tried it with the right record and it's OK.
Is there a way using aegis to block only incoming communication from different IPs.

No problem.

First, this is certainly not a stupid mistake.
Computer science and networking is complex and has many layers and protocols... Easy to get confused, particularly when tired and in a rush.

Aegis blocks systematically both ways, considering a blocked IP should not send anything or have anything sent from your network (then revealing activity from your IP). In 99.99% of the cases, blocking one way would not make much sense...

I suspect you want to test the security and be able to reach the web site, but blocking anything coming from their scanning servers... The problem is even if you could send http requests to it, any http data coming back from the site would be blocked anyway...
Only solution is using special iptables rules, tailored for your situation, using conntrack to allow http(s) packets from a connection you initiated first.

Something like this (removing blocking from aegis first):

iptables -t mangle I PREROUTING -s 4.79.142.192/28 -i brwan -m conntrack --ctstate NEW -j DROP

This would block any new connection coming from ShieldsUp, but not connection already established (that you initiated). But this is not perfect.

You could make it more solid by only allowing established TCP connections on port 80 and 443, blocking anything else:

iptables -t mangle I PREROUTING -s 4.79.142.192/28 -i brwan -m state --state RELATED,ESTABLISHED -p tcp -m tcp --dports 80,443 -j ACCEPT
iptables -t mangle I PREROUTING -s 4.79.142.192/28 -i brwan -j DROP

This is a quick untested hint...

 

[HELLO_wORLD]

I have IGMP packets blocked every few seconds and wonder where these IGMP packets might come from.

IGMP is likely coming from your ISP. If your connection is fine, you can just ignore it.

 

[HELLO_wORLD]

Release 1.7.4

Minor upgrade.
Added command to aegis CLI:
aegis debug

That will output all the useful information to report here in case of problems. It even outputs the CODE /CODE tags, so it is ready to be copied/pasted in this forum as is.

Same with web GUI: the debug info in the status was removed, and a debug tab was added, with the same output as the CLI (ready to copy/paste).