IEV Lists Source and Destination Addresses Wrong

tscislaw_2 · ‎07-10-2003

Cisco IEV v4.0(1)S37

Cisco IDS v4.0(2)S47

Cisco PIX v6.2(2)

A "TCP Upper Port Sweep" popped up on IEV today showing our webserver as the Source Address. After checking the PIX log, I find that IEV has the wrong source and destination addresses listed.

According to the PIX syslog, our webserver was the destination address. Here is a sample of the log:

WTsyslog[2003-07-10 11:48:40 ip=x.x.x.x pri=6] <190>Jul 10 2003 11:48:40: %PIX-6-302013: Built inbound TCP connection 6855503 for outside:12.16.16.118/42620 (12.16.16.118/42620) to dmz1:192.168.1.2/443 (x.x.x.x/443)

WTsyslog[2003-07-10 11:48:42 ip=x.x.x.x pri=6] <190>Jul 10 2003 11:48:42: %PIX-6-302013: Built inbound TCP connection 6855504

for outside:12.16.16.118/42621 (12.16.16.118/42621) to dmz1:192.168.1.2/443 (x.x.x.x/443)

Yet the IEV lists 12.16.16.118 as the Destination Address. This kind of traffic goes on for awhile, with the source incrementing the ports upward.

The log also shows 12 other hosts connected with our webserver in this fashion over a 1 hour period. IEV has the Source and Destination addresses reversed on these as well. (if one can believe the PIX log)

Am I missing something?

Is there something that needs to be addressed in IEV or the IDS?

Thanks,

Tony

jlin1 · ‎07-10-2003

Tony,

First, you can check if this is IDS or IEV problem by logging into sensor CLI and issue "show events" command. When this kind of traffic comes, the sensor CLI will show the corresponding events which include the attack (source) and victim (destination) ip addresses. If IEV display the same information as shown on sensor CLI, then it is IDS problem. Otherwise, it could be IEV problem.

Second, the IEV signature need to be updated to latest S47. S37 is quite old, but it should not have impact on the reversed src/dest addresses problem. You can download IEV signature update from CCO too.

Let us know how it goes.

Thanks,

Jie

tscislaw_2 · ‎07-11-2003

Jie,

Here's what I found on the IDS event log:

signature: sigId=3010 sigName=TCP Upper Port Sweep subSigId=0 version=S37

participants:

attack:

attacker:

addr: locality=OUT x.x.x.x (our webserver address)

port: 443

victim:

addr: locality=OUT 12.16.16.118

port: 42620

port: 42621

port: 42622

port: 42623

port: 42632

port: 42635

port: 42639

port: 42638

port: 42641

port: 42640

port: 42644

port: 42645

port: 42646

port: 42648

port: 42649

port: 42651

port: 42653

port: 42654

port: 42655

port: 42657

port: 42658

port: 42659

port: 42660

port: 42661

port: 42662

So, if I read that right, the IDS is saying our webserver is the "attacker". Contrary to what the PIX log shows.

Now, there are other entries of this same signature with correct attacker/victim addresses. But, these are not to our webserver (which is on a PIX DMZ) but to NAT'd addresses for our internal network hosts.

Suggestions?

Tony

mcerha · ‎07-11-2003

From all indications, the source / destination addresses are probably correct in the alarm. This looks like a probable false postive alarm. The "victim" in this case is probably using Internet Explorer to browse the "attacker" web server. To improve performance, IE uses Resets to terminate TCP connections instead of the normal graceful disconnect. Because web browsers typically make many connections to a web server, it looks to the IDS like the web client is sending many Reset packets to the web server in response to a port scan. Signature 3010 is a little different than other port scan signatures in that is looks for lots of Resets going from host A to host B. If seen, the IDS will report B as the actual attacker by flipping the source and destination addresses in the alarm. Further validation of this false positive could be made by looking at the logs of the web server for the client type. A note in the NSDB will be made to reflect this condition as a possible false positive.

tscislaw_2 · ‎07-14-2003

Sounds good to me.

Thanks for the detailed explaination.

Tony