RE: [ossec-list] MSSQL support?
MSSQL helpfully logs useful information to the Application event log in Windows, so in a way, OSSEC already supports MSSQL. You can customize various out-of-the-box OSSEC rules to generate email alerts on things such as logon failures, backup success/failure, or job failures (for jobs to write to the event log, you need to make sure the "Write to the Windows Application event log" option is checked under the Notifications tab of your job configuration). If you're talking about text log files in the MSSQL installation directory, then you're talking about custom decoders. I'd also be interested in decoders for these, if anyone has tackled the project. Unfortunately, compared to other things on my plate, this hasn't risen to the level of importance for me to devote resources to it yet. From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of DGeebs Sent: Tuesday, May 14, 2013 9:19 AM To: ossec-list@googlegroups.com Subject: [ossec-list] MSSQL support? I know Ossec's page says that MSSQL support was coming soon, but its been a while since they have said this and I was wondering if anyone was already ahead of the curve and had made some decoders and/or rules already. Anything to get a head start would be nice, don't want to reinvent the wheel if I don't have to! Thanks! -- --- 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] Re: ar.conf not updated on agents
i think i fixed it. on ossec hids server the owner was root. changed it to ossec and worked On Wednesday, May 22, 2013 12:10:17 PM UTC-8, cristian wrote: > > HI , > > > > I have a problem with active response on ossec hids 2.7 stable release > > > > [root@ossec1 etc]# /var/ossec/bin/manage_agents -V > > > > OSSEC HIDS v2.7 - Trend Micro Inc. > > > > > > [root@ossec1 etc]# /var/ossec/bin/agent_control -L > > > > OSSEC HIDS agent_control. Available active responses: > > > >No active response available. > > > > > > > > > > I had all working until i upgraded from 2.6 to 2.7 > > > > active response stoped working on agents. > > > > > > 2012/11/23 17:43:45 ossec-execd(1312): ERROR: Error executing > '/var/ossec/active-response/bin/': Permission denied > > 2012/11/23 17:45:55 ossec-execd(1312): ERROR: Error executing > '/var/ossec/active-response/bin/': Permission denied > > > > so i fixed the permission issue , then > > > > 2013/05/16 15:16:11 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop60' provided. > > 2013/05/16 15:16:41 ossec-execd(1311): ERROR: Invalid command name > 'host-deny60' provided. > > 2013/05/16 15:16:41 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop60' provided. > > 2013/05/16 15:17:11 ossec-execd(1311): ERROR: Invalid command name > 'host-deny60' provided. > > 2013/05/16 15:17:11 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop60' provided. > > > > > > > > > > > > initial problem was that ar.conf on agent was empty so i had to copy the > content of ar.conf from ossec server to ar.conf on agent. > > > > that fixed the problem with ossec on agent and it was blocking the > intruders while doing tests. > > > > Fri May 17 20:16:52 EDT 2013 > /var/ossec/active-response/bin/firewall-drop.sh add - 38.64.1x.xx > 1368836216.1016824 6210 > > > > > > Fri May 17 20:27:22 EDT 2013 > /var/ossec/active-response/bin/firewall-drop.sh delete - 38.64.1x.xx > 1368836216.1016824 6210 > > > > > > i also had to clear the content of /var/ossec/etc/shared/merged.mg on the > agent > > > > cat /dev/null > /var/ossec/etc/shared/merged.mg > > > > permissions for this 2 file on agent : > > > > just for test i did > > chmod 777 ar.conf > > chmod 777 merged.mg > > > > > > -rwxrwx--- 1 root ossec 70186 May 15 13:53 merged.mg > > -rwxrwxrwx 1 root root151 May 17 17:54 ar.conf > > > > > > and iv try with the following permissions also. > > > > -rwxrwxrwx 1 ossec ossec 151 May 17 17:54 ar.conf > > > > -rwxrwx--- 1 ossec ossec 70186 May 15 13:53 merged.mg > > > > > > > > > > > > > > at this stage everything works fine , but when i make changes to > ossec.conf on server the issues re-appears > > > > if i change the timeout value in > > > > host-deny > > local > > 6 > > 63 > > > > > > the content of ar.conf changes on the server > > > > [root@ossec1 etc]# more /var/ossec/etc/shared/ar.conf > > restart-ossec0 - restart-ossec.sh - 0 > > restart-ossec0 - restart-ossec.cmd - 0 > > host-deny63 - host-deny.sh - 63 > > firewall-drop603 - firewall-drop.sh - 603 > > > > i restarted ossec server > > > > ar.conf on agent still shows > > > > more /var/ossec/etc/shared/ar.conf > > restart-ossec0 - restart-ossec.sh - 0 > > restart-ossec0 - restart-ossec.cmd - 0 > > host-deny60 - host-deny.sh - 60 > > firewall-drop600 - firewall-drop.sh - 600 > > > > so im restarting the agent just to make sure > > > > > > [root@h22 shared]# /etc/init.d/ossec restart > > Stopping OSSEC:[ OK ] > > Starting OSSEC:[ OK ] > > [root@h22 shared]# more /var/ossec/etc/shared/ar.conf > > restart-ossec0 - restart-ossec.sh - 0 > > restart-ossec0 - restart-ossec.cmd - 0 > > host-deny60 - host-deny.sh - 60 > > firewall-drop600 - firewall-drop.sh - 600 > > > > the ar.conf is not changed > > > > and will trow the following errors on the agent > > > > [root@h22 shared]# tail -f /var/ossec/logs/ossec.log > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'host-deny63' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop603' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'host-deny63' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop603' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'host-deny63' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop603' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'host-deny63' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop603' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name >
[ossec-list] Re: ar.conf not updated on agents
while running ossec server in debug 2 2013/05/23 19:11:58 ossec-remoted: INFO: Started (pid: 8938). 2013/05/23 19:11:58 ossec-remoted: Error accessing file '/etc/shared/ar.conf' 2013/05/23 19:11:58 ossec-remoted(4111): INFO: Maximum number of agents allowed: '256'. 2013/05/23 19:11:58 ossec-remoted(1410): INFO: Reading authentication keys file. is it normal to look for ar.conf in /etc/shared/ ?? On Wednesday, May 22, 2013 12:10:17 PM UTC-8, cristian wrote: > > HI , > > > > I have a problem with active response on ossec hids 2.7 stable release > > > > [root@ossec1 etc]# /var/ossec/bin/manage_agents -V > > > > OSSEC HIDS v2.7 - Trend Micro Inc. > > > > > > [root@ossec1 etc]# /var/ossec/bin/agent_control -L > > > > OSSEC HIDS agent_control. Available active responses: > > > >No active response available. > > > > > > > > > > I had all working until i upgraded from 2.6 to 2.7 > > > > active response stoped working on agents. > > > > > > 2012/11/23 17:43:45 ossec-execd(1312): ERROR: Error executing > '/var/ossec/active-response/bin/': Permission denied > > 2012/11/23 17:45:55 ossec-execd(1312): ERROR: Error executing > '/var/ossec/active-response/bin/': Permission denied > > > > so i fixed the permission issue , then > > > > 2013/05/16 15:16:11 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop60' provided. > > 2013/05/16 15:16:41 ossec-execd(1311): ERROR: Invalid command name > 'host-deny60' provided. > > 2013/05/16 15:16:41 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop60' provided. > > 2013/05/16 15:17:11 ossec-execd(1311): ERROR: Invalid command name > 'host-deny60' provided. > > 2013/05/16 15:17:11 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop60' provided. > > > > > > > > > > > > initial problem was that ar.conf on agent was empty so i had to copy the > content of ar.conf from ossec server to ar.conf on agent. > > > > that fixed the problem with ossec on agent and it was blocking the > intruders while doing tests. > > > > Fri May 17 20:16:52 EDT 2013 > /var/ossec/active-response/bin/firewall-drop.sh add - 38.64.1x.xx > 1368836216.1016824 6210 > > > > > > Fri May 17 20:27:22 EDT 2013 > /var/ossec/active-response/bin/firewall-drop.sh delete - 38.64.1x.xx > 1368836216.1016824 6210 > > > > > > i also had to clear the content of /var/ossec/etc/shared/merged.mg on the > agent > > > > cat /dev/null > /var/ossec/etc/shared/merged.mg > > > > permissions for this 2 file on agent : > > > > just for test i did > > chmod 777 ar.conf > > chmod 777 merged.mg > > > > > > -rwxrwx--- 1 root ossec 70186 May 15 13:53 merged.mg > > -rwxrwxrwx 1 root root151 May 17 17:54 ar.conf > > > > > > and iv try with the following permissions also. > > > > -rwxrwxrwx 1 ossec ossec 151 May 17 17:54 ar.conf > > > > -rwxrwx--- 1 ossec ossec 70186 May 15 13:53 merged.mg > > > > > > > > > > > > > > at this stage everything works fine , but when i make changes to > ossec.conf on server the issues re-appears > > > > if i change the timeout value in > > > > host-deny > > local > > 6 > > 63 > > > > > > the content of ar.conf changes on the server > > > > [root@ossec1 etc]# more /var/ossec/etc/shared/ar.conf > > restart-ossec0 - restart-ossec.sh - 0 > > restart-ossec0 - restart-ossec.cmd - 0 > > host-deny63 - host-deny.sh - 63 > > firewall-drop603 - firewall-drop.sh - 603 > > > > i restarted ossec server > > > > ar.conf on agent still shows > > > > more /var/ossec/etc/shared/ar.conf > > restart-ossec0 - restart-ossec.sh - 0 > > restart-ossec0 - restart-ossec.cmd - 0 > > host-deny60 - host-deny.sh - 60 > > firewall-drop600 - firewall-drop.sh - 600 > > > > so im restarting the agent just to make sure > > > > > > [root@h22 shared]# /etc/init.d/ossec restart > > Stopping OSSEC:[ OK ] > > Starting OSSEC:[ OK ] > > [root@h22 shared]# more /var/ossec/etc/shared/ar.conf > > restart-ossec0 - restart-ossec.sh - 0 > > restart-ossec0 - restart-ossec.cmd - 0 > > host-deny60 - host-deny.sh - 60 > > firewall-drop600 - firewall-drop.sh - 600 > > > > the ar.conf is not changed > > > > and will trow the following errors on the agent > > > > [root@h22 shared]# tail -f /var/ossec/logs/ossec.log > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'host-deny63' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop603' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'host-deny63' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'firewall-drop603' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name > 'host-deny63' provided. > > 2013/05/21 15:10:52 ossec-execd(1311): ERROR: Invalid command name
[ossec-list] Re: ossec-csyslogd dies on status query
Sethu, Good catch! I tried your debug code and found that on 64-bit CentOS, the sizes are the same so the issue did not appear during earlier tests. sizeof(struct stat) is 144 sizeof(struct stat64) is 144 However, on 32-bit Ubuntu, the sizes are different. It would explain the resulting memory corruption and therefore crash. sizeof(struct stat) is 88 sizeof(struct stat64) is 96 After applying your fix, the sizes for 'stat' and 'stat64' are the same on 32-bit Ubuntu. sizeof(struct stat) is 96 sizeof(struct stat64) is 96 This fix has been integrated to https://bitbucket.org/jbcheng/ossec-hids/commits/all and will appear in the upcoming 2.7.1 release. Thank you very much! On Thursday, May 23, 2013 5:31:30 AM UTC-7, Sethu Madhav Bhattiprolu wrote: > > Hi, > > I ran the csyslogd through valgrind and and found that the problem is that > fstat64 requires stat64 struct but calloc on csyslogd.c:48 is allocating > stat. fstat64 is corrupting the heap. > > > ==13788== Syscall param fstat64(buf) points to unaddressable byte(s) > ==13788==at 0x2545D3: __fxstat64@@GLIBC_2.2 (in /lib/libc-2.5.so) > ==13788==by 0x806189B: *fstat64* (in /root/ossec-csyslogd) > ==13788==by 0x805716C: *Handle_Queue* (file-queue.c:121) > ==13788==by 0x8057294: *Init_FileQueue* (file-queue.c:165) > ==13788==by 0x804A417: OS_CSyslogD (csyslogd.c:49) > ==13788==by 0x804AD96: main (main.c:188) > ==13788== Address 0x40370fc is 0 bytes after a block of size 372 alloc'd > ==13788==at 0x4004C42: calloc (vg_replace_malloc.c:418) > ==13788==by 0x804A3A1: OS_CSyslogD (csyslogd.c:48) > ==13788==by 0x804AD96: main (main.c:188) > > > I attaching two patch files . fstat-debug.patch is how i debugged this > issue . csyslogd-crash-fix.patch has the actual fix. > > Hope this helps > > Sethu > > > On Friday, 17 May 2013 21:19:38 UTC-4, Jb Cheng wrote: >> >> csyslogd crashed when trying to read alerts.log file, at the line >> starting with '** Alert'. >> For example, >> ** Alert 1368839704.12015: - pam,syslog,authentication_success, >> >> It was trying to allocate memory for the alertid (e.g., 1368839704.12015) >> but failed to do so. >> >> If you can identify the alerts.log file lines when this happened, it may >> be useful. >> Also, which XML tag was causing it? >> >> >> On Saturday, May 11, 2013 8:32:55 AM UTC-7, Xme wrote: >>> >>> Hi Jb, >>> >>> FYI, I'm working on a patch for OSSEC and it makes my csyslogd crashing >>> too! >>> It coredumps here: >>> >>> (gdb) bt >>> #0 0x0025af40 in ?? () from /lib/tls/i686/cmov/libc.so.6 >>> #1 0x0025cd4c in malloc () from /lib/tls/i686/cmov/libc.so.6 >>> #2 0x0805a5e8 in GetAlertData (flag=0, fp=0x80791d0) at read-alert.c:246 >>> #3 0x08058843 in Read_FileMon (fileq=0x807ddd8, p=0x3486a0, timeout=5) >>> at file-queue.c:225 >>> #4 0x0804abab in OS_CSyslogD (syslog_config=0x807dfb0) at csyslogd.c:91 >>> #5 0x0804b4f7 in main (argc=3, argv=0xb854) at main.c:185 >>> >>> My patch uses a new XML directive in ossec.conf (global). When I disable >>> the new XML tag, csyslogd works like a charm >>> (version 2.7) >>> >>> Note: Branch is 2.7 stable and csyslogd code was NOT patched! >>> >>> On Thursday, April 18, 2013 2:28:40 AM UTC+2, Jb Cheng wrote: Dominique, Could you try 2.7.1 Alpha build from http://www.ossec.net/?page_id=19 and see it the issue is still there? On Tuesday, April 9, 2013 12:00:23 PM UTC-7, Dominique Derrier wrote: > > Hi all, > On a fresh Install I've got : > > ./ossec-csyslogd -D /var/ossec -f > 2013/04/09 14:57:07 ossec-csyslogd: INFO: Started (pid: 17899). > *** glibc detected *** ./ossec-csyslogd: malloc(): memory corruption: > 0x08798990 *** > Aborted > > But no trouble with: -d flag > ./ossec-csyslogd -D /var/ossec -f -d > > Regards, > Dominique > > Le lundi 18 février 2013 08:07:45 UTC-5, Uldis Biks a écrit : >> >> Hi everyone, >> >> I`m trying to enable log forwarding from ossec server to syslog by >> enabling client-syslog option from ossec-control script. Running >> ossec-control >> start shows that ossec-csyslogd is started but after that running >> ossec-control >> status ossec-csyslogd dies. When debug is enabled everything is >> working as it should and syslog receives messages. Ossec server 2.7, OS >> RHEL5.9 i386, selinux disabled. >> Any idea anyone where could be a problem? >> >> [root@~ bin]# ./ossec-control enable client-syslog >> [root@~ bin]# ./ossec-control restart >> Killing ossec-monitord .. >> Killing ossec-logcollector .. >> Killing ossec-remoted .. >> Killing ossec-syscheckd .. >> Killing ossec-analysisd .. >> ossec-maild not running .. >> ossec-execd not running ..
[ossec-list] Re: ossec-csyslogd dies on status query
Hi, I ran the csyslogd through valgrind and and found that the problem is that fstat64 requires stat64 struct but calloc on csyslogd.c:48 is allocating stat. fstat64 is corrupting the heap. ==13788== Syscall param fstat64(buf) points to unaddressable byte(s) ==13788==at 0x2545D3: __fxstat64@@GLIBC_2.2 (in /lib/libc-2.5.so) ==13788==by 0x806189B: *fstat64* (in /root/ossec-csyslogd) ==13788==by 0x805716C: *Handle_Queue* (file-queue.c:121) ==13788==by 0x8057294: *Init_FileQueue* (file-queue.c:165) ==13788==by 0x804A417: OS_CSyslogD (csyslogd.c:49) ==13788==by 0x804AD96: main (main.c:188) ==13788== Address 0x40370fc is 0 bytes after a block of size 372 alloc'd ==13788==at 0x4004C42: calloc (vg_replace_malloc.c:418) ==13788==by 0x804A3A1: OS_CSyslogD (csyslogd.c:48) ==13788==by 0x804AD96: main (main.c:188) I attaching two patch files . fstat-debug.patch is how i debugged this issue . csyslogd-crash-fix.patch has the actual fix. Hope this helps Sethu On Friday, 17 May 2013 21:19:38 UTC-4, Jb Cheng wrote: > > csyslogd crashed when trying to read alerts.log file, at the line > starting with '** Alert'. > For example, > ** Alert 1368839704.12015: - pam,syslog,authentication_success, > > It was trying to allocate memory for the alertid (e.g., 1368839704.12015) > but failed to do so. > > If you can identify the alerts.log file lines when this happened, it may > be useful. > Also, which XML tag was causing it? > > > On Saturday, May 11, 2013 8:32:55 AM UTC-7, Xme wrote: >> >> Hi Jb, >> >> FYI, I'm working on a patch for OSSEC and it makes my csyslogd crashing >> too! >> It coredumps here: >> >> (gdb) bt >> #0 0x0025af40 in ?? () from /lib/tls/i686/cmov/libc.so.6 >> #1 0x0025cd4c in malloc () from /lib/tls/i686/cmov/libc.so.6 >> #2 0x0805a5e8 in GetAlertData (flag=0, fp=0x80791d0) at read-alert.c:246 >> #3 0x08058843 in Read_FileMon (fileq=0x807ddd8, p=0x3486a0, timeout=5) >> at file-queue.c:225 >> #4 0x0804abab in OS_CSyslogD (syslog_config=0x807dfb0) at csyslogd.c:91 >> #5 0x0804b4f7 in main (argc=3, argv=0xb854) at main.c:185 >> >> My patch uses a new XML directive in ossec.conf (global). When I disable >> the new XML tag, csyslogd works like a charm >> (version 2.7) >> >> Note: Branch is 2.7 stable and csyslogd code was NOT patched! >> >> On Thursday, April 18, 2013 2:28:40 AM UTC+2, Jb Cheng wrote: >>> >>> Dominique, >>> >>> Could you try 2.7.1 Alpha build from http://www.ossec.net/?page_id=19 and >>> see it the issue is still there? >>> >>> On Tuesday, April 9, 2013 12:00:23 PM UTC-7, Dominique Derrier wrote: Hi all, On a fresh Install I've got : ./ossec-csyslogd -D /var/ossec -f 2013/04/09 14:57:07 ossec-csyslogd: INFO: Started (pid: 17899). *** glibc detected *** ./ossec-csyslogd: malloc(): memory corruption: 0x08798990 *** Aborted But no trouble with: -d flag ./ossec-csyslogd -D /var/ossec -f -d Regards, Dominique Le lundi 18 février 2013 08:07:45 UTC-5, Uldis Biks a écrit : > > Hi everyone, > > I`m trying to enable log forwarding from ossec server to syslog by > enabling client-syslog option from ossec-control script. Running > ossec-control > start shows that ossec-csyslogd is started but after that running > ossec-control > status ossec-csyslogd dies. When debug is enabled everything is > working as it should and syslog receives messages. Ossec server 2.7, OS > RHEL5.9 i386, selinux disabled. > Any idea anyone where could be a problem? > > [root@~ bin]# ./ossec-control enable client-syslog > [root@~ bin]# ./ossec-control restart > Killing ossec-monitord .. > Killing ossec-logcollector .. > Killing ossec-remoted .. > Killing ossec-syscheckd .. > Killing ossec-analysisd .. > ossec-maild not running .. > ossec-execd not running .. > ossec-csyslogd not running .. > OSSEC HIDS v2.7 Stopped > Starting OSSEC HIDS v2.7 (by Trend Micro Inc.)... > Started ossec-csyslogd... > 2013/02/18 14:14:25 ossec-maild: INFO: E-Mail notification disabled. > Clean Exit. > Started > ossec-maild... > Started > ossec-execd... > Started > ossec-analysisd... > Started > ossec-logcollector... > Started > ossec-remoted... > Started > ossec-syscheckd... > Started > ossec-mon
[ossec-list] Re: Process old logs with OSSEC 2.7 + Splunk
Ok, it seems i can answer this now. After digging through the ossec-source it was confirmed, that ossec-logtest uses the current time as alert-time. This is absolutely correct. Having the sourcecode (thank ossec-devs), i had the chance to modify ossec-logtest to fetch the date/time from the logdata and set the alert-time to the appropriate value and feed it to splunk. Regards, Thomas -- --- 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] is ossec really monitoring my apache log files
i found it useful to run a nessus-scan (web-app profile) against one of my servers. If you reveive alerts by ossec then the log is really monitored. Regards, T. -- --- 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.
