Re: [ossec-list] 404 error
Hey Once I make changes to ossec config at windows client, it stops permanently? What to do! On Fri, Jun 29, 2012 at 6:26 AM, Michael Starks ossec-l...@michaelstarks.com wrote: On 06/28/2012 12:51 PM, Mike Disley wrote: Thx. Also just noticed this link not working either; http://ossec.net/ossec-docs/**OSSEC-book-Ch02_SA240.pdfhttp://ossec.net/ossec-docs/OSSEC-book-Ch02_SA240.pdf Trend just changed the site. It will probably take a little while for things to settle down.
Re: [ossec-list] Force ossec server and client to use TCP only
And did anyone faced lost UDP packets problem? пятница, 29 июня 2012 г., 15:59:49 UTC+4 пользователь dan (ddpbsd) написал: On Fri, Jun 29, 2012 at 2:16 AM, kay kay kay.d...@gmail.com wrote: Is it possible to use only TCP protocol? UDP packets are not reliable and frequently are being lost and some active-response not executed. I've tried to find an option for ossec server to listen TCP port, but found only TCP option for clients (syslog protocol). It's not currently possible.
Re: [ossec-list] Multiple Agents with 1 Key
Dan, Thank you very much for all of your information. You've been very helpful. I just have 1 more quick question then I'll stop bugging you, for now. :) Is there any other way to manage the keys or do some sort of automated agent key management? I know there is ossec-authd that would work on an internal system with individual IPs for each host but I didn't know how/if that would work with a mixed environment of agents and multiple agents coming from 1 IP. Thanks again, Eric On Wednesday, June 27, 2012 12:21:06 PM UTC-4, dan (ddpbsd) wrote: On Wed, Jun 27, 2012 at 12:15 PM, Eric wrote: Thank you for the information. Is there any better way that you can think of architecting this setup? One of the main concerns is that location1 will reuse Host1's key for Host2 and then it completely confuse those monitoring the alerts. You could setup local OSSEC servers and have them forward their alerts to a central OSSEC server. Tell the locations that re-using keys is bad, and they shouldn't do it. Write it out in crayon if you have to. On Wednesday, June 27, 2012 10:43:47 AM UTC-4, dan (ddpbsd) wrote: Hello, I am working on a deployment that is going to involve multiple external locations (behind a NAT) with all of them talking back to 1 server. Location 1 will be a mixture of Linux and Windows agents. There will be ~10 hosts at this location all going out of a single NAT, 1.1.1.1. Location 2 will have ~5 Linux machines going out a single NAT, 2.2.2.2. Location 3 will have ~20 Windows machines going out a single NAT, 3.3.3.3. So far I have gotten this general setup to work by creating an individual key for each host and setting the IP address to any. However, I am curious if there is anyway to set up 1 key per location and have all agents share that one key. So I can give location 1 keyA and they put that on all of the agents and it is able to talk by to the portal. I kinda sorta gotten this to work by creating Location1 on the OSSEC server and giving it an IP of 1.1.1.1/32. I know if I just do 1.1.1.1 it says duplicate key error but if I put a CIDR around it, it has worked sometimes and other times it hasn't. So that is my first question. Is this scenario doable? No. Each individual agent requires its own unique key. My second question is if I am able to make the above setup work, is there anyway I can distinguish the individual agents from one another? I know by default, if we have the hostnames set up correctly, I will see Location1 as the location but I will see host1 somewhere in the log to distinguish it. Are there any additional fields that I can force OSSEC to send with the logs, such as the internal IP? This is especially the case for integrity checking alerts since it doesn't even give the hostname on those. Can I force it to? Thanks in advance for any advice/information you all have.
Re: [ossec-list] Multiple Agents with 1 Key
On Fri, Jun 29, 2012 at 9:17 AM, Eric eric.luel...@gmail.com wrote: Dan, Thank you very much for all of your information. You've been very helpful. I just have 1 more quick question then I'll stop bugging you, for now. :) Is there any other way to manage the keys or do some sort of automated agent key management? I know there is ossec-authd that would work on an internal system with individual IPs for each host but I didn't know how/if that would work with a mixed environment of agents and multiple agents coming from 1 IP. ossec-authd is pretty much all we have. It sets the IP to 'any' for every new host though, so it may work for you. Might be worth testing, but I don't have a lot of experience with it so my insight is very limited. Thanks again, Eric On Wednesday, June 27, 2012 12:21:06 PM UTC-4, dan (ddpbsd) wrote: On Wed, Jun 27, 2012 at 12:15 PM, Eric wrote: Thank you for the information. Is there any better way that you can think of architecting this setup? One of the main concerns is that location1 will reuse Host1's key for Host2 and then it completely confuse those monitoring the alerts. You could setup local OSSEC servers and have them forward their alerts to a central OSSEC server. Tell the locations that re-using keys is bad, and they shouldn't do it. Write it out in crayon if you have to. On Wednesday, June 27, 2012 10:43:47 AM UTC-4, dan (ddpbsd) wrote: Hello, I am working on a deployment that is going to involve multiple external locations (behind a NAT) with all of them talking back to 1 server. Location 1 will be a mixture of Linux and Windows agents. There will be ~10 hosts at this location all going out of a single NAT, 1.1.1.1. Location 2 will have ~5 Linux machines going out a single NAT, 2.2.2.2. Location 3 will have ~20 Windows machines going out a single NAT, 3.3.3.3. So far I have gotten this general setup to work by creating an individual key for each host and setting the IP address to any. However, I am curious if there is anyway to set up 1 key per location and have all agents share that one key. So I can give location 1 keyA and they put that on all of the agents and it is able to talk by to the portal. I kinda sorta gotten this to work by creating Location1 on the OSSEC server and giving it an IP of 1.1.1.1/32. I know if I just do 1.1.1.1 it says duplicate key error but if I put a CIDR around it, it has worked sometimes and other times it hasn't. So that is my first question. Is this scenario doable? No. Each individual agent requires its own unique key. My second question is if I am able to make the above setup work, is there anyway I can distinguish the individual agents from one another? I know by default, if we have the hostnames set up correctly, I will see Location1 as the location but I will see host1 somewhere in the log to distinguish it. Are there any additional fields that I can force OSSEC to send with the logs, such as the internal IP? This is especially the case for integrity checking alerts since it doesn't even give the hostname on those. Can I force it to? Thanks in advance for any advice/information you all have.
[ossec-list] Simple(?) - Forensics (historical?) but live
Here's hoping there is a simple answer to this. I know of the technique to run the forensics into ossec-logtest. And that is a fabulous tool/method. But, I want to take a previous years data - BO - (before ossec) and run it through and have ossec actually process it into the appropriate log files (and perhaps mysql or spunk) just as if it was live data. In other words, process it like live data so it is logged and saved in the database/splunk. The reason for this is simple - to build up the past couple of years of raw data into a searchable/historical reference. I know ossec-logtest can be piped into anything, but before I start trying it, I am wondering if you could use the same method of catting the files but into live ossec? Off to try some tests - if I find anything, I will let you know. If anyone else can think of a way to do it, would love to hear. thanks ~k
Re: [ossec-list] Force ossec server and client to use TCP only
On 29.06.2012 01:16, kay kay wrote: Is it possible to use only TCP protocol? UDP packets are not reliable and frequently are being lost and some active-response not executed. I've tried to find an option for ossec server to listen TCP port, but found only TCP option for clients (syslog protocol). You could use a syslog client which can do TCP and analyze the logs on the server side.
[ossec-list] Deciding the Level to Set Log Alerts
I would like to determine the level to set Log Alerts in my OSSEC installation. How was each event assigned a severity level? How have you all decided the level to set your log alerts? I am concerned about logging too many events but missing legitimate security events. Your opinions will help. Thank you.
Re: [ossec-list] Simple(?) - Forensics (historical?) but live
Hi, You can try to pipe the data into ossec's syslog daemon with cat and netcat On Fri, Jun 29, 2012 at 7:07 PM, Kat uncommon...@gmail.com wrote: Here's hoping there is a simple answer to this. I know of the technique to run the forensics into ossec-logtest. And that is a fabulous tool/method. But, I want to take a previous years data - BO - (before ossec) and run it through and have ossec actually process it into the appropriate log files (and perhaps mysql or spunk) just as if it was live data. In other words, process it like live data so it is logged and saved in the database/splunk. The reason for this is simple - to build up the past couple of years of raw data into a searchable/historical reference. I know ossec-logtest can be piped into anything, but before I start trying it, I am wondering if you could use the same method of catting the files but into live ossec? Off to try some tests - if I find anything, I will let you know. If anyone else can think of a way to do it, would love to hear. thanks ~k -- MVH/With regards Frank -- Name: Frank Stefan Sundberg Solli E-mail: frankste...@gmail.com Web:http://0x41.me GPG:684119F4
[ossec-list] HKEY_LOCALMACHINE
Hello, Any ideas what would cause HKLM to become locked? Possibly timed along with the scheduled installation of OSSEC. Every installed just fine up to and following OSSEC; then HKLM becomes locked or read only. Global problem with two common user accounts. No other HIVE is locked, just HKLM. Thanks Brad
