cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1726
Views
0
Helpful
16
Replies

BackOrifice BO2K port 4500

natehausrath
Level 1
Level 1

Hey everyone,

This event (NR-4055/2) shows up in CS-MARS from one of our ASA-SSM machines several times every day. It's always on UDP port 4500, which is used with IPSec. IntelliShield also confirms that this is probably benign, so I'm not too worried. Now, I know I can create a filter in MARS to drop the events that come in on that port, but what I would really like to do is tweak the IPS signature.

So first, is this even advisable?

And second (I'd still like to know the answer to this even if the first answer is 'no'), I can't seem to find if it is really possible to modify the signatures in a useful way or not. I've gone into the IPS Manager Express and found the signature, but it doesn't seem to have any useful ways to modify it. For instance, the engine says it's a "Trojan UDP", but it doesn't really show what that means. Is it possible to dig deeper and find exactly what this signature is looking for?

I've been trying to track down more information on all this, but I haven't found quite what I'm looking for. So forgive me if this can be found somewhere. Also, I'm still pretty new to all this, so I may not entirely understand how these things work together and what I should be able to do! So thanks for any help in advance!

3 Accepted Solutions

Accepted Solutions

Farrukh Haroon
VIP Alumni
VIP Alumni

Back Orfice which then became Bo2k, used to be one of the cool toys 'people' used to play with when I was in high school :). It has now become a 'white collar' remote administration tool like VNC or Symantec PCAnywhere. It is always recommended to tune signatures on the 'reporting device' than MARS itself. Just go to Event Action Filters on your IPS and make an exception for this signature. Use the Source/Dest IP/Ports as you see in the alert, and subtract the 'Product Alert' action.

We also see similar false positives for this signature.

http://www.bo2k.com/whatis.html

Regards

Farrukh

View solution in original post

Nate,

BO2K is a traffic analysis signature. As such, it is hardcoded and doesn't really have any parameters in the signature defintion (other than actions/events). Its most common false positive is encrypted traffic that happens to randomly match the multi-packet pattern. It is generally rare, but proves the fact that "one in a million can happen when you have billions"

Scott

View solution in original post

Any of the log packet actions WILL force an alert to be created even when product alert is not an action or produce alert was removed by a filter.

In addition the request-snmp-trap, and produce-verbose-alert actions will also force an alert to be produced.

So when creating filters to prevent an alert from being created you need to set actions to subtract to at a minimum be produce-alert, produce-verbose-alert, request-snmp-trap, and all log packet actions.

The deny actions, block actions, and reset actions can all happen without an alert, and so will not force an alert.

View solution in original post

16 Replies 16

mhellman
Level 7
Level 7

I'm not familiar with IPS Manager Express, but connecting to the sensor directly via HTTPS will show you the most complete interface. You can see all the gritty details (okay most, more than a few signatures have hidden regex patterns).

Farrukh Haroon
VIP Alumni
VIP Alumni

Back Orfice which then became Bo2k, used to be one of the cool toys 'people' used to play with when I was in high school :). It has now become a 'white collar' remote administration tool like VNC or Symantec PCAnywhere. It is always recommended to tune signatures on the 'reporting device' than MARS itself. Just go to Event Action Filters on your IPS and make an exception for this signature. Use the Source/Dest IP/Ports as you see in the alert, and subtract the 'Product Alert' action.

We also see similar false positives for this signature.

http://www.bo2k.com/whatis.html

Regards

Farrukh

Thanks! That worked perfectly!

Unfortunately, I'm still not able to really find how to dig into the signature though. I logged in through the web interface (which looks a lot like IPSME) and went to "Configuration" -> "Policies" and into the signature definitions. I searched for 4055/2 and found it. About the only thing somewhat useful I can find is when I right-click on it and go to "Edit". This still doesn't give me much information about what it is looking for specifically.

So perhaps this is just one of those signatures that has a lot of hidden information?

Thanks for your help!

Nate,

BO2K is a traffic analysis signature. As such, it is hardcoded and doesn't really have any parameters in the signature defintion (other than actions/events). Its most common false positive is encrypted traffic that happens to randomly match the multi-packet pattern. It is generally rare, but proves the fact that "one in a million can happen when you have billions"

Scott

Ahh, makes sense. Thanks for your help!

Hey everyone,

Sorry to bring this back up. For some reason I thought I had this filtered on the IPS, but I'm seeing this event show up again in MARS.

Right now, I have two separate event action filters on the IPS. Both are set as follows:

- They are enabled :P

- Using signature 4055/2 (which is the one I'm seeing on MARS)

- Filter on any IP address for both source and destination (0.0.0.0-255.255.255.255)

- Risk rating is 0-100

- Actions to subtract are: deny packet inline, deny attacker inline, produce alert

For one signature the attacker port is 4500 and the destination is any (0-65535). The other is flipped.

Now, I just just realize that I had enabled "Log attacker packets" for RR of 80-100, and I had not set this change in the subtract list of the event action filters. Would this cause the event to fire even though it's not supposed to produce an alert? If not, is there anything else special I'm missing here?

Thanks for any help again!

What is the 'Raw Event' you are receiving in MARS, can you post that? Just click the 'icon' next to the reporting device on the MARS >> Incidents Page.

Regards

Farrukh

Here it is (blanked out the IPs):

X.X.X.X/4500 --> Y.Y.Y.Y/4500 UDP BackOrifice BO2K UDP,NR-4055/2,Time:1216324397,Risk Rating:80,VLAN:0,Port List:,4500,Action:sd:ipLoggingActivated cid:logAttackerPacketsActivated

This is the only one that came in since I made the change to subtract "log attacker packets" yesterday. So perhaps that was the issue. This event has both addresses using port 4500, but I would have expected it to be filtered as well.

MARS doesn't really seem to make a distinction between the types of events received by an ids sensor. an alarm event is the same as a summary alarm event is the same as an ip log event.

So, from a MARS perspective, what you were seeing is not surprising at all and I would say you fixed it be removing that action.

actually, this isn't true. the ip log event should get mapped to event type "packet data" and event type group "info/misc" so shouldn't cause an inspection rule to fire by itself. so, I'm not sure why this action alone would generate the event you are seeing unless log packets automagically generates a "produce alert" event.

"Now, I just just realize that I had enabled "Log attacker packets" for RR of 80-100, and I had not set this change in the subtract list of the event action filters. Would this cause the event to fire even though it's not supposed to produce an alert?"

That is possible. The actions are not as independent as they might seem. For instance, you should never have "produce verbose alert" on if you don't also have "produce alert" checked. It breaks alarm summarization.

Since you're trying to filter from any source anyway, why don't you disable the signature? Perhaps I'm not understanding something about your filters (since you mention having two that are identical?)

Well, they aren't exactly identical. One of them has the source port as 4500 and the destination port as anything. The other has source port as anything and the destination port as 4500. I didn't think there was a way to combine this as one filter. Essentially what I want is:

If source port is 4500 OR destination port is 4500 (or both), ignore the event.

Any of the log packet actions WILL force an alert to be created even when product alert is not an action or produce alert was removed by a filter.

In addition the request-snmp-trap, and produce-verbose-alert actions will also force an alert to be produced.

So when creating filters to prevent an alert from being created you need to set actions to subtract to at a minimum be produce-alert, produce-verbose-alert, request-snmp-trap, and all log packet actions.

The deny actions, block actions, and reset actions can all happen without an alert, and so will not force an alert.

Excellent. Thanks for the clarification!

Just for future reference, is this documented anywhere? I've read a lot of documentation so far, but I did not remember seeing this. However, it is certainly possible that I just missed it.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: