[Ossec-list] No response from server to agent

[daniel.cid at gmail.com (Daniel Cid)]

Hi Alberto,

I think I know what is going on there... It's really a bug.

-When ossec receives the logs, it will remove the date, so in the
case of squid, it will remove up to the point of "1148464015.233"

-After it removes the dates, it checks if the message is duplicated.
However, when checking for the duplicates, we ignore the first
word. We do this because in the case of a syslog message, it
will have the process[pid] and the pid generally changes. It is
useful for some cases (like ssh messages, where both the parent
and child process log the same thing).

-So on your case, we are only looking only for:

10.182.35.253 TCP_DENIED/407 1726 GET http://www.google.com/ - NONE/- text/html
10.182.35.253 TCP_DENIED/407 1726 GET http://www.google.com/ - NONE/- text/html
10.182.35.253 TCP_DENIED/407 1726 GET http://www.google.com/ - NONE/- text/html

Which are all the same, so ossec thinks they are duplicate and don't
process them....

If you try different requests (for different pages for example), it will
work.

I will release a new patch version with this fix soon (including others).

For now, you may want to go to:
src/analysisd/analysisd.c

And go to the line 611 and comment the following block:

/*
if(LastMsg_Stats(lf->log) == 1)
                goto CLMEM;
            else
                LastMsg_Change(lf->log);
*/

After that, go to src/analysisd and type "make" and then copy
ossec-analysisd to /var/ossec/bin/ (on the server side).

# cd src/analysisd
# make
# cp -pr ossec-analysisd /var/ossec/bin
# /var/ossec/bin/ossec-control restart

Let me know if it helps.

Thanks,

--
Daniel B. Cid
dcid @ ( at ) ossec.net

On 5/24/06, alberto.avi at gmail.com <alberto.avi at gmail.com> wrote:
> Hi Daniel,
>     thank you in advice for your support.
>
> Daniel Cid wrote:
> > Hi Alberto,
> >
> > I don't know what may be your problem, but can you try the following
> > tests for me?
> >
> > 1- Look at /var/ossec/logs/alerts/2006/May/ossec-alerts-23.log
> > on your server and see if any alert is being generated when you
> > send a lot of the TCP_DENIED logs to the server. If the alerts is
> > being generated, then your authentication keys are correct.
> >
> Today rule 5007 (level 5) is fired ! Great, this is the first step to
> resolve my headache.
> But I'd like to see rule 5052 (level 10) fired !
> I see that you use 'if_sid' in the rule 5007 and 'if_matched_sid' in the
> rule 5052 in squid_rules.xml: what is the difference ?
>
>    ** Alert 1148462838.11742:
>    2006 May 24 11:27:18 (nabas.usinet.it)
> 10.182.35.249->/usr/local/prod/squid-2.5.STABLE12/var/logs/access.log
>    Rule: 5007 (level 5) -> 'Proxy Authentication Required: User is not
> authorized to use proxy.'
>    Src IP: 10.182.35.253
>    User: (none)
>    37 10.182.35.253 TCP_DENIED/407 1726 GET http://www.google.com/ -
> NONE/- text/html
>
> This is the default definition for rule 5052:
>   <rule id="5052" level="10" frequency="$SQUID_FREQ" timeframe="120">
>     <if_matched_sid>5007</if_matched_sid>
>     <same_source_ip />
>     <description>Multiple unauthorized attempts to use proxy.</description>
>   </rule>
>
> I tried this configuration whitout success:
> ...
>   <rule id="5052" level="10" frequency="$SQUID_FREQ" timeframe="120">
>     <if_sid>5007</if_sid>
>     <same_source_ip />
>     <description>Multiple unauthorized attempts to use proxy.</description>
>   </rule>
> ...
> and this one
> ...
>   <rule id="5052" level="10" frequency="$SQUID_FREQ" timeframe="120">
>     <if_matched_sid>5007</if_matched_sid>
>     <description>Multiple unauthorized attempts to use proxy.</description>
>   </rule>
> ...
>
> This is an example of my squid-2.5.STABLE12 access.log :
>
> 1148464013.584      0 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464013.637     53 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464014.822    239 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464014.994    171 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464015.201    207 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464015.233     31 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464017.105    197 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464017.137     31 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464018.476    702 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464018.656     94 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464018.851    194 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464018.885     34 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464019.929    304 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464020.030    101 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464021.336    407 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464021.508    172 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464021.675    167 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464021.701      0 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464021.740     38 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464023.793    427 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464024.284    491 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464024.468    103 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464024.499     30 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464027.241    865 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464027.274     33 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464028.474    895 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464028.685    120 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464028.842    157 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464028.875     32 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464030.305    222 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464030.336     31 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464031.235    899 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464031.416     41 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464031.594    178 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
> 1148464031.645     50 10.182.35.253 TCP_DENIED/407 1726 GET
> http://www.google.com/ - NONE/- text/html
>
>
> > 2-Do you get the e-mail alerts for the multiple TCP_DENIED errors?
> >
> I get the e-mail alert for the rule 5007 (level 5).
> > 3-If you are not getting alerts, make sure of the following:
> > -there is no firewall between the server and the client.
> > -If there is a firewall, make sure to open port 1514 UDP.
> > -Remember that tcpdump reads before iptables. So even if you
> > can see on tcpdump, does not garantee that the firewall is
> > allowing it.
> > -Make sure the server-ip on the agent is correct and that
> > you added the right agent IP on the server.
> > -If the firewall is not a problem, re-generate the authentication
> > keys using the manage_agents. Just go to the server, and
> > extract the keys from your agent. On your agent, past this
> > key in the import option of the manage_agents.
> >
> No firewall on the LAN and no firewall rules on the server/agent.
> > 4-If you are getting alerts, but the response is not being executed,
> > try the following (on your agent):
> >
> > /var/ossec/active-response/bin/firewall-drop.sh add "null" 1.2.3.4
> >
> Work fine.
> > And see if the IP 1.2.3.4 is being added to the drop list on iptables.
> > You can also look at
> > /var/ossec/active-response/ossec-hids-responses.log
> > For the active response logs.
> >
> > Let us know how these tests go...
> >
> > Thanks,
> >
> > --
> > Daniel B. Cid
> > dcid @ ( at ) ossec.net
> >
> >
> >
> >
> > On 5/23/06, alberto.avi at gmail.com <alberto.avi at gmail.com> wrote:
> >> Hi Ahmet,
> >>     thank you for the suggestion.
> >>
> >> ahmet ozturk wrote:
> >> > Hi Alberto,
> >> >
> >> > "TCP_DENIED/407" is matched with rule 5007 in squid rules,
> >> > and it's alert level is 5. However, in ossec.conf, it's defined
> >> > that the active-response is used if alert level >= 6. (Please see
> >> below
> >> > for the related configuration file part)
> >> > Btw, there's another rule (5052), which is fired if rule 5007 was
> >> fired
> >> > 8 times in 2 minutes for the same source IP address and it's alert
> >> > level is 10.
> >> >
> >> > I mean, if you just get "TCP_DENIED/407" once, ossec-hids will
> >> > generate an alert with level 5,
> >> > (5007) and default configuration won't use active-response because
> >> > it's configured for rules
> >> > with level >=6.
> >> > If you get the same "TCP_DENIED/407" for the same ip at least 8 times
> >> > in a 2 min. timeframe,
> >> > ossec-hids will generate an alert with level 10 (5052), and now
> >> > active-response will be used.
> >> In the Squid access.log I generate about 20-30 lines of TCP_DENIED/407
> >> for every test case that I'm runnig.
> >> In this situation the rule 5052 should be fired.
> >> > Now you have chance to change this behaviour:
> >> > * you may edit ossec.conf file, and decrease the level at which
> >> > active-respnse is used.
> >> >   (Please read docs/rules.txt in source directory for alert levels)
> >> > * you may also edit squid_rules.xml file and increase level for
> >> rule 5007
> >> > * and also you may change the SQUID_FREQ(=8) in rule 5052 in order to
> >> > decrease the
> >> >   required number of entries for the same source ip to fire this rule.
> >> >
> >> > related part
> >> > ----
> >> > <command>firewall-drop</command>
> >> > <location>defined-agent</location>
> >> > <agent_id>001</agent_id>
> >> > <level>6</level>                     <----change this------
> >> I tried <level>1</level> but no rule is loaded in iptables. :-(
> >> > <timeout>60</timeout>
> >> > </active-response>
> >> > ----
> >> >
> >> > I hope this helps.
> >> >
> >> > Regards,
> >> >
> >> > Ahmet Ozturk.
> >>
> >> Could be a certificate communication error between agent and server ?
> >> I tried to regenerate the certificate on server and import it in the
> >> agent whithout success.
> >>
> >> Thank you for you help.
> >>
> >> Alberto.
> >> _______________________________________________
> >> ossec-list mailing list
> >> ossec-list at ossec.net
> >> http://mailman.underlinux.com.br/mailman/listinfo/ossec-list
> >>
> >
>
>