Re: Protocol Specific Intrusion Detect/Prevention Systems.

["Albert Gonzalez" <incodeblood () gmail com>]

Hello Davie,

Comments in-line.

On 2/27/06, coder <elite.coder () ntlworld com> wrote:
> Hello Everyone,
>
> Some of you may have seen many of my emails on this list and the other
> lists, mainly asking about firewalls and filters.

[...snip...]

> Anyways, I have been reading a book on Intrusion Detection and Prevention,
> which covers the limitations of IDSs and IPSs... and I think I have come up
> with a great idea to improve on these, and I just want to run it by people
> that are in the security field.
>
> It seems that current IDS/IPSs have several limitations... if they are
> signature based, you have to wait for new signatures for a new attack, if
> they are anomaly based they have to be trained to the network traffic, which
> takes a while and also they are generic in the sense that they have to
> detect attacks on all protocols/services.. which means lots of
> rules/signatures to process and the signatures are not very generic in the
> sense that a signature will only detect one type of attack.

Anymore limitations that you see, beyond these two that you state? You
will be able to find limitations with ANYTHING you use, its just the
nature of things. But you don't want to put all security tasks into
one machine, it will get overwhelmed, especially the people that have
to look at the data or make business decisions regarding the data.

> My idea is to create a service specific IPS, which just monitors one
> services that it has been custom written for, so that it "fully understands"
> the service. So for example, the idea I have to the HTTP IPS will:

Well, since you said "service" then I guess SecureIIS can apply to
this. Since SecureIIS protects the IIS service. Might be something to
look into, You can download a free-trial of the software from Eeye's
website. ModSecurity might also apply to this. Check that out too.

> > Search for and store the names of all the folders within the wwwroot
> folder, then, when a 404 error is returned the IPS will check to see if the
> user was way off in folders, or just out of range.. eg:
> If the following folders were accessed that caused 404 errors were read from
> the IIS log file:
>
> \afolder\annotherfolder\index.html
> \afolder\annotherfolder\blah.html
> \afolder\index.html
>
> If these folders actually exist in the wwwroot, the IPS will just assume
> that the user mistyped the filename or they assumed a file/folder that
> didn't exist. BUT if these folders do not exist in the wwwroot folder, then
> the IPS will take it as a failed attack (after say 3 404s) and block the IP.
> The IPS will also store old folders that have been deleted (unless told not
> to, by the admin) for people that are linked to old pages that no longer
> exist for Google etc.

Damn, so attempting to view a folder, file, etc... is an attack
attempt? And your IPS will block it? I can see you being paged quite
often, that might cause blocking of legitimate traffic. That might
fall into a different category of protection schemes, since well you
know *most* (at least the ones I have used/tried) successful IPS in
the industry *are* signature based and or a mix of the two (anomaly +
signature). You get to inherit both limitations, YAY! :)

> > the IPS will scan for folders in the HTTP request that do not exist within
> wwwroot (Traversal attempt etc)
> > the IPS will also scan for SQL within a POST/GET (Possible SQL Injection)
> > the IPS will scan for lots of characters that are the same and machine
> language code (Possible buffer overflow)
>
> And other generic attacks can be scanned for, the other thing that all the
> service specific IPSs will scan for are:

> > To detect if an attacker has killed the IPS, the IPS will do an insert
> into a remote DB (where it stores alerts etc) every X mins... if the admin
> page shows that an insert has not been made in X mins, the admin knows the
> IPS was killed and also the last IP to have sent data.

There HAS to more checks in here, you can' t assume just because there
hasn't been an alert insert into the DB in X amount of time that the
sensor is down. So many things can come into play, drop in packet
volume, drop in alerts, connectivity issues with the network, etc.. So
yea, a few checks need to be implemented before I see anyone deploying
this. Also because the IPS stopped alerting doesn't mean it was killed
by an attacker. Remember that most implementations of an IPS are
inline.
> I think the service specific intrusion detection scans that I have shown
> above can be applied to all services.
>
> Please let me know if this has been tried or if it is a good/bad idea.
>
> Thanks for your input.

You say you want "service" specific IPS, but at the end of the e-mail,
still hard to see exactly what you are looking for, so you have to
really ask yourself, what is it that you are proposing here? Hell,
what do you want to SEE and PREVENT?

Hope that helps,

-Albert
> ~Davie Elliott

---------------------------------------------------------------------------
EARN A MASTER OF SCIENCE IN INFORMATION ASSURANCE - ONLINE
The Norwich University program offers unparalleled Infosec management
education and the case study affords you unmatched consulting experience.
Tailor your education to your own professional goals with degree
customizations including Emergency Management, Business Continuity Planning,
Computer Emergency Response Teams, and Digital Investigations.

http://www.msia.norwich.edu/secfocus
---------------------------------------------------------------------------