Re: [ossec-list] Whitelist instead of blacklist
On Mon, Mar 11, 2013 at 2:16 PM, TWAD higd...@gmail.com wrote: Thank you Dan, The first issue is solved. I was not monitoring the list (blacklist) so it would not fire an alert. I am now monitoring and it does fire. The second issue: I misunderstood the key to represent the second field. My list is now correct but it does not fire. So here is my reasoning (and perhaps demonstrated lack of understanding of OSSEC). Even though I have the blacklist configured correctly, the OSSEC agent will not detect an offending IP unless said IP shows up in a log/file on the system right? In otherwords, OSSEC will need to be reading from a file that is being fed from utilities such as tcpdump, snort, or wireshark... right? aka It does not have the capability to do port detection on its own. Correct. OSSEC reads logs and creates alerts based on the logs. If you are not feeding it logs, it will not do much. Thank you again On Thursday, March 7, 2013 9:28:29 PM UTC-6, dan (ddpbsd) wrote: There are 2 separate issues that you seem to be munging together. Let's try to keep them separated a bit. On Thu, Mar 7, 2013 at 10:54 AM, TWAD hig...@gmail.com wrote: I did not get a 550... and perhaps 550 may not have been the right choice. You need to find out what rule is firing. When I set this up for myself, 550 was the one I had used in my rule: rule id=510011 level=10 if_sid550/if_sid match/var/ossec/lists/blocked.txt/match descriptionblocked.txt has been modified/description /rule And then my active response uses this rule: active-response commandmakelists/command locationserver/location rules_id510011/rules_id /active-response So find out why you aren't getting an alert for the file changing. Are you monitoring the file's location in syscheck? Is the file in the syscheck database? How often does syscheck run? In fact, I do a grep for 192.168.1.10 (an IP in the blacklist) in audit.log, messages, alert.log, and secure etc, and it does not show up, even though is is an active agent. Here is the log after immediate start-up I'm totally confused by this. You were saying you were not getting an alert based on your CDB list, right? Your rule: rule id=101004 level=10 if_sid101003/if_sid list field=srcip lookup=address_match_keylists/blacklist.txt.cdb/list descriptionDNS query on a potentially malicious domain./description /rule Your list: IP1: 192.168.1.8 IP2: 10.10.1.200 Your rule is matching on the key, the first field (eg: IP1, IP2). You have expressed interest in the value (192.168.1.8), so I believe your rule is useless as written. You also need to make sure the decoder matched in 101003 decodes the srcip correctly. You can use ossec-logtest to determine if this is the case. 2013/03/07 09:04:01 ossec-dbd: Connected to database 'wtshiddb' at '192.168.1.8'. 2013/03/07 09:04:01 ossec-execd: INFO: Started (pid: 5962). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading local decoder file. 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading loading the lists file: 'lists/blacklist.txt' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'rules_config.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pam_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'sshd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'telnetd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'syslog_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'arpwatch_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'symantec-av_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'symantec-ws_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pix_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'named_rules.xml' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5974). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'smbd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vsftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pure-ftpd_rules.xml' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5976). 2013/03/07 09:04:01 ossec-remoted: Remote syslog allowed from: '192.168.1.0/24' 2013/03/07 09:04:01 ossec-remoted: Remote syslog allowed from: '10.10.1.0/24' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5975). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'proftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ms_ftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'hordeimp_rules.xml' 2013/03/07
Re: [ossec-list] Whitelist instead of blacklist
Thank you Dan, The first issue is solved. I was not monitoring the list (blacklist) so it would not fire an alert. I am now monitoring and it does fire. The second issue: I misunderstood the key to represent the second field. My list is now correct but it does not fire. So here is my reasoning (and perhaps demonstrated lack of understanding of OSSEC). Even though I have the blacklist configured correctly, the OSSEC agent will not detect an offending IP unless said IP shows up in a log/file on the system right? In otherwords, OSSEC will need to be reading from a file that is being fed from utilities such as tcpdump, snort, or wireshark... right? aka It does not have the capability to do port detection on its own. Thank you again On Thursday, March 7, 2013 9:28:29 PM UTC-6, dan (ddpbsd) wrote: There are 2 separate issues that you seem to be munging together. Let's try to keep them separated a bit. On Thu, Mar 7, 2013 at 10:54 AM, TWAD hig...@gmail.com javascript: wrote: I did not get a 550... and perhaps 550 may not have been the right choice. You need to find out what rule is firing. When I set this up for myself, 550 was the one I had used in my rule: rule id=510011 level=10 if_sid550/if_sid match/var/ossec/lists/blocked.txt/match descriptionblocked.txt has been modified/description /rule And then my active response uses this rule: active-response commandmakelists/command locationserver/location rules_id510011/rules_id /active-response So find out why you aren't getting an alert for the file changing. Are you monitoring the file's location in syscheck? Is the file in the syscheck database? How often does syscheck run? In fact, I do a grep for 192.168.1.10 (an IP in the blacklist) in audit.log, messages, alert.log, and secure etc, and it does not show up, even though is is an active agent. Here is the log after immediate start-up I'm totally confused by this. You were saying you were not getting an alert based on your CDB list, right? Your rule: rule id=101004 level=10 if_sid101003/if_sid list field=srcip lookup=address_match_keylists/blacklist.txt.cdb/list descriptionDNS query on a potentially malicious domain./description /rule Your list: IP1: 192.168.1.8 IP2: 10.10.1.200 Your rule is matching on the key, the first field (eg: IP1, IP2). You have expressed interest in the value (192.168.1.8), so I believe your rule is useless as written. You also need to make sure the decoder matched in 101003 decodes the srcip correctly. You can use ossec-logtest to determine if this is the case. 2013/03/07 09:04:01 ossec-dbd: Connected to database 'wtshiddb' at '192.168.1.8'. 2013/03/07 09:04:01 ossec-execd: INFO: Started (pid: 5962). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading local decoder file. 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading loading the lists file: 'lists/blacklist.txt' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'rules_config.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pam_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'sshd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'telnetd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'syslog_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'arpwatch_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'symantec-av_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'symantec-ws_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pix_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'named_rules.xml' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5974). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'smbd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vsftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pure-ftpd_rules.xml' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5976). 2013/03/07 09:04:01 ossec-remoted: Remote syslog allowed from: '192.168.1.0/24' 2013/03/07 09:04:01 ossec-remoted: Remote syslog allowed from: '10.10.1.0/24' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5975). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'proftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ms_ftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'hordeimp_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'roundcube_rules.xml'
Re: [ossec-list] Whitelist instead of blacklist
I did not get a 550... and perhaps 550 may not have been the right choice. In fact, I do a grep for 192.168.1.10 (an IP in the blacklist) in audit.log, messages, alert.log, and secure etc, and it does not show up, even though is is an active agent. Here is the log after immediate start-up *2013/03/07 09:04:01 ossec-dbd: Connected to database 'wtshiddb' at '192.168.1.8'. 2013/03/07 09:04:01 ossec-execd: INFO: Started (pid: 5962). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading local decoder file. 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading loading the lists file: 'lists/blacklist.txt' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'rules_config.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pam_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'sshd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'telnetd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'syslog_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'arpwatch_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'symantec-av_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'symantec-ws_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pix_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'named_rules.xml' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5974). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'smbd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vsftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pure-ftpd_rules.xml' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5976). 2013/03/07 09:04:01 ossec-remoted: Remote syslog allowed from: '192.168.1.0/24' 2013/03/07 09:04:01 ossec-remoted: Remote syslog allowed from: '10.10.1.0/24' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5975). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'proftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ms_ftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'hordeimp_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'roundcube_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'wordpress_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'cimserver_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vpopmail_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vmpop3d_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'courier_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'web_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'web_appsec_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'apache_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'nginx_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'php_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'mysql_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'postgresql_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ids_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'squid_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'firewall_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'cisco-ios_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'netscreenfw_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'sonicwall_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'postfix_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'sendmail_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'imapd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'mailscanner_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'dovecot_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ms-exchange_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'racoon_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vpn_concentrator_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'spamd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'msauth_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'mcafee_av_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'trend-osce_rules.xml'
Re: [ossec-list] Whitelist instead of blacklist
There are 2 separate issues that you seem to be munging together. Let's try to keep them separated a bit. On Thu, Mar 7, 2013 at 10:54 AM, TWAD higd...@gmail.com wrote: I did not get a 550... and perhaps 550 may not have been the right choice. You need to find out what rule is firing. When I set this up for myself, 550 was the one I had used in my rule: rule id=510011 level=10 if_sid550/if_sid match/var/ossec/lists/blocked.txt/match descriptionblocked.txt has been modified/description /rule And then my active response uses this rule: active-response commandmakelists/command locationserver/location rules_id510011/rules_id /active-response So find out why you aren't getting an alert for the file changing. Are you monitoring the file's location in syscheck? Is the file in the syscheck database? How often does syscheck run? In fact, I do a grep for 192.168.1.10 (an IP in the blacklist) in audit.log, messages, alert.log, and secure etc, and it does not show up, even though is is an active agent. Here is the log after immediate start-up I'm totally confused by this. You were saying you were not getting an alert based on your CDB list, right? Your rule: rule id=101004 level=10 if_sid101003/if_sid list field=srcip lookup=address_match_keylists/blacklist.txt.cdb/list descriptionDNS query on a potentially malicious domain./description /rule Your list: IP1: 192.168.1.8 IP2: 10.10.1.200 Your rule is matching on the key, the first field (eg: IP1, IP2). You have expressed interest in the value (192.168.1.8), so I believe your rule is useless as written. You also need to make sure the decoder matched in 101003 decodes the srcip correctly. You can use ossec-logtest to determine if this is the case. 2013/03/07 09:04:01 ossec-dbd: Connected to database 'wtshiddb' at '192.168.1.8'. 2013/03/07 09:04:01 ossec-execd: INFO: Started (pid: 5962). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading local decoder file. 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading loading the lists file: 'lists/blacklist.txt' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'rules_config.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pam_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'sshd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'telnetd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'syslog_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'arpwatch_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'symantec-av_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'symantec-ws_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pix_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'named_rules.xml' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5974). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'smbd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vsftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'pure-ftpd_rules.xml' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5976). 2013/03/07 09:04:01 ossec-remoted: Remote syslog allowed from: '192.168.1.0/24' 2013/03/07 09:04:01 ossec-remoted: Remote syslog allowed from: '10.10.1.0/24' 2013/03/07 09:04:01 ossec-remoted: INFO: Started (pid: 5975). 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'proftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ms_ftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'ftpd_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'hordeimp_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'roundcube_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'wordpress_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'cimserver_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vpopmail_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'vmpop3d_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'courier_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'web_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'web_appsec_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'apache_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'nginx_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'php_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'mysql_rules.xml' 2013/03/07 09:04:01 ossec-analysisd: INFO: Reading rules file: 'postgresql_rules.xml' 2013/03/07
Re: [ossec-list] Whitelist instead of blacklist
Thank you Dan. Now I have something new to learn...CDB and Makelists. Should do the trick though. Cheers On Tuesday, March 5, 2013 5:45:10 PM UTC-6, dan (ddpbsd) wrote: On Mon, Mar 4, 2013 at 4:45 PM, TWAD hig...@gmail.com javascript: wrote: Hey everybody, I have a task that I'm struggling with; could you help? Task: I need to have a blacklist capability on all of my agents ( to alert, not block) Alerts are only created by the server, not the agents. Issue 1: The blacklist contains over 700 IPs (currently) so creating a rule for each would (to me) seem taxing on the agent and server Using a cdb seems like a decent option. I had a cdb of over 100k domains at one point. Issue 2: The white list will contain over 200 IPs or 10 domains/subnets Questions: Should I use a white list instead of the blacklist? Has anybody on this list done this? What is the most practical method? Reasearch: I found an excellent example written by Anthony Kasza (anthonykasza.webs.com/docs/honeyports.pdf) but none of my agents will be running nc. I looked on this list and other great resources but do not have a good answer Thank you in advance for your time! -- --- 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+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- --- 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/groups/opt_out.
Re: [ossec-list] Whitelist instead of blacklist
Hey Dan, I took your advice and created a CDB with over 10k IPs and then I added one of my local IPs to test for an alert. However, the alert does not fire when one of my local hosts trys to connect or when I change the blacklists file. I am running tcpdump and I can see the host trying to connect, but nothing in the alert.log. The active response log is still at 0 as well. What am I doing wrong? Blacklist format for CDB: IP1: 192.168.1.8 IP2: 10.10.1.200 etc In ossec.conf I have rules ... listlists/blacklist.txt/list includelocal_rules.xml/include /rules I added this to execute ossec-makelist when the blacklist changes. I do not believe it worked because I ran it manuallyy and it showed an update was needed command namemakelists/name executablemakelists.sh/executable expect/expect /command active-response disabledno/disabled commandmakelists/command locationserver/location rules_id105001/rules_id /active-response Here is my blacklist file with the new CDB created from Makelists [root@RHEL6-4 lists]# ls -la total 712 drwxr-xr-x. 2 ossec ossec 4096 Mar 6 22:03 . dr-xr-x---. 15 root ossec 4096 Mar 6 16:49 .. -rw-r--r--. 1 ossec ossec 239574 Mar 6 22:03 blacklist.txt -rw-r--r--. 1 ossec ossec 478742 Mar 6 17:09 blacklist.txt.cdb My local_rules.xml addition for the alert rule id=101003 level=0 noalert=1 decoded_asunbound/decoded_as descriptionGrouping for unbound./description /rule rule id=101004 level=10 if_sid101003/if_sid list field=srcip lookup=address_match_key*lists/blacklist.txt.cdb */list descriptionDNS query on a potentially malicious domain./description /rule rule id=101005 level=10 if_sid550/if_sid match/var/ossec/lists/blacklist.txt/match descriptionblacklist.txt has been modified/description /rule On Tuesday, March 5, 2013 5:45:10 PM UTC-6, dan (ddpbsd) wrote: On Mon, Mar 4, 2013 at 4:45 PM, TWAD hig...@gmail.com javascript: wrote: Hey everybody, I have a task that I'm struggling with; could you help? Task: I need to have a blacklist capability on all of my agents ( to alert, not block) Alerts are only created by the server, not the agents. Issue 1: The blacklist contains over 700 IPs (currently) so creating a rule for each would (to me) seem taxing on the agent and server Using a cdb seems like a decent option. I had a cdb of over 100k domains at one point. Issue 2: The white list will contain over 200 IPs or 10 domains/subnets Questions: Should I use a white list instead of the blacklist? Has anybody on this list done this? What is the most practical method? Reasearch: I found an excellent example written by Anthony Kasza (anthonykasza.webs.com/docs/honeyports.pdf) but none of my agents will be running nc. I looked on this list and other great resources but do not have a good answer Thank you in advance for your time! -- --- 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+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- --- 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/groups/opt_out.
Re: [ossec-list] Whitelist instead of blacklist
On Mar 6, 2013 11:31 PM, TWAD higd...@gmail.com wrote: Hey Dan, I took your advice and created a CDB with over 10k IPs and then I added one of my local IPs to test for an alert. However, the alert does not fire when one of my local hosts trys to connect or when I change the blacklists file. I am running tcpdump and I can see the host trying to connect, but nothing in the alert.log. The active response log is still at 0 as well. What am I doing wrong? Please provide a log sample. Blacklist format for CDB: IP1: 192.168.1.8 IP2: 10.10.1.200 etc In ossec.conf I have rules ... listlists/blacklist.txt/list includelocal_rules.xml/include /rules I added this to execute ossec-makelist when the blacklist changes. I do not believe it worked because I ran it manuallyy and it showed an update was needed command namemakelists/name executablemakelists.sh/executable expect/expect /command active-response disabledno/disabled commandmakelists/command locationserver/location rules_id105001/rules_id /active-response Here is my blacklist file with the new CDB created from Makelists [root@RHEL6-4 lists]# ls -la total 712 drwxr-xr-x. 2 ossec ossec 4096 Mar 6 22:03 . dr-xr-x---. 15 root ossec 4096 Mar 6 16:49 .. -rw-r--r--. 1 ossec ossec 239574 Mar 6 22:03 blacklist.txt -rw-r--r--. 1 ossec ossec 478742 Mar 6 17:09 blacklist.txt.cdb My local_rules.xml addition for the alert rule id=101003 level=0 noalert=1 decoded_asunbound/decoded_as descriptionGrouping for unbound./description /rule rule id=101004 level=10 if_sid101003/if_sid list field=srcip lookup=address_match_keylists/blacklist.txt.cdb/list descriptionDNS query on a potentially malicious domain./description /rule rule id=101005 level=10 if_sid550/if_sid Did you get a 550 with the path you defined below? match/var/ossec/lists/blacklist.txt/match descriptionblacklist.txt has been modified/description /rule On Tuesday, March 5, 2013 5:45:10 PM UTC-6, dan (ddpbsd) wrote: On Mon, Mar 4, 2013 at 4:45 PM, TWAD hig...@gmail.com wrote: Hey everybody, I have a task that I'm struggling with; could you help? Task: I need to have a blacklist capability on all of my agents ( to alert, not block) Alerts are only created by the server, not the agents. Issue 1: The blacklist contains over 700 IPs (currently) so creating a rule for each would (to me) seem taxing on the agent and server Using a cdb seems like a decent option. I had a cdb of over 100k domains at one point. Issue 2: The white list will contain over 200 IPs or 10 domains/subnets Questions: Should I use a white list instead of the blacklist? Has anybody on this list done this? What is the most practical method? Reasearch: I found an excellent example written by Anthony Kasza (anthonykasza.webs.com/docs/honeyports.pdf) but none of my agents will be running nc. I looked on this list and other great resources but do not have a good answer Thank you in advance for your time! -- --- 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+...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- --- 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/groups/opt_out. -- --- 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/groups/opt_out.
Re: [ossec-list] Whitelist instead of blacklist
On Mon, Mar 4, 2013 at 4:45 PM, TWAD higd...@gmail.com wrote: Hey everybody, I have a task that I'm struggling with; could you help? Task: I need to have a blacklist capability on all of my agents ( to alert, not block) Alerts are only created by the server, not the agents. Issue 1: The blacklist contains over 700 IPs (currently) so creating a rule for each would (to me) seem taxing on the agent and server Using a cdb seems like a decent option. I had a cdb of over 100k domains at one point. Issue 2: The white list will contain over 200 IPs or 10 domains/subnets Questions: Should I use a white list instead of the blacklist? Has anybody on this list done this? What is the most practical method? Reasearch: I found an excellent example written by Anthony Kasza (anthonykasza.webs.com/docs/honeyports.pdf) but none of my agents will be running nc. I looked on this list and other great resources but do not have a good answer Thank you in advance for your time! -- --- 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/groups/opt_out. -- --- 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/groups/opt_out.
[ossec-list] Whitelist instead of blacklist
Hey everybody, I have a task that I'm struggling with; could you help? *Task*: I need to have a blacklist capability on all of my agents ( to alert, not block) *Issue 1*: The blacklist contains over 700 IPs (currently) so creating a rule for each would (to me) seem taxing on the agent and server *Issue 2*: The white list will contain over 200 IPs or 10 domains/subnets *Questions*: - Should I use a white list instead of the blacklist? - Has anybody on this list done this? - What is the most practical method? *Reasearch*: - I found an excellent example written by Anthony Kasza (* anthonykasza.webs.com/docs/honeyports.pdf)* but none of my agents will be running nc. - I looked on this list and other great resources but do not have a good answer Thank you in advance for your time! -- --- 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/groups/opt_out.
