[ossec-list] Re: HP-UX
We've run on HP-UX for a while; it mostly behaves like any other Unix system. And it's actually pretty simple to write an init script for OSSEC to start at boot. I'd share the one we wrote but I don't have company release permission. On Sunday, September 30, 2012 8:48:24 AM UTC-7, Mike Disley wrote: > > I needed to install gcc but other than that no issues. > > > > -Original Message- > From: ossec...@googlegroups.com [mailto: > ossec...@googlegroups.com ] On Behalf Of Nelson, James > Sent: Thursday, September 27, 2012 3:27 PM > To: ossec...@googlegroups.com > Subject: [ossec-list] HP-UX > > Has anyone installed the ossec agent on an HP UX system? I'm looking for > any experiences or gotchas I should be aware of. >
[ossec-list] AIX 7 agents?
Hi list, Has anyone had a chance to install OSSEC agents on AIX 7/7.1 yet? We're investigating an upgrade to AIX 7 (from 5) and we want to know the impact on our OSSEC deployment, but it's a bit of a chicken-and-egg situation since we can't test unless we get some AIX 7 servers to play with. Any major issues, gotchas, considerations, etc, we should look out for? Thanks! -Alisha
[ossec-list] Re: Manager doesn't see agent
All right, we *finally* found the problem - not OSSEC, but a new system hardening step. The NSA security guidelines recommend setting Linux systems to validate the source IP address of received packets. With eth3 up, this validation fails because the IP stack sees packets sourced from the network on eth3 coming in on eth0, which is a violation, and the packets are dropped. So it's not that OSSEC is listening on the wrong port, local_ip option or not; it's that the IP stack is dropping the packets before they get to OSSEC. Thanks so much for all your help!
[ossec-list] Re: Manager doesn't see agent
I can't post the exact ifconfig, but it boils down to this: eth0: Up, xxx.xxx.xxx.xxx (primary IP address for communication with OSSEC agents and Active Directory; does not share a subnet with any agents; address translation handled at the router/switch level) eth1: Up, Promiscuous (no IP) eth2: Down (unused) eth3: Up, xxx.xxx.xxx.xxx (secondary IP address for security assessments; shares first two octets with OSSEC agents; route is down at the router/switch level except during assessments) The section of the manager's ossec.conf is: secure Our sysadmin has been running some other tests; he found that if he changes eth3 to a different IP address that doesn't share anything with the agents, the problem goes away and OSSEC hears from its agents. So it seems like OSSEC has decided to only listen to the interface which shares part of its IP with its agents. But we'd had this tested and working before, so why would it start to do this now?
[ossec-list] Re: Manager doesn't see agent
All right, so I tried using the local_ip option - but no luck. Netstat -uan reports that the box is listening on eth0 to the OSSEC port. However, OSSEC still didn't pick up any agent messages. I turned eth3 down, and immediately got agent messages. Turned it back up, messages stopped. So local_ip has no effect on this problem. The OSSEC Manager wants to listen to eth3 unless forced to do otherwise. I've got no idea what to try next... any suggestions?
[ossec-list] Re: Manager doesn't see agent
*Oops, I meant tags in my last message...
[ossec-list] Re: Manager doesn't see agent
Hmm, I had not actually heard of that option before. So after looking it up... it just goes in between the tags on the manager's ossec.conf? Is it even applicable to OSSEC 2.4? (Yeah... we're way behind.) Thanks! -Alisha
[ossec-list] Re: Manager doesn't see agent
Bump. Can someone explain how OSSEC decides which Linux interface to listen on? Is there a way to force it to listen to one in particular? Thanks! -Alisha
[ossec-list] Re: Manager doesn't see agent
Okay, update: We finally figured out, after completely rebuilding the machine from scratch on new hardware, that the problem is that OSSEC is listening on the wrong interface. However, it didn't previously listen on the wrong interface (several months ago, when we first built and tested this machine, and before we moved to the new room), and on a similarly-configured machine, OSSEC listens on the correct interface. The machine is configured with three interfaces, eth0, eth1, and eth3 (eth2 is reserved and not active). Eth0 is configured as the primary interface for the box, and it's the interface to which our router/ switch forwards packets addressed to the OSSEC port. Eth1 is in promiscuous mode, and eth3 is configured as a rare-use management port, with its route disabled at the switch. It happens to be on the same subnet as some of our OSSEC agents, though not all of them. Up until now, through multiple builds of this and similar machines, OSSEC has had no problem understanding that it is supposed to listen on eth0. However, on this particular machine, OSSEC tries to listen on eth3 as long as it's active. Only if we ifconfig eth3 down does OSSEC listen to eth0. We've rebuilt this machine from scratch - deleted the old partitions and overwrote the old data - and put it on new hardware, yet OSSEC continues to try to listen to the wrong interface. We've never had this happen before, on half a dozen identical builds. What mechanism does OSSEC use to determine which interface to listen on in Linux? What could have caused OSSEC to stop listening to eth0 and switch to eth3? Could the fact that eth3 exists on the same subnet as some, but not all, agents have any effect on this? Thanks! -Alisha
[ossec-list] Re: Manager doesn't see agent
Yeah, I checked everyone's IP addresses and ports; those are all fine. The manager's IP hasn't changed, either; we just had a physical room move. I tried deleting the agent off the manager and creating a new one with a new key, but the manager didn't pick up that agent either. I even tried giving the agent a bad key to see if I could at least get the manager to give that message that means it's seeing messages from an agent with the wrong key, but no luck. I'm starting to think this is some low-level network problem way beyond my depth... On Mar 27, 2:01 pm, "dan (ddp)" wrote: > 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.
[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)" 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] 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
[ossec-list] Incorrect location tagging in MySQL
Hi list, We're using OSSEC's process monitoring feature to run a heartbeat on our one-way systems, so that we can know if an agent dies without the manager needing to talk to the agent. But when we fielded the system, we started seeing some very weird behavior. Every so often, OSSEC gets an event's location data mixed up when entering the event into our MySQL database. It's only happening with two servers, 4 and 6. Server 4 is HP-UX, while Server 6 is Windows 2003. We noticed this when we realized that Server 6 was reporting messages from the HP-UX command line, while Server 4 was reporting output from DOS. In other words, an event from Server 4 is being tagged with Server 6's location data in MySQL, and vice versa. Here's the "full_log" and "message" fields for some of the mixed-up events, as pulled from MySQL: Oct 21 18:13:35 svr4 ossec-hb: Heartbeat: 181335ossec 2353 1 0 Oct 4 ? 0:23 /var/ossec/bin/ossec-agentd | (svr6) 192.168.1.74->"C\Program Filesossec-agentwin32_heartbeat.bat" ossec: output: `"C//Program Files/ossec-agent/win32_heartbeat.bat"`: Fri 10/21/2011 15:54 PM ossec-win-hb: Heartbeat: ossec-agent.exe 1944 0 4,808 K | (svr4) 192.168.1.54->/var/adm/syslog/syslog.log Oct 21 11:58:59 svr4 ossec-hb: Heartbeat: 115859ossec 2353 1 0 Oct 4 ? 0:22 /var/ossec/bin/ossec-agentd | (svr6) 192.168.1.74->"C\Program Filesossec-agentwin32_heartbeat.bat" Oct 21 03:01:01 svr4 ossec-hb: Heartbeat: 030101ossec 2353 1 0 Oct 4 ? 0:22 /var/ossec/bin/ossec-agentd | (svr6) 192.168.1.74->"C\Program Filesossec-agentwin32_heartbeat.bat" It happens infrequently and isn't reciprocal - we may see one Server 4 event tagged with Server 6 location data on Monday, none on Tuesday, three on Wednesday, and then the reverse on Thursday. We don't know yet if it's doing this with any other events than the heartbeats; we spotted these while tracking down an unrelated issue. What could possibly be causing OSSEC to confuse its location data like that? Thanks in advance! -Alisha Kloc
[ossec-list] Re: Build 2.6 agent on HP-UX fails
All right, I'll make sure to include that.
Out of curiosity, can you explain exactly what this new code is doing?
Is it the same thing that would be added if the official build
included a switch to turn off IPv6?
The reason I ask is, even if I test this code and it works, we
wouldn't be able to use it to build our agents. We're only allowed to
use officially released software - a dot build like 2.4 or 2.5.1.
Doing anything else counts as modifying the source code, which we're
not allowed to do. So I need to make sure the time I spend testing
will move toward a released 2.X build that includes the fix -
otherwise I can't justify the time to my boss. :)
On Sep 6, 6:00 pm, "dan (ddp)" wrote:
> Oops, I forgot a step. You have to make sure to add -DOS_NOINET6=\"1\"
> to the CFLAGS in the Config.Make file before running install.sh
> Mine looks like this on that system:
> CFLAGS = -g -Wall -I${PT} -I${PT}headers ${CPATH} ${CEXTRA} ${DEXTRA}
> ${EEXTRA} ${FEXTRA} ${GEXTRA} ${HEXTRA} -DARGV0=\"${NAME}\"
> -DXML_VAR=\"var\" -DOSSECHIDS -DOS_NOINET6=\"1\"
>
>
>
>
>
>
>
> On Tue, Sep 6, 2011 at 5:47 PM, Alisha Kloc wrote:
> > Okay, thanks!
>
> > It'll be a few days, at least, before I have access to our HP-UX
> > systems to try these - we're in the middle of a testing cycle right
> > now. But once I can I'll let you know what happens.
>
> > On Sep 6, 2:11 pm, dan wrote:
> >> Like I said, I haven't tested these (beyond compiling them on a system
> >> WITH ipv6). They may not work at all
>
> >> These are simple code diffs. To apply cd into the ossec-hids-2.6/src
> >> directory and run "patch -p0 < os_net.diff" and "patch -p0 <
> >> client-agent.diff"
>
> >> It should look something like:
>
> >> [ddp@ix] :; patch -p0 < /tmp/os_net.diff
> >> Hmm... Looks like a unified diff to me...
> >> The text leading up to this was:
> >> --
> >> |diff -u ../../2/ossec-hids-2.6/src/os_net/os_net.c ./os_net/os_net.c
> >> |--- ../../2/ossec-hids-2.6/src/os_net/os_net.c Mon Jul 11 15:36:59 2011
> >> |+++ ./os_net/os_net.c Tue Sep 6 16:04:09 2011
> >> --
> >> Patching file ./os_net/os_net.c using Plan A...
> >> Hunk #1 succeeded at 41.
> >> Hunk #2 succeeded at 83.
> >> Hunk #3 succeeded at 103.
> >> Hunk #4 succeeded at 112.
> >> Hunk #5 succeeded at 137.
> >> Hunk #6 succeeded at 163.
> >> Hunk #7 succeeded at 302.
> >> Hunk #8 succeeded at 356.
> >> Hunk #9 succeeded at 380.
> >> Hunk #10 succeeded at 404.
> >> Hmm... The next patch looks like a unified diff to me...
> >> The text leading up to this was:
> >> --
> >> |diff -u ../../2/ossec-hids-2.6/src/os_net/os_net.h ./os_net/os_net.h
> >> |--- ../../2/ossec-hids-2.6/src/os_net/os_net.h Mon Jul 11 15:36:59 2011
> >> |+++ ./os_net/os_net.h Tue Sep 6 16:00:05 2011
> >> --
> >> Patching file ./os_net/os_net.h using Plan A...
> >> Hunk #1 succeeded at 23.
> >> Hunk #2 succeeded at 43.
>
> >> and
>
> >> [ddp@ix] :; patch -p0 < /tmp/client-agent.diff
> >> Hmm... Looks like a unified diff to me...
> >> The text leading up to this was:
> >> --
> >> |diff -u ../../2/ossec-hids-2.6/src/client-agent/start_agent.c
> >> ./client-agent/start_agent.c
> >> |--- ../../2/ossec-hids-2.6/src/client-agent/start_agent.c Mon Jul
> >> 11 15:36:58 2011
> >> |+++ ./client-agent/start_agent.c Tue Sep 6 16:11:03 2011
> >> --
> >> Patching file ./client-agent/start_agent.c using Plan A...
> >> Hunk #1 succeeded at 101.
> >> done
>
> >> Good luck!
> >> dan
>
> >> On Tue, Sep 06, 2011 at 01:29:36PM -0700, Alisha Kloc wrote:
> >> > Daniel,
>
> >> > Is that something that can be added as a switch to an official
> >> > release? We are absolutely forbidden from modifying source code, so we
> >> > wouldn't be able to do it ourselves.
>
> >> > Dan,
>
> >> > I'd offer to test those when our HP-UX systems become available again,
> >> > but I have no idea what they're telling me - I'm not a programmer and
> >> > we don't do code on this project. Sorry!
>
> >> > On Sep 6, 1:16?pm, dan wrote:
> >> > > I do
[ossec-list] Re: Build 2.6 agent on HP-UX fails
Okay, thanks! It'll be a few days, at least, before I have access to our HP-UX systems to try these - we're in the middle of a testing cycle right now. But once I can I'll let you know what happens. On Sep 6, 2:11 pm, dan wrote: > Like I said, I haven't tested these (beyond compiling them on a system > WITH ipv6). They may not work at all > > These are simple code diffs. To apply cd into the ossec-hids-2.6/src > directory and run "patch -p0 < os_net.diff" and "patch -p0 < > client-agent.diff" > > It should look something like: > > [ddp@ix] :; patch -p0 < /tmp/os_net.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |diff -u ../../2/ossec-hids-2.6/src/os_net/os_net.c ./os_net/os_net.c > |--- ../../2/ossec-hids-2.6/src/os_net/os_net.c Mon Jul 11 15:36:59 2011 > |+++ ./os_net/os_net.c Tue Sep 6 16:04:09 2011 > -- > Patching file ./os_net/os_net.c using Plan A... > Hunk #1 succeeded at 41. > Hunk #2 succeeded at 83. > Hunk #3 succeeded at 103. > Hunk #4 succeeded at 112. > Hunk #5 succeeded at 137. > Hunk #6 succeeded at 163. > Hunk #7 succeeded at 302. > Hunk #8 succeeded at 356. > Hunk #9 succeeded at 380. > Hunk #10 succeeded at 404. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -- > |diff -u ../../2/ossec-hids-2.6/src/os_net/os_net.h ./os_net/os_net.h > |--- ../../2/ossec-hids-2.6/src/os_net/os_net.h Mon Jul 11 15:36:59 2011 > |+++ ./os_net/os_net.h Tue Sep 6 16:00:05 2011 > -- > Patching file ./os_net/os_net.h using Plan A... > Hunk #1 succeeded at 23. > Hunk #2 succeeded at 43. > > and > > [ddp@ix] :; patch -p0 < /tmp/client-agent.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |diff -u ../../2/ossec-hids-2.6/src/client-agent/start_agent.c > ./client-agent/start_agent.c > |--- ../../2/ossec-hids-2.6/src/client-agent/start_agent.c Mon Jul > 11 15:36:58 2011 > |+++ ./client-agent/start_agent.c Tue Sep 6 16:11:03 2011 > ------ > Patching file ./client-agent/start_agent.c using Plan A... > Hunk #1 succeeded at 101. > done > > Good luck! > dan > > > > > > > > On Tue, Sep 06, 2011 at 01:29:36PM -0700, Alisha Kloc wrote: > > Daniel, > > > Is that something that can be added as a switch to an official > > release? We are absolutely forbidden from modifying source code, so we > > wouldn't be able to do it ourselves. > > > Dan, > > > I'd offer to test those when our HP-UX systems become available again, > > but I have no idea what they're telling me - I'm not a programmer and > > we don't do code on this project. Sorry! > > > On Sep 6, 1:16?pm, dan wrote: > > > I don't have an ipv6-less system to test this, but these MAY work > > > on an agent. > > > > On Tue, Sep 06, 2011 at 11:32:02AM -0700, Alisha Kloc wrote: > > > > Well, crud. We need HP-UX support and if we can't compile the agents > > > > because of IPv6, I guess that means we won't be upgrading past OSSEC > > > > 2.5. > > > > > Does OSSEC still have that bug tracker/feature request site? I don't > > > > know if we're a corner case or what, but if it's not too difficult to > > > > add, I really would like to file it as a feature request. > > > > > On Sep 5, 11:41?am, "dan (ddp)" wrote: > > > > > There isn't currently a way to disable ipv6 like that. > > > > ?os_net.diff > > > 6KViewDownload > > > > ?client-agent.diff > > > < 1KViewDownload > > > > os_net.diff > 6KViewDownload > > client-agent.diff > < 1KViewDownload
[ossec-list] Re: Build 2.6 agent on HP-UX fails
Daniel, Is that something that can be added as a switch to an official release? We are absolutely forbidden from modifying source code, so we wouldn't be able to do it ourselves. Dan, I'd offer to test those when our HP-UX systems become available again, but I have no idea what they're telling me - I'm not a programmer and we don't do code on this project. Sorry! On Sep 6, 1:16 pm, dan wrote: > I don't have an ipv6-less system to test this, but these MAY work > on an agent. > > > > > > > > On Tue, Sep 06, 2011 at 11:32:02AM -0700, Alisha Kloc wrote: > > Well, crud. We need HP-UX support and if we can't compile the agents > > because of IPv6, I guess that means we won't be upgrading past OSSEC > > 2.5. > > > Does OSSEC still have that bug tracker/feature request site? I don't > > know if we're a corner case or what, but if it's not too difficult to > > add, I really would like to file it as a feature request. > > > On Sep 5, 11:41?am, "dan (ddp)" wrote: > > > There isn't currently a way to disable ipv6 like that. > > > > os_net.diff > 6KViewDownload > > client-agent.diff > < 1KViewDownload
[ossec-list] Re: Build 2.6 agent on HP-UX fails
Well, crud. We need HP-UX support and if we can't compile the agents because of IPv6, I guess that means we won't be upgrading past OSSEC 2.5. Does OSSEC still have that bug tracker/feature request site? I don't know if we're a corner case or what, but if it's not too difficult to add, I really would like to file it as a feature request. On Sep 5, 11:41 am, "dan (ddp)" wrote: > There isn't currently a way to disable ipv6 like that.
[ossec-list] Re: Build 2.6 agent on HP-UX fails
It might just be that we don't have IPv6 installed on our machine then, if Daniel's right about how it's failing. Is there a flag or command to disable IPv6 support in OSSEC when compiling? If not, can I log a feature request for OSSEC 2.7? :) On Aug 22, 2:10 pm, Jeremy Lee wrote: > We're running B.11.11 (B.11.11 U 9000/800) on a majority of them. Although, > not sure if they are PA-RISC or not > > On Mon, Aug 22, 2011 at 2:01 PM, Alisha Kloc wrote: > > > > > > > > > Whoops, lots of simultaneous posts. > > > We are using gcc; we installed it and supporting software specifically > > to build OSSEC agents. > > > Like I said, we're able to successfully build agents on this machine > > from the OSSEC 2.4 tarball; the problem seems restricted to the 2.6 > > build. > > > Jeremy, what version of HP-UX do you have? > > > On Aug 22, 1:51 pm, Michael Starks > > wrote: > > > On Mon, 22 Aug 2011 13:32:32 -0700, Jeremy Lee wrote: > > > > Are you building with the CC compiler? If not, try forcing the use of > > > > GCC. > > > > We have a handful of HPUX boxes that I just installed OSSEC 2.6 on > > > > and it > > > > seems to be working fine - I had to use the GCC compiler though. > > > > I also had to always use GCC when I was supporting HP-UX. > > > > -- > > > Michael Starks > > > [I] Immutable Securityhttp://www.immutablesecurity.com
[ossec-list] Re: Build 2.6 agent on HP-UX fails
Whoops, lots of simultaneous posts. We are using gcc; we installed it and supporting software specifically to build OSSEC agents. Like I said, we're able to successfully build agents on this machine from the OSSEC 2.4 tarball; the problem seems restricted to the 2.6 build. Jeremy, what version of HP-UX do you have? On Aug 22, 1:51 pm, Michael Starks wrote: > On Mon, 22 Aug 2011 13:32:32 -0700, Jeremy Lee wrote: > > Are you building with the CC compiler? If not, try forcing the use of > > GCC. > > We have a handful of HPUX boxes that I just installed OSSEC 2.6 on > > and it > > seems to be working fine - I had to use the GCC compiler though. > > I also had to always use GCC when I was supporting HP-UX. > > -- > Michael Starks > [I] Immutable Securityhttp://www.immutablesecurity.com
[ossec-list] Re: Build 2.6 agent on HP-UX fails
Wish I could offer our boxes for dev/testing, but we're in a restricted lab. Sorry! It does look like IPv6 isn't immediately available on HP-UX 11.11; you have to install a special bundle that I don't think we have: https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=T1306AA If it would help to get you guys more logs or information, let me know and I'll see what I can do. On Aug 22, 1:07 pm, Daniel Cid wrote: > It seems the new ipv6 code is breaking in there... Probably a missing header. > > Anyone with an HP-UX box available there? :) > > thanks, > > > > > > > > On Mon, Aug 22, 2011 at 3:49 PM, Alisha Kloc wrote: > > Hi list, > > > Has anyone else tried to build OSSEC 2.6 on HP-UX? > > > We just tried to build install binaries on our compilation system and > > encountered a fatal error (I have to hand-copy these messages so I > > apologize if I mistyped something): > > > start snip- > > *** making os_net *** > > > os_net.c: In function 'OS_Bindport': > > os_net.c:54: error: storage size of 'server6' isn't known > > os_net.c:92: error: 'in6addr_any' undeclared (first use in this > > function) > > ... > > os_net.c:54: warning: unused variable 'server6' > > os_net.c: In function 'OS_Connect': > > os_net.c:54: error: storage size of 'server6' isn't known > > os_net.c:92: error: 'in6addr_any' undeclared (first use in this > > function) > > os_net.c:54: warning: unused variable 'server6' > > > *** Error exit code 1 > > Stop > > > Error Making os_net > > > *** Error exit code 1 > > Stop > > end snip- > > > We had previously used this system to build 2.4 binaries, and in fact > > I built a 2.4 binary with no trouble immediately after encountering > > this error on 2.6. So it's not something wrong with our compiler. > > > System is HP-UX 11i (B.11.11), PA-RISC architecture. I don't know what > > version of gcc but like I said, it works fine with earlier OSSEC > > versions. > > > Has anyone else seen this, or know what's going on? > > > Thanks! > > -Alisha Kloc
[ossec-list] Build 2.6 agent on HP-UX fails
Hi list, Has anyone else tried to build OSSEC 2.6 on HP-UX? We just tried to build install binaries on our compilation system and encountered a fatal error (I have to hand-copy these messages so I apologize if I mistyped something): start snip- *** making os_net *** os_net.c: In function 'OS_Bindport': os_net.c:54: error: storage size of 'server6' isn't known os_net.c:92: error: 'in6addr_any' undeclared (first use in this function) ... os_net.c:54: warning: unused variable 'server6' os_net.c: In function 'OS_Connect': os_net.c:54: error: storage size of 'server6' isn't known os_net.c:92: error: 'in6addr_any' undeclared (first use in this function) os_net.c:54: warning: unused variable 'server6' *** Error exit code 1 Stop Error Making os_net *** Error exit code 1 Stop end snip- We had previously used this system to build 2.4 binaries, and in fact I built a 2.4 binary with no trouble immediately after encountering this error on 2.6. So it's not something wrong with our compiler. System is HP-UX 11i (B.11.11), PA-RISC architecture. I don't know what version of gcc but like I said, it works fine with earlier OSSEC versions. Has anyone else seen this, or know what's going on? Thanks! -Alisha Kloc
[ossec-list] Re: Monitoring logins via btmp and wtmp
Sorry for the delay; I was at Defcon and didn't dare log in to reply. > How are the users connecting; ssh or telnet ? AFAIK on HP-UX SSH logins are > recorded to syslog as PAM events. They typically connect via various remote programs; however, there's one particular application that requires a local root login, and we need to be able to monitor that. We also want to have a record of other local logins for policy enforcement. >What about tmp files? Run last and spit it out to /tmp/lastlog or something.. > Then have ossec monitor that file. Any changes should pop out with >check_diff. I've been playing with a way to do that via shell scripting. It's really awkward and unreliable, though. The file gets huge fast, meaning we're sucking up an inordinate amount of bandwidth, plus you stop being able to see the changes after a while because the length of the file exceeds the character limit for that field in MySQL. I also played with a variation where I keep two files, one with the previous run of last and one with a current run, and use the Unix diff command to see the difference. This is slightly less awkward, but I still can't get it to run smoothly since diff's own lines in the output can trigger OSSEC's check_diff. >Or, if you can't do it locally on the hp-ux server, write a script on the >ossec manager that logs into the hp-ux machine, runs last, and stores that >locally on the ossec manager. Then just monitor that log. Our manager isn't allowed to talk to our agents or their hosts (we're the reason OSSEC now has the one-way agent feature...). If we could, it'd be a huge help. Thanks! -Alisha On Aug 4, 2:52 am, "--[ UxBoD ]--" wrote: > How are the users connecting; ssh or telnet ? AFAIK onHP-UXSSH logins are > recorded to syslog as PAM events. > -- > Thanks, Phil > > > > > > > > - Original Message - > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > On Aug 1, 2011, at 6:55 PM, Alisha Kloc wrote: > > > Unfortunately, we can't make any changes to theHP-UXsystem, which > > > means no cron jobs, no clearing logs, etc. All we're allowed to > > > touch > > > is OSSEC agent stuff. Within that, I have some flexibility if I use > > > the process monitor to call a simple shell script, which allows > > > consecutive commands like you suggested, but anything beyond that > > > isn't allowed. > > > > Sounds like this might not be possible... > > > What about tmp files? Run last and spit it out to /tmp/lastlog or > > something.. Then have ossec monitor that file. Any changes should > > pop out with check_diff. > > > Or, if you can't do it locally on thehp-uxserver, write a script on > > the ossec manager that logs into thehp-uxmachine, runs last, and > > stores that locally on the ossec manager. Then just monitor that > > log. > > > > -Alisha > > > - --- > > Jason 'XenoPhage' Frisvold > > xenoph...@godshell.com > > - --- > > "Any sufficiently advanced magic is indistinguishable from > > technology." > > - - Niven's Inverse of Clarke's Third Law > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG/MacGPG2 v2.0.16 (Darwin) > > > iEYEARECAAYFAk459bwACgkQ8CjzPZyTUTTMMwCcCNjQ3cL0lL+G/byMwIvRj6hE > > h3gAniADRO6Fd1JVWJGmJoSPi8Vs7Xw+ > > =JCh9 > > -END PGP SIGNATURE-
[ossec-list] Re: Monitoring logins via btmp and wtmp
If I could, that's exactly how I'd do it. Unfortunately, like I said, we are not allowed to clear the logs on these systems - they have to remain there locally. We can't do anything except read them. Believe me, I'd love to be able to use your suggestion, because it would solve this whole issue very quickly. But we're limited to a strict "look, don't touch" policy... On Aug 1, 5:50 pm, Michael Starks wrote: > On 08/01/2011 05:55 PM, Alisha Kloc wrote: > > > Unfortunately, we can't make any changes to the HP-UX system, which > > means no cron jobs, no clearing logs, etc. All we're allowed to touch > > is OSSEC agent stuff. Within that, I have some flexibility if I use > > the process monitor to call a simple shell script, which allows > > consecutive commands like you suggested, but anything beyond that > > isn't allowed. > > How about something like 'command-to-read btmp' && 'cat /dev/null > > /path/to/btmp_file' in the ossec command. I don't know if the system > wouldn't like that and there is the unfortunate consequence of not > having the logs locally, but it seems like it would give you only new > entries, which you could then do the check_diff on. Run this every > minute or so and it would be semi-real time. > > -Mike
[ossec-list] Re: Monitoring logins via btmp and wtmp
On Aug 1, 1:35 pm, Michael Starks wrote: > > We probably didn't solve that in any elegant way. There was nothing > like check_diff available in OSSEC at the time. Huh. The reason it's a problem for us is because if we just spit last to a syslog, we get new alerts on old logins (if user1 has logged in any time since wtmp was cleared, we'll alert on that one login every time we re-read wtmp). Did you just clear wtmp every time you sent it to the text file? > > Hmmm, well if the problem is that the last command results in too much > output for check_diff to handle, then you may have to address this on > the HP-UX side. This seems like it would be a frequent audit concern for > HP-UX systems. I can't imagine they haven't addressed this in some way > natively yet. I don't know HP-UX well at all. Can you run another > command consecutively (like command1 && command2) where the second > command clears the btmp database? That way you would only get new output > to OSSEC. Unfortunately, we can't make any changes to the HP-UX system, which means no cron jobs, no clearing logs, etc. All we're allowed to touch is OSSEC agent stuff. Within that, I have some flexibility if I use the process monitor to call a simple shell script, which allows consecutive commands like you suggested, but anything beyond that isn't allowed. Sounds like this might not be possible... -Alisha
[ossec-list] Re: Monitoring logins via btmp and wtmp
Hi Michael, Hmm, sounds a lot like what we're trying to do. How did you get around the fact that "last" spits out all entries in wtmp, not just newly- added ones? That's our biggest sticking point; wtmp gets very long very quickly and we don't need old entries, just new ones since the last check. Sadly, we don't have an option to fix the issue on the HP-UX side... it would certainly make things easier if we did. Thanks! -Alisha On Aug 1, 12:20 pm, Michael Starks wrote: > On Mon, 1 Aug 2011 10:43:43 -0700 (PDT), Alisha Kloc wrote: > > Hi again list, > > > My team is trying to find a way to monitor logins, logouts, and > > failed > > logins on HP-UX using OSSEC. Problem is, HP-UX only records these in > > the binary wtmp and btmp files. > > > We've experimented with a few different methods that involve the > > process monitor, but they're all network-intensive, difficult for an > > analyst to understand, and/or unreliable. > > > We've tried using check_diff to monitor the output of last; using the > > Unix diff command to compare previous and new outputs from last; and > > generating diff output into the regular syslog. None of these has > > worked well enough to deploy in the field. > > > Has anyone ever tried something similar? Is there any way to > > configure > > OSSEC to use the HP-UX shell to alert on logins? > > Hello Alisha, > > I remember having this issue many, many moons ago. I haven't used HP-UX > in years so my memory is a bit fuzzy. If I recall correctly, I *think* > we ran the commands in cron and output that to a file, then had OSSEC > monitor the file. It was either that or we sent it to syslog, which then > went to the syslog server, which was then monitored by OSSEC. it is less > than ideal because the composite rules really don't work well when logs > are sent in batches like that. > > Also, consider the entry points into the system. If you can only SSH to > it, for example, perhaps it will be good enough to collect SSH logs. But > then you wouldn't necessarily get console logins... > > By now, perhaps HPUX has a better solution. I recall using something > like a "Skunkware" repo or something like that. Is that still around? > > -- > Michael Starks > [I] Immutable Securityhttp://www.immutablesecurity.com
[ossec-list] Monitoring logins via btmp and wtmp
Hi again list, My team is trying to find a way to monitor logins, logouts, and failed logins on HP-UX using OSSEC. Problem is, HP-UX only records these in the binary wtmp and btmp files. We've experimented with a few different methods that involve the process monitor, but they're all network-intensive, difficult for an analyst to understand, and/or unreliable. We've tried using check_diff to monitor the output of last; using the Unix diff command to compare previous and new outputs from last; and generating diff output into the regular syslog. None of these has worked well enough to deploy in the field. Has anyone ever tried something similar? Is there any way to configure OSSEC to use the HP-UX shell to alert on logins? Thanks! -Alisha Kloc
[ossec-list] Re: Check_diff difficulties
Ah, I'll try that. I thought "command" versus "full_command" was just a syntactical difference between 2.4 and 2.5; I didn't know it had further meaning. So just to be clear, using command makes OSSEC read each line of output individually, and using full_command makes OSSEC treat multiple lines as one unit? Thanks! -Alisha On Jul 28, 2:21 pm, Daniel Cid wrote: > Hi Alisha, > > Try to use full_command as the log format. It will treat the whole > output as one ... > > thanks, > > > > > > > > On Thu, Jul 28, 2011 at 5:22 PM, Alisha Kloc wrote: > > Hi list, > > > My team is trying to use the check_diff feature to monitor logins via > > wtmp, using OSSEC 2.4. We implemented the rule by copying what Daniel > > Cid describes > > athttp://dcid.me/2010/03/alerting-when-a-log-or-output-of-a-command-cha..., > > and modifying with the appropriate command and parameters: > > > > > command > > last -R > > > > > > > 530 > > ossec: output: 'last -R > > > > Successful login. > > > > > However, we get about 30 alerts every time the process monitor runs, > > even if no one has logged in. It seems to read each line of the multi- > > line output as an individual response, and alerts on each line because > > it's not the same as the line before it. > > > We want check_diff to process the entire output as a single unit, and > > alert only if the whole unit is changed, i.e., if a new login is added > > to the log. > > > Both examples provided for the check_diff feature seem to imply it's > > capable of handling multi-line output, so why isn't it working here? > > > Thanks! > > -Alisha Kloc
[ossec-list] Check_diff difficulties
Hi list, My team is trying to use the check_diff feature to monitor logins via wtmp, using OSSEC 2.4. We implemented the rule by copying what Daniel Cid describes at http://dcid.me/2010/03/alerting-when-a-log-or-output-of-a-command-changes, and modifying with the appropriate command and parameters: command last -R 530 ossec: output: 'last -R Successful login. However, we get about 30 alerts every time the process monitor runs, even if no one has logged in. It seems to read each line of the multi- line output as an individual response, and alerts on each line because it's not the same as the line before it. We want check_diff to process the entire output as a single unit, and alert only if the whole unit is changed, i.e., if a new login is added to the log. Both examples provided for the check_diff feature seem to imply it's capable of handling multi-line output, so why isn't it working here? Thanks! -Alisha Kloc
[ossec-list] Re: agent_control disconnect bug?
Hi Daniel, Why does setting the agent to be one-way stop the keepalives, and why does it do so only on the Windows agents? The *nix agents are apparently sending their keepalives normally, since none of them appear disconnected, even though they are configured one-way as well, and behind the same network firewall as the Windows agents. Also, we did some more testing in our lab overnight, and we realized that a one-way Windows agent which can still hear from the manager (i.e., it is configured to be one-way, but there isn't any network configuration preventing the manager from communicating back) remains properly connected. However, the same one-way Windows agent, when it can't hear from the manager (i.e., there's a router blocking all UDP traffic between the manager and the agent), shows as disconnected in agent_control. So it seems to be a bug specifically in the one-way Windows agents... Thanks! -Alisha On Apr 12, 12:08 pm, Daniel Cid wrote: > Hi Alisha, > > Always Windows giving us problem :) > > The manager itself (remoted) doesn't keep state from any of the agents > (doesn't know if it is on or off). But whenever it receives the keep > alive > from the agent, it will update the timestamp from the agent file in the queue. > > That agent file is ready by the other tools (agent_control, monitord, > etc) to list which agents are on and off. So even if your agent is > sending > lots of events and communicating properly wit the manager, if it > doesn't send the keep alive, the manager will never update the file > and > all the tools will think it is disconnected... > > Hope I made sense. > > thanks, > > On Tue, Apr 12, 2011 at 3:03 PM, Alisha Kloc wrote: > > Hi, > > > I don't think it's because of the one-way setup. We've seen the > > disconnect issue in lab/troubleshoot setups where one-way isn't > > configured; also, our *nix agents are configured to be one-way as > > well, but they always show properly as connected. It's only the > > Windows agents that do this. > > > Would there be any reason for the OSSEC manager to not attribute a > > process monitor event to a Windows agent, so it doesn't realize that > > the heartbeat sent by the process monitor is an event for purposes of > > keeping the agent marked alive? > > > Also, how exactly does OSSEC determine whether an agent is connected > > or not? We were originally told that it just marks an agent as > > disconnected if it hasn't seen an event from the agent in 15 minutes, > > but you just now said the agents send keepalives. Could you clarify? > > > Thanks! > > -Alisha > > > On Apr 12, 10:38 am, Daniel Cid wrote: > >> Hey, > > >> Maybe because it is setup as one-way? The manager uses the keep alives > >> (internally sent by the agent) to keep > >> track if they are up or not. Since you have it disabled, those keep > >> alives are never sent, so they show up as > >> disabled. > > >> thanks, > > >> On Mon, Apr 11, 2011 at 4:36 PM, Alisha Kloc > >> wrote: > >> > Hi list, > > >> > My team would like to report an unusual pattern we're seeing, and find > >> > out whether it's a bug and if it will be fixed in a future OSSEC > >> > version. > > >> > Our setup is an OSSEC v2.4.1 manager monitoring around a dozen servers > >> > and workstations (using agent v2.4.1), mixed Windows 2003 and *nix. > >> > Our systems are strict one-way; that is, the agents can talk to the > >> > manager, but the manager cannot talk to the agents. Our *nix agents > >> > behave as expected, but our Windows 2003 agents frequently show up as > >> > "disconnected" when checked with agent_control. However, the Windows > >> > agents ARE connected, and are sending events before and after > >> > agent_control shows them as disconnected. > > >> > It was our understanding that agent_control marks an agent as > >> > disconnected if that agent hasn't sent an event within the last 15 > >> > minutes (if this is incorrect, please tell me what it really is). Our > >> > systems tend to be very quiet for long periods of time, so we > >> > originally thought that the "disconnects" were happening simply > >> > because there were no events. > > >> > We implemented a heartbeat to fix this, which uses OSSEC's process > >> > monitoring tool to periodically send events. On Windows, the process > >> > monitor sends an event every 5-7 minutes. We expected that i
[ossec-list] Re: agent_control disconnect bug?
Hi, I don't think it's because of the one-way setup. We've seen the disconnect issue in lab/troubleshoot setups where one-way isn't configured; also, our *nix agents are configured to be one-way as well, but they always show properly as connected. It's only the Windows agents that do this. Would there be any reason for the OSSEC manager to not attribute a process monitor event to a Windows agent, so it doesn't realize that the heartbeat sent by the process monitor is an event for purposes of keeping the agent marked alive? Also, how exactly does OSSEC determine whether an agent is connected or not? We were originally told that it just marks an agent as disconnected if it hasn't seen an event from the agent in 15 minutes, but you just now said the agents send keepalives. Could you clarify? Thanks! -Alisha On Apr 12, 10:38 am, Daniel Cid wrote: > Hey, > > Maybe because it is setup as one-way? The manager uses the keep alives > (internally sent by the agent) to keep > track if they are up or not. Since you have it disabled, those keep > alives are never sent, so they show up as > disabled. > > thanks, > > On Mon, Apr 11, 2011 at 4:36 PM, Alisha Kloc wrote: > > Hi list, > > > My team would like to report an unusual pattern we're seeing, and find > > out whether it's a bug and if it will be fixed in a future OSSEC > > version. > > > Our setup is an OSSEC v2.4.1 manager monitoring around a dozen servers > > and workstations (using agent v2.4.1), mixed Windows 2003 and *nix. > > Our systems are strict one-way; that is, the agents can talk to the > > manager, but the manager cannot talk to the agents. Our *nix agents > > behave as expected, but our Windows 2003 agents frequently show up as > > "disconnected" when checked with agent_control. However, the Windows > > agents ARE connected, and are sending events before and after > > agent_control shows them as disconnected. > > > It was our understanding that agent_control marks an agent as > > disconnected if that agent hasn't sent an event within the last 15 > > minutes (if this is incorrect, please tell me what it really is). Our > > systems tend to be very quiet for long periods of time, so we > > originally thought that the "disconnects" were happening simply > > because there were no events. > > > We implemented a heartbeat to fix this, which uses OSSEC's process > > monitoring tool to periodically send events. On Windows, the process > > monitor sends an event every 5-7 minutes. We expected that if OSSEC > > saw a heartbeat every 5-7 minutes, the 15-minute disconnect period in > > agent_control would never trigger. > > > However, even with the heartbeat, the Windows agents continue to show > > as "disconnected" for long periods of time - even if there was a > > heartbeat a few minutes prior to running the agent_control query. In > > addition, events continue to arrive at the manager despite the agent > > showing disconnected. > > > Below is the output of two agent_control commands, and two alerts from > > OSSEC's alerts.log which show heartbeats 3 minutes before the first > > agent_control and one minute after the second: > > _ > > # date > > Mon Apr 11 18:10:51 GMT 2011 > > # ./agent_control -l > > > OSSEC HIDS agent_control. List of available agents: > > ID: 000, Name: manager (server), IP: 127.0.0.1, Active/Local > > > > ID: 009, Name: win-server1, IP: , Disconnected > > > # date > > Mon Apr 11 18:12:51 GMT 2011 > > # ./agent_control -l > > > OSSEC HIDS agent_control. List of available agents: > > ID: 000, Name: manager (server), IP: 127.0.0.1, Active/Local > > > > ID: 009, Name: win-server1, IP: , Disconnected > > > /opt/ossec/logs/alerts/alerts.log: > > > ** Alert 1302545271.2550465: - local,syslog, > > 2011 Apr 11 18:07:51 (win-server1) ->"C\\Program Files\ossec-agent > > \win_heartbeat.bat" > > Rule: 101003 (level 1) -> 'OSSEC heartbeat: OSSEC Windows is running' > > Src IP: (none) > > User: (none) > > ossec: output: '"C\\Program Files\ossec-agent\win_heartbeat.bat"': Mon > > 04/11/2011 18:07 PM ossec-win-hb: Heartbeat: ossec- > > agent.exe 5852 0 4,652 K > > > > > > ** Alert 1302545632.2566243: - local,syslog, > > 2011 Apr 11 18:13:52 (win-server1) ->"C\\Program Files\ossec-agent > > \win_heartbeat.bat" > > Rule: 101003
[ossec-list] agent_control disconnect bug?
Hi list, My team would like to report an unusual pattern we're seeing, and find out whether it's a bug and if it will be fixed in a future OSSEC version. Our setup is an OSSEC v2.4.1 manager monitoring around a dozen servers and workstations (using agent v2.4.1), mixed Windows 2003 and *nix. Our systems are strict one-way; that is, the agents can talk to the manager, but the manager cannot talk to the agents. Our *nix agents behave as expected, but our Windows 2003 agents frequently show up as "disconnected" when checked with agent_control. However, the Windows agents ARE connected, and are sending events before and after agent_control shows them as disconnected. It was our understanding that agent_control marks an agent as disconnected if that agent hasn't sent an event within the last 15 minutes (if this is incorrect, please tell me what it really is). Our systems tend to be very quiet for long periods of time, so we originally thought that the "disconnects" were happening simply because there were no events. We implemented a heartbeat to fix this, which uses OSSEC's process monitoring tool to periodically send events. On Windows, the process monitor sends an event every 5-7 minutes. We expected that if OSSEC saw a heartbeat every 5-7 minutes, the 15-minute disconnect period in agent_control would never trigger. However, even with the heartbeat, the Windows agents continue to show as "disconnected" for long periods of time - even if there was a heartbeat a few minutes prior to running the agent_control query. In addition, events continue to arrive at the manager despite the agent showing disconnected. Below is the output of two agent_control commands, and two alerts from OSSEC's alerts.log which show heartbeats 3 minutes before the first agent_control and one minute after the second: _ # date Mon Apr 11 18:10:51 GMT 2011 # ./agent_control -l OSSEC HIDS agent_control. List of available agents: ID: 000, Name: manager (server), IP: 127.0.0.1, Active/Local ID: 009, Name: win-server1, IP: , Disconnected # date Mon Apr 11 18:12:51 GMT 2011 # ./agent_control -l OSSEC HIDS agent_control. List of available agents: ID: 000, Name: manager (server), IP: 127.0.0.1, Active/Local ID: 009, Name: win-server1, IP: , Disconnected /opt/ossec/logs/alerts/alerts.log: ** Alert 1302545271.2550465: - local,syslog, 2011 Apr 11 18:07:51 (win-server1) ->"C\\Program Files\ossec-agent \win_heartbeat.bat" Rule: 101003 (level 1) -> 'OSSEC heartbeat: OSSEC Windows is running' Src IP: (none) User: (none) ossec: output: '"C\\Program Files\ossec-agent\win_heartbeat.bat"': Mon 04/11/2011 18:07 PM ossec-win-hb: Heartbeat: ossec- agent.exe 58520 4,652 K ** Alert 1302545632.2566243: - local,syslog, 2011 Apr 11 18:13:52 (win-server1) ->"C\\Program Files\ossec-agent \win_heartbeat.bat" Rule: 101003 (level 1) -> 'OSSEC heartbeat: OSSEC Windows is running' Src IP: (none) User: (none) ossec: output: '"C\\Program Files\ossec-agent\win_heartbeat.bat"': Mon 04/11/2011 18:13 PM ossec-win-hb: Heartbeat: ossec- agent.exe 58520 4,644 K _ Although our current setup is OSSEC v2.4.1, we've been seeing this since OSSEC v1.6.1. It's definitely not that the Windows agents are disconnecting, as in the bug reports from a few years back, but that agent_control is marking them as disconnected when they are still connected and still sending events. We have several instances of this setup (dev, lab, test, etc) and it happens in all of them. What is going on here? Is there some reason why the process monitor heartbeat isn't registering as an event to the manager? What else could be causing agent_control to display the Windows agents as disconnected when they're not? Thanks! -Alisha Kloc
[ossec-list] Re: Processes for syscheck and rootcheck
It sounds like the process ossec-syscheckd handles all three events I was seeing: the scan_on_start/database building for both syscheck and rootcheck (where ossec-syscheckd jumped up to 40%), then the actual syscheck (which didn't show up as using CPU because it's limiting itself), and finally rootcheck (which also jumped to 40%). And ossec- agentd only showed up because it needed to talk to the manager during syscheck. We've been trying for a while to figure out where rootcheck lives, since in the logs it's listed as "rootcheckd" but there is no ossec- rootcheckd process. It sounds like what you're both saying is that ossec-syscheckd is also ossec-rootcheckd. Is that correct? And does this mean that if our machines are hypersensitive to rootcheck grabbing 40% CPU, we can re-nice/re-prioritize ossec- syscheckd so that rootcheck will behave a little better? Thanks! -Alisha
[ossec-list] Processes for syscheck and rootcheck
Hi list, We are trying to examine the impact of the OSSEC agent on our more sensitive systems. However, we're quite confused about which OSSEC process does what. Our agents are configured with syscheck and rootcheck both enabled and syscheck set to scan on start. We watched the agent restart by tailing ossec.log and using top to monitor CPU usage and process activity. We saw significant activity by ossec-syscheckd, jumping as high as 40% CPU, in the minute or so after the agent started. This was expected given the scan_on_start=yes. Five minutes later, the log showed the message "Starting syscheck scan", but ossec-syscheckd didn't even make top's list of processes using the CPU, while ossec-agentd went up to around 1% CPU usage and stayed there. Then ossec-agentd dropped back to 0% usage immediately after the "Ending syscheck scan" message in the logs. This was odd since we were expecting to see ossec-syscheckd in use during the syscheck. Next came the rootcheck, at which point ossec-syscheckd became active, again shooting up to 35-40% CPU usage for the duration of rootcheck. After the "Ending rootcheck scan" message, ossec-syscheckd gradually dropped back down to 0% usage, leaving us thoroughly confused. Could someone please explain which process does what? Why does ossec- syscheckd show significant activity during rootcheck and scan_on_start, but do nothing during a scheduled syscheck? Why does ossec-agentd show activity during a syscheck? Thanks in advance! -Alisha
[ossec-list] Re: Odd child decoder behavior
Bump, since I suspect this got lost in the Friday shuffle Anyone have any insight as to why this particular decoder is behaving strangely? We need this decoder/rule chain, but I don't want to risk something down the road turning up broken. Thanks! -Alisha Kloc On Sep 24, 1:27 pm, Alisha Kloc wrote: > Hello list, > > I have an odd problem and I'm hoping more sets of eyes can help. > > I've made the following decoder: > > > ossec-alert > true > Heartbeat: (\w*)\s*\d*\s\S*\s(\w)\s*(\S*) > user,status,data > > > When I run it through ossec-logtest, I get: > > 2010/09/24 16:44:56 ossec-testrule: INFO: Started (pid: 6332). > ossec-testrule: Type one log per line. > > Sep 24 16:32:25 vm-test ossec: Heartbeat: root 3255 15:59 S / > opt/ossec/bin/ossec-logcollector > > **Phase 1: Completed pre-decoding. > full event: 'Sep 24 16:32:25 vm-test ossec: Heartbeat: > root 3255 15:59 S /opt/ossec/bin/ossec-logcollector' > hostname: 'vm-test' > program_name: 'ossec' > log: 'Heartbeat: root 3255 15:59 S /opt/ossec/bin/ossec- > logcollector' > > **Phase 2: Completed decoding. > decoder: 'ossec-alert' > dstuser: 'root' > status: 'S' > extra_data: '/opt/ossec/bin/ossec-logcollector' > > [r...@vm-test bin]# > > It stops there, and logtest never fires my custom rules, which use the > heartbeat tag: > > > heartbeat > OSSEC heartbeat events grouped > > > I saw in an earlier post that there's a bug in logtest that doesn't > allow the child decoder's name to show up in logtest, but any custom > rules that fire based on the child decoder's name should work if the > tag is present. I can tell the child decoder is firing, > because if I test the log with just the ossec-alert decoder, I don't > see the dstuser, status, and extra_data fields in logtest. However, > the child decoder's name isn't getting passed to my custom rule, so > the rule isn't firing. This happens in both logtest and the full OSSEC > manager (after restarting OSSEC with the custom decoder and rules). > > We ran this by Daniel Cid already, and he was equally puzzled: > > "It worked fine for me when I added the Heartbeat > to the decoder. But even without, it should have worked. Maybe you > have another rule matching on it before the 101000?" > > I can't find any rules that match on a decoder name of "ossec-alert" > at all, and I can't think of any other rules that this log would > trigger before getting to my custom rule. It does work if, as Daniel > suggested, I add the tags, but that doesn't make much sense > either. > > I'm worried that even if I use it with the tags, my decoder > will break something behind the scenes. I'm hoping more sets of eyes > can pick out what's going on, and help me get this thing working > properly. Why doesn't my decoder's name get passed using > ? Why does adding a make it work? > > Thanks in advance! > -Alisha Kloc
[ossec-list] Odd child decoder behavior
Hello list, I have an odd problem and I'm hoping more sets of eyes can help. I've made the following decoder: ossec-alert true Heartbeat: (\w*)\s*\d*\s\S*\s(\w)\s*(\S*) user,status,data When I run it through ossec-logtest, I get: 2010/09/24 16:44:56 ossec-testrule: INFO: Started (pid: 6332). ossec-testrule: Type one log per line. Sep 24 16:32:25 vm-test ossec: Heartbeat: root 3255 15:59 S/ opt/ossec/bin/ossec-logcollector **Phase 1: Completed pre-decoding. full event: 'Sep 24 16:32:25 vm-test ossec: Heartbeat: root 3255 15:59 S/opt/ossec/bin/ossec-logcollector' hostname: 'vm-test' program_name: 'ossec' log: 'Heartbeat: root 3255 15:59 S/opt/ossec/bin/ossec- logcollector' **Phase 2: Completed decoding. decoder: 'ossec-alert' dstuser: 'root' status: 'S' extra_data: '/opt/ossec/bin/ossec-logcollector' [r...@vm-test bin]# It stops there, and logtest never fires my custom rules, which use the heartbeat tag: heartbeat OSSEC heartbeat events grouped I saw in an earlier post that there's a bug in logtest that doesn't allow the child decoder's name to show up in logtest, but any custom rules that fire based on the child decoder's name should work if the tag is present. I can tell the child decoder is firing, because if I test the log with just the ossec-alert decoder, I don't see the dstuser, status, and extra_data fields in logtest. However, the child decoder's name isn't getting passed to my custom rule, so the rule isn't firing. This happens in both logtest and the full OSSEC manager (after restarting OSSEC with the custom decoder and rules). We ran this by Daniel Cid already, and he was equally puzzled: "It worked fine for me when I added the Heartbeat to the decoder. But even without, it should have worked. Maybe you have another rule matching on it before the 101000?" I can't find any rules that match on a decoder name of "ossec-alert" at all, and I can't think of any other rules that this log would trigger before getting to my custom rule. It does work if, as Daniel suggested, I add the tags, but that doesn't make much sense either. I'm worried that even if I use it with the tags, my decoder will break something behind the scenes. I'm hoping more sets of eyes can pick out what's going on, and help me get this thing working properly. Why doesn't my decoder's name get passed using ? Why does adding a make it work? Thanks in advance! -Alisha Kloc
[ossec-list] Re: Process monitoring command list?
Thanks! I was fairly sure that each line of output gets handled individually, but it doesn't actually say anywhere and I wanted to make sure that was the case before trying any further debugging, to avoid wasted effort. We're not actually using ps | grep mysql - that was just my original basic metaphor, and I've been reusing it for simplicity (old writing habits, sorry!) and because I can post examples of that command. What we are actually looking for is a way to monitor Solaris audit logs with OSSEC. Since our versions of Solaris can't write logs directly to text files, our original plan was to set up cron jobs to manually run the series of commands which translates the binary audit trail to text and saves it to a syslog, and then point OSSEC to the syslog with custom decoders/rules. But this solution is impractical for a number of reasons, most of which would be alleviated if we could output the command string results directly to OSSEC. The general format of the trail is one audit record per line, like a syslog. Ossec.conf has praudit -l our.audit.trail ; audit -n which reads the audit trail, translates it to text, then rotates the audit trail so the same events aren't read multiple times. But nothing from the audit trail shows up in the manager (other events do as normal). The command appears to be read and performed correctly since the audit trail is getting rotated on schedule, and the decoder and rules I've written match individual audit records correctly in logtest, so I don't think that's the problem. But other than those two checks, I'm hard-pressed to further isolate the cause, so I'm trying to eliminate some of the really obvious possibilities before getting into the complex details... On Feb 2, 7:33 am, "dan (ddp)" wrote: > > Based on the manual's description of the feature > (http://www.ossec.net/main/manual/manual-process-monitoring/), I'd > guess that it handles each line independently. The example uses > 'df -h,' which outputs multiple lines of output. The example rule uses > matches and regexes that appear to look at each line of output > separately. > Could you describe what you are looking for? I know you can't post > samples, but I'm having trouble coming up with an example to test > that utilizes something like 'ps | grep mysql.' The only thing I've > come up with is looking for a process not running, and I'm also > having trouble thinking about how to do that at the moment. I blame > a lack of coffee.
[ossec-list] Re: Process monitoring command list?
Bump. If I use a command between the tags which returns multi-line results, such as a ps | grep mysql, will OSSEC process the results one line at a time, or will it read all the lines as a single log entry? I have set up a command like this, but nothing's coming through to OSSEC and now I'm trying to debug. My custom decoders and rules check out with ossec_logtest, so presumably the problem is happening sometime before the decoders get called. If OSSEC is reading all the lines as a single log, that might explain it, but I can't figure out how to test that as I don't have a way of reducing the command output in question to one line at a time. (I also can't post log samples, unfortunately, but like I said ossec_logtest checks out correctly.) Thanks! On Jan 20, 9:53 am, Alisha Kloc wrote: > Hi Daniel, > > I have one more quick question about howprocessmonitoringworks, if > you don't mind: How will OSSECprocesscommands that return multi-line > output? To use my previous example, if ps aux | grep mysql returns the > following lines: > > root 5481 0.0 0.0 4540 1288 ? S 17:25 0:00 /bin/ > sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/ > mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/ > mysqld/mysqld.pid > mysql 5541 0.3 1.2 136776 18016 ? Sl 17:25 0:02 /usr/ > libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql -- > pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --socket=/ > var/lib/mysql/mysql.sock > root 7793 0.0 0.0 3924 668 pts/1 R+ 17:38 0:00 grep > mysql > > will OSSEC treat that as a single line, or will it understand the > three lines are separate and apply decoders/rules accordingly? > > Thanks! > -Alisha
[ossec-list] Re: Process monitoring command list?
Hi Daniel, I have one more quick question about how process monitoring works, if you don't mind: How will OSSEC process commands that return multi-line output? To use my previous example, if ps aux | grep mysql returns the following lines: root 5481 0.0 0.0 4540 1288 ?S17:25 0:00 /bin/ sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/ mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/ mysqld/mysqld.pid mysql 5541 0.3 1.2 136776 18016 ?Sl 17:25 0:02 /usr/ libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql -- pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --socket=/ var/lib/mysql/mysql.sock root 7793 0.0 0.0 3924 668 pts/1R+ 17:38 0:00 grep mysql will OSSEC treat that as a single line, or will it understand the three lines are separate and apply decoders/rules accordingly? Thanks! -Alisha On Jan 15, 11:17 am, Daniel Cid wrote: > Hi Alisha, > > You can run whatever commands you like and write your own rules to parse > those. > By default we have just a few commands supported (with rules), but they are > very easy to extend. You can do "ps auwx |grep mysql" as you said... > > As far as the frequency of the checks, OSSEC is not time driven but event > driven, so it is generally every 1.5 or 2 minutes that it checks (can > take a bit longer > or less depending on the flow). > > Thanks, > > -- > Daniel B. Cid > dcid ( at ) ossec.net > > On Fri, Jan 8, 2010 at 4:43 PM, Alisha Kloc wrote: > > Hello, > > > I am very excited about the new process monitoring feature. However, I > > looked athttp://www.ossec.net/main/manual/manual-process-monitoring, > > as well as the release notes for v. 2.3, but didn't see a list of > > supported commands. > > > Are all commands supported (i.e., OSSEC will run whatever command is > > put between the tags), and I just need to write decoders/ > > rules for the commands I'm interested in? Or is there a specific > > subset of commands OSSEC can run with this feature? Also, how complex > > can the commands be? Can they be piped together (such as ps aux | grep > > mysqld)? Or is it just the base command with arguments? > > > I also noticed in another post that Daniel Cid said the command output > > is checked every 1-2 minutes depending on the flow of the logs. What > > does that mean? Is there a timer, or is it tied to another check, or > > what? > > > Thanks in advance! > > -Alisha Kloc
[ossec-list] Process monitoring command list?
Hello, I am very excited about the new process monitoring feature. However, I looked at http://www.ossec.net/main/manual/manual-process-monitoring, as well as the release notes for v. 2.3, but didn't see a list of supported commands. Are all commands supported (i.e., OSSEC will run whatever command is put between the tags), and I just need to write decoders/ rules for the commands I'm interested in? Or is there a specific subset of commands OSSEC can run with this feature? Also, how complex can the commands be? Can they be piped together (such as ps aux | grep mysqld)? Or is it just the base command with arguments? I also noticed in another post that Daniel Cid said the command output is checked every 1-2 minutes depending on the flow of the logs. What does that mean? Is there a timer, or is it tied to another check, or what? Thanks in advance! -Alisha Kloc
[ossec-list] Re: Solaris BSM to OSSEC Instructions?
Hi Wim, Thanks for the link! Does that mean that there is no way to do this at all on Solaris machines earlier than 10? (We have a variety.) Cheers, -Alisha On Dec 17, 5:38 am, Wim Remes wrote: > Alisha, > > Solaris (10 only!) has an option to dump BSM logs to > syslog.http://www.cuddletech.com/blog/pivot/entry.php?id=647 > > configure this, point ossec to the syslog (format is obviously syslog) > and you're done. > > Cheers, > > Wim > > > > On Wed, Dec 16, 2009 at 11:37 PM, Alisha Kloc > wrote: > > Hello, > > > Are there instructions anywhere for setting up OSSEC to read Solaris > > BSM audit logs? As of v. 1.5, OSSEC lists support for Solaris BSM, and > > I've found posts by people who say they are doing it, but nowhere can > > I find instructions on how to actually make it happen. > > > Can I just point OSSEC at the directory where BSM stores its binary > > logs? If so, what log format must be specified in the tag > > in the configuration file? Or do I need a script which translates BSM > > binary logs to another format? If so, what options/tags/commands/etc > > are needed to get the records formatted correctly in the output file, > > so that OSSEC can parse the logs? > > > Thanks in advance for your help! > > -Alisha > > -- > Wim Remes > Security Afficionado
[ossec-list] Solaris BSM to OSSEC Instructions?
Hello, Are there instructions anywhere for setting up OSSEC to read Solaris BSM audit logs? As of v. 1.5, OSSEC lists support for Solaris BSM, and I've found posts by people who say they are doing it, but nowhere can I find instructions on how to actually make it happen. Can I just point OSSEC at the directory where BSM stores its binary logs? If so, what log format must be specified in the tag in the configuration file? Or do I need a script which translates BSM binary logs to another format? If so, what options/tags/commands/etc are needed to get the records formatted correctly in the output file, so that OSSEC can parse the logs? Thanks in advance for your help! -Alisha
[ossec-list] Re: Timestamps to the millisecond
Odd... looks like my original reply never showed up. I did try comparing the timestamp in the database to the timestamp in the alert log, and saw a difference of up to four seconds sometimes. This still doesn't answer my question, though - I don't know if the reason for the difference is because OSSEC is stamping the alert and recording it in its log, then writing it to the database and stamping it there (which shouldn't take four seconds), or because OSSEC is stamping the log and passing the information to MySQL which then timestamps it (which also shouldn't take four seconds). The only answer this rules out is that OSSEC is writing to the alert log and MySQL at the same time. I also can't come up with any good reason why there is a four-second difference, unless OSSEC is like Snort in that it keeps its own time and never checks the system clock, and therefore gets ahead while MySQL uses the system clock (or vice versa). So, unfortunately, I'm still quite baffled... On Nov 18, 9:09 am, "dan (ddp)" wrote: > Have you tried comparing the timestamp in the mysql database to the timestamp > in the alert log? > > On Tue, Nov 17, 2009 at 8:02 PM, Alisha Kloc wrote: > > Hello, > > > I wanted to ask my question again after seeing a reply to my > > suggestion in the feedback forum. Daniel Cid posted there that the > > manager does in fact timestamp the events, but I still can't figure > > out where this happens or how. Is what shows up in the database the > > timestamp generated by the manager? Is the timestamp in the database > > generated by MySQL, and the manager timestamp used for a different > > form of reporting? We need to know in order to correctly report on our > > timestamping capabilities, but I can't find this information > > anywhere... > > > Thanks! > > -Alisha > > > On Nov 3, 10:30 am, Alisha Kloc wrote: > >> Hello, > > >> We recently noticed that OSSEC doesn't appear to have the ability to > >> timestamp events in milliseconds. This led to an examination of how > >> OSSEC timestamps its events, but we couldn't figure that out either. > >> I've done some searching on this, but haven't had any luck. > > >> Does anyone know where the timestamps in an OSSEC MySQL database come > >> from? Are they inserted by MySQL's automatic now() function? Does > >> OSSEC have any control over the timestamps? Are the timestamps in any > >> way related to the time logged in the syslog from which OSSEC is > >> pulling the event, or are they assigned after the event is passed to > >> the manager? Is there a way to get OSSEC events stamped with a time > >> down to themillisecond, for detailed forensic reporting? > > >> Thanks in advance! > >> -Alisha
[ossec-list] Re: Timestamps to the millisecond
Hello, I wanted to ask my question again after seeing a reply to my suggestion in the feedback forum. Daniel Cid posted there that the manager does in fact timestamp the events, but I still can't figure out where this happens or how. Is what shows up in the database the timestamp generated by the manager? Is the timestamp in the database generated by MySQL, and the manager timestamp used for a different form of reporting? We need to know in order to correctly report on our timestamping capabilities, but I can't find this information anywhere... Thanks! -Alisha On Nov 3, 10:30 am, Alisha Kloc wrote: > Hello, > > We recently noticed that OSSEC doesn't appear to have the ability to > timestamp events in milliseconds. This led to an examination of how > OSSEC timestamps its events, but we couldn't figure that out either. > I've done some searching on this, but haven't had any luck. > > Does anyone know where the timestamps in an OSSEC MySQL database come > from? Are they inserted by MySQL's automatic now() function? Does > OSSEC have any control over the timestamps? Are the timestamps in any > way related to the time logged in the syslog from which OSSEC is > pulling the event, or are they assigned after the event is passed to > the manager? Is there a way to get OSSEC events stamped with a time > down to the millisecond, for detailed forensic reporting? > > Thanks in advance! > -Alisha
[ossec-list] Timestamps to the millisecond
Hello, We recently noticed that OSSEC doesn't appear to have the ability to timestamp events in milliseconds. This led to an examination of how OSSEC timestamps its events, but we couldn't figure that out either. I've done some searching on this, but haven't had any luck. Does anyone know where the timestamps in an OSSEC MySQL database come from? Are they inserted by MySQL's automatic now() function? Does OSSEC have any control over the timestamps? Are the timestamps in any way related to the time logged in the syslog from which OSSEC is pulling the event, or are they assigned after the event is passed to the manager? Is there a way to get OSSEC events stamped with a time down to the millisecond, for detailed forensic reporting? Thanks in advance! -Alisha
[ossec-list] Re: Windows "audit log cleared" message not sent
Hi Daniel, We are currently using version 1.6.1 (we can't upgrade at this time due to policy, unfortunately). What I'm really confused about is that all other Windows events are logged and processed normally. The only thing I can think of, which I haven't managed to repeat and record, is that at one point during the tests we noticed that the Ossec Windows agent wasn't seeing the first event in any log - Application, Security, or System. It appeared to fix itself in the other two logs after a few more tests, but since the "audit log cleared" event is by default the first log in the Security log, and cannot be anything other than the first (and no other event can be the first in the Security log), perhaps that's the reason? I'll keep trying to get it to repeat and if I can, I'll post the logs... Thanks! -Alisha On Sep 18, 10:41 am, Daniel Cid wrote: > Hi Alisha, > > Which version of OSSEC are you using? It should create a log in the > ossec.log (in the agent > file) and an alert by default on the manager. > > On version 2.2 we even added additional checks for that so even if you > don't have auditing > enabled you will get the alert. Try going to 2.2 and see if it works. > > Thanks, > > -- > Daniel B. Cid > dcid ( at ) ossec.net > > On Wed, Sep 2, 2009 at 12:49 PM, Alisha Kloc wrote: > > > Hi, > > > Thanks for the reply! However, the problem isn't that we're not > > receiving an emailed alert from the OSSEC manager; we've got OSSEC > > configured to send events to a MySQL database and then pass the > > database on to another tool which pulls and tickets events, which > > works fine for all other events and rules. The problem is that the > > "audit log cleared" log entry isn't even making it into the MySQL > > database. As far as I can tell, the agent isn't picking it up on the > > client end - watching via Wireshark, there's no indication of any > > communication between the agent and the manager for that specific log > > entry, even though if I generate other events, there's immediately > > communication, and the other events arrive in the MySQL database. If I > > turn on debugging, there's also no sign in the OSSEC log to indicate > > that the agent is finding the "audit log cleared" entry, or trying to > > communicate with the manager regarding the event. > > > So the problem appears to be that the OSSEC agent can't see the > > Windows log event "audit log cleared" when it's generated into the > > log, and therefore the entry never gets passed on to the manager to > > fire rule 18118. > > > Hope that clears things up! > > > Thanks again for your help, > > -Alisha
[ossec-list] Re: Windows "audit log cleared" message not sent
We are using the default msauth_rules.xml file, version 1.33, with no modifications from the original download package, and no custom rules in the local_rules.xml file. The ossec.conf file is also default except the following addition: [path to firewall log] syslog And the Syscheck - Integrity Checking config disabled switch is set to "no", so that we are running Syscheck with all default values. Everything else is default off-the-shelf (part of the reason I'm running my tests is to determine what needs to be modified). Thanks! -Alisha On Sep 17, 2:29 pm, Cyberlink wrote: > Is there a chance you can send me an extract of your ossec.conf file and a > copy of the msauth.xml rule file? > > You can just blank out you ip addresses and I'll have a look at the configs > for you. > > Cheers. > > Louis > > On Fri, Sep 18, 2009 at 3:11 AM, Alisha Kloc wrote: > > > > > Hello, > > > I haven't heard anything in a while so I thought I'd ask again. My > > office is still having trouble with the Ossec Windows agent. For some > > reason, the Windows agent appears not to see the Security log entry > > "Windows audit log cleared." No notification of this entry is sent to > > the Ossec manager (and therefore, no rules are fired), and no activity > > is recorded in the Ossec logs when this event is generated. All other > > log events are seen and recorded normally. > > > Why would the Ossec Windows agent ignore this specific message, and > > how can I get it to see the event and pass it on to the manager? > > > Thanks very much! > > -Alisha
[ossec-list] Re: Windows "audit log cleared" message not sent
Hello, I haven't heard anything in a while so I thought I'd ask again. My office is still having trouble with the Ossec Windows agent. For some reason, the Windows agent appears not to see the Security log entry "Windows audit log cleared." No notification of this entry is sent to the Ossec manager (and therefore, no rules are fired), and no activity is recorded in the Ossec logs when this event is generated. All other log events are seen and recorded normally. Why would the Ossec Windows agent ignore this specific message, and how can I get it to see the event and pass it on to the manager? Thanks very much! -Alisha
[ossec-list] Re: Windows "audit log cleared" message not sent
Hi, Thanks for the reply! However, the problem isn't that we're not receiving an emailed alert from the OSSEC manager; we've got OSSEC configured to send events to a MySQL database and then pass the database on to another tool which pulls and tickets events, which works fine for all other events and rules. The problem is that the "audit log cleared" log entry isn't even making it into the MySQL database. As far as I can tell, the agent isn't picking it up on the client end - watching via Wireshark, there's no indication of any communication between the agent and the manager for that specific log entry, even though if I generate other events, there's immediately communication, and the other events arrive in the MySQL database. If I turn on debugging, there's also no sign in the OSSEC log to indicate that the agent is finding the "audit log cleared" entry, or trying to communicate with the manager regarding the event. So the problem appears to be that the OSSEC agent can't see the Windows log event "audit log cleared" when it's generated into the log, and therefore the entry never gets passed on to the manager to fire rule 18118. Hope that clears things up! Thanks again for your help, -Alisha
[ossec-list] Windows "audit log cleared" message not sent
Hi, I noticed recently that when I clear the security audit log on my Windows XP and Server 2003 machines, no corresponding message shows up in OSSEC (either the manager or the log) to report the event. I've tested it repeatedly, and tried stopping and restarting both the OSSEC manager and the agent, but there's still no message regarding the audit log being cleared. The Windows event appears in the Security log every time, but no messages are recorded in the OSSEC log, and when I used a packet sniffer to watch the traffic between the agent and the manager, no traffic was sent after I cleared the audit log. This suggests that for some reason, the OSSEC Windows agent is not seeing the security log entry for this event, and therefore is not sending it to the manager to be processed by the rules. The OSSEC log file looks like: 2009/09/01 18:48:30 ossec-agent(4102): INFO: Connected to the server. 2009/09/01 18:48:30 ossec-agent(1951): INFO: Analyzing event log: ‘Application’ 2009/09/01 18:48:30 ossec-agent(1951): INFO: Analyzing event log: ‘Security’ 2009/09/01 18:48:30 ossec-agent(1951): INFO: Analyzing event log: ‘System’ 2009/09/01 18:48:30 ossec-agent(1951): INFO: Analyzing file: ‘C:/ Windows/pfirewall.log’ 2009/09/01 18:48:30 ossec-agent: INFO: Started (pid: 1056) This is after stopping and restarting the manager and the agent, then clearing the security audit log three times. Nothing was added to the log after the agent was started. I noticed that another user had experienced this issue, but his solution (cycling the agent and the manager) hasn't worked for me. I'd greatly appreciate any advice on how to handle this and to find out why the agent isn't seeing this event. Thanks in advance! -Alisha
[ossec-list] OSSEC system rules?
Hi,
My department is testing a new installation of OSSEC using a MySQL
database, where we use automated MySQL queries to extract certain data
for our network. We ran across "Rule 11" ("The average number of logs
between 20:00 and 21:00 is X. We reached Y") while testing, and
realized that our query, which relies on the rule ID number to
properly extract and process the data, won't catch alerts related to
Rule 11 or any similar system "rules", as they aren't listed in the
rules XML files and don't have corresponding rule ID numbers. We've
implemented a workaround to catch Rule 11, but we were wondering if
there were any other system rules (i.e. things OSSEC will give an
alert about but which don't have a rule ID number) that we need to
look for.
Thanks very much in advance!
-Alisha
