Aegis Aegis (simple yet effective protection)

[D3FenD3r]

available

 

[HELLO_wORLD]

1.5.3

aegis down; aegis upgrade; aegis up
Or using Web Companion.

new options for log:
aegis log -get-history to displays the history size (number of records) for the log file /var/log/log-aegis
aegis log -set-history=N sets the history size to N records for the log file /var/log/log-aegis

Default size is 5000.
Please note that the higher the number, the more memory it will use. Between 1000 and 20000 seems reasonable.
If you don’t have a need for a bigger history in the log (analysis), you probably don’t need to touch that number.
Note that his number does not affect what is displayed in Web Companion (unless you put a very small history), so again, a higher number is more for very specific needs.

Also, @D3FenD3r , I tried another way in the log daemon. Tell me if it works.

PLEASE, NOTE THAT LOGGING PREFERENCES WILL BE RESET WITH THIS VERSION.
So reenable logging if you are using it:
aegis log -enable

 

[HELLO_wORLD]

@D3FenD3r I suppose the log daemon is working for you?

 

[D3FenD3r]

open now and the log is updated

 

[D3FenD3r]

it's 11.30 but the log stops at 3.17 tonight

 

[HELLO_wORLD]

it's 11.30 but the log stops at 3.17 tonight

View attachment 28898

3:17
I think it is something else related to your cron.
What is your status? And what is your cron command?

 

[D3FenD3r]

now I install a minipc connected to the router so that you can access with vnc, so you can do all the tests you want

 

[HELLO_wORLD]

now I install a minipc connected to the router so that you can access with vnc, so you can do all the tests you want

Thank you @D3FenD3r ! It is one way to make things easy

 

[D3FenD3r]

the log is stopped at 12.04 while the pc is 13.12

 

[HELLO_wORLD]

the log is stopped at 12.04 while the pc is 13.12

I reverted wc to how it was in 1.4.9 (before you experienced this problem) and upgraded your aegis with new code. We will see.

If it is good this evening, then I will release 1.5.4 to public.

 

[HELLO_wORLD]

Ok folks.

Made some progress. Realized that /usr/bin/wc was behaving strangely (putting some spaces before result), so even with cut, it would not work properly.
So I did a version with awk '{print $1}' that seems to work (at least not crashing on @D3FenD3r ’ R9000), but after a while, it did stop transferring the log (but daemon running).

So I am trying with cat $file|wc -l and we will see.
I also implemented a debug output feature for the daemon, and @D3FenD3r : for you, it is saved in /mnt/sdc1/aegis_logd_debug
Depending on results (and needs), I will be able to enrich the debug output to pinpoint what is not working (if needed).

Will wait some more, and if later tonight or tomorrow morning all is ok, then I will release.

@D3FenD3r : thank you again for this setup allowing me to test on R9000.

 

[HELLO_wORLD]

1.5.4

Optimizations, code cleaning and potential bug fixing (bug that never occurred but could in rare conditions)

Fixed partially @D3FenD3r problem (daemon crashing wc problem). However, it is not fully solved as the log daemon quits after a while (another problem) when his iptables are changed. the daemon checks regularly if the logging rules are in iptables and quits if they are not there. I made a lock when aegis changes rules, but it is not enough as something else is changing the rules here.
I need to catch the iptables lock itself as well.

Will be for next release, in 2021.

 

[D3FenD3r]

I take this opportunity to wish everyone a happy new year


sorry but google translate ..... english 0

 

[HELLO_wORLD]

Some news:
A lot of progress has been made, and some improvements, more optimizations and new options (mostly ability to refresh directives only from custom lists to not download all the time from sources when you change your custom list.

That will be released in the coming days.

 

[HELLO_wORLD]

Ok, I think I fixed the problem @D3FenD3r encountered (beside the script crashing that was already solved). For some reason, the log-message file sometimes is not rotated in a long time (same inode), and the while awk process that extracts aegis data from it stalls after 30 minutes (no crash though and it can resume by itself). Maybe a cache thing (although fflush() seems to work fine).
Anyway, now I restart the loop at either inode changing (like it was) or every 10 minutes (this should fix the issue).

So I am waiting until tomorrow to check all works fine at @D3FenD3r and then I will release 1.5.5

 

[HELLO_wORLD]

1.5.5

Aegis Core:

• renamed internal directive files to be consistent with terminology,
• added a debug ability to the log daemon,
• log daemon now does not stall if the log-message inode is not changing for a long time,
• optimizations,
• unset will now remove directive files,
• the parsing of lists (from sources or custom) is improved. Now comments on the same line are working # or ;
• a new cache was created for lists from sources. This allow to refresh offline if needed/wanted with a new option for refresh: aegis refresh -custom-only will now only refresh the directives from the custom lists and not update the ones from remote urls in the sources.

Web Companion:

• updated to reflect changes in the core (status showing latest refresh of offline cache from sources, and in commands ability to refresh only custom directives).

BECAUSE OF CHANGE OF NAME FOR INTERNAL DIRECTIVES, PLEASE UPGRADE THIS WAY:

mv /opt/bolemo/etc/aegis-bl.netset /opt/bolemo/etc/aegis.bl.directives
mv /opt/bolemo/etc/aegis-wl.netset /opt/bolemo/etc/aegis.wl.directives
aegis down; aegis upgrade; aegis up

If you don’t, not a big deal, status will show warnings until next refresh, and two useless files will be sitting in the bolemo/etc directory. Can be removed easily afterwards:

rm -f /opt/bolemo/etc/aegis-bl.netset
rm -f /opt/bolemo/etc/aegis-wl.netset

 

[D3FenD3r]

in the log is it possible to have custom blacklist in a different color than blacklist source?
so as to see the ip blocked by me with respect to the lists

if it's an easy thing

 

[HELLO_wORLD]

in the log is it possible to have custom blacklist in a different color than blacklist source?
so as to see the ip blocked by me with respect to the lists

if it's an easy thing

This is a very good idea. Unfortunately not that simple to implement...
I thought about that (and more exactly having a feedback to know exactly which list or source is blocking what), and there are two approaches, none are simple:
1) get the data upstream, at the iptables level, creating a logging rule for each list. Easy to set up, less to maintain and check. That means creating as many rules as lists, so that would impact performance and simplicity of the design.

2) analyse the data downstream. This would require a lot of process (process all lists for each ip), so again performance issue... The only way that could work is when clicking on one ip in the log to know in which list it is. An idea for a future functionality.

 

[HELLO_wORLD]

1.5.6

Optimization of log daemon and minor other optimizations.

In the way of enabling orbi support: changed all wget instances to ignore ssl certificates (as it appears to be a problem with orbi wget and GitHub certificate).

 

[HELLO_wORLD]

1.5.7

Corrected a potential silent bug.
More tweaks to prepare for Orbi.