Home page logo
/

basics logo Security Basics mailing list archives

Re: Protocol Specific Intrusion Detect/Prevention Systems.
From: "Albert Gonzalez" <incodeblood () gmail com>
Date: Wed, 1 Mar 2006 15:52:21 -0600

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
---------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault