snort and proxy servers

zuessh · 03-03-2004, 10:31 AM

IF snort is set to monitor a proxy server can this cause many false negatives. We have snort set to monitor our proxy server and are receiving a large amount of snort alerts. Could this be from it just passing http and html traffic? Thanks

unSpawn · 03-05-2004, 06:25 PM

What interface? What kind of FP's? Post some?

chort · 03-05-2004, 06:43 PM

A "false negative" is when a detection service fails to detect an actual attack. What you're referring to is a "false positive" which is when a dection service generates and alert of for "good stuff" that is not an attack.

To answer your question "maybe". Unless you post some details, there's no way of telling (and even if you do post details from the snort logs, you're going to need to explain how your network is setup and what "good" traffic is).

zuessh · 03-08-2004, 10:11 AM

Little background on networkwork setup; all client request to outside (http, ftp, etc.) go through proxy server. Proxy server has two nic's, internal and external (dmz). When I make a request it goes to internal nic and gets forwared to dmz nic. I have snort machine in dmz with switch configured to allow snort box to monitor all active ports in dmz (monitors serveral servers). I am using ACID.

Large number of these from external proxy address to internet address: SCAN Proxy Port 8080 attempt (ACID does not give any kind of payload)

Very large number of these from internet addresses coming from port 80 to what appears to be random high ports on external proxy address: ATTACK-RESPONSES 403 Forbidden
Payload: length = 315

000 : 48 54 54 50 2F 31 2E 31 20 34 30 33 20 41 63 63 HTTP/1.1 403 Acc
010 : 65 73 73 20 46 6F 72 62 69 64 64 65 6E 0D 0A 53 ess Forbidden..S
020 : 65 72 76 65 72 3A 20 4D 69 63 72 6F 73 6F 66 74 erver: Microsoft
030 : 2D 49 49 53 2F 35 2E 30 0D 0A 44 61 74 65 3A 20 -IIS/5.0..Date:
040 : 53 61 74 2C 20 30 36 20 4D 61 72 20 32 30 30 34 Sat, 06 Mar 2004
050 : 20 31 39 3A 31 37 3A 35 38 20 47 4D 54 0D 0A 43 19:17:58 GMT..C
060 : 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 74 65 78 ontent-Type: tex
070 : 74 2F 68 74 6D 6C 0D 0A 43 6F 6E 74 65 6E 74 2D t/html..Content-
080 : 4C 65 6E 67 74 68 3A 20 31 37 32 0D 0A 0D 0A 3C Length: 172....<
090 : 68 74 6D 6C 3E 3C 68 65 61 64 3E 3C 74 69 74 6C html><head><titl
0a0 : 65 3E 44 69 72 65 63 74 6F 72 79 20 4C 69 73 74 e>Directory List
0b0 : 69 6E 67 20 44 65 6E 69 65 64 3C 2F 74 69 74 6C ing Denied</titl
0c0 : 65 3E 3C 2F 68 65 61 64 3E 0A 3C 62 6F 64 79 3E e></head>.<body>
0d0 : 3C 68 31 3E 44 69 72 65 63 74 6F 72 79 20 4C 69 <h1>Directory Li
0e0 : 73 74 69 6E 67 20 44 65 6E 69 65 64 3C 2F 68 31 sting Denied</h1
0f0 : 3E 54 68 69 73 20 56 69 72 74 75 61 6C 20 44 69 >This Virtual Di
100 : 72 65 63 74 6F 72 79 20 64 6F 65 73 20 6E 6F 74 rectory does not
110 : 20 61 6C 6C 6F 77 20 63 6F 6E 74 65 6E 74 73 20 allow contents
120 : 74 6F 20 62 65 20 6C 69 73 74 65 64 2E 3C 2F 62 to be listed.</b
130 : 6F 64 79 3E 3C 2F 68 74 6D 6C 3E ody></html>

This one caught my attention but from the payload appears to be a false positive: WEB-MISC http directory traversal
payload: length = 278

000 : 47 45 54 20 2F 69 6D 61 67 65 73 2F 68 6F 74 6C GET /images/hotl
010 : 69 6E 65 2E 67 69 66 20 48 54 54 50 2F 31 2E 30 ine.gif HTTP/1.0
020 : 0D 0A 56 69 61 3A 20 31 2E 30 20 50 52 43 37 39 ..Via: 1.0 PRC79
030 : 57 32 4B 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A W2K..User-Agent:
040 : 20 4D 6F 7A 69 6C 6C 61 2F 34 2E 30 20 28 63 6F Mozilla/4.0 (co
050 : 6D 70 61 74 69 62 6C 65 3B 20 4D 53 49 45 20 36 mpatible; MSIE 6
060 : 2E 30 3B 20 57 69 6E 64 6F 77 73 20 4E 54 20 34 .0; Windows NT 4
070 : 2E 30 29 0D 0A 48 6F 73 74 3A 20 77 77 77 2E 6F .0)..Host: www.o
080 : 64 79 73 73 65 79 73 65 61 66 6F 6F 64 2E 63 6F dysseyseafood.co
090 : 6D 0D 0A 41 63 63 65 70 74 3A 20 2A 2F 2A 0D 0A m..Accept: */*..
0a0 : 52 65 66 65 72 65 72 3A 20 68 74 74 70 3A 2F 2F Referer: http://
0b0 : 77 77 77 2E 6F 64 79 73 73 65 79 73 65 61 66 6F www.odysseyseafo
0c0 : 6F 64 2E 63 6F 6D 2F 2E 2E 2F 72 65 63 69 70 65 od.com/../recipe
0d0 : 73 2F 62 75 74 74 65 72 73 61 75 63 65 2E 68 74 s/buttersauce.ht
0e0 : 6D 6C 0D 0A 41 63 63 65 70 74 2D 4C 61 6E 67 75 ml..Accept-Langu
0f0 : 61 67 65 3A 20 65 6E 2D 75 73 0D 0A 43 6F 6E 6E age: en-us..Conn
100 : 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D 41 6C 69 ection: Keep-Ali
110 : 76 65 0D 0A 0D 0A ve....

Thse are also coming from outisde sites via port 80 to a random high port on the proxy server: ATTACK-RESPONSES Invalid URL
payload: length = 355

000 : 48 54 54 50 2F 31 2E 30 20 34 30 30 20 42 61 64 HTTP/1.0 400 Bad
010 : 20 52 65 71 75 65 73 74 0D 0A 53 65 72 76 65 72 Request..Server
020 : 3A 20 41 6B 61 6D 61 69 47 48 6F 73 74 0D 0A 4D : AkamaiGHost..M
030 : 69 6D 65 2D 56 65 72 73 69 6F 6E 3A 20 31 2E 30 ime-Version: 1.0
040 : 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 ..Content-Type:
050 : 74 65 78 74 2F 68 74 6D 6C 0D 0A 43 6F 6E 74 65 text/html..Conte
060 : 6E 74 2D 4C 65 6E 67 74 68 3A 20 31 34 35 0D 0A nt-Length: 145..
070 : 45 78 70 69 72 65 73 3A 20 46 72 69 2C 20 30 35 Expires: Fri, 05
080 : 20 4D 61 72 20 32 30 30 34 20 31 37 3A 35 38 3A Mar 2004 17:58:
090 : 35 36 20 47 4D 54 0D 0A 44 61 74 65 3A 20 46 72 56 GMT..Date: Fr
0a0 : 69 2C 20 30 35 20 4D 61 72 20 32 30 30 34 20 31 i, 05 Mar 2004 1
0b0 : 37 3A 35 38 3A 35 36 20 47 4D 54 0D 0A 43 6F 6E 7:58:56 GMT..Con
0c0 : 6E 65 63 74 69 6F 6E 3A 20 63 6C 6F 73 65 0D 0A nection: close..
0d0 : 0D 0A 3C 48 54 4D 4C 3E 3C 48 45 41 44 3E 0A 3C ..<HTML><HEAD>.<
0e0 : 54 49 54 4C 45 3E 49 6E 76 61 6C 69 64 20 55 52 TITLE>Invalid UR
0f0 : 4C 3C 2F 54 49 54 4C 45 3E 0A 3C 2F 48 45 41 44 L</TITLE>.</HEAD
100 : 3E 3C 42 4F 44 59 3E 0A 3C 48 31 3E 49 6E 76 61 ><BODY>.<H1>Inva
110 : 6C 69 64 20 55 52 4C 3C 2F 48 31 3E 0A 54 68 65 lid URL</H1>.The
120 : 20 72 65 71 75 65 73 74 65 64 20 55 52 4C 20 22 requested URL "
130 : 26 23 34 37 3B 74 65 73 74 26 23 34 36 3B 68 74 /test.ht
140 : 6D 6C 22 2C 20 69 73 20 69 6E 76 61 6C 69 64 2E ml", is invalid.
150 : 3C 70 3E 0A 3C 2F 42 4F 44 59 3E 3C 2F 48 54 4D <p>.</BODY></HTM
160 : 4C 3E 0A L>.

These are just a few that immediately caught my eye. My thoughts are that some client pc's may have spyware or be infected with virus and are forced to go throgh the proxy server. My paranoid side says the proxy server has been compromised and it attacking other servers.

Thanks

unSpawn · 03-08-2004, 12:48 PM

ATTACK-RESPONSES 403 Forbidden
Payload: length = 315

000 : 48 54 54 50 2F 31 2E 31 20 34 30 33 20 41 63 63 HTTP/1.1 403 Acc
010 : 65 73 73 20 46 6F 72 62 69 64 64 65 6E 0D 0A 53 ess Forbidden..S
020 : 65 72 76 65 72 3A 20 4D 69 63 72 6F 73 6F 66 74 erver: Microsoft
030 : 2D 49 49 53 2F 35 2E 30 0D 0A 44 61 74 65 3A 20 -IIS/5.0..Date:

SID1201: flow:from_server,established; content:"HTTP/1.1 403";

This one caught my attention but from the payload appears to be a false positive: WEB-MISC http directory traversal
payload: length = 278
(...)
090 : 6D 0D 0A 41 63 63 65 70 74 3A 20 2A 2F 2A 0D 0A m..Accept: */*..
0a0 : 52 65 66 65 72 65 72 3A 20 68 74 74 70 3A 2F 2F Referer: http://
0b0 : 77 77 77 2E 6F 64 79 73 73 65 79 73 65 61 66 6F www.odysseyseafo
0c0 : 6F 64 2E 63 6F 6D 2F 2E 2E 2F 72 65 63 69 70 65 od.com/../recipe
0d0 : 73 2F 62 75 74 74 65 72 73 61 75 63 65 2E 68 74 s/buttersauce.ht
0e0 : 6D 6C 0D 0A 41 63 63 65 70 74 2D 4C 61 6E 67 75 ml..Accept-Langu
0f0 : 61 67 65 3A 20 65 6E 2D 75 73 0D 0A 43 6F 6E 6E age: en-us..Conn
100 : 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D 41 6C 69 ection: Keep-Ali
110 : 76 65 0D 0A 0D 0A ve....

SID1113: flow:to_server,established; content: "../";

Thse are also coming from outisde sites via port 80 to a random high port on the proxy server: ATTACK-RESPONSES Invalid URL
payload: length = 355
(...)
0b0 : 37 3A 35 38 3A 35 36 20 47 4D 54 0D 0A 43 6F 6E 7:58:56 GMT..Con
0c0 : 6E 65 63 74 69 6F 6E 3A 20 63 6C 6F 73 65 0D 0A nection: close..
0d0 : 0D 0A 3C 48 54 4D 4C 3E 3C 48 45 41 44 3E 0A 3C ..<HTML><HEAD>.<
0e0 : 54 49 54 4C 45 3E 49 6E 76 61 6C 69 64 20 55 52 TITLE>Invalid UR
0f0 : 4C 3C 2F 54 49 54 4C 45 3E 0A 3C 2F 48 45 41 44 L</TITLE>.</HEAD
100 : 3E 3C 42 4F 44 59 3E 0A 3C 48 31 3E 49 6E 76 61 ><BODY>.<H1>Inva
110 : 6C 69 64 20 55 52 4C 3C 2F 48 31 3E 0A 54 68 65 lid URL</H1>.The
120 : 20 72 65 71 75 65 73 74 65 64 20 55 52 4C 20 22 requested URL "
(...)

SID1200: content:"Invalid URL"; nocase; flow:from_server,established;

... in essence you can say that in some cases simple string match doesn't mean much all by itself. This is why IDS automation is such a PITA, you will always need educated personnel to investigate incidents.
If you want to track rules like these you could copy the rule (up the SID into the private 10000 range please) and make Snort track the stream for say the next 30 packets in and outbound. That way you'll get part of the conversation to investigate (check the "Snort writing rules" howto).

These are just a few that immediately caught my eye. My thoughts are that some client pc's may have spyware or be infected with virus and are forced to go throgh the proxy server. My paranoid side says the proxy server has been compromised and it attacking other servers.
I don't see evidence for either option. All I see is (example 0) IIS returning an error, someone using a wacky referrer (ex 1) and another invalid request (ex 2). IMHO unless you got additional "evidence" these reports do not establish a case for malicious access to the server or proxy subversion all by themselves.

chort · 03-08-2004, 01:17 PM

I agree with unSpawn. It looks like you probably have some compromised internal clients that are attempting to attack outside sites. There's an outside chance the proxy itself is compromised, although that's unlikely. The simple way to figure it out is to put a Snort sensor on the inside as well and correlate the traffic.

The incoming data in the DMZ is coming from 80/tcp and going to >1023/tcp because that's how the client/server model for HTTP works. HTTP daemons listen on port 80/tcp and send back all responses from that same port. Clients open a port greater than 1023/tcp in order to make an outbound HTTP request and listen for return data on that same "high port".

Since all you get on the DMZ segment is the proxy address as the src/dst of the "attack packets", you really need a Snort sensor on your LAN segment as well (at least monitoring your proxy traffic) so that you can correlate bad outbound requests with the actual internal client that made them.

zuessh · 03-08-2004, 04:20 PM

Thanks, let me post one more and get some thoughts on it.

These are showing up from outside addresses port 80 to a random high port on the proxy server: DDOS shaft client to handler

payload: length = 293

000 : 48 54 54 50 2F 31 2E 30 20 32 30 30 20 4F 4B 0D HTTP/1.0 200 OK.
010 : 0A 53 65 72 76 65 72 3A 20 41 70 61 63 68 65 2F .Server: Apache/
020 : 31 2E 33 2E 32 37 20 28 55 6E 69 78 29 0D 0A 4C 1.3.27 (Unix)..L
030 : 61 73 74 2D 4D 6F 64 69 66 69 65 64 3A 20 57 65 ast-Modified: We
040 : 64 2C 20 32 38 20 4A 61 6E 20 32 30 30 34 20 32 d, 28 Jan 2004 2
050 : 32 3A 30 33 3A 34 36 20 47 4D 54 0D 0A 45 54 61 2:03:46 GMT..ETa
060 : 67 3A 20 22 66 65 31 34 64 2D 32 62 2D 34 30 31 g: "fe14d-2b-401
070 : 38 33 31 63 32 22 0D 0A 41 63 63 65 70 74 2D 52 831c2"..Accept-R
080 : 61 6E 67 65 73 3A 20 62 79 74 65 73 0D 0A 43 6F anges: bytes..Co
090 : 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A 20 34 33 ntent-Length: 43
0a0 : 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 ..Content-Type:
0b0 : 69 6D 61 67 65 2F 67 69 66 0D 0A 44 61 74 65 3A image/gif..Date:
0c0 : 20 53 61 74 2C 20 30 36 20 4D 61 72 20 32 30 30 Sat, 06 Mar 200
0d0 : 34 20 30 38 3A 34 35 3A 35 39 20 47 4D 54 0D 0A 4 08:45:59 GMT..
0e0 : 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 6B 65 65 70 Connection: keep
0f0 : 2D 61 6C 69 76 65 0D 0A 0D 0A 47 49 46 38 39 61 -alive....GIF89a
100 : 01 00 01 00 80 00 00 FE D5 66 00 00 00 21 F9 04 .........f...!..
110 : 00 00 00 00 00 2C 00 00 00 00 01 00 01 00 00 02 .....,..........
120 : 02 44 01 00 3B .D..;

Quote:

If you want to track rules like these you could copy the rule (up the SID into the private 10000 range please) and make Snort track the stream for say the next 30 packets in and outbound. That way you'll get part of the conversation to investigate (check the "Snort writing rules" howto).

I'm sure I will ned help with this. thanks again

unSpawn · 03-08-2004, 05:25 PM

Thanks, let me post one more and get some thoughts on it.
These are showing up from outside addresses port 80 to a random high port on the proxy server: DDOS shaft client to handler
With all due respect, but I kinda posted the rule contents in bold to say something like you should read the Snort rules... Isn't that hard and you get a feel for what packets needs to trip a certain rule.
If you're strictly interested in "real" malicious then you could call a lot of Snort rules "weak".
Some just need a *port* to fire off an alert, which behaviour IMNSHO is just as bad as portsentry in that it doesn't do additional payload checks (the real forte of Snort, something portsentry can't do).
Here we got one: SID 230, the DDoS Shaft Client to handler rule (ddos.rules file):
[font=fixed]alert tcp $EXTERNAL_NET any -> $HOME_NET 20432 (msg:"DDOS shaft client to handler"; flow:established; reference:arachnids,254; classtype:attempted-dos; sid:230; rev:2;)[/fixed]

In human language: gimme alert, where packet and:
transport layer protocol equals TCP, and
is part of ongoing connection, and
remote address equals any, and
port equals 20432.

Hmm. Not that "strong" a rule I think.

I'm sure I will ned help with this.
NP. Just think what you want to trigger and for how long. Then build the rules using the Snort Writing Rules HOWTO and post 'em if you got probs.

I agree with unSpawn. It looks like you probably have some compromised internal clients that are attempting to attack outside sites.
I disagree. I said these incidents are, when viewed isolated, no "evidence" of compromises. Hell, anyone could "program" the wrong referrer or get IIS to return an error page. Of course if you got a constant stream of one LAN workstation methodically probing subnets or host paths, OK, then you got a case.

There's an outside chance the proxy itself is compromised, although that's unlikely.
How unlikely? Again, from my POV these packet logs do not provide ammo for determining subversion nor for the opposite.

chort · 03-08-2004, 06:41 PM

Quote:

I agree with unSpawn. It looks like you probably have some compromised internal clients that are attempting to attack outside sites.
I disagree. I said these incidents are, when viewed isolated, no "evidence" of compromises. Hell, anyone could "program" the wrong referrer or get IIS to return an error page. Of course if you got a constant stream of one LAN workstation methodically probing subnets or host paths, OK, then you got a case.

Well, given that the first was trying to access an invalid virtual host, it's probably trying to connect to an HTTP server via IP rather than passing the Host: header with an actual HTTP agent, but of course that's only a guess. The third example was a request for test.html and it didn't exist, so again likely an automated tool looking for exploitable test pages, but could be a legitimate user just being curious (or a really stale link).

BTW I didn't mean to put words in your mouth there.

Quote:

There's an outside chance the proxy itself is compromised, although that's unlikely.
How unlikely? Again, from my POV these packet logs do not provide ammo for determining subversion nor for the opposite.

This is based purely on the fact that a) there are a lot more clients than proxy servers, so much higher probability that if one out of the sample is compromised, it will be a client and b) there's a ton of malware circulating that would have to be downloaded by using a browser to connect to sites, something that the proxy wouldn't be doing (at least, I *hope* no one is logging into the proxy locally and firing up a browser).

You're right, there's no way of telling just from Snort, though. Also, the percentage probability can't be quantified, just "more" or "less" likely.