Aegis Aegis (simple yet effective protection)

[HELLO_wORLD]

1.4.6

A lot of internal structural changes (to reflect new terminology concept and optimize/rationalize the code).
Fixes the bug described by @Jauger
Changed the command clean by unset
unset and down are now different:
- down is to stop aegis, but it does not unset its code in firewall-start.sh and post-mount.sh and it does not removes the directives files (calculated blocklist and whitelist from sources and custom lists). It is more logical to use down when you intend to start it later.
Even though code is left in these files, aegis won’t start unless aegis up is called.
- unset stops aegis, but also removes its code from above-mentioned files. More intended to use if you won’t be using aegis for a long time.

Also, when aegis up is used and no directives files are found (first launch or after firmware upgrade), it will automatically refresh the directives.

Web Companion was updated to work with those changes (and fix the log display bug).

Recommended upgrade procedure is either from cli, or from the web interface, but after the upgrade, please reload the web page and restart aegis with refresh (if you want it on).

 

[NetBytes]

So I clicked the web upgrade to 1.4.6 from 1.4.5 and results are:
Aegis shield is not set (environment is clean).
Active WAN interface is 'brwan'.
no VPN tunnel found.
Blocklist directives generation time: 2020-12-21 03:40:12
No status file found.
Debug Info

• device info: R7800 R7800 V1.0.2.81SF
• aegis info: aegis 1.4.6-ext
• status codes: 0#0#0#brwan#x.x.x.x/21###0#0#1
• file codes: //
• iptables engine rules:
• no aegis rules are set.
• ipset engine sets:

---------------------------------
Had to run a "Refresh directives then start aegis (without logging)" from the GUI and now everything is back to working.

 

[R. Gerrits]

I noticed the same; also had to "refresh directives" before the GUI showed OK.

btw, "shield was upreared from" -> I thought my english (or american english) was pretty good, but I really had to look up the meaning of uprear; it was the first time I've seen this word being used.

 

[HELLO_wORLD]

Yes, internal changes are important, and the upgrade can bring little glitches like that. The web companion is in fact trying to start it with a command that is not existing anymore (because web page calling the upgrade is still on prior version)

Solution is to refresh the page after the upgrade, then uprear the shield
Yep, thought that this word was appropriate to uplift a legendary shield.

 

[Jauger]

Heads up, the Web UI still has a slight problem, its reversing internal for external sources....
ex:
2020-12-21 18:09:56 Blocked Incoming UDP packet from WAN: 10.0.0.3:25377 to LAN: 194.57.91.200:53

2020-12-21 18:09:55 Blocked Incoming UDP packet from WAN: 10.0.0.4:47224 to LAN: 194.167.45.250:53

10.0.0.3 & 10.0.0.4 are my pihole internal addresses

 

[HELLO_wORLD]

Heads up, the Web UI still has a slight problem, its reversing internal for external sources....
ex:
2020-12-21 18:09:56 Blocked Incoming UDP packet from WAN: 10.0.0.3:25377 to LAN: 194.57.91.200:53

2020-12-21 18:09:55 Blocked Incoming UDP packet from WAN: 10.0.0.4:47224 to LAN: 194.167.45.250:53

10.0.0.3 & 10.0.0.4 are my pihole internal addresses

Thanks for reporting.

To debug this one, I need the raw log.
Could you send me the result of this command:

grep -F "$(echo -ne "10.0.0.3\n10.0.0.4")" /var/log/log-aegis

Also, do you experience the same bug by doing in the terminal aegis log -show ?

Thank you

 

[h1ms3lf]

for me the output of the command
grep -F "$(echo -ne "10.0.0.3\n10.0.0.4")" /var/log/log-aegis
is empty.
I'm on v 1.4.5

 

[HELLO_wORLD]

for me the output of the command
grep -F "$(echo -ne "10.0.0.3\n10.0.0.4")" /var/log/log-aegis
is empty.
I'm on v 1.4.5

This command is for @Jauger to pin-point why he experiments the bug he reported. It won’t give anyone else useful results (like you, it would return empty).

Do you experiment the same glitch in Web Companion log tab than @Jauger ?

 

[h1ms3lf]

This command is for @Jauger to pin-point why he experiments the bug he reported. It won’t give anyone else useful results (like you, it would return empty).

Do you experiment the same glitch in Web Companion log tab than @Jauger ?

The only thing i've noticed is if I leave open the LOG tab, without refresh, after a few new entries the displayed log changes from "Blocked INCOMING TCP packet from WAN" to "Blocked INCOMING TCP packet from VPN"
but in rest everything works ok.

 

[Jauger]

Thanks for reporting.

To debug this one, I need the raw log.
Could you send me the result of this command:

grep -F "$(echo -ne "10.0.0.3\n10.0.0.4")" /var/log/log-aegis

Also, do you experience the same bug by doing in the terminal aegis log -show ?

Thank you

Will do but I must be on the other side of the planet from you. I'll swing home in a few hours and try....

 

[HELLO_wORLD]

The only thing i've noticed is if I leave open the LOG tab, without refresh, after a few new entries the displayed log changes from "Blocked INCOMING TCP packet from WAN" to "Blocked INCOMING TCP packet from VPN"
but in rest everything works ok.

v1.4.6 fixed this issue ( @Jauger experienced that as well with 1.4.5)
On 1.4.6, he has another issue with WAN and LAN reversed for some of his devices.

 

[Jauger]

running grep -F "$(echo -ne "10.0.0.3\n10.0.0.4")" /var/log/log-aegis gives an empty reply and my logs in the web ui and terminal are now not showing the bug. I'll continue to run it and see if it returns.

 

[Jauger]

ok, in terminal log it shows as
2020-12-22 11:02:05 Blocked outgoing UDP packet to WAN: 208.80.126.13:53 from LAN: <unknown> (10.0.0.3):21026
which looks correct but in web ui it shows as

2020-12-22 11:02:05 Blocked Incoming UDP packet from WAN:10.0.0.3: 21026 to LAN:208.80.126.13:53

(also no outgoing logs, which is weird)

 

[HELLO_wORLD]

Ok, thanks; can you send me the result of

grep -F "$(echo -ne "10.0.0.3\n10.0.0.4")" /var/log/log-aegis

I need that to reproduce this here and find why.

The code is the same for cli and gui, so it is a variable or some environment difference.

 

[HELLO_wORLD]

Ok, maybe it was just that

Your log extract is helpful, particularly if the problem comes back.

 

[Jauger]

Ive completly uninstalled aegis...removed all my custom iptables, rebooted and did a fresh install of aegis......what I am seeing is the log in terminal is showing the correct outbound logs, the web ui isnt showing any outbound but incoming...and incoming doesnt look complete

 

[HELLO_wORLD]

Ive completly uninstalled aegis...removed all my custom iptables, rebooted and did a fresh install of aegis......what I am seeing is the log in terminal is showing the correct outbound logs, the web ui isnt showing any outbound but incoming...and incoming doesnt look complete

Ok, I will need to be able to reproduce the bug here to work on it. As you seem to be the only one experiencing this. Here the GUI log viewing is fine.
Here a great code that should work

grep -F '10.0.0.4' /var/log/log-aegis
grep -F '10.0.0.3' /var/log/log-aegis

Knowing it is only on the web GUI clears some research, but then it can be on the server script delivering the log to the webpage, or the client script in the webpage.

First, could you give me (in pm if you are not confortable having it public) the result of this:

cat /tmp/netscan/attach_device /tmp/dhcpd_hostlist /tmp/hosts

I might come with a new version that will not solve the problem, but would have a debug mode allowing to better pinpoint this kind of situation.

PS: I might be a little less responsive these times (Xmas season), but what is important is this bug is not affecting the shield itself.

 

[HELLO_wORLD]

1.4.7 1.4.8

Code cleaning.
Major optimization in generation of web log (all process is done via a very big awk command). Uses way less cpu. That should also solve @Jauger bug

1.4.8 corrects minor bug: wrong protocol showing in web log for uncommon protocols.

 

[h1ms3lf]

1.4.7 1.4.8

Code cleaning.
Major optimization in generation of web log (all process is done via a very big awk command). Uses way less cpu. That should also solve @Jauger bug

1.4.8 corrects minor bug: wrong protocol showing in web log for uncommon protocols.

Thank you! Wish you a Merry Christmas !

 

[HELLO_wORLD]

Thank you @h1ms3lf

Merry Christmas to you all!

Stay safe in the real world, and in the virtual one behind the shield.​