[ossec-list] RootCheck disableing
Hey, I tried to disabled the rootcheck on one of the servers. I have added the following line to the agent.conf file - yes and after I am restarting the service I get the following output - Starting ossec-hids: 2016/04/14 06:16:27 ossec-rootcheck: Rootcheck disabled. Exiting. ossec-syscheckd: WARN: Rootcheck module disabled. and a few min later I see in the logs that the rootcheck is running again. any one have an idea why did I miss? -- --- 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.
Re: [ossec-list] windows active response logic
On Wed, Apr 13, 2016 at 2:49 PM, Rob B wrote: > Thanks, that gave me the food for thought I needed... > I will push my packages with updated .conf files for agents in an automated > "update like" fashion. > > Will test the directory that ossec agent needs to fire my package from. ( > Do you all know what I should run and look for to see the verbose > information? ie: debug mode / debug log location?) > Create an active response that prints the current directory to a file, then trigger it? > Off to testing now.. =) > > Thanks! --Rob > > On Wednesday, April 13, 2016 at 7:27:53 AM UTC-4, dan (ddpbsd) wrote: >> >> On Tue, Apr 12, 2016 at 4:52 PM, Rob B wrote: >> > Hello Folks, >> > >> > Could someone help me wrap my head around the windows active response >> > mechanism? >> > >> > If I understand correctly, the active response / bin folder on the >> > server >> > will house my .CMD file containing my windows response actions.? >> > >> >> I'm not totally sure on Windows, but I think so. >> >> > What I would like to do is have active response fire on an event such >> > as: >> > >> > 18100 >> > >> > Which would then run my .cmd file, where I want to run an executable >> > that I >> > have already packaged. >> > >> > My question here is: what is the logic to run my packaged executable >> > from >> > the .cmd file? Where do I store my packaged executable, how does it get >> > to >> >> It should be on the agent you want to run it. >> >> > the client agent to fire? Where will it fire from, so that I may have >> > the >> > correct syntax in my .cmd file? Can the package be pushed from the >> > server to >> >> That's a good question, I would assume either the ossec directory, or >> the ar/bin directory. It shouldn't be too hard to test though. >> >> > all windows agents once they refresh somehow? >> > >> >> What package? The AR configuration should be pushed, but it's up to >> you to put your executable in place. >> >> > I do understand the basics as to how to setup active response in the >> > .conf >> > file on the server ossec.conf file and where to turn it ON in the agent >> > side >> > .conf file. How can I turn ON all the agents active response from the >> > server? (Currently i only know how to manually update the file at each >> > client.) >> > >> >> It's possible the agent.conf can be used for this, but if not your >> configuration management solution should be able to handle pushing new >> ossec.confs to the agents. >> >> > Any pointers from the Gurus would be greatly appreciated. =) >> > >> > Thanks much Guys!! >> > >> > >> > Rob >> > >> > >> > >> > >> > -- >> > >> > --- >> > 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/d/optout. > > -- > > --- > 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. -- --- 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.
Re: [ossec-list] RootCheck disableing
On Thu, Apr 14, 2016 at 6:27 AM, eyal gershon wrote: > Hey, > > I tried to disabled the rootcheck on one of the servers. > I have added the following line to the agent.conf file - > > > yes > > > and after I am restarting the service I get the following output - > Starting ossec-hids: 2016/04/14 06:16:27 ossec-rootcheck: Rootcheck > disabled. Exiting. > ossec-syscheckd: WARN: Rootcheck module disabled. > > and a few min later I see in the logs that the rootcheck is running again. > any one have an idea why did I miss? > Which log messages are you seeing specifically? > -- > > --- > 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. -- --- 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.
Re: [ossec-list] RootCheck disableing
2016/04/14 06:03:17 ossec-rootcheck: INFO: Started (pid: 30101). 2016/04/14 06:06:05 ossec-rootcheck: INFO: Starting rootcheck scan. 2016/04/14 06:06:05 ossec-rootcheck: No rootcheck_files file configured. 2016/04/14 06:06:05 ossec-rootcheck: No rootcheck_trojans file configured. 2016/04/14 06:17:38 ossec-rootcheck: INFO: Ending rootcheck scan. The start of the scan is right after the restart of the ossed-hids restart from the original post On Thursday, April 14, 2016 at 2:57:36 PM UTC+3, dan (ddpbsd) wrote: > > On Thu, Apr 14, 2016 at 6:27 AM, eyal gershon > wrote: > > Hey, > > > > I tried to disabled the rootcheck on one of the servers. > > I have added the following line to the agent.conf file - > > > > > > yes > > > > > > and after I am restarting the service I get the following output - > > Starting ossec-hids: 2016/04/14 06:16:27 ossec-rootcheck: Rootcheck > > disabled. Exiting. > > ossec-syscheckd: WARN: Rootcheck module disabled. > > > > and a few min later I see in the logs that the rootcheck is running > again. > > any one have an idea why did I miss? > > > > Which log messages are you seeing specifically? > > > -- > > > > --- > > 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/d/optout. > -- --- 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.
[ossec-list] Re: Windows Agent Compilation
Thank you Victor.
We tried with both 2.8.2 as well as the 2.8.3 version. But both were throwing
error for make.
The changes were made as suggested, however there were some errors and not sure
if all the executables were created.
These are the only exe files under src\win-pkg
04/14/2016 05:30 AM 139,059 add-localfile.exe
04/14/2016 05:30 AM 376,910 manage_agents.exe
04/14/2016 05:26 AM17,920 ossec-lua.exe
04/14/2016 05:26 AM 333,565 ossec-luac.exe
04/14/2016 05:30 AM 141,048 os_win32ui.exe
04/14/2016 05:30 AM 142,606 setup-iis.exe
04/14/2016 05:30 AM 159,043 setup-syscheck.exe
7 File(s) 1,310,151 bytes
These were the error we got while make.
C:\Users\Administrator\Desktop\ossec_compile\ossec-hids-2.8.3\ossec-hids-2.8.3\s
rc\win-pkg>"C:\MinGW\bin\gcc.exe" -o "ossec-agent" -Wall -DARGV0=\"ossec-agent\
" -DCLIENT -DWIN32 -DOSSECHIDS icon.o os_regex/*.c os_net/*.c os_xml/*.c zlib-1.
2.8/*.c config/*.c shared/*.c os_execd/*.c os_crypto/blowfish/*.c os_crypto/md5/
*.c os_crypto/sha1/*.c os_crypto/md5_sha1/*.c os_crypto/shared/*.c rootcheck/*.c
*.c -I. -Iheaders/ -lwsock32
rootcheck/win-common.c: In function '__os_winreg_querykey':
rootcheck/win-common.c:212:11: warning: variable 'sub_key_name_b' set but not us
ed [-Wunused-but-set-variable]
TCHAR sub_key_name_b[MAX_KEY_LENGTH +1];
^
In file included from run_realtime.c:45:0:
headers/shared.h:181:0: warning: "os_calloc" redefined
#define os_calloc(x,y,z) ((z = calloc(x,y)))?(void)1:ErrorExit(MEM_ERROR, ARGV0
)
^
run_realtime.c:29:0: note: this is the location of the previous definition
#define os_calloc(x,y,z) (z = calloc(x,y))?(void)1:ErrorExit(MEM_ERROR, ARGV0)
^
In file included from run_realtime.c:45:0:
headers/shared.h:183:0: warning: "os_strdup" redefined
#define os_strdup(x,y) ((y = strdup(x)))?(void)1:ErrorExit(MEM_ERROR, ARGV0)
^
run_realtime.c:30:0: note: this is the location of the previous definition
#define os_strdup(x,y) (y = strdup(x))?(void)1:ErrorExit(MEM_ERROR, ARGV0)
^
C:\Users\ADMINI~1\AppData\Local\Temp\cccRUZbH.o:file_op.c:(.text+0x9e6): undefin
ed reference to `_imp__PathFindFileNameA@4'
collect2.exe: error: ld returned 1 exit status
C:\Users\Administrator\Desktop\ossec_compile\ossec-hids-2.8.3\ossec-hids-2.8.3\s
rc\win-pkg>"C:\MinGW\bin\gcc.exe" -o "ossec-rootcheck" -Wall -DARGV0=\"ossec-ro
otcheck\" -DCLIENT -DWIN32 icon.o os_regex/*.c os_net/*.c os_xml/*.c config/*.c
shared/*.c win_service.c rootcheck/*.c -Iheaders/ -I. -lwsock32
rootcheck/rootcheck-config.c: In function 'Read_Rootcheck_Config':
rootcheck/rootcheck-config.c:69:18: warning: variable 'xml_time' set but not use
d [-Wunused-but-set-variable]
const char *(xml_time[])={xml_rootcheck, "frequency", NULL};
^
rootcheck/win-common.c: In function '__os_winreg_querykey':
rootcheck/win-common.c:212:11: warning: variable 'sub_key_name_b' set but not us
ed [-Wunused-but-set-variable]
TCHAR sub_key_name_b[MAX_KEY_LENGTH +1];
^
C:\Users\ADMINI~1\AppData\Local\Temp\ccFt34en.o:file_op.c:(.text+0x9e6): undefin
ed reference to `_imp__PathFindFileNameA@4'
collect2.exe: error: ld returned 1 exit status
The lua file compilation has fixed the error at the time of creating
executable, but failing now with it not finding ossec-agent-eventchannel.exe at
line 149 in ossec-installer.nsi.
We also tried out making the package from Linux server, seems like its not able
to find out the required mingw gcc compilers on them. Checking going on.
Regards
Kumar
--
---
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.
[ossec-list] Re: Windows Agent Compilation
Thank you Victor.
We tried with both 2.8.2 as well as the 2.8.3 version. But both were throwing
error for make.
The changes were made as suggested, however there were some errors and not sure
if all the executables were created.
These are the only exe files under src\win-pkg
04/14/2016 05:30 AM 139,059 add-localfile.exe
04/14/2016 05:30 AM 376,910 manage_agents.exe
04/14/2016 05:26 AM17,920 ossec-lua.exe
04/14/2016 05:26 AM 333,565 ossec-luac.exe
04/14/2016 05:30 AM 141,048 os_win32ui.exe
04/14/2016 05:30 AM 142,606 setup-iis.exe
04/14/2016 05:30 AM 159,043 setup-syscheck.exe
7 File(s) 1,310,151 bytes
These were the error we got while make.
C:\Users\Administrator\Desktop\ossec_compile\ossec-hids-2.8.3\ossec-hids-2.8.3\s
rc\win-pkg>"C:\MinGW\bin\gcc.exe" -o "ossec-agent" -Wall -DARGV0=\"ossec-agent\
" -DCLIENT -DWIN32 -DOSSECHIDS icon.o os_regex/*.c os_net/*.c os_xml/*.c zlib-1.
2.8/*.c config/*.c shared/*.c os_execd/*.c os_crypto/blowfish/*.c os_crypto/md5/
*.c os_crypto/sha1/*.c os_crypto/md5_sha1/*.c os_crypto/shared/*.c rootcheck/*.c
*.c -I. -Iheaders/ -lwsock32
rootcheck/win-common.c: In function '__os_winreg_querykey':
rootcheck/win-common.c:212:11: warning: variable 'sub_key_name_b' set but not us
ed [-Wunused-but-set-variable]
TCHAR sub_key_name_b[MAX_KEY_LENGTH +1];
^
In file included from run_realtime.c:45:0:
headers/shared.h:181:0: warning: "os_calloc" redefined
#define os_calloc(x,y,z) ((z = calloc(x,y)))?(void)1:ErrorExit(MEM_ERROR, ARGV0
)
^
run_realtime.c:29:0: note: this is the location of the previous definition
#define os_calloc(x,y,z) (z = calloc(x,y))?(void)1:ErrorExit(MEM_ERROR, ARGV0)
^
In file included from run_realtime.c:45:0:
headers/shared.h:183:0: warning: "os_strdup" redefined
#define os_strdup(x,y) ((y = strdup(x)))?(void)1:ErrorExit(MEM_ERROR, ARGV0)
^
run_realtime.c:30:0: note: this is the location of the previous definition
#define os_strdup(x,y) (y = strdup(x))?(void)1:ErrorExit(MEM_ERROR, ARGV0)
^
C:\Users\ADMINI~1\AppData\Local\Temp\cccRUZbH.o:file_op.c:(.text+0x9e6): undefin
ed reference to `_imp__PathFindFileNameA@4'
collect2.exe: error: ld returned 1 exit status
C:\Users\Administrator\Desktop\ossec_compile\ossec-hids-2.8.3\ossec-hids-2.8.3\s
rc\win-pkg>"C:\MinGW\bin\gcc.exe" -o "ossec-rootcheck" -Wall -DARGV0=\"ossec-ro
otcheck\" -DCLIENT -DWIN32 icon.o os_regex/*.c os_net/*.c os_xml/*.c config/*.c
shared/*.c win_service.c rootcheck/*.c -Iheaders/ -I. -lwsock32
rootcheck/rootcheck-config.c: In function 'Read_Rootcheck_Config':
rootcheck/rootcheck-config.c:69:18: warning: variable 'xml_time' set but not use
d [-Wunused-but-set-variable]
const char *(xml_time[])={xml_rootcheck, "frequency", NULL};
^
rootcheck/win-common.c: In function '__os_winreg_querykey':
rootcheck/win-common.c:212:11: warning: variable 'sub_key_name_b' set but not us
ed [-Wunused-but-set-variable]
TCHAR sub_key_name_b[MAX_KEY_LENGTH +1];
^
C:\Users\ADMINI~1\AppData\Local\Temp\ccFt34en.o:file_op.c:(.text+0x9e6): undefin
ed reference to `_imp__PathFindFileNameA@4'
collect2.exe: error: ld returned 1 exit status
The lua file compilation has fixed the error at the time of creating
executable, but failing now with it not finding ossec-agent-eventchannel.exe at
line 149 in ossec-installer.nsi.
We also tried out making the package from Linux server, seems like its not able
to find out the required mingw gcc compilers on them. Checking going on.
Regards
Kumar
--
---
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.
[ossec-list] Re: Email notification for adding new users, new packages, triggering hours later
I hadn't really considered the mail server may be the problem - we naturally utilize sendmail to offload the notifications and route them through our corporate O365 exchange server. I was getting some integrity changes hours after the changes actually occurred (on boxes with realtime=yes and inotify packages installed). I also double checked my inbox, and this particular alert (for a file being re-added, i.e. a new version) only appears once in my inbox. On Wednesday, April 6, 2016 at 4:40:08 PM UTC-4, ba...@x-cart.com wrote: > > did you look to maillog of your server ? > When were actual sent notifications ? > Email may be deferred by couple of reasons: > * graylisting > * mail server overloading or even inactivvity. > > If you want fast and reliable delivery - try to setup additional > notification engine. > We choose slack, but there're couple of chat systems, that can receive > notifications by their api. > > среда, 6 апреля 2016 г., 17:33:03 UTC+4 пользователь thak написал: >> >> Any idea what the likely reason would be for this? We were installing >> some diagnostic packages yesterday afternoon, but I didn't get email >> notifications until 0430 today. >> > -- --- 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.
[ossec-list] Re: Email notification for adding new users, new packages, triggering hours later
So after some investigating it seems what's ACTUALLY happening is that the realtime notifications aren't working, and the syscheck 20 hour scan is picking up the changes. Thus, one could reasonably (I think) interpret this as delayed realtime notifications. I certainly have the realtime="yes" option set for these directories, and the inotify package installed. Anything else I'm missing? Might give the agents a restart just in case. On Thursday, April 14, 2016 at 2:21:02 PM UTC-4, thak wrote: > > I hadn't really considered the mail server may be the problem - we > naturally utilize sendmail to offload the notifications and route them > through our corporate O365 exchange server. > > I was getting some integrity changes hours after the changes actually > occurred (on boxes with realtime=yes and inotify packages installed). I > also double checked my inbox, and this particular alert (for a file being > re-added, i.e. a new version) only appears once in my inbox. > > On Wednesday, April 6, 2016 at 4:40:08 PM UTC-4, ba...@x-cart.com wrote: >> >> did you look to maillog of your server ? >> When were actual sent notifications ? >> Email may be deferred by couple of reasons: >> * graylisting >> * mail server overloading or even inactivvity. >> >> If you want fast and reliable delivery - try to setup additional >> notification engine. >> We choose slack, but there're couple of chat systems, that can receive >> notifications by their api. >> >> среда, 6 апреля 2016 г., 17:33:03 UTC+4 пользователь thak написал: >>> >>> Any idea what the likely reason would be for this? We were installing >>> some diagnostic packages yesterday afternoon, but I didn't get email >>> notifications until 0430 today. >>> >> -- --- 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.
[ossec-list] netstat part of syscheck not seeing all ports on initial read
I have been using Ossec on a couple of my servers for several years now. I recently updated one of them to Ubuntu 14.04 server edition and found that the agent running on that machine was no longer communicating with the server. I took this as an opportunity to upgrade both machines from version 2.6 to 2.8 and I am running into a new issue that I am not sure how to handle. I am getting repeated alerts about the netstat command detecting new ports open. Specifically I am getting the report shown below: > ossec: output: 'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort': > tcp0 0 0.0.0.0:110 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:139 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:143 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:25 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:445 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:465 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:587 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:993 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:995 0.0.0.0:* LISTEN > > tcp0 0 172.16.10.3:53 0.0.0.0:* LISTEN > > tcp0 0 192.168.0.49:53 0.0.0.0:* LISTEN > > tcp0 0 192.168.0.49:6470.0.0.0:* LISTEN > > tcp6 0 0 :::139 :::*LISTEN > > tcp6 0 0 ::1:783 :::* > Previous output: > ossec: output: 'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort': > tcp0 0 0.0.0.0:110 0.0.0.0:* LISTEN > > tcp0 0 0.0.0.0:139 0.0.0.0:* LISTEN > > According to my interpretation of this output, it is trying to tell me that when the initial scan was run the only ports with applications listening on them were 110 and 139. I know however this is incorrect because the system was up, active, and had all of these other processes running, nor are they routinely terminated and some of them were even actively connected to at the time, such as port 22 for SSH. This same message will repeat periodically, claiming that the same two ports were open in the previous reading and all the ports are currently open. It never seems to update or correct itself. I tried stopping ossec, going into the /var/ossec/queue directory and deleting everything (there were only two files) and restarting it. This seemed to silence this error for several hours and then it started again. I like the idea of the feature and would like to correct it rather than disable it (if that is even possible), but the repeated erroneous alerts are seriously annoying. Does anyone have a suggestion as to why this feature does not appear to be working correctly and how to fix it? -- --- 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.
