/var/ossec/queue/diff/local/etc/sysconfig/iptables (and its twin iptables.save) are 2.5gb each. there are over 10000 ~500kb diff.134080477X state.134530098X files in each dir.

this might be related: "/sbin/service iptables save" runs every minute via cron to dump the firewall config (solely managed by ASL) to /etc/sysconfig/iptables, so the live config can be seen via webmin (which is where I prefer to look at the firewall config).

How do i flush these files? I find it hard to believe they are necessary.

Thanks for your question. Yes, your cronjob is what is causing this.

As you may know, ASL does not use /etc/sysconfig/iptables. What is happening is that you have setup a cronjob to save all your firewall rules to /etc/sysconfig/iptables, including the dynamically generated temporary blocking rules (which change, a lot, depending on how many attacks you get). As you may also know, ASL dynamically changes your firewall rules on the fly to block attackers, so what this cronjob does is save all those temporary changes, every minute, which could be a lot of new rules and is therefore creating a lot of changes to that file. By default ASL monitors the systems configuration files in /etc, and will alert and record all changes to those files, and thats why ASL is alerting on and recording changes to this file, because that file changed and it really shouldnt change (this file doesnt change with a default system, because no distribution saves running firewall rules to a file every minute, theres no need to do it). Therefore, ASL is correctly detecting, alerting on, and logging those unusual changes. This is expected behaviour. That file doesnt change through any action from ASL or the Linux distribution, its changing because of your cronjob (and ASL thinks that is pretty unusual, potentially malicious and is alerting you to this, plus recording the changes so you'll know what changed. If this had been an attacker, you'd know exactly what they did).

If you do not want to monitor the changes to that file, just follow this FAQ:

https://www.atomicorp.com/wiki/index.ph ... rive_space

Although I realize you are doing this because you want to use webmins firewall management tool, we do not recommend you stop monitoring this file in the long term. Unauthorized changes to this file will not be recorded or alerted on if you disable those. Again, I realize you are doing this because webmin requires it, but doing so will create a blind spot in your system and the inability to detect unauthorized or malicious changes to this file. I recommend you contact webmin, and ask them to instead read the firewall state from the kernel. They really shouldn't rely on a file as you cant trust its contents to tell you what the firewalls actual state is, as you have already discovered.

Its a work around because they arent checking the firewalls actual state that you have to do this, and you can certainly configure ASL to ignore this file, I'm just saying that its not ideal and I'd let webmin know it would be nice for them to use a more reliable and secure method that doesnt require you to create this blindspot (or to setup a cronjob to save your kernel state to a file).

Nevertheless, if you want to do this just follow the link above and set the file up to be ignored.

Note: We do not recommend users stop monitoring this file. ASL will not generate any changes to this file and does not use this file, so you should not see changes to this file unless someone or something has changed it. Changes to this file should be considered highly suspicious. A normal system will also not cause changes to this file, and firewall management tools should not rely on this file to determine the actual firewall state. Changes to this file may indicate that a malicious or unauthorized user or process has changed your default OS firewall rules (used by some distributions on boot).

If you are using a firewall tool that does not read the actual firewall state from the kernel, and instead relies on a file, we recommend you encourage its authors to read the firewall rules from the kernel instead, its always accurate and MUCH faster.

The cron job was setup because "service iptables restart" had to be run everytime I need to get into Webmin after an asl-firewall restart (until this bug was fixed). It had to be kept current with the active state since "service iptables restart" would reset the active state FROM the rules in /etc/sysconfig/iptables. So instead of running iptables-save manually before restarting iptables (and to allow webmin to display current firewall state quicker, since webmin DOES have an option to read from active state, no file, its just a lot slower) I had a cronjob do it.

Thanks for the detailed explanation!

Wow, I'd file a bug report with them. Reading from the kernel shouldnt take longer than a file, if thats happening they have a pretty serious bug and I'm sure they would be happy to know about it.

yeah iptables-save by default goes to stdout, its ridiculously fast. Ive had it export hundreds of thousands of lines to arrays in under .5s. Reading the same data from a file can take 8-14s depending on disk IO load.