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'. >> > > >> > >> >> >> >
