[ossec-list] Manager doesn't see agent
Hi list, I've got a thorny problem that I'm hoping will turn out to be a simple one. Our OSSEC Manager refuses to see the one agent currently connected to it. It's been connected in the past, and the manager remembers this - the agent shows as disconnected in agent_control rather than never connected - but for some reason it won't connect now. Compounding the problem is that we're using one-way agents, which don't require communication from the manager to start. So we don't get feedback in the agent logs about what the problem might be. Using Wireshark, we've determined that UDP packets from our agent host machine are reaching our OSSEC manager machine, addressed to our OSSEC port, but we can't figure out what's happening after they show up that is causing our manager to ignore them. I've checked the following: iptables (port is open), ifconfig (interface is up and running; other communication works fine over it), OSSEC agent and manager configs (agent is pointed at the right port/ IP; manager is listening on the right port), OSSEC manager logs (no errors that would indicate a bad client.keys or RIDS problem), and OSSEC agent logs (again, no errors, but it's a one-way agent). I've restarted everything a couple of times, cleared the RIDS, etc. There are no other machines currently on this subnet, so I can't test other agents. Anyone have any idea where else I can look, or what the problem might be? Thanks! -Alisha Kloc
Re: [ossec-list] Manager doesn't see agent
Are you sure that isn't how one way agents always show up? I have no idea, I don't like that option. Was the manager updated recently (maybe the one way comms setting has to be set on the manager and someone forgot to set it)? You can try: Turn off the firewall on the manager. Run the manager's ossec processes in debug mode, look for errors again. Double check to make sure logs aren't making it to the manager (you can even turn on the log all option to triple check). On Tue, Mar 27, 2012 at 4:19 PM, Alisha Kloc fallintosan...@gmail.com wrote: Hi list, I've got a thorny problem that I'm hoping will turn out to be a simple one. Our OSSEC Manager refuses to see the one agent currently connected to it. It's been connected in the past, and the manager remembers this - the agent shows as disconnected in agent_control rather than never connected - but for some reason it won't connect now. Compounding the problem is that we're using one-way agents, which don't require communication from the manager to start. So we don't get feedback in the agent logs about what the problem might be. Using Wireshark, we've determined that UDP packets from our agent host machine are reaching our OSSEC manager machine, addressed to our OSSEC port, but we can't figure out what's happening after they show up that is causing our manager to ignore them. I've checked the following: iptables (port is open), ifconfig (interface is up and running; other communication works fine over it), OSSEC agent and manager configs (agent is pointed at the right port/ IP; manager is listening on the right port), OSSEC manager logs (no errors that would indicate a bad client.keys or RIDS problem), and OSSEC agent logs (again, no errors, but it's a one-way agent). I've restarted everything a couple of times, cleared the RIDS, etc. There are no other machines currently on this subnet, so I can't test other agents. Anyone have any idea where else I can look, or what the problem might be? Thanks! -Alisha Kloc
Re: [ossec-list] Problems with ossec-maild
What's your mail configuration in the manager's ossec.conf? I wish ossec was compiled with -ggdb by default. It might make the gdb information a bit easier to follow. On Thu, Mar 22, 2012 at 1:47 PM, MDACC-Luckie luckief...@gmail.com wrote: I increased the number of agents my installation was capable of supporting, reinstalled and then copied my saved ossec.conf file and internal_options.conf into the ossec/etc directory and restarted ossec. My ossec-maild daemon starts, runs for a few seconds and then dies. I ran the following based on a previous email thread I saw and have attached the results. Please let me know if anyone has ideas on why it is happening: [root@dcprpoemprddb1 logs]# gdb /opt/ossec/bin/ossec-maild GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/ gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/ossec/bin/ossec-maild...done. (gdb) set follow-fork-mode child (gdb) run Starting program: /opt/ossec/bin/ossec-maild [New process 2615] [New process 2616] Program received signal SIGSEGV, Segmentation fault. [Switching to process 2616] 0x00387c879b60 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x00387c879b60 in strlen () from /lib64/libc.so.6 #1 0x00387c846cb9 in vfprintf () from /lib64/libc.so.6 #2 0x00387c8699da in vsnprintf () from /lib64/libc.so.6 #3 0x00387c84d5e3 in snprintf () from /lib64/libc.so.6 #4 0x00402d66 in OS_RecvMailQ (fileq=0x635640, p=0x387cb56cc0, Mail=0x7fffe870, msg_sms=0x7fffe7e0) at os_maild_client.c:96 #5 0x00402848 in OS_Run (mail=0x7fffe870) at maild.c:381 #6 0x004023d0 in main (argc=1, argv=0x7fffe9f8) at maild.c:171 (gdb)
Re: [ossec-list] Solaris ossec-dbd crashes
There was no information with the segfault? Did you try running ossec-dbd under gdb? What database are you using? Any errors in ossec.log? Any errors in the DB's log? On Fri, Mar 23, 2012 at 12:37 PM, Nico Bugash nicobug...@gmail.com wrote: I have successfully installed the ossec server on Solaris 10 with one minor problem as soon as the ossec server beings to write to the database, ossec-dbd crashes. When I restart the ossec server, all of the daemon processes runs fine: === ossec-monitord is running... ossec-logcollector is running... ossec-remoted is running... ossec-syscheckd is running... ossec-analysisd is running... ossec-maild is running... ossec-execd is running... ossec-dbd is running... == However as a test, I try to generate an alert and see if it gets logged in to the database. But as soon as it tries to write in to the database, ossec-dbd stops. Here's the steps that I took to generate the alert: 1. stop ossec server ( ossec-control stop) 2. stop the ossec agent. Stopped the agent through Windows services 3. start the ossec server (ossec-control start) 4. as soon as I see that all the daemon process are running, I start the ossec-agent again through Windows Service. However as soon as I start it, a few seconds after ossec-dbd would just stop running, but the ossec server was able to send an alert via email (this is how I now that an alert was generated) I investigated further by running ossec-dbd as a foreground process (ossec-dbd -f) and restarted the ossec agent. As expected as soon as the agent starts, ossec-dbd stops and outputs a segmentation fault (with no other verbose but a segmentation fault) Another observation that I found out is that, for some reason, ossec- dbd doesn't crash if I generate a level 9 alert, in particular Rule: 5302 because when I do a SELECT query on to the alert table, I see values being inserted. One thing to note here is that, this is the only level 9 alert that I was able to generate at the moment. If you can suggest or provide a step-by-step procedure on how generate other type of alerts as a test, it would be appreciated.
Re: [ossec-list] Database and File rules encrypted?
If an attacker has gotten privileged access to the system there should be a log somewhere detailing this. Hopefully there's a rule for that log message... What do you mean by use a directory or file not monitored to carry out the attack? You mean monitored by syscheckd? As soon as they change something of consequence there should be a syscheckd alert triggered. And there should be alerts when the OSSEC processes are stopped, so that's another reason to investigate. Whenever possible, export logs to a hardened/remote host. Installing a local OSSEC instance should be a last resort. On Thu, Mar 22, 2012 at 5:52 PM, Michel Henrique Aquino Santos michel@gmail.com wrote: If an attacker managed to enter the machine and gain privileged access, it can read the configuration files if the OSSEC installed as local. Thus, you can use a directory or file not monitored to carry out the attack, or even modify the file rules. Em 22-03-2012 18:16, Nelson, James escreveu: The vast majority of log data is not encrypted to begin with, so how do you figure it’s a vulnerability? At most, transmission between agent and master could be considered vulnerable but you can set it up to use secure transmission which would be encrypted. James From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Michel Henrique Aquino Santos Sent: Thursday, March 22, 2012 3:54 PM To: ossec-list@googlegroups.com Subject: Re: [ossec-list] Database and File rules encrypted? Thanks for the reply. This is not good because it creates a vulnerability in the system. Att. Em 22-03-2012 17:33, dan (ddp) escreveu: Neither are encrypted in OSSEC. On Thu, Mar 22, 2012 at 4:22 PM, Michel Henrique Aquino Santos michel@gmail.com wrote: Hello, I'm doing an paper on university study (Federal University of Lavras - UFLA - www.ufla.br), comparing four tools for checking integrity of files (Tripwire, OSSEC, AIDE and Samhain). I need some information about the tool OSSEC. The generated database (snapshot) is encrypted? The rules file is encrypted? Sorry my english, I can not write correctly. I await response. Thank you! -- Att, Michel Henrique Aquino Santos Bacharelado em Ciência da Computação Universidade Federal de Lavras - UFLA Skype: michel_has Gtalk: michel.has michel@gmail.com Linux User # 496756 http://resolvidoslinux.blogspot.com/ -- Att, Michel Henrique Aquino Santos Bacharelado em Ciência da Computação Universidade Federal de Lavras - UFLA Skype: michel_has Gtalk: michel.has michel@gmail.com Linux User # 496756 http://resolvidoslinux.blogspot.com/ -- Att, Michel Henrique Aquino Santos Bacharelado em Ciência da Computação Universidade Federal de Lavras - UFLA Skype: michel_has Gtalk: michel.has michel@gmail.com Linux User # 496756 http://resolvidoslinux.blogspot.com/
[ossec-list] Re: Problems with ossec-maild
Our config is pretty standard with respect to the ossec.conf. The only non-standard thing we have is that we are usiing port 9025 for SMTP on the mail server we are using rather than 25. We have that changed in the sendmail.c file that is used when everything is compiled: OSSEC.CONF global email_notificationyes/email_notification email_toos...@xx.xxx/email_to smtp_serverdcprpafszenoss2.xx.xxx/smtp_server email_fromoss...@xx.xxx/email_from email_maxperhour1000/email_maxperhour /global SENDMAIL.C /* Default values use to connect */ #define SMTP_DEFAULT_PORT 9025 #define HELOMSG Helo notify.ossec.net\r\n #define MAILFROMMail From: %s\r\n #define RCPTTO Rcpt To: %s\r\n #define DATAMSG DATA\r\n #define FROMFrom: OSSEC HIDS %s\r\n #define TO To: %s\r\n #define CC Cc: %s\r\n #define SUBJECT Subject: %s\r\n #define ENDDATA \r\n.\r\n #define QUITMSG QUIT\r\n It was working prior to the increase of the number of agents supported and the recompile. I ran a tcpdump on the manager and don't see the manager even attempting to try to connect to the SMTP host on port 9025, only using the agent/manager connection between the two boxes. On Mar 27, 3:36 pm, dan (ddp) ddp...@gmail.com wrote: What's your mail configuration in the manager's ossec.conf? I wish ossec was compiled with -ggdb by default. It might make the gdb information a bit easier to follow. On Thu, Mar 22, 2012 at 1:47 PM, MDACC-Luckie luckief...@gmail.com wrote: I increased the number of agents my installation was capable of supporting, reinstalled and then copied my saved ossec.conf file and internal_options.conf into the ossec/etc directory and restarted ossec. My ossec-maild daemon starts, runs for a few seconds and then dies. I ran the following based on a previous email thread I saw and have attached the results. Please let me know if anyone has ideas on why it is happening: [root@dcprpoemprddb1 logs]# gdb /opt/ossec/bin/ossec-maild GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/ gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/ossec/bin/ossec-maild...done. (gdb) set follow-fork-mode child (gdb) run Starting program: /opt/ossec/bin/ossec-maild [New process 2615] [New process 2616] Program received signal SIGSEGV, Segmentation fault. [Switching to process 2616] 0x00387c879b60 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x00387c879b60 in strlen () from /lib64/libc.so.6 #1 0x00387c846cb9 in vfprintf () from /lib64/libc.so.6 #2 0x00387c8699da in vsnprintf () from /lib64/libc.so.6 #3 0x00387c84d5e3 in snprintf () from /lib64/libc.so.6 #4 0x00402d66 in OS_RecvMailQ (fileq=0x635640, p=0x387cb56cc0, Mail=0x7fffe870, msg_sms=0x7fffe7e0) at os_maild_client.c:96 #5 0x00402848 in OS_Run (mail=0x7fffe870) at maild.c:381 #6 0x004023d0 in main (argc=1, argv=0x7fffe9f8) at maild.c:171 (gdb)- Hide quoted text - - Show quoted text -
Re: [ossec-list] Database and File rules encrypted?
Plus the files/filesystem would have to be decrypted to use. A privileged user would probably have access to that decrypted data. On Thu, Mar 22, 2012 at 5:58 PM, Castle, Shane scas...@bouldercounty.org wrote: If this happened then it's game over. Encrypting the files/filesystem will do no good if your system is compromised. Sorry, I don't buy it. Try again. -- Shane Castle Data Security Mgr, Boulder County IT CISSP GSEC GCIH -Original Message- From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Michel Henrique Aquino Santos Sent: Thursday, March 22, 2012 15:52 To: ossec-list@googlegroups.com Subject: Re: [ossec-list] Database and File rules encrypted? If an attacker managed to enter the machine and gain privileged access, it can read the configuration files if the OSSEC installed as local. Thus, you can use a directory or file not monitored to carry out the attack, or even modify the file rules. Em 22-03-2012 18:16, Nelson, James escreveu: The vast majority of log data is not encrypted to begin with, so how do you figure it's a vulnerability? At most, transmission between agent and master could be considered vulnerable but you can set it up to use secure transmission which would be encrypted. James From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Michel Henrique Aquino Santos Sent: Thursday, March 22, 2012 3:54 PM To: ossec-list@googlegroups.com Subject: Re: [ossec-list] Database and File rules encrypted? Thanks for the reply. This is not good because it creates a vulnerability in the system. Att. Em 22-03-2012 17:33, dan (ddp) escreveu: Neither are encrypted in OSSEC. On Thu, Mar 22, 2012 at 4:22 PM, Michel Henrique Aquino Santos michel@gmail.com mailto:michel@gmail.com wrote: Hello, I'm doing an paper on university study (Federal University of Lavras - UFLA - www.ufla.br), comparing four tools for checking integrity of files (Tripwire, OSSEC, AIDE and Samhain). I need some information about the tool OSSEC. The generated database (snapshot) is encrypted? The rules file is encrypted? Sorry my english, I can not write correctly. I await response. Thank you! -- Att, Michel Henrique Aquino Santos Bacharelado em Ciência da Computação Universidade Federal de Lavras - UFLA Skype: michel_has Gtalk: michel.has michel@gmail.com Linux User # 496756 http://resolvidoslinux.blogspot.com/ -- Att, Michel Henrique Aquino Santos Bacharelado em Ciência da Computação Universidade Federal de Lavras - UFLA Skype: michel_has Gtalk: michel.has michel@gmail.com Linux User # 496756 http://resolvidoslinux.blogspot.com/ -- Att, Michel Henrique Aquino Santos Bacharelado em Ciência da Computação Universidade Federal de Lavras - UFLA Skype: michel_has Gtalk: michel.has michel@gmail.com Linux User # 496756 http://resolvidoslinux.blogspot.com/
[ossec-list] Re: Manager doesn't see agent
One-way agents normally show as Connected like regular agents, actually. All the one-way flag does afaik is skip the section in the agent startup where it waits for a response from the manager before continuing to start; otherwise, they behave exactly like normal agents. Also, no, the manager wasn't updated recently, although we did physically move to a new location so I'm a little worried there's some kind of connection issue (although Wireshark says the packets are getting to the manager...). I've already confirmed from a few angles that we're receiving no events at all, and I think the agent would show up as Connected under agent_control before it would send events...? But I'll definitely try killing the firewall and setting debug. Thanks! -Alisha On Mar 27, 1:30 pm, dan (ddp) ddp...@gmail.com wrote: Are you sure that isn't how one way agents always show up? I have no idea, I don't like that option. Was the manager updated recently (maybe the one way comms setting has to be set on the manager and someone forgot to set it)? You can try: Turn off the firewall on the manager. Run the manager's ossec processes in debug mode, look for errors again. Double check to make sure logs aren't making it to the manager (you can even turn on the log all option to triple check).
Re: [ossec-list] Re: Manager doesn't see agent
tcpdump will pick up packets even if they're blocked by the firewall. Are the messages coming from the correct IP? Did the manager's IP change at all? You could also try deleting the agent from the manager, creating a new one, and installing that key on the agent. On Tue, Mar 27, 2012 at 4:50 PM, Alisha Kloc fallintosan...@gmail.com wrote: One-way agents normally show as Connected like regular agents, actually. All the one-way flag does afaik is skip the section in the agent startup where it waits for a response from the manager before continuing to start; otherwise, they behave exactly like normal agents. Also, no, the manager wasn't updated recently, although we did physically move to a new location so I'm a little worried there's some kind of connection issue (although Wireshark says the packets are getting to the manager...). I've already confirmed from a few angles that we're receiving no events at all, and I think the agent would show up as Connected under agent_control before it would send events...? But I'll definitely try killing the firewall and setting debug. Thanks! -Alisha On Mar 27, 1:30 pm, dan (ddp) ddp...@gmail.com wrote: Are you sure that isn't how one way agents always show up? I have no idea, I don't like that option. Was the manager updated recently (maybe the one way comms setting has to be set on the manager and someone forgot to set it)? You can try: Turn off the firewall on the manager. Run the manager's ossec processes in debug mode, look for errors again. Double check to make sure logs aren't making it to the manager (you can even turn on the log all option to triple check).
[ossec-list] Re: Problems with ossec-maild
Not long by max length standards 15 characters or so. Are there any other of those type of things I could check data corruption somewhere that I might need to look for that isnt obvious to me. I dont think it is with ossec-maild but something with the extra 60 or so agent keys I generated that might be causing some type of issue. The reason I ask is that used list_agents and saw a device name as being an agent but when I looked for it in a manage_agents listed of keys, it wasnt there. Some type of consistency check that can be run that looks for possible issues? On Mar 27, 3:58 pm, dan (ddp) ddp...@gmail.com wrote: Kind of off the wall: Do you have very long agent names? On Tue, Mar 27, 2012 at 4:46 PM, MDACC-Luckie luckief...@gmail.com wrote: Our config is pretty standard with respect to the ossec.conf. The only non-standard thing we have is that we are usiing port 9025 for SMTP on the mail server we are using rather than 25. We have that changed in the sendmail.c file that is used when everything is compiled: OSSEC.CONF global email_notificationyes/email_notification email_toos...@xx.xxx/email_to smtp_serverdcprpafszenoss2.xx.xxx/smtp_server email_fromoss...@xx.xxx/email_from email_maxperhour1000/email_maxperhour /global SENDMAIL.C /* Default values use to connect */ #define SMTP_DEFAULT_PORT 9025 #define HELOMSG Helo notify.ossec.net\r\n #define MAILFROM Mail From: %s\r\n #define RCPTTO Rcpt To: %s\r\n #define DATAMSG DATA\r\n #define FROM From: OSSEC HIDS %s\r\n #define TO To: %s\r\n #define CC Cc: %s\r\n #define SUBJECT Subject: %s\r\n #define ENDDATA \r\n.\r\n #define QUITMSG QUIT\r\n It was working prior to the increase of the number of agents supported and the recompile. I ran a tcpdump on the manager and don't see the manager even attempting to try to connect to the SMTP host on port 9025, only using the agent/manager connection between the two boxes. On Mar 27, 3:36 pm, dan (ddp) ddp...@gmail.com wrote: What's your mail configuration in the manager's ossec.conf? I wish ossec was compiled with -ggdb by default. It might make the gdb information a bit easier to follow. On Thu, Mar 22, 2012 at 1:47 PM, MDACC-Luckie luckief...@gmail.com wrote: I increased the number of agents my installation was capable of supporting, reinstalled and then copied my saved ossec.conf file and internal_options.conf into the ossec/etc directory and restarted ossec. My ossec-maild daemon starts, runs for a few seconds and then dies. I ran the following based on a previous email thread I saw and have attached the results. Please let me know if anyone has ideas on why it is happening: [root@dcprpoemprddb1 logs]# gdb /opt/ossec/bin/ossec-maild GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/ gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/ossec/bin/ossec-maild...done. (gdb) set follow-fork-mode child (gdb) run Starting program: /opt/ossec/bin/ossec-maild [New process 2615] [New process 2616] Program received signal SIGSEGV, Segmentation fault. [Switching to process 2616] 0x00387c879b60 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x00387c879b60 in strlen () from /lib64/libc.so.6 #1 0x00387c846cb9 in vfprintf () from /lib64/libc.so.6 #2 0x00387c8699da in vsnprintf () from /lib64/libc.so.6 #3 0x00387c84d5e3 in snprintf () from /lib64/libc.so.6 #4 0x00402d66 in OS_RecvMailQ (fileq=0x635640, p=0x387cb56cc0, Mail=0x7fffe870, msg_sms=0x7fffe7e0) at os_maild_client.c:96 #5 0x00402848 in OS_Run (mail=0x7fffe870) at maild.c:381 #6 0x004023d0 in main (argc=1, argv=0x7fffe9f8) at maild.c:171 (gdb)- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text -
