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

Re: [ISSForum] NIDS 7.0 source and destination fields



where can I find this new parameter?
How can I tuning it?

Thanks in advance
Lorenzo

----- Original Message ----- 
From: "Palmer, Paul (ISSAtlanta)" <PPalmer@xxxxxxx>
To: <robert.d.turner@xxxxxx>; <jack.chan@xxxxxxxxxxxxx>; <ISSForum@xxxxxxx>
Sent: Thursday, June 19, 2003 3:43 PM
Subject: 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.
>
> Paul
>
> -----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
>
>
> 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
> Robert.D.Turner@xxxxxx
>
> == # 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
> ISSForum@xxxxxxx
>
> TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
>
> _______________________________________________
> ISSForum mailing list
> ISSForum@xxxxxxx
>
> TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo

_______________________________________________
ISSForum mailing list
ISSForum@xxxxxxx

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