Hola Daniel, Yes, that was my first try. Problem was that the result of an iptables command was too large and the content was truncated mostly of the time. Therefore, it was triggering false positives.
Do you think of another way of perform an iptables -S check diff in real time? El miércoles, 27 de enero de 2016, 6:44:03 (UTC+1), Daniel Cid escribió: > > Yes, that would be an issue. Have you tried not sending the output to a > file and using the check_diff option on the rules itself? > > You could do: > > <localfile> > <log_format>full_command</log_format> > <command>iptables -S</command> > <alias>iptables_status</alias> > <frequency>3600</frequency> > </localfile> > > And then write a rule to alert on changes: > > <rule id="1001001" level="7"> > <if_sid>530</if_sid> > <match>ossec: output: 'iptables_status</match> > <check_diff /> > <description>Iptables changed</description> > </rule> > > See if that works. > > thanks, > > > On Monday, January 25, 2016 at 8:51:31 AM UTC-4, ZaNN wrote: >> >> Hi all, >> >> I have configured a checksum alert in real time that triggers and e-mail >> alert each time a file is being modified. This file is an output of an >> iptables command executed in all agents every hour: >> >> <localfile> >> <log_format>full_command</log_format> >> <command>iptables -S > >> /var/ossec/active-response/iptables_diff.txt</command> >> <alias>iptables_status</alias> >> <frequency>3600</frequency> >> </localfile> >> >> The problem is that lot of times false positives are received due to size >> changed *to 0 or from 0*. Not every hour definitely. >> >> Integrity checksum changed for: >> '/var/ossec/active-response/iptables_diff.txt'*Size changed from '1089' to >> '0'* >> What changed: >> 1,20d0 >> < -P INPUT DROP >> < -P FORWARD DROP >> < -P OUTPUT ACCEPT >> < -N LOGGING >> < -N OUTPUT-NOLOG >> < -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT >> < -A INPUT -p icmp -j ACCEPT >> < -A INPUT -i lo -j ACCEPT >> < -A INPUT -s 10.0.0.0/8 -p tcp -m state --state NEW -m tcp --dport 22 -j >> ACCEPT >> < -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT >> < -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT >> < -A OUTPUT -d 8.8.8.8/32 -p udp -m udp --dport 53 -m state --state NEW -j >> OUTPUT-NOLOG >> < -A OUTPUT -d 8.8.4.4/32 -p udp -m udp --dport 53 -m state --state NEW -j >> OUTPUT-NOLOG >> < -A OUTPUT -p udp -m udp --dport 123 -m state --state NEW -j OUTPUT-NOLOG >> < -A OUTPUT -d 192.168.116.0/24 -p udp -m udp --dport 1514 -m state --state >> NEW -j OUTPUT-NOLOG >> < -A OUTPUT -d 192.168.116.0/24 -p udp -m udp --dport 514 -m state --state >> NEW -j OUTPUT-NOLOG >> Old md5sum was: '0b43600d67c9fdde33912771c81927e2' >> New md5sum is : 'd41d8cd98f00b204e9800998ecf8427e' >> Old sha1sum was: 'e991b6897be54bfc0fd2ef0410fd5e50d54317b6' >> New sha1sum is : 'da39a3ee5e6b4b0d3255bfef95601890afd80709' >> >> >> Integrity checksum changed for: >> '/var/ossec/active-response/iptables_diff.txt'*Size changed from '0' to >> '1089'* >> What changed: >> 0a1,20 >> >> -P INPUT DROP >> -P FORWARD DROP >> -P OUTPUT ACCEPT >> -N LOGGING >> -N OUTPUT-NOLOG >> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT >> -A INPUT -p icmp -j ACCEPT >> -A INPUT -i lo -j ACCEPT >> >> >> >> >> >> >> I suspect that this behaviour is related to real time (inotify) and rewrite >> the file each time the command is executed ( > ). Is there any best practice >> to avoid this false >> positives? maybe a delay in real time check? >> >> Thanks in advance >> >> >> -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
