Suggestions
Gareth
PHPIDS has grown into a great system now for detecting attacks, I've
got a few suggestions to make it even better:-
1. Each detection reg exp should be categorised depending which attack
vector it blocks. So for example XSS->Injection or XSS->Javascript URL
2. I don't know if this exists already because I've not checked the
source for a while but the ability to selectively choose which
expressions should be applied would be a good idea.
3. Identification of the exact malicious string should be possible,
for example:-
javascript:alert(1)//abcde skhf, the comment should be ignored and the
vector should be highlighted.
4. Detection of character set attacks should be included like UTF-7
e.g.:-
<http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php?
input=PEB1dGY3XzA%2BIj48c2NyaXB0PjxAL3V0ZjdfMD4%3D>
Thanks
Mario Heiderich
Thanks for the feedback!
The UTF7 decoding is still pretty basic - principally we'd need a conversion engine and not just plain string replacement since it is very easy to obfuscate strings by just adding arbitrary special chars - this is not caught yet but will be in the future. I will take care for that before the 0.4.7 is being released.
And kind of attack type specification is already done by the tags - but it's very unprecise. Anyway it is hard to find either the right categories and manage the correct detection. It can alwayss happen parts of a JS vector are matching SQLI rules and the other way round. Any ideas and help are very much appreciated.
Same goes for the separation of malicious input and correct input - but is this feature really needed? I mean of what use could it be to extract the evil code and leave the harmless stuff untouched. Anyway - I am going to think about this idea more deeply because meanwhile it's definitely sexy to implement a kind of IPS mode... :)
Greetings,
.mario
_______________________
php-ids.org
.ﻩﻨﺮﻪﺴ
Mario Heiderich
_______________________
php-ids.org
.ﻩﻨﺮﻪﺴ
Gareth
The reason for separating malicious and valid data isn't for IPS but
for detecting vectors within code. Your expressions may be used in
things like Firewalls or for analysing a large amount of attack data.
Just something to think about how to take it to the next level ;)
On Feb 14, 5:22 pm, "Mario Heiderich" <mario.heider...@googlemail.com>
wrote:
> now ;)
>
> On Thu, Feb 14, 2008 at 6:10 PM, Mario Heiderich <
>
>
>
> mario.heider...@googlemail.com> wrote:
> > Hey Gareth!
>
> > Thanks for the feedback!
>
> > The UTF7 decoding is still pretty basic - principally we'd need a
> > conversion engine and not just plain string replacement since it is very
> > easy to obfuscate strings by just adding arbitrary special chars - this is
> > not caught yet but will be in the future. I will take care for that before
> > the 0.4.7 is being released.
>
> > And kind of attack type specification is already done by the tags - but
> > it's very unprecise. Anyway it is hard to find either the right categories
> > and manage the correct detection. It can alwayss happen parts of a JS vector
> > are matching SQLI rules and the other way round. Any ideas and help are very
> > much appreciated.
>
> > Same goes for the separation of malicious input and correct input - but is
> > this feature really needed? I mean of what use could it be to extract the
> > evil code and leave the harmless stuff untouched. Anyway - I am going to
> > think about this idea more deeply because meanwhile it's definitely sexy to
> > implement a kind of IPS mode... :)
>
> > Greetings,
> > .mario
>
>
> > > Hi all
>
> > > PHPIDS has grown into a great system now for detecting attacks, I've
> > > got a few suggestions to make it even better:-
>
> > > 1. Each detection reg exp should be categorised depending which attack
> > > vector it blocks. So for example XSS->Injection or XSS->Javascript URL
> > > 2. I don't know if this exists already because I've not checked the
> > > source for a while but the ability to selectively choose which
> > > expressions should be applied would be a good idea.
> > > 3. Identification of the exact malicious string should be possible,
> > > for example:-
> > > javascript:alert(1)//abcde skhf, the comment should be ignored and the
> > > vector should be highlighted.
> > > 4. Detection of character set attacks should be included like UTF-7
> > > e.g.:-
> > > <http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php?
christ1an
> think about this idea more deeply because meanwhile it's definitely sexy to
> implement a kind of IPS mode... :)
I don't like that. PHPIDS should remain an IDS only for the simple
reason that rsnake stated on slackers couple of days ago. There is no
way to offer a degree of protection that one may in fact rely on with
blacklists, which besides Centrifuge is what we're mainly using.
Furthermore, we'll probably never get rid of the false positive
problem. This isn't too much of an issue in IDS as it would be in IPS
because as far as IDS is concerned, malicious actions will only be
logged somehow for later analysis instead of being blocked permanently
in IP systems. The latter of course would be a severe usability issue
and moreover, if IPS mode was implemented in PHPIDS, require
unproportionally more effort to actually configurate the framework.
So please, as long as we don't invent a whitelist solution, the IPS mode
decision should definitely be up to the developer.
-
christ1an
am Donnerstag, 14. Februar 2008 um 18:10 schrieben Sie:
> Hey Gareth!
> Thanks for the feedback!
> Greetings,
> .mario
>> input=PEB1dGY3XzA%2BIj48c2NyaXB0PjxAL3V0ZjdfMD4%3D<http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php?input=PEB1dGY3XzA%2BIj48c2NyaXB0PjxAL3V0ZjdfMD4%3D>
>> >
>>
>> Thanks
>> >
>>
Gareth
but the separation of valid and attack data is a useful feature IMO. I
can see so many uses for it. For example gather statistics on common
attack vectors etc
>
> >> Hi all
>
> >> PHPIDS has grown into a great system now for detecting attacks, I've
> >> got a few suggestions to make it even better:-
>
> >> 1. Each detection reg exp should be categorised depending which attack
> >> vector it blocks. So for example XSS->Injection or XSS->Javascript URL
> >> 2. I don't know if this exists already because I've not checked the
> >> source for a while but the ability to selectively choose which
> >> expressions should be applied would be a good idea.
> >> 3. Identification of the exact malicious string should be possible,
> >> for example:-
> >> javascript:alert(1)//abcde skhf, the comment should be ignored and the
> >> vector should be highlighted.
> >> 4. Detection of character set attacks should be included like UTF-7
> >> e.g.:-
> >> <http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php?
>
> >> Thanks
Mario Heiderich
Furthermore, we'll probably never get rid of the false positive
problem.
We did with 0.4.6 - after seven days of live testing on a high traffic site we have had _no_ false alert at all. I couldn't beleive it myself and tested several times but that's the way it is.
The statistics option is interesting - and i am desperately waiting for Phil from Blogsecurity.net who seems to be having great plans in work. Also I don't want to deny my interest in providing an optional IPS mode. We'd have to discuss how such a thing could look like but we should not block the thought.
_______________________
php-ids.org
.ﻩﻨﺮﻪﺴ
christ1an
>> but the separation of valid and attack data is a useful feature IMO. I
>> can see so many uses for it. For example gather statistics on common
>> attack vectors etc
Well, I admittedly do not see too much use in this but I won't refuse
your request just because of that. It's a small feature that some
might want for e.g. analysis and statistics and others don't. If we
manage to solve the parsing problem mentioned by mario on this, it'll
be included somewhere in the next releases.
> We did with 0.4.6 - after seven days of live testing on a high traffic site
> we have had _no_ false alert at all. I couldn't beleive it myself and tested
> several times but that's the way it is.
Ghehe come on, that is an illusion ;) one: seven days doesn't mean
anything. I won't deny that we're good but we're not free from
defects. two: Accurate intrusion protection requires precisely this.
three: Even if you're right, lets wait for the myvideo.de results. I
don't know which high traffic site you were referring to but I think
myvideo has more. Not necessarily more attackers though... so lets
see.
> Also I don't want to deny my interest in providing an optional IPS mode.
> We'd have to discuss how such a thing could look like but we should not
> block the thought.
I'm not blocking any thoughts. My point is that I don't like to
develop and promote things if I'm not convinced of it's quality
myself. I am standing for both detection and protection but being good
at the first doesn't mean being good at the second too.
Protection with blacklists, even though they are good, has been proven
numerous times to be bad and doomed to fail >by design<. Thats what we
use to emphasise all day, am I right? So why should we adopt this
principle then?
Actually, it must not even be optional. It's simply not a feature but
a totally different aim that requires different approaches.
--
christ1an
am Donnerstag, 14. Februar 2008 um 23:48 schrieben Sie: