Aegis Aegis (simple yet effective protection)

[HELLO_wORLD]

tried now ... does not upgrade

View attachment 27608


View attachment 27609


maybe it's about kamoj?

Aegis has nothing to do with AdGuard process or upgrades.

The only way it could disturb an upgrade is if the AdGuard server was blacklisted.

If you disable Aegis (Web: Command -> Restart Internal Firewall without Aegis Engine), and have the same problem, it confirms that it is not Aegis related.

 

[D3FenD3r]

even with aegis disabled .......... same problem

 

[R. Gerrits]

AdGuard Home is installed via Kamoj addon -> it must also be updated via Kamoj addon.
(auto update is not supported)
go to Kamoj Menu -> DNS Privacy/Ad-Blocking and at the top click on Download Latest Version.

 

[D3FenD3r]

mea culpa I had already done it another time
but now my brain is clouded

 

[HELLO_wORLD]

mea culpa I had already done it another time
but now my brain is clouded

nvram set brain_cloud_disable=1

It’s ok, it happens to the best of us.

 

[D3FenD3r]

now I enter aegis and I see this

after an update

settled with a router reboot

 

[HELLO_wORLD]

Glad a reboot solved it.
If you encounter little problems like that, you can also do:

aegis restart

or from the Web Companion: RESTART INTERNAL FIREWALL WITH AEGIS ENGINE.
Contrarily to update, it actually resets the firewall and restarts the engine.

From your screenshot, I notice that you have a link that seems to be gzipped in your sources. Please, note that Aegis is not able to read gzipped sources, it has to be plain TXT ips or ipranges.

 

[HELLO_wORLD]

1.3.9 is out

Aegis Core:
- some minor bug fix (incorrect log warning when IFO rules reports errors),
- changed iptables outgoing engine rule from DROP to REJECT to notify local devices their requests were denied. Incoming rules are kept to DROP as we don’t want remote devices to know we exist,
- tweaked the show log function.

Aegis Web:
- LOG display was improved,
- new tab TOOLS, from where it possible to check if an IP is blocked, and in engine blacklist and whitelist.
- STATUS now has a Debug info, with more info for debugging, just in case.


Clean and restart will be needed.

 

[NetBytes]

Smooth upgrade, all set here. Thank You!

 

[D3FenD3r]

adding this line makes everything slow

https://iplists.firehol.org/files/firehol_anonymous.netset

maybe there are too many ip's to check?

 

[HELLO_wORLD]

adding this line makes everything slow

https://iplists.firehol.org/files/firehol_anonymous.netset

maybe there are too many ip's to check?

Yes, is a huge list (22 Mb)!
The Firehol level1, 2, 3, and other lists are a few hundreds of Kb.

 

[Jauger]

R9000 smooth upgrade.....what are your thoughts of checking "Disable Port Scan and DOS Protection" with running Aegis? Any pros or cons? Ive seen on a few forums people suggesting disabling

 

[HELLO_wORLD]

R9000 smooth upgrade.....what are your thoughts of checking "Disable Port Scan and DOS Protection" with running Aegis? Any pros or cons? Ive seen on a few forums people suggesting disabling

I personally have it disabled for a long time. I also have read back then about disabling it ; I do not remember what was the reason...

One thing about this is we don’t know exactly what it does, and I like to know what is going on.

 

[h1ms3lf]

Hmmm, is this an error/bug? Check IP from Tools reports listed ip from custom blacklist as not being blocked by the router.
My aegis status:

• Active WAN interface is 'ppp0'.
• no VPN tunnel found.
• Blocklist generation time: 2020-11-03 20:38:24
• 'firewall-start.sh' is set for aegis.
• 'post-mount.sh' is set for aegis.
• ipset: blocklist is set.
• iptables: engine chains are set.
• iptables: aegis logging is on.
• iptables: WAN interface IFO rules are set.

 

[HELLO_wORLD]

Hmmm, is this an error/bug? Check IP from Tools reports listed ip from custom blacklist as not being blocked by the router.
My aegis status:

• Active WAN interface is 'ppp0'.
• no VPN tunnel found.
• Blocklist generation time: 2020-11-03 20:38:24
• 'firewall-start.sh' is set for aegis.
• 'post-mount.sh' is set for aegis.
• ipset: blocklist is set.
• iptables: engine chains are set.
• iptables: aegis logging is on.
• iptables: WAN interface IFO rules are set.

The checking process is very simple: 1) it tries to ping the address, if it cannot, then it means it is blocked; 2) it checks if the IP is in the Engine sets (black and white), so the check is probably telling the truth.
From the terminal (or any device on your LAN), you can try to ping the address, if it does not return an error, it means it is not blocked.

Now, there is a reason why it is not blocked in your case : the custom blacklist with your IP was probably not loaded in the Engine set when you did the test.
Your Engine set was loaded the 2020-11-03 at 20:38:24.
Your custom list was modified the 2020-11-17.

Once a change is made to the lists (sources, blacklist, whitelist), it is not automatically loaded in the Engine set. For that, you need to update it from the COMMAND (or aegis update from terminal). So in your case, if you added the IP after 2020-11-03 20:38:24, it was not loaded.

 

[h1ms3lf]

I've check with ping and indeed it timed out. I've done an update set + reload aegis engine, and now check ip dispays the ips from custom blacklist as blocked. Thank you!

 

[Jauger]

I've got a small issue. With Aegis I use it to block hard coded Google devices ( 8.8.8.8 & 8.8.4.4 ). With the engine rule changed from DROP to REJECT my logs are being flooded with requests and Ive notice a performance hit on my router. Temporarily Ive set up a static route under netgear settings and pointed these to my piholes....Thought you should know and see if you have any suggestions. Thanks

 

[HELLO_wORLD]

I've got a small issue. With Aegis I use it to block hard coded Google devices ( 8.8.8.8 & 8.8.4.4 ). With the engine rule changed from DROP to REJECT my logs are being flooded with requests and Ive notice a performance hit on my router. Temporarily Ive set up a static route under netgear settings and pointed these to my piholes....Thought you should know and see if you have any suggestions. Thanks

That is a very good point.
Any performance degradation is unacceptable to me.
The REJECT is helping devices on the LAN to avoid timeouts when trying to reach blacklisted IPs.

Those devices seems very aggressive!? How many requests by second?

You say your logs are being flooded. Which logs?
Any chance the performance hit is from those logs?

The addresses you mention are Google DNS resolvers. Why not using a DNAT rule on the PREROUTING table to change the destination address of these DNS to your own (Stubby, dnscrypt or your ISP’s or 9.9.9.9)?
Your devices might work better if they can resolve their DNS queries. I understand you don’t want them to use the forced hardware coded Google ones, but if you can change the destination DNS resolver in the way...

Now, if this REJECT policy is slowing performances in general for users, I will revert to DROP, but let see if it is really an issue here.

 

[Jauger]

More than likely I am the only one having this issue.....On my setup I have forced all my dns to my piholes and run unbound. When you came out with Aegis I discovered that hardcoded google devices were actully bypassing my setup. Its manly a Nvidia Shield going crazy, maybe an insane 10 hits a second showing in the outbound log. Prerouting seems to be the best alternative but its a tad complicated for my level of expertise ( especially routing 2 piholes) but Ill do some more research today and try to figure it out. Once again thanks for the hard work you have put into this, its a life saver.....

 

[HELLO_wORLD]

More than likely I am the only one having this issue.....On my setup I have forced all my dns to my piholes and run unbound. When you came out with Aegis I discovered that hardcoded google devices were actully bypassing my setup. Its manly a Nvidia Shield going crazy, maybe an insane 10 hits a second showing in the outbound log. Prerouting seems to be the best alternative but its a tad complicated for my level of expertise ( especially routing 2 piholes) but Ill do some more research today and try to figure it out. Once again thanks for the hard work you have put into this, its a life saver.....

Maybe something like this:

iptables -t nat -A PREROUTING -i br0 -d 8.8.8.8/32 --dport 53 -j DNAT --to-destination PIHOLEIP
iptables -t nat -A PREROUTING -i br0 -d 8.8.4.4/32 --dport 53 -j DNAT --to-destination PIHOLEIP
iptables -t nat -A POSTROUTING -o br0 -s PIHOLEIP --sport 53 -j SNAT --to-source 8.8.8.8

I did not try but it should work (or close to).
You could also create a rule to redirect all DNS traffic to your PiHoles, whatever the destination address, but the rule would need to be carefully tailored (exclude the PiHoles and the router from it).