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. Paul -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 9:09 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [ISSForum] NIDS 7.0 source and destination fields Hi 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! Robert 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 [EMAIL PROTECTED] == # 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 [EMAIL PROTECTED] TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo _______________________________________________ ISSForum mailing list [EMAIL PROTECTED] TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo
