IDS mailing list archives

RE: x-forwarded-for an IDS capability


From: "Hellman, Matthew" <Hellman.Matthew () principal com>
Date: Wed, 29 Apr 2009 17:04:42 -0500

I believe that the original poster is trying to deal with the problem of not having the true source IP address for a 
given IDS alarm specifically because of a forwarding proxy or NAT device on his own network. The mistake in my response 
may be that I'm assuming the user is concerned with his OWN source-ip-address-changing device (he mentioned downloads). 
In that scenario, if the SIM receives logs from the proper network devices, then it should correlate those events and 
the analyst can determine the original source IP. 


________________________________________
From: arian.evans () gmail com [mailto:arian.evans () gmail com] On Behalf Of Arian J. Evans
Sent: Wednesday, April 29, 2009 2:48 PM
To: Hellman, Matthew
Cc: focus-ids () securityfocus com
Subject: Re: x-forwarded-for an IDS capability

inline
On Wed, Apr 29, 2009 at 7:55 AM, Hellman, Matthew <Hellman.Matthew () principal com> wrote:
That's a nice idea, I personally haven't seen or heard of it being implemented.  If you can get a trace with the alert 
you might see it there. Also, a SIM should be able to do this for you (by means of including the firewall/router/proxy 
logs and correlating them).


Actually, no. Firewall / router / and some proxy logs are usually useless. SIMs cannot usually do this for you (though 
they could, if you fed them the right data). This is not a fault of SIMs so much as it is a fault of their 
implementation (what data sources you feed them).

Few Router / FW / IDS / IPS/ SIM situations analyze more than GET / URI data structure. Occasionally you will find some 
partial HTTP header logging, maybe cookies and such. The RFC and W3C specifications for HTTP logging specify NOT to log 
POST requests. POST is supposed to be used for both non-idempotent data (volatile or state-changing) and sensitive 
data, and neither is supposed to be captured or logged. So most WWW logging systems do not allow you to capture 
POSTdata (including even some HTTP proxies).


The main attack surface of most web vulnerabilities are in POST requests.

Most attacks today (SQLi Bots, XSS worms) occur over POST requests, AKA Form-submits in POSTdata strings.

The reduction in attack surface via GET is for a variety of reasons, including both changes in modern programming 
techniques, and increased automatic input validation by "scrubbers" (IIS URLscan), and more robust URI escaping by 
browsers.

---

Long and short: Yes, this could be done with a SIM if you have a robust proxy or WAF AND are capturing *everything* in 
the Request object.

But.....Most cannot AND do not capture the entire Request object today. So != visibility.

I still work with many fine folks wondering why they are getting hacked or have gotten hacked and why they cannot see 
what is going on.

Betwixt their firewall / router / WWW logs / Web Server Agents (URLScan type stuff) / syslog / splunk / etc. they 
cannot find the activity, which is where most traditional traffic analysis guidelines tell them to go find this sort of 
activity.

The reason for the inability to find the data, in summary, is because the vast majority of successful attacks are 
passed in POST Requests (POSTdata) and a smaller percentage in Header values, the former of which is almost never 
logged, and the latter of which are rarely to partially logged.

On a secondary note, a surprising number of folks still don't decrypt and inspect their SSL traffic (usually the most 
interesting HTTP traffic) at the network layers (via firewall, IDS, IPS) and do not seem aware that they have this 
obvious blind spot. This is so 2001. :)

Perhaps the current generation of technologies that can share SSL certs will solve this whether or not people realize 
it is getting solved.

That or everyone will buy a WAF and implement it correctly.

Or start blocking all this Port 80 and 443 craziness.

Cheerio,

-- 
Arian Evans

"There's of course been the hookers and the cocaine, there's been a
lot of mistakes, and a lot of lessons we had to learn, and most of all
there's been a lot of World of Warcraft."

George Broussard, 2009


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Connect () principal com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.




Current thread: