We accept patches. http://bitbucket.org/dcid/ossec-hids
On Tue, Mar 8, 2011 at 2:23 PM, Lars Oberg <[email protected]> wrote: > Hi Gutsy / Jeromy, > > Using a pipe delimited list of host names will be too much work to maintain > going forward, since there are around 100 different hosts involved, and they > do change. Creating an initial pipe delimited list of host names would not > be very difficult, it is the maintenance I am concerned with. But like I > said, it is not a very big deal for me to just disable this particular rule. > > But I am surprised that I can't match with a regex on the hostname ("l807" > below in the line "Mar 8 11:04:49 l807 kernel: Kernel log daemon > terminating."). I could very easily write a regex that matches the host > names in question: > > OSSEC HIDS Notification. > 2011 Mar 08 11:04:50 > > Received From: (pos-vm) 10.1.1.152->/var/log/messages > Rule: 5113 fired (level 7) -> "System is shutting down." > Portion of the log(s): > > Mar 8 11:04:49 l807 kernel: Kernel log daemon terminating. > > > > --END OF NOTIFICATION > > > Thanks again for your help on this. > > Lars > > On 3/8/2011 10:15 AM, Jeremy Lee wrote: > > Also, if the concern is changing/deleting/adding hostnames, there might be a > way to come up with a script to edit the rules file directly. Of course, I'm > not sure how much work/dev has been done in this area. It sure would be a > nice feature though (i.e. Web GUI frontend) > > On Tue, Mar 8, 2011 at 10:10 AM, Jeremy Lee <[email protected]> wrote: >> >> Lars, >> >> If the list of hostnames doesn't change often and is pretty static, the >> most immediate option is just to add them to the rule using <hostname> or >> what not. >> >> Shouldn't be too hard to create a list of hostnames in "piped" format, >> i.e. "host1|host2|host3|host4" - especially if they are ordered. Just write >> up a perl/bash/python script to increment and print the pipe. >> >> Of course, that's assuming the hosts are numbered in order. It probably >> wouldn't hurt to keep a maintained list/inventory anyway :) >> >> >> On Tue, Mar 8, 2011 at 10:01 AM, Gurtaj Singh <[email protected]> >> wrote: >>> >>> Hi Lars, >>> Ok so now i know what u need exactly. The thing is the default decoder >>> (iptables decoder in this case-since its a kernel message)does not >>> extract srcip's as u said. >>> But also notice how the alert itself doesnt show an IP address. >>> If the alert doesnt show an IP-address u cant make a regex for an IP >>> address. One thing i noticed in the alerts is the machine name(something >>> like l807) Im assuming every machine has its own IP and so in that case >>> u can do it by machine names and not IP-subnets. Machine name is >>> referred to as hostname in ossec. >>> So u can specify what host shutdowns u wanna see and which ones u dont. >>> >>> Hope that helps...Ill see if i can make a rule for that.In order to do >>> that i'll have to see if u edited the decoder or not..(so that my rule >>> is coherent) >>> Can u test this alert in a logtest envirnoment and send me the result >>> Basically run ossec-logtest >>> thanks >>> >>> On Tue, 2011-03-08 at 09:41 -0800, Lars Oberg wrote: >>> > Hello Gutsy, >>> > >>> > The problem is how to disable the email alerts for given IP subnets / >>> > ranges - not totally disable the alerts. I have already totally >>> > disabled the alerts since I do not know how to do it by IP subnets. >>> > Please read my original e-mail. >>> > >>> > Lars >>> > >>> > On 3/8/2011 7:32 AM, Gurtaj Singh wrote: >>> > > Hey Lars, >>> > > I just looked into this >>> > > and this is all u need to do(try it and let me know if it works) >>> > > >>> > > <group name="shut"> >>> > > <rule id="700200" level="5"> >>> > > <if_sid>5113</if_sid> >>> > > <description>dont need this</description> >>> > > </rule> >>> > > </group> >>> > > (------put above in ur local_rules.xml file--------------) >>> > > FYI: i suggest that u do this but there is another alternative to >>> > > this(which is sorta pro.xD) >>> > > What u can do is edit the real file where the 5113 rule is(I checked >>> > > its >>> > > syslog_rules.xml) and make a small little bash script that will do >>> > > this >>> > > change for u. So, if ever with a new update ur changes to >>> > > syslog_rules >>> > > gets overwritten u can use the bash script to make that change again. >>> > > this way u can make rules for unknown stuff in local_rules.xml and >>> > > not >>> > > repeat the stuff already assigned rules. Sounds more efficient but >>> > > needs >>> > > some scripting. >>> > > >>> > > >>> > > On Mon, 2011-03-07 at 15:28 -0800, Lars Oberg wrote: >>> > >> Ok, great. Yes, it is the "Kernel log daemon terminating" message: >>> > >> >>> > >> This is the alert in the alert.log: >>> > >> ** Alert 1299259678.72480: mail - >>> > >> syslog,linuxkernel,system_shutdown, >>> > >> 2011 Mar 04 09:27:58 (pos-vm) 10.1.1.152->/var/log/messages >>> > >> Rule: 5113 (level 7) -> 'System is shutting down.' >>> > >> Src IP: (none) >>> > >> User: (none) >>> > >> Mar 4 09:27:57 l807 kernel: Kernel log daemon terminating. >>> > >> >>> > >> Here is the email: >>> > >> OSSEC HIDS Notification. >>> > >> 2011 Mar 04 09:27:58 >>> > >> >>> > >> Received From: (pos-vm) 10.1.1.152->/var/log/messages >>> > >> Rule: 5113 fired (level 7) -> "System is shutting down." >>> > >> Portion of the log(s): >>> > >> >>> > >> Mar 4 09:27:57 l807 kernel: Kernel log daemon terminating. >>> > >> >>> > >> >>> > >> >>> > >> --END OF NOTIFICATION >>> > >> >>> > >> Thanks, >>> > >> Lars >>> > >> >>> > >> On 3/7/2011 10:24 AM, gutsy gibbon wrote: >>> > >>> I am pretty sure i can help u with this if u tell me what is the >>> > >>> alert >>> > >>> u got...ALL i need is the one line alert...sorry i cant get it from >>> > >>> ur >>> > >>> post >>> > >>> i think the line is "Mar 4 12:47:55 l785 kernel: Kernel log daemon >>> > >>> terminating. " >>> > >>> plz confirm >>> > >>> >>> > >>> If the above is the alert--2 things >>> > >>> 1. Since u are using if_sid to check for the rule 5113 being fired >>> > >>> I >>> > >>> am sure u dont need a regex >>> > >>> 2. All u need to do is route all 5113 alerts to 100200(or w/e ) >>> > >>> So i suggest trying it with a if_sid , Description, and ur >>> > >>> preferred >>> > >>> rule level only >>> > >>> Dont use regular expressions >>> > >>> Let me know if i helped >>> > >>> >>> > >>> >>> > >>> On Mar 4, 7:46 pm, Lars Oberg<[email protected]> wrote: >>> > >>>> The host names are fixed, and I cannot change them. Yes, maybe >>> > >>>> someone >>> > >>>> else will chime in with a solution... >>> > >>>> >>> > >>>> On 3/4/2011 4:39 PM, Jeremy Lee wrote: >>> > >>>> >>> > >>>>> There might be another way... I'm sure someone will chime in if >>> > >>>>> they >>> > >>>>> have an idea. I just can't think of anything else off the top of >>> > >>>>> my >>> > >>>>> head. If anything, there would have to be a way to grab it via >>> > >>>>> the >>> > >>>>> decoder. Actually, you might be able to use<regex> if you type >>> > >>>>> in the >>> > >>>>> actual hostname<regex>785</regex> - this wouldn't be much >>> > >>>>> different >>> > >>>>> than<hostname> however. Unless you add a common prefix to all >>> > >>>>> your >>> > >>>>> servers like "POS785" etc. Then maybe you could use a regex rule >>> > >>>>> to >>> > >>>>> filter based on<regex>POS*</regex> or something like that. My >>> > >>>>> regex >>> > >>>>> is off but you get the idea. >>> > >>>>> On Fri, Mar 4, 2011 at 4:20 PM, Lars Oberg<[email protected] >>> > >>>>> <mailto:[email protected]>> wrote: >>> > >>>>> That's too bad. Maintaining that rule with about 100 hosts >>> > >>>>> names >>> > >>>>> will be too much work to be feasible, so I don't think I >>> > >>>>> have a >>> > >>>>> choice but to ignore the rule altogether. >>> > >>>>> At least I don't have to keep banging my head on this >>> > >>>>> problem >>> > >>>>> anymore. >>> > >>>>> Thanks for your help. >>> > >>>>> Lars >>> > >>>>> On 3/4/2011 3:44 PM, Jeremy Lee wrote: >>> > >>>>>> If you need to enter multiple hostnames, the delimiter is >>> > >>>>>> "|" >>> > >>>>>> Let us know what you find. >>> > >>>>>> On Fri, Mar 4, 2011 at 3:39 PM, Jeremy Lee<[email protected] >>> > >>>>>> <mailto:[email protected]>> wrote: >>> > >>>>>> Not sure what you would modify in decoder.xml to get >>> > >>>>>> the >>> > >>>>>> 5100/5113 rules to pickup source IP... Because it seems >>> > >>>>>> like >>> > >>>>>> the 5100 base rule is not relying on a decoder but >>> > >>>>>> rather >>> > >>>>>> program_name - in this case "^kernel" >>> > >>>>>> In this scenario, I *think* you may need to utilize >>> > >>>>>> <hostname> (what I had suggested in your other >>> > >>>>>> thread). The >>> > >>>>>> drawback is that you'll have to add a long list of >>> > >>>>>> hostnames... because I'm assuming this is for all those >>> > >>>>>> Linux >>> > >>>>>> boxes you're monitoring, right? >>> > >>>>>> I'm not sure if you can use regex in the<hostname> >>> > >>>>>> attribute >>> > >>>>>> but it's not difficult to test. Especially with >>> > >>>>>> ossec-logtest. >>> > >>>>>> On Fri, Mar 4, 2011 at 3:24 PM, Lars Oberg >>> > >>>>>> <[email protected]<mailto:[email protected]>> >>> > >>>>>> wrote: >>> > >>>>>> Hi Dan, >>> > >>>>>> Thanks for clarifying that. If I understand you >>> > >>>>>> correctly: even though the alert log shows the IP >>> > >>>>>> address, I cannot match on it using RegEx since it >>> > >>>>>> is not >>> > >>>>>> part of the actual message body from syslog. >>> > >>>>>> Is there another way to suppress these e-mails, or >>> > >>>>>> do I >>> > >>>>>> have to mess with the decoder, so that it decodes >>> > >>>>>> the >>> > >>>>>> source IP? >>> > >>>>>> Lars >>> > >>>>>> On 3/4/2011 2:59 PM, dan (ddp) wrote: >>> > >>>>>> Hi Lars, >>> > >>>>>> On Fri, Mar 4, 2011 at 5:54 PM, Lars >>> > >>>>>> Oberg<[email protected] >>> > >>>>>> <mailto:[email protected]>> wrote: >>> > >>>>>> Actually, it does - I tested the RegEx >>> > >>>>>> against >>> > >>>>>> the email alert, and it >>> > >>>>>> matches. But I tested with PCRE regex. Is >>> > >>>>>> there >>> > >>>>>> a different flavor regex I >>> > >>>>>> need to use? >>> > >>>>>> The OSSEC regex. >>> > >>>>>> http://www.ossec.net/doc/syntax/regex.html >>> > >>>>>> Also, if the regex is not correct, how come >>> > >>>>>> the >>> > >>>>>> other rule (100201) fires? >>> > >>>>>> 100201 Deals with the log message: "ossec: >>> > >>>>>> Agent >>> > >>>>>> started: '785->10.1.3.4'." >>> > >>>>>> That log message contains an IP address. >>> > >>>>>> 100200 deals with the log message: "Mar 4 >>> > >>>>>> 12:47:55 >>> > >>>>>> l785 kernel: >>> > >>>>>> Kernel log daemon terminating." >>> > >>>>>> That log message does not contain an IP >>> > >>>>>> address. >>> > >>>>>> On 3/4/2011 2:05 PM, dan (ddp) wrote: >>> > >>>>>> The log message in 5113 does not appear >>> > >>>>>> to >>> > >>>>>> contain an IP address: >>> > >>>>>> "Mar 4 12:47:55 l785 kernel: Kernel >>> > >>>>>> log >>> > >>>>>> daemon terminating." >>> > >>>>>> A regex for an IP would not match that >>> > >>>>>> log >>> > >>>>>> message. >>> > >>>>>> On Fri, Mar 4, 2011 at 4:57 PM, Lars >>> > >>>>>> Oberg<[email protected] >>> > >>>>>> <mailto:[email protected]>> >>> > >>>>>> wrote: >>> > >>>>>> I have a rule for which I cannot >>> > >>>>>> seem to >>> > >>>>>> disable the email alerts. Since >>> > >>>>>> SrcIp is not decoded for this rule, >>> > >>>>>> I am >>> > >>>>>> using a regex. Below is my >>> > >>>>>> local_rules.xml file (only 2 >>> > >>>>>> rules). The >>> > >>>>>> rule that doesn't fire is >>> > >>>>>> 100200, >>> > >>>>>> but the strange thing is that the >>> > >>>>>> rule >>> > >>>>>> below it (100201) is firing just >>> > >>>>>> fine, use the exact same regex to >>> > >>>>>> match >>> > >>>>>> on the IP address of the >>> > >>>>>> workstation >>> > >>>>>> I'm testing on. >>> > >>>>>> This is very confusing to me, but I >>> > >>>>>> am >>> > >>>>>> new to ossec, so I am hopefully >>> > >>>>>> just >>> > >>>>>> overlooking something simple. >>> > >>>>>> Below is also the e-mail >>> > >>>>>> notification I >>> > >>>>>> am trying to suppress as well as >>> > >>>>>> the >>> > >>>>>> contents of the alert log. >>> > >>>>>> What am I missing? >>> > >>>>>> ----- local_rules.xml ----- >>> > >>>>>> <group name="local,syslog,"> >>> > >>>>>> <rule id="100200" level="2"> >>> > >>>>>> <if_sid>5113</if_sid> >>> > >>>>>> >>> > >>>>>> <regex>(10\.\d*\.3\.\d*)|(10.1.1.152)</regex> >>> > >>>>>> <options>no_email_alert</options> >>> > >>>>>> <description>No e-mail alerts for >>> > >>>>>> work >>> > >>>>>> stations shutting >>> > >>>>>> down.</description> >>> > >>>>>> </rule> >>> > >>>>>> <rule id="100201" level="2"> >>> > >>>>>> <if_sid>503</if_sid> >>> > >>>>>> >>> > >>>>>> <regex>(10\.\d*\.3\.\d*)|(10.1.1.152)</regex> >>> > >>>>>> <options>no_email_alert</options> >>> > >>>>>> <description>No email alerts when >>> > >>>>>> work >>> > >>>>>> stations start up.</description> >>> > >>>>>> </rule> >>> > >>>>>> </group> <!-- SYSLOG,LOCAL --> >>> > >>>>>> ----- Email ----- >>> > >>>>>> OSSEC HIDS Notification. >>> > >>>>>> 2011 Mar 04 12:47:56 >>> > >>>>>> Received From: (785) >>> > >>>>>> 10.1.3.4->/var/log/messages >>> > >>>>>> Rule: 5113 fired (level 7) -> >>> > >>>>>> "System >>> > >>>>>> is shutting down." >>> > >>>>>> Portion of the log(s): >>> > >>>>>> Mar 4 12:47:55 l785 kernel: Kernel >>> > >>>>>> log >>> > >>>>>> daemon terminating. >>> > >>>>>> --END OF NOTIFICATION >>> > >>>>>> ----- Alert log (notice that 5113 >>> > >>>>>> fires, >>> > >>>>>> instead of 100200) ----- >>> > >>>>>> ** Alert 1299272104.152207: mail - >>> > >>>>>> syslog,linuxkernel,system_shutdown, >>> > >>>>>> 2011 Mar 04 12:55:04 (785) >>> > >>>>>> 10.1.3.4->/var/log/messages >>> > >>>>>> Rule: 5113 (level 7) -> 'System >>> > >>>>>> is >>> > >>>>>> shutting down.' >>> > >>>>>> Src IP: (none) >>> > >>>>>> User: (none) >>> > >>>>>> Mar 4 12:55:03 l785 kernel: Kernel >>> > >>>>>> log >>> > >>>>>> daemon terminating. >>> > >>>>>> ** Alert 1299272227.153206: - >>> > >>>>>> local,syslog, >>> > >>>>>> 2011 Mar 04 12:57:07 (785) >>> > >>>>>> 10.1.3.4->ossec >>> > >>>>>> Rule: 100201 (level 2) -> 'No >>> > >>>>>> email >>> > >>>>>> alerts when POS stations start up.' >>> > >>>>>> Src IP: (none) >>> > >>>>>> User: (none) >>> > >>>>>> ossec: Agent started: >>> > >>>>>> '785->10.1.3.4'. >>> > > >>> > >>> >>> >> > > >
