Aegis Aegis (simple yet effective protection)

[D3FenD3r]

I wanted to bring it back to the previous version but ......

 

[kamoj]

You have to add this to downgrade:
--force-downgrade

BUT be aware that you might destroy your router firmware.
You MUST remove previous add-on before installing another one:
/bin/opkg remove -V1 --force-remove kamoj-addon

Now you have been warned.

I wanted to bring it back to the previous version but ......

View attachment 27389

 

[D3FenD3r]

yes back .... so it's the fault of the new version

 

[kamoj]

Nothing fault. It's by (bad) design.
This release was rushed since it was needed for the strange timestamp >9999 bug.
Like I said; the release only looks in internal memory, so if you use external memory it's not showing up.
Same for R7800.
Thank you for reporting.

yes back .... so it's the fault of the new version

View attachment 27390

 

[HELLO_wORLD]

It gets visible when the add-on detects the presence of:
/root/bolemo/www/aegis.htm
Note that the web-page in your browser must be re-loaded (e.g. by pressing F5) for this.
(Maybe it's not working on the R9000, since I have not tested that)

You should test this path:
/www/bolemo/aegis.htm
Or
/opt/bolemo/www/aegis.htm
it works for internal and external install

 

[R. Gerrits]

2020-10-27 02:51:35 Blocked VPN incoming UDP packet from RICHARDSSIPHONE (192.168.1.10)51413 (remote) to 195.35.245.30 6881 (local)

not sure why 192.168.1.10 is recognized as RICHARDSSIPHONE, I'll look in that later.
(192.168.1.10 is reservation with a bogus mac-address, that I manually assigned as a 2nd IP-address for my NAS.)

Seems to be another small bug.
aegis is parsing /tmp/dhcpd_hostlist (and /tmp/hosts).
my dhcpd_hostlist looks like this:

192.168.1.12 NAS2
192.168.1.40
192.168.1.20 LIBREELEC
192.168.1.100 RICHARDSSIPHONE
192.168.1.101
192.168.1.30
192.168.1.25
192.168.1.26 MEDIABOX

So 192.168.1.10 should not resolve to anything in that file.
But as 192.168.1.100 contains 192.168.1.10, it probably uses that one.
I think you should search for "IP " instead of "IP".

Also, there might be better places to look for the device-names. As this dhcpd_hostlist is pretty limited (at least on my router)
If you have Kamoj's addon, you could look at his logic in /usr/bin/addon_bypassvpnip.sh because his list of ipaddresses and names in VPN Bypassing is much more complete.

 

[HELLO_wORLD]

1.3.5 is out.
Optimizations and fixed the wrong device name ( thx @R. Gerrits ).

As for the devices names, yes, the more the merrier... I try to be only dependent on @Voxel’s firmware though. There are more names in nvram (device_list) by MAC. I will have to investigate more, when I find the time.

 

[R. Gerrits]

I didn't mean that you should use Kamojs addon in aegis, just meant to look in that file and get inspiration on which sources he is using.

But in case you don't have it installed, Kamoj is dumping nvram reservation*, device_list* and access_control* values.
The last two however only show mac-address vs name -> you'd then also need to look in the arp-table to map IP-address via mac-address to a name.
So that might be a bit more complicated to do.
Also not sure if it hurts to call nvram show many times. (i.e. does this come from memory, or would it everytime need to access the actual flash)

 

[HELLO_wORLD]

I didn't mean that you should use Kamojs addon in aegis, just meant to look in that file and get inspiration on which sources he is using.

But in case you don't have it installed, Kamoj is dumping nvram reservation*, device_list* and access_control* values.
The last two however only show mac-address vs name -> you'd then also need to look in the arp-table to map IP-address via mac-address to a name.
So that might be a bit more complicated to do.
Also not sure if it hurts to call nvram show many times. (i.e. does this come from memory, or would it everytime need to access the actual flash)

I am looking at that right now.
iptables logs are showing source and destination MAC, so it is not so hard to get device name from nvram.
Reading nvram is not bad in speed and consequences, it is already in ram. Writing and commit is another story as it writes to the chip and some R7800 chips are very sensitive, but here, we are only reading.

[EDIT] MAC in log is good only for source, destination is mostly brwan or br0 (depending on outgoing or incoming). It can be useful to get name for local source for outgoing, but not incoming to local source,

 

[HELLO_wORLD]

Ah! Found another file to parse: /tmp/netscan/attach_device
It has IP and device name (as well as MAC)

 

[HELLO_wORLD]

1.3.6 is here
More device names, minor bug fixes and optimizations.

 

[kamoj]

File only exist if you have opened the "Attached Devices" tab/form.

Ah! Found another file to parse: /tmp/netscan/attach_device
It has IP and device name (as well as MAC)

 

[Jauger]

1.3.6 is here
More device names, minor bug fixes and optimizations.

I highly reccomend a router reboot after this upgrade...seems to help settle things down on the logs

 

[HELLO_wORLD]

File only exist if you have opened the "Attached Devices" tab/form.

I have the file but don’t recall opening the Attached Devices tab.
Now, I need to see what this tab is triggering. There is a net-scan binary that could be behind...

 

[HELLO_wORLD]

[Technical post]

Ok, /usr/sbin/net-scan does not seem to do anything, and it is not called when the “devices list” web page is loaded.
What triggers it is the call to the cgi-bin start-netscan() function (from <% start_netscan() %> in html code read from uhttpd), but nobody found (yet) how to talk directly to /usr/sbin/cgi-bin from shell, or figured what it does (NG black boxed).

So my solution is to run this JavaScript each time the log tab is loaded. I might call it even at each log refresh (10 seconds), but I need to check it is not too much load on cpu:

var ngDev = new XMLHttpRequest(); ngDev.open("GET", "/DEV_device.htm", true); ngDev.send();

I could have called a custom html page with just <% start_netscan() %> in it, but /www/DEV_device.htm is a small page and is already there, so...

 

[HELLO_wORLD]

1.3.7 released
Reduced significantly the CPU load of Web Companion log updates.
Devices list (from NG) is updated every minutes when the log tab is displayed.

 

[HELLO_wORLD]

1.3.8 is out

Aegis Core:
- some optimizations,
- changed iptables whitelist rule from ACCEPT to RETURN to allow packets matching whitelist to go through other rules,
- possibility of multiple blacklist files (in /opt/bolemo/etc/ aegis.blacklist of course, and any file named aegis-something.blacklist ),
- possibility of multiple whitelist files (in /opt/bolemo/etc/ aegis.whitelist of course, and any file named aegis-something.whitelist ex: aegis-vpn.whitelist with public IPs of your VPN provider)

Aegis Web:
- log protocols are now using a custom database, allowing to have a better description. Particularly useful for protocols other than ICMP, UDP or TCP,
- tab to read/edit blacklist sources /opt/bolemo/etc/aegis.sources,
- tab to read/edit custom blacklist /opt/bolemo/etc/aegis.blacklist,
- tab to read/edit custom whitelist /opt/bolemo/etc/aegis.whitelist

 

[foo man]

Aegis Web:
- log protocols are now using a custom database, allowing to have a better description. Particularly useful for protocols other than ICMP, UDP or TCP,
- tab to read/edit blacklist sources /opt/bolemo/etc/aegis.sources,
- tab to read/edit custom blacklist /opt/bolemo/etc/aegis.blacklist,
- tab to read/edit custom whitelist /opt/bolemo/etc/aegis.whitelist

Nice additions! Thanks for the update

 

[D3FenD3r]

here ... what I expected, how cool

 

[D3FenD3r]

tried now ... does not upgrade

maybe it's about kamoj?