[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ISSForum] NIDS 7.0 source and destination fields

This behavior has been with us for a long time (that is, source is the source of the packet not the attack). In old versions of RealSecure Network Sensor (3-5), it was not much of a problem as almost all signatures triggered on packets coming from the intruder. In RealSecure Network Sensor 6.5 it was a little worse, but basically just mildly annoying for most customers. When we combined Black Ice algorithms with legacy RealSecure algorithms to form RealSecure Network Sensor 7.0, we discovered two things. The first was that a lot of the Black Ice algorithms trigger on the responses seen from the server (actually on both sides of the communication). The second was that this was not a problem in Black Ice products because they report victim and intruder, not source and destination (of the packet). We wanted to change the semantics of Source and Destination at that time to be the source of the attack and the destination of the attack. However, we had a serious concern about impa!
cting our customer base and making an already potentially difficult upgrade even worse. That is, we know a lot of our customers use user-defined responses and data base mining applications to add additional value to their installations. The tools were configured for our legacy behavior. We were very concerned that if we changed the semantics of source and destination, many of our customers would be significantly impacted. To make the decision even more difficult, we felt that we could not accurately assess the risk because we did not know how widely the tools were used or what percentage made decisions on source and destination. We chose to err on the side of caution and leave the semantics of source and destination alone.

Over the last year, we have realized that the confusion our 7.0 customers have felt from the legacy semantics is greater than we expected. We have also realized that many of our customers currently believe that source IS the source of the attack. That is, our customers do not expect us to report source of the packet (and probably never have). We have brainstormed several solutions. Recently (XPU 20.13), we introduced a new tuning parameter that some of you have already discovered. This tuning parameter allows each customer to choose which semantics are most appropriate for their environment. Currently, this tuning parameter defaults to using legacy semantics. We hope that customers will experiment with the new semantics in their environment (and certainly let us know if they encounter any problems). Eventually, we will change the default behavior of our products to use the new semantics. At that time, we will advertise the change to let any customers still dependent on legac!
y semantics know that they will need to tune their sensors to maintain consistent behavior.


-----Original Message-----
From: robert.d.turner@xxxxxx [mailto:robert.d.turner@xxxxxx]
Sent: Wednesday, June 18, 2003 9:09 AM
To: jack.chan@xxxxxxxxxxxxx; ISSForum@xxxxxxx
Subject: RE: [ISSForum] NIDS 7.0 source and destination fields


Jack Chan wrote:
> Can anyone kindly suggest which tables/fields I can find the
> intruder and victim in ISSED?? 
> As I am writing code (using odbc) to extract out attackers 
> and other info. The code works for HIDS, but NIDS data will
> look a bit funny if my web server is rated as Top ten attackers
> for the month :)

I have moaned about this behaviour off and on for a couple of years
now. All credit to ISS - there was a new tuning parameter introduced
in XPU 20.13 for RSNS7.0 that fixes the 'source' and 'destination'
addresses to mean what we expect them to mean, rather than what is
technically correct!

>From the .ini file for XPU 20.13:

a) Normally, sensors report and consoles show source and destination
as the source and destination of the packet that triggered the event.
As an alternative, you can enable the Boolean tuning parameter,
pam.report.intruder-as-source, to change the semantics of source and
destination. When enabled, sensors will report and consoles will show
source and destination as the source of the attack and destination of
the attack respectively (for attack events). Likewise, for audits, 
source and destination will be the source and destination of the
client request. That is, source will be the client and destination
will be the server.

Obviously, this will only help for alerts that come in after you make
the change, but should help matters from here on in!


PS - if you are scripting results, "additional" details are in the
EventParams table, but are not that easy to extract!

Robert Turner GCIA
Security Solutions Designer & Analyst

BT Secure Business Services
T: +44 (0)113 244 5951  F: +44 (0)113 244 5657

== # include std.disclaimer =====================================

British Telecommunications plc

Registered office: 81 Newgate Street London EC1A 7AJ

Registered in England no. 1800000

This electronic message contains information from British
Telecommunications plc which may be privileged or confidential.
The information is intended to be for the use of the individual(s)
or entity named above. If you are not the intended recipient be
aware that any disclosure, copying, distribution or use of the
contents of this information is prohibited. If you have received
this electronic message in error, please notify us by telephone
or email (to the numbers or address above) immediately.

Activity and use of the British Telecommunications plc E-mail
system is monitored to secure its effective operation and for
other lawful business purposes. Communications using this system
will also be monitored and may be recorded to secure effective
operation and for other lawful business purposes.

ISSForum mailing list

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo

ISSForum mailing list

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo