[ossec-list] Syscheck from Win2012 not reporting
All, I just do not understand how integrity checking identifies and reports, because it does not report for me. I spent the better part of three days configuring and reconfiguring to no avail. If I change, add, or delete a file on my Win2012 host, nothing reports to the Ossec server... or should I say I do not get an alert. - Configuration: OSSEC 2.7 - Server RH 6.4 - Agent Windows Server 2012 - ossec-agent directory permissions: ossec-agent full control to subfolders and files (to eliminate any permission issues) - syscheck (syscheckregistry.db) directory shows no updates for the past 10 days - Agent shows active on the server through agent_control -lc - active response works from the agent to the server - Rule 554 (see below) does not show up in alerts.log after two days of waiting and restarting etc - I added, changed and deleted files in directories monitored under syscheck. Many changes in this directory: %WINDIR%/System32/drivers/etc - /var/ossec/queue/diff only contains my RH and Solaris agents - /var/ossec/queue/syscheck contains the following: -rwxr-. 1 ossec ossec3976 Mar 12 13:03 (Window8) 192.168.1.1->syscheck -rw-r-. 1 ossec ossec 723441 Mar 15 04:27 (Window8) 192.168.1.1->syscheck-registry ***BTW, off topic why does syscheck-registry not show up as a file?*** -rwxr-. 1 ossec ossec 644163 Mar 12 23:36 (Solaris10) 192.168.1.10->syscheck -rwxr-. 1 ossec ossec 1173984 Mar 27 22:39 syscheck -rwxr-. 1 ossec ossec3870 Mar 27 22:06 (Win2012) 192.168.1.7->syscheck -rw-r-. 1 ossec ossec 612144 Mar 15 04:26 (Win2012) 192.168.1.7->syscheck-registry So something is going into the Win2012 file but when I look in syscheck, only Unix-style directories are in there, and none of the files or directories I created in the Win2012 server. *Ossec Server configuration* ossec.conf 7200 yes no no ... /etc,/usr/bin,/usr/sbin /bin,/sbin ossec_rules.xml **<-yes I know this will get overwritten but I want to eliminate any mistakes for this test. I will move to local_rules when successful** ossec syscheck_new_entry File added to the system. syscheck, *Agent configuration* ossec.conf 72000 no %WINDIR%/win.ini %WINDIR%/system.ini C:\autoexec.bat C:\config.sys C:\boot.ini %WINDIR%/System32/CONFIG.NT %WINDIR%/System32/AUTOEXEC.NT %WINDIR%/System32/drivers/etc etcetera... Agent ossec.log 2013/03/27 22:56:42 ossec-execd: INFO: Started (pid: 3612). 2013/03/27 22:56:42 ossec-agent(1410): INFO: Reading authentication keys file. 2013/03/27 22:56:42 ossec-agent: INFO: Assigning counter for agent Win2012: '0:2291'. 2013/03/27 22:56:42 ossec-agent: INFO: Assigning sender counter: 21:5388 2013/03/27 22:56:42 ossec-agent: INFO: Trying to connect to server (192.168.1.8:1024). 2013/03/27 22:56:42 ossec-agent: INFO: Using IPv4 for: 192.168.1.8 . 2013/03/27 22:56:42 ossec-agent: Starting syscheckd thread. 2013/03/27 22:56:42 ossec-rootcheck: INFO: Started (pid: 3612). 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\batfile'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\cmdfile'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\comfile'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\exefile'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\piffile'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\AllFilesystemObjects'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Directory'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Folder'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Protocols'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Policies'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Security'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs'. 2013/03/27 22:56:42 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg'. 2013/03/27 22:
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 > > 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: > > 550 > /var/ossec/lists/blocked.txt > blocked.txt has been modified > > > And then my active response uses this rule: > > makelists > server > 510011 > > > 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: > > 101003 > lookup="address_match_key">lists/blacklist.txt.cdb > DNS query on a potentially malicious > domain. > > > 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' >
Re: [ossec-list] Whitelist instead of blacklist
3:8363'. 2013/03/07 09:04:02 ossec-remoted: INFO: Assigning sender counter: 0:2081 2013/03/07 09:04:02 ossec-monitord: INFO: Started (pid: 5985). 2013/03/07 09:04:03 ossec-dbd: INFO: Started (pid: 5955). 2013/03/07 09:04:04 ossec-analysisd: INFO: Connected to '/queue/alerts/execq' (exec queue) 2013/03/07 09:04:06 ossec-syscheckd: INFO: Started (pid: 5981). 2013/03/07 09:04:06 ossec-rootcheck: INFO: Started (pid: 5981). 2013/03/07 09:04:06 ossec-syscheckd: INFO: Monitoring directory: '/etc'. 2013/03/07 09:04:06 ossec-syscheckd: INFO: Monitoring directory: '/usr/bin'. 2013/03/07 09:04:06 ossec-syscheckd: INFO: Monitoring directory: '/usr/sbin'. 2013/03/07 09:04:06 ossec-syscheckd: INFO: Monitoring directory: '/bin'. 2013/03/07 09:04:06 ossec-syscheckd: INFO: Monitoring directory: '/sbin'. 2013/03/07 09:04:07 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/audit/audit.log'. 2013/03/07 09:04:07 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/messages'. 2013/03/07 09:04:07 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/secure'. 2013/03/07 09:04:07 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/maillog'. 2013/03/07 09:04:07 ossec-logcollector: INFO: Monitoring output of command(360): df -h 2013/03/07 09:04:07 ossec-logcollector: INFO: Monitoring full output of command(360): netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort 2013/03/07 09:04:07 ossec-logcollector: INFO: Monitoring full output of command(360): last -n 5 2013/03/07 09:04:07 ossec-logcollector: INFO: Started (pid: 5970). 2013/03/07 09:05:08 ossec-syscheckd: INFO: Starting syscheck scan (forwarding database). 2013/03/07 09:05:08 ossec-syscheckd: INFO: Starting syscheck database (pre-scan).* ** ** On Thursday, March 7, 2013 12:35:21 AM UTC-6, dan (ddpbsd) wrote: > > On Mar 6, 2013 11:31 PM, "TWAD" > 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 > > > > ... > > > > lists/blacklist.txt > > > > local_rules.xml > > > > > > > > > > > > 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 > > > > > > > >makelists > > > >makelists.sh > > > > > > > > > > > > > > > > > > > >no > > > >makelists > > > >server > > > >105001 > > > > > > > > > > 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 > > > > > > > > > > > > unbound > > > > Grouping for unbound. > > > > > > > > > > > > > > > > 101003 > > > > lookup="address_match_key">lists/blacklist.txt.cdb > > > > DNS query on a potentially malicious > domain. > > > > > > > >550 > > > > Did you get a 550 with the path you defined below? > > >/var/ossec/lists/blacklist.txt > > > >blacklist.txt has been modified > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, March 5, 2013 5:45:10 PM UTC-6, dan (ddpbsd) wrote: > >> > >> On Mon, Mar 4, 2013 at 4:45 PM, TWAD 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, > >> > no
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 ... lists/blacklist.txt local_rules.xml 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 makelists makelists.sh no makelists server 105001 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 unbound Grouping for unbound. 101003 *lists/blacklist.txt.cdb * DNS query on a potentially malicious domain. 550 /var/ossec/lists/blacklist.txt blacklist.txt has been modified On Tuesday, March 5, 2013 5:45:10 PM UTC-6, dan (ddpbsd) wrote: > On Mon, Mar 4, 2013 at 4:45 PM, TWAD > > 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.
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 > > 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.
[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.
Re: [ossec-list] Hybrid Killed Me?
Thanks Dan. Old habbit. I removed them and all is well On Tuesday, February 26, 2013 2:05:52 PM UTC-6, dan (ddpbsd) wrote: > On Wed, Feb 20, 2013 at 9:28 PM, TWAD > > wrote: > > Dan, > > I changed the permisisons for merged.mg to rwrwr and it is updating as > I > > write this. Group is ossec, owner is ossec > > I no longer run the hybrid, I have only the server installed to reduce > > troubleshooting efforts. > > > > Here is what I recently noticed and changed. Upon start-up tonight, > > ossec-remotd was not starting. I noticed an error that I did not have an > IP > > for syslog so I edited ossec.conf and noticed that I have two remote > > elements. One for syslog, and one for secure. I removed the syslog > element, > > added a port 1514 (sisnce I cannot see it through tcpdump), and allowed > IPs > > . > > > > > > > > 127.0.0.1 > > > > ^localhost.localdomain$ > > > > 10.10.1.1 > > > > 10.10.2.8 > > > > 10.10.2.100 > > > > 10.10.1.100 > > > > > > > > > > > > > > > > secure > > > > 1514 > > > > 10.10.1.100 > > > > 10.10.1.1 > > > > 10.10.2.100 > > > > 10.10.2.8 > > > > 10.10.2.10 > > > > > > > > > > > > # > > > > # secure > > > > # > > > > I know this problem has been solved, but I wanted to toss this into > the archives: The hashes at the beginning of these lines will probably > break the configuration. Commenting lines out should be done via at the end. > > > > > > > I saved the configuration and ran ossec-control restart > > > > Now I get: > > > > [root@rhelx bin]# ./ossec-control status ossec-monitord is running... > > > > ossec-logcollector is running... > > > > ossec-remoted: Process 24878 not used by ossec, removing .. > > > > ossec-remoted not running... > > > > ossec-syscheckd is running... > > > > ossec-analysisd is running... > > > > ossec-maild not running... > > > > ossec-execd is running... > > > > > > The agent still gets: > > 2013/02/20 19:54:35 ossec-agent: INFO: Started (pid: 6364). > > 2013/02/20 19:54:45 ossec-agent: WARN: Process locked. Waiting for > > permission... > > 2013/02/20 19:54:55 ossec-agent(4101): WARN: Waiting for server reply > (not > > started). Tried: '10.10.2.8'. > > 2013/02/20 19:54:57 ossec-agent: INFO: Trying to connect to server > > (10.10.2.8:1514). > > 2013/02/20 19:54:57 ossec-agent: INFO: Using IPv4 for: 10.10.2.8 . > > > > and when I grep for ossec-remoted in the ossec log, I get this: > > > > 2013/02/20 19:53:10 ossec-remoted: DEBUG: Starting ... > > > > 2013/02/20 19:53:10 ossec-remoted: INFO: Started (pid: 24876). > > > > 2013/02/20 19:53:10 ossec-remoted: DEBUG: Forking remoted: '1'. > > > > 2013/02/20 19:53:10 ossec-remoted: DEBUG: Forking remoted: '0'. > > > > 2013/02/20 19:53:10 ossec-remoted: INFO: Started (pid: 24878). > > > > 2013/02/20 19:53:10 ossec-remoted(1206): ERROR: Unable to Bind port > '1514' > > > > 2013/02/20 19:53:11 ossec-remoted: DEBUG: Running manager_init > > > > 2013/02/20 19:53:11 ossec-remoted: INFO: (unix_domain) Maximum send > buffer > > set to: '229376'. > > > > 2013/02/20 19:53:11 ossec-remoted(4111): INFO: Maximum number of agents > > > > allowed: '256'. > > > > 2013/02/20 19:53:11 ossec-remoted(1410): INFO: Reading authentication > keys > > file. > > > > 2013/02/20 19:53:11 ossec-remoted: DEBUG: OS_StartCounter. > > > > 2013/02/20 19:53:11 ossec-remoted: OS_StartCounter: keysize: 2 > > > > > > I searched for hours today looking through old posts to find an answer > and I > > noticed a guy (Eric Hansen) had the same issue, but the thread stopped > > before the solve. > > > https://groups.google.com/forum/?fromgroups#!topic/ossec-list/gDbBjD6r-DQ > > > > Thanks > > Will > > > > > > > > On Wednesday, February 20, 2013 9:10:47 AM UTC-6, dan (ddpbsd) wrote: > >> > >> On Tue, Feb 19, 2013 at 11:55 PM, TWAD wrote: > >> > Bottom line: No Clients will connect after I installed Hybrid, > >> > Uninstalled > >> > Hybrid, and Reins
Re: [ossec-list] OSSec Agent Setup on Solaris 10
Thank you btr33x. I had the same problem with my fresh install and changing
the *group* and *owner* to *root* fixed the issue.
My process if this helps:
- I downloaded and installed the dcid version
(dcid-ossec-hids-42e2cec7090c) onto my Solaris10 target
- In my excitement that it worked, I accidently installed the server
- I uninstalled all ossec files and pointers
- I reinstalled agent
- I received the same errors as you experienced
- Changed the owner/group and success
On Wednesday, February 20, 2013 2:14:19 AM UTC-6, bTr33x wrote:
> Found some more interesting information (but no explanation for it so far).
> When I trace the ossec-agentd binary, I can see a segfault happening
> (output shown only after opening log file):
>
> 10549: open64("/logs/ossec.log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 8
> 10549: llseek(8, 0, SEEK_END) = 5425
> 10549: fstat64(8, 0x08046B80) = 0
> 10549: brk(0x080F6648) = 0
> 10549: brk(0x080F8648) = 0
> 10549: fstat64(8, 0x08046AC0) = 0
> 10549: ioctl(8, TCGETA, 0x08046B54)Err#25 ENOTTY
> 10549: write(8, " 2 0 1 3 / 0 2 / 2 0 0".., 68) = 68
> 10549: close(8)= 0
> 10549: time() = 1361345738
> 10549: open("/var/run/tzsync", O_RDONLY) Err#2 ENOENT
> 10549: open("/usr/share/lib/zoneinfo/Europe/Zurich", O_RDONLY) = 8
> 10549: fstat64(8, 0x080478D0) = 0
> 10549: read(8, " T Z i f\0\0\0\0\0\0\0\0".., 675) = 675
> 10549: close(8)= 0
> 10549: open64("/logs/ossec.log", O_WRONLY|O_APPEND|O_CREAT, 0666) = 8
> 10549: llseek(8, 0, SEEK_END) = 5493
> 10549: fstat64(8, 0x08046B80) = 0
> 10549: fstat64(8, 0x08046AC0) = 0
> 10549: ioctl(8, TCGETA, 0x08046B54)Err#25 ENOTTY
> 10549: write(8, " 2 0 1 3 / 0 2 / 2 0 0".., 70) = 70
> 10549: close(8)= 0
> 10549: open64("/etc/local_internal_options.conf", O_RDONLY) Err#2 ENOENT
> 10549: open64("/etc/internal_options.conf", O_RDONLY) = 8
> 10549: fstat64(8, 0x080474F0) = 0
> 10549: fstat64(8, 0x08047430) = 0
> 10549: ioctl(8, TCGETA, 0x080474C4)Err#25 ENOTTY
> 10549: read(8, " # i n t e r n a l _ o".., 3072) = 2842
> 10549: llseek(8, 0xFA0B, SEEK_CUR) = 1317
> 10549: close(8)= 0
> 10549: open64("/etc/local_internal_options.conf", O_RDONLY) Err#2 ENOENT
> 10549: open64("/etc/internal_options.conf", O_RDONLY) = 8
> 10549: fstat64(8, 0x080474F0) = 0
> 10549: fstat64(8, 0x08047430) = 0
> 10549: ioctl(8, TCGETA, 0x080474C4)Err#25 ENOTTY
> 10549: read(8, " # i n t e r n a l _ o".., 3072) = 2842
> 10549: llseek(8, 0xFA59, SEEK_CUR) = 1395
> 10549: close(8)= 0
> 10549: open64("/etc/local_internal_options.conf", O_RDONLY) Err#2 ENOENT
> 10549: open64("/etc/internal_options.conf", O_RDONLY) = 8
> 10549: fstat64(8, 0x080474F0) = 0
> 10549: fstat64(8, 0x08047430) = 0
> 10549: ioctl(8, TCGETA, 0x080474C4)Err#25 ENOTTY
> 10549: read(8, " # i n t e r n a l _ o".., 3072) = 2842
> 10549: llseek(8, 0xFA9B, SEEK_CUR) = 1461
> 10549: close(8)= 0
> 10549: open64("/queue/ossec/.agent_info", O_WRONLY|O_CREAT|O_TRUNC, 0666)
> = 8
> 10549: fstat64(8, 0x08046E00) = 0
> 10549: fstat64(8, 0x08046D40) = 0
> 10549: ioctl(8, TCGETA, 0x08046DD4)Err#25 ENOTTY
> 10549: Incurred fault #6, FLTBOUNDS %pc = 0xFED8646C
> 10549:siginfo: SIGSEGV SEGV_MAPERR addr=0x
> 10549: Received signal #11, SIGSEGV [default]
> 10549:siginfo: SIGSEGV SEGV_MAPERR addr=0x
>
> The file queue/ossec/.agent_info is actually an empty file:
>
> # ls -la /opt/ossec/queue/ossec
> total 8
> drwxrwx--- 2 ossecossec 4 Feb 20 08:56 .
> dr-xr-x--- 7 root ossec 7 Feb 20 08:10 ..
> -rw-r--r-- 1 ossecossec 0 Feb 20 08:47 .agent_info
> srw-rw 1 ossecossec 0 Feb 20 08:56 queue
>
> I deleted the file and restarted ossec-agentd, same result and the file is
> recreated but again empty. Then I changed ownership of that file to root
> (chmod
> root:root /opt/ossec/queue/ossec/.agent_info). Interestingly enough, I
> can now successfully start ossec-agentd, no more segfault. And the server
> sees the ag
Re: [ossec-list] Hybrid Killed Me?
Dan, I changed the permisisons for merged.mg to rwrwr and it is updating as I write this. Group is ossec, owner is ossec I no longer run the hybrid, I have only the server installed to reduce troubleshooting efforts. Here is what I recently noticed and changed. Upon start-up tonight, ossec-remotd was not starting. I noticed an error that I did not have an IP for syslog so I edited ossec.conf and noticed that I have two remote elements. One for syslog, and one for secure. I removed the syslog element, added a port 1514 (sisnce I cannot see it through tcpdump), and allowed IPs . 127.0.0.1 ^localhost.localdomain$ 10.10.1.1 10.10.2.8 10.10.2.100 10.10.1.100 secure 1514 10.10.1.100 10.10.1.1 10.10.2.100 10.10.2.8 10.10.2.10 # # secure # I saved the configuration and ran ossec-control restart Now I get: [root@rhelx bin]# ./ossec-control status ossec-monitord is running... ossec-logcollector is running... *ossec-remoted: Process 24878 not used by ossec, removing ..* * * *ossec-remoted not running...* ossec-syscheckd is running... ossec-analysisd is running... ossec-maild not running... ossec-execd is running... The agent still gets: 2013/02/20 19:54:35 ossec-agent: INFO: Started (pid: 6364). 2013/02/20 19:54:45 ossec-agent: WARN: Process locked. Waiting for permission... 2013/02/20 19:54:55 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.10.2.8'. 2013/02/20 19:54:57 ossec-agent: INFO: Trying to connect to server (10.10.2.8:1514). 2013/02/20 19:54:57 ossec-agent: INFO: Using IPv4 for: 10.10.2.8 . and when I grep for ossec-remoted in the ossec log, I get this: 2013/02/20 19:53:10 ossec-remoted: DEBUG: Starting ... 2013/02/20 19:53:10 ossec-remoted: INFO: Started (pid: 24876). 2013/02/20 19:53:10 ossec-remoted: DEBUG: Forking remoted: '1'. 2013/02/20 19:53:10 ossec-remoted: DEBUG: Forking remoted: '0'. 2013/02/20 19:53:10 ossec-remoted: INFO: Started (pid: 24878). 2013/02/20 19:53:10 ossec-remoted(1206): ERROR: Unable to Bind port '1514' 2013/02/20 19:53:11 ossec-remoted: DEBUG: Running manager_init 2013/02/20 19:53:11 ossec-remoted: INFO: (unix_domain) Maximum send buffer set to: '229376'. 2013/02/20 19:53:11 ossec-remoted(4111): INFO: Maximum number of agents allowed: '256'. 2013/02/20 19:53:11 ossec-remoted(1410): INFO: Reading authentication keys file. 2013/02/20 19:53:11 ossec-remoted: DEBUG: OS_StartCounter. 2013/02/20 19:53:11 ossec-remoted: OS_StartCounter: keysize: 2 I searched for hours today looking through old posts to find an answer and I noticed a guy (Eric Hansen) had the same issue, but the thread stopped before the solve. https://groups.google.com/forum/?fromgroups#!topic/ossec-list/gDbBjD6r-DQ Thanks Will On Wednesday, February 20, 2013 9:10:47 AM UTC-6, dan (ddpbsd) wrote: > On Tue, Feb 19, 2013 at 11:55 PM, TWAD > > wrote: > > Bottom line: No Clients will connect after I installed Hybrid, > Uninstalled > > Hybrid, and Reinstalled Server. What am I doing/have I done wrong? > > > > Hybrid just installs a server installation in /var/ossec, and an agent > in /var/ossec/ossec-agent (for forwarding alerts to other OSSEC > servers). So setup should be the same. > > > Details > > > > 1. SO I had v2.7 installed as a server on RHEL 6.4 > > > > 2. I had agents on 10 hosts in the lab > > > > 3. All agents were monitored with no issues > > > > 4. I wanted an agent on the server, So I installed Hybrid > > > > 5. Then none of the agents would connect > > > > 6. Every agent log shows ossec-agent (4101): WARN: Waiting for server > reply > > (not started). Tried 10.10.2.8, trying to connect to server ( > 10.10.2.8:1514) > > > > 7. So from here I uninstalled and reinstalled over and over again keys, > > clients, and finally the server using the script below AND removing the > > /var/ossec directory > > > > 8. Today I reinstalled the server (not hybrid) and > uninstalled/reinstalled > > installed clients on two hosts. I am getting the same error no matter > what > > > > 9. I have the firewall completely disabled > > > > [root@rhelx uninstall-ossec]# iptables --list > > Chain INPUT (policy ACCEPT) > > > > target prot opt source destination > > > > > > > > Chain FORWARD (policy ACCEPT) > > > > target prot opt source destination > > > > > > > > Chain OUTPUT (policy ACCEPT) > > > > target prot opt source destination > > > > > > > > 10.The agents never connect > > > > [root@rhel
[ossec-list] Re: A standard procedure for manually starting rootcheck and syscheck
If it helps anybody: Prior to installing the agent, I did get this script
to work on the server... but it's rather useless for the agent:
#!/bin/sh
## This script finds the IP on one of my three operating systems, and then
looks for the agent ID
## To execute a manual restart of syscheck and rootcheck. I still have to
work AIX 7 into the script, but this seems to do the trick.
# Get OS name first
OS=`uname`
IO="" # store IP
case $OS in
Linux) IP=`ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d:
-f2 | awk '{ print $1}'`;;
FreeBSD|OpenBSD) IP=`ifconfig | grep -E 'inet.[0-9]' | grep -v
'127.0.0.1' | awk '{ print $2}'` ;;
SunOS) IP=`ifconfig -a | grep inet | grep -v '127.0.0.1' | awk '{
print $2} '` ;;
*) IP="Unknown";;
esac
echo "$IP"
ID=`/var/ossec/bin/agent_control -l |grep $IP | awk '{ print $2 }'| cut
-d"," -f1` echo "$ID"
/var/ossec/bin/agent_control -r -u "$ID"
# /var/ossec/bin/agent_control -i "$ID"
On Wednesday, February 13, 2013 8:13:25 AM UTC-6, TWAD wrote:
> Hey There,
>
> I find myself in a situation where all hosts in our network must execute
> syscheck and rootcheck through a manual process vs. a scheduled basis. And
> when I say manual process, I mean each administrator must have the
> capability/choice to run it at the least intrusive time of operations. We
> will still execute both on startup, but thereafter, syscheck and rootcheck
> must be executed manually. I understand this can be executed with
> agent_control –r u ; however, the administrator does not outright know
> the agent ID. Has anybody written a procedure that would accomplish this
> manual task on *nix and/or Windows?
>
>
>
> If no, do you know of a way I can write this that ensures the task is
> foolproof for the administrator?
>
>
>
> Thank you
>
--
---
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] Re: A standard procedure for manually starting rootcheck and syscheck
Thank you Jb. I asked the group the question before I had installed the agent on my Linux host, so I thought the way to mannually execute the syscheck/rootcheck processes was to execute agent_control -r -u ,. Now that I have the agent installed on the hybrid server, I see there is no agent_control command in the ossec-agent/ bin directory. With that, what is the most efficient way to run the agent syscheck/rootcheck processes on the agent? ... just restart the agent itself? On Wednesday, February 13, 2013 8:13:25 AM UTC-6, TWAD wrote: > Hey There, > > I find myself in a situation where all hosts in our network must execute > syscheck and rootcheck through a manual process vs. a scheduled basis. And > when I say manual process, I mean each administrator must have the > capability/choice to run it at the least intrusive time of operations. We > will still execute both on startup, but thereafter, syscheck and rootcheck > must be executed manually. I understand this can be executed with > agent_control –r u ; however, the administrator does not outright know > the agent ID. Has anybody written a procedure that would accomplish this > manual task on *nix and/or Windows? > > > > If no, do you know of a way I can write this that ensures the task is > foolproof for the administrator? > > > > Thank you > -- --- 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] A standard procedure for manually starting rootcheck and syscheck
Hey There, I find myself in a situation where all hosts in our network must execute syscheck and rootcheck through a manual process vs. a scheduled basis. And when I say manual process, I mean each administrator must have the capability/choice to run it at the least intrusive time of operations. We will still execute both on startup, but thereafter, syscheck and rootcheck must be executed manually. I understand this can be executed with agent_control –r u ; however, the administrator does not outright know the agent ID. Has anybody written a procedure that would accomplish this manual task on *nix and/or Windows? If no, do you know of a way I can write this that ensures the task is foolproof for the administrator? Thank you -- --- 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] Any Success with AIX 7?
I'm new to the group but did search a while for any questions on AIX 7. Has anybody had success installing on AIX 7. Thank you! TWAD
