This is kind of cool, we can atleast stop future attacks. Also we can
place honeypot and fine tune ossec for SQL injection kind of attack.
--
Sent from my iPhone
On Feb 5, 2011, at 11:52 AM, Michael Starks > wrote:
Exactly. The first injection connection can be bad. I have run
systems
tha
Oops. Meant to reply to Michael's post - also I had a 'typo' and added
"HIDS" (OSSEC is a HIDS...DUH) - I just meant "HIPS (inline)"
On Sat, Feb 5, 2011 at 9:01 AM, Jeremy Lee wrote:
> That gets me thinking - any chance Daniel and the crew would consider
> implementing a HIPS/HIDS (inline) exten
That gets me thinking - any chance Daniel and the crew would consider
implementing a HIPS/HIDS (inline) extension for OSSEC? That would be
awesome... Of course, we have already mentioned ModSecurity. There's another
one that looks really promising called "AppSensor" (check the OWASP pages -
it's al
Exactly. The first injection connection can be bad. I have run systems
that were found to be vulnerable to SQL injection. OSSEC detected the
attack, but we were being hit from multiple IPs over a long time at a
low rate. Active response wouldn't have helped. We were able to use
OSSECs logs (and
On 02/04/2011 09:46 PM, tanishk lakhaani wrote:
> Yes, the active response works on the basis of this only...When u
> launch a scan, a few attacks will acually pass thru, then only the agent
> will forward the corresponding logs to the OSSEC Server, who will then
> decide whether to use Active Resp
On 02/04/2011 11:51 PM, Jeremy Lee wrote:
I think his point is that one attack 'passing' through is enough. Think
about it - if they can get an attack through that successfully commits a
DROP TABLE statement, you're already in the black. Whether you've
dropped them at that point or not doesn't re
I think his point is that one attack 'passing' through is enough. Think
about it - if they can get an attack through that successfully commits a
DROP TABLE statement, you're already in the black. Whether you've dropped
them at that point or not doesn't really matter because they've accomplished
wha
Yes, the active response works on the basis of this only...When u launch a
scan, a few attacks will acually pass thru, then only the agent will forward
the corresponding logs to the OSSEC Server, who will then decide whether to
use Active Response or not. Once the server decides to use active respo
On 02/04/2011 12:39 PM, tanishk lakhaani wrote:
> Well, I think that deploying active response can be a good way out to
> prevent SQL Injection based attacks. However, there may be a few issues
> related to it viz..decoders in ossec are designed to indicate a SQL
> Injection attack even in case SEL
Well, I think that deploying active response can be a good way out to
prevent SQL Injection based attacks. However, there may be a few issues
related to it viz..decoders in ossec are designed to indicate a SQL
Injection attack even in case SELEC/UNION or any other SQL Based command is
used in the R
On 02/03/2011 12:00 PM, satish patel wrote:
> How efficient OSSEC is to stop SQL injection ? If not then i have to
> move on mod_security
>
> Is anybody out there who using ossec for sql injection ?
>
>
> Thanks,
> S
It's very good at detecting SQL injection, but your code shouldn't
() be suscep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you really want to stop SQL injection you need to update your
application code. Bolting on security will only buy you some wiggle
room, it won't solve the problem.
OSSEC is very good at recognizing keyword signatures in URL requests
after they are
See here:
http://www.ossec.net/wiki/Samples_of_attacks_detected_by_ossec
I would think the only issue here is that OSSEC is *responsive* and will
look for patterns from the logs post-occurrence. So if your app is
vulnerable to SQL injection, theoretically, the attacker would get in on the
first
How efficient OSSEC is to stop SQL injection ? If not then i have to
move on mod_security
Is anybody out there who using ossec for sql injection ?
Thanks,
S
14 matches
Mail list logo
