Hi Thorne,

You raise a valid concern regarding our timeouts (which is by default
10 minutes, not 5)
and it was chosen mainly based on some sshd brute force scripts (that
I had access on
the past), which gave up on a specific ip after 5/6 minutes without
response. That's why 10, so they would leave us alone for a while...

Why is it not longer? First, ips change quite often, so if the timeout
is very long you
can end up blocking valid users. Second, active responses are
dangerous and our alerts can have false positives (if you forget your
password or get multiple 404s in a small period of time, etc). To
minimize the problems caused by these false positives, we decided to
keep the value small. Our manual talks a bit about it:

http://www.ossec.net/main/manual/#active-response

*Like any security tool, ossec should be customized, and the defaults
are just what we thought would be best for the majority of users. If
in your environment you can live with the risk of being blocked for a
few days, just increase it :)


Anyway, I really liked your idea of a dynamic timeouts and I will add
it to our todo list.

Thanks,

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





On 8/21/07, Thorne Lawler <[EMAIL PROTECTED]> wrote:
>
> Jeff,
>
> ossec-list@googlegroups.com wrote on 22/08/2007 06:53:59 AM:
>
> > On Aug 20, 7:58 pm, Thorne Lawler <[EMAIL PROTECTED]> wrote:
> > > I'm sure there was some solid reasoning behind the default fixed value
> for
> > > active-response.timeout. I'd love to hear it if anyone knows what it
> was.
> > >
> > Ever heard of the term "spoofing"? Think about if someone malicious
> > spoofed the ip addresses of valid hosts and blocked them all. This
> > would be an easy way to make a server useless.
> > http://en.wikipedia.org/wiki/IP_address_spoofing
>
> https://www.trouble.net.au/~thorin/cute/suckeggs.shtml
>
> Yes, thanks, I believe I've heard of it. :-)
>
> I've got three takes on this:
> 1. If a substantial amount of spoofed traffic is coming in through your
> ISP, consider changing ISPs: Spoofing, especially for stateful (i.e. TCP
> traffic) requires some serious router subversion. If the source is local,
> your ISP needs to beef up their per-client routing controls, or possibly
> boot a troublemaker. What I'm trying to say is: any significant amount of
> spoofing is in itself a security problem. If someone is able to spoof the
> IPs of any significant number of your valid client hosts, blocking
> everything but administrative for a while might not be such a bad idea.
>
> 2. This is what the whitelist is for. If you get noise on an IP and it
> gets blocked incorrectly, you whitelist it. This is just as true for
> legitimate clients as it is for spoofing or proxy-aggregation or DHCP
> turnover or any other potential IP-identity confusion. Actual example: My
> friend is debugging his rather crufty new webDAV mechanism to maintain his
> site on my server. It spews out bazillions of 404 errors every time he
> tries to connect, and OSSEC obediently cuts him off. He complains, so I
> add him to the whitelist.
>
> 3. How is five minutes any less harmful than an hour, or a day? If someone
> is spoofing an IP, they can get that IP cut off in less than a second.
> That still means they can keep it cut off more than 99% of the time.
>
> So my question stands: Why five minutes?
>
> --
> Thorne Lawler
>
> Technical Consultant
> ICT Outsourcing Services | Infrastructure Services | Unix Storage and
> Delivery
> KAZ Group Pty Ltd
> 360 Elizabeth Street | Melbourne Victoria 3000
> (03) 9631 1747 | 0408 491 552 | Fax: (03) 9654 7334
> [EMAIL PROTECTED]  |  www.kaz-group.com
> --------------------------------------------------------------------------------
> This communication may contain confidential information and/or copyright
> material of KAZ Group Pty Ltd ABN 25 002 124 405 and its related bodies
> corporate.  It may also be the subject of legal professional privilege. If
> you
> are not an intended recipient, you must not keep, forward, copy, use, save
> or
> rely on this communication and any such action is unauthorised and
> prohibited.
> If you have received this communication in error, please reply to this
> e-mail to
> notify the sender of its incorrect delivery, and then delete both it and
> your
> reply
>
>
>
>
>
> This communication may contain confidential information and/or copyright 
> material of KAZ Group Pty Ltd ABN 25 002 124 405 and its related bodies 
> corporate.  It may also be the subject of legal professional privilege.  If 
> you are not an intended recipient, you must not keep, forward, copy, use, 
> save or rely on this communication and any such action is unauthorised and 
> prohibited.  If you have received this communication in error, please reply 
> to this e-mail to notify the sender of its incorrect delivery, and then 
> delete both it and your reply.
>

Reply via email to