TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ----------------------------------------------------------------------------
ISS, i have a doubt about two issues topics. 1 - PacketsPerEvent: Is The value defined at PacketsPerEvent by second or by destination. How can i know when value is reached ? Tnks in advance . Adilson Lemos. Hello Adilson, The following article explains how RealSecure uses TCP reset packets to terminate specified connections. This information applies to: RealSecure Network Sensors 3.2 and higher Fix Version: N/A Related Articles: None Solution: When you specify an RSKill as a response for an event in your policy, this tells the RealSecure Network Sensor to attempt to terminate or reset the connection responsible for generating the event. The RSKill is the only RealSecure response capable of going back through the stealth/promiscuous interface, which makes this response work well whether the NIC is in "Stealth Mode" or not. An RSKill is, simply put, a TCP packet with the RST or reset flag set. The RealSecure Network Sensor sends two of these for each RSKill. One of these is sent to the machine originating the connection, with the IP address of the target spoofed by RealSecure. The other packet is sent to the target machine, with the IP address of the originating machine also spoofed by RealSecure. What this does, in effect, is to fool both machines into closing the connection, as if the other machine requested it. A TCP Packet with the RST flag set is used for this same purpose in normal TCP communications. The result, is that after initial connection negotiations occur, RealSecure will terminate any TCP traffic for which this response is specified. An RSKill can be used to prohibit unauthorized hosts, or networks from connecting to services on specified machines, or to enforce the ban of a service such as Telnet. There are many valid uses for this, and a creative administrator can make this a valuable tool. If misconfigured, however, an RSKill can quickly become a nuisance or even a detriment to an otherwise healthy network. Care must be taken when setting this up so as not to interfere with legitimate traffic such as email. A common use of the RSKill is to setup a UDE (user-defined event) to monitor SMTP traffic for particular text in the body or header of a message, and when a match is found, to terminate that connection with an RSKill. This is mainly used to terminate virus-infected email, and is effective, unless the string happens to be common, i.e. the infamous "I Love You" VBS worm. The result is, legitimate traffic being terminated on the segment that RealSecure is monitoring, and a local Denial-of-Service attack launched by the same system that is supposed to be preventing such things. This can also interfere with mail delivery to other systems, especially if there is an email relay on the same segment. This is only one example, but there are several possible ways to misuse the RSKill feature. As a general rule, it is a good idea not to set the RSKill as a response unless it is a matter of some importance. Any UDE's should be verified for proper configuration, and an RSKill should be set as a response, only if it is absolutely necessary. As a safety precaution, the RealSecure Network Sensor also embeds what is known as a "RealSecure Kill Tag" into the packet payload. This can be read by any other RealSecure Network Sensor that the packet passes. This identifies the license holder of the Sensor from which the RSKill originated, and also contains IP information, among other things. This is to prevent a malicious user from employing this powerful tool as a DoS against a host or network. Due to the nature of the TCP protocol, an RSKill cannot be used to terminate ICMP or UDP-based traffic. Therefore, an RSKill will not work for events such as Ping Flood, Smurf, UDPBomb, or other, non TCP-based traffic. An RSKill is also ineffective against portscans, simply because, once the TCP connection is opened (if it is a full-connect portscan), the portscanner is moving to another port, and the RSKill sent by the Network Sensor does nothing. The portscanner would already have the information it needed by the initial response from the port. While the RealSecure Kill can be a powerful tool, it is also important to remember that it is not a replacement for proper firewall configuration or network security policies. How can I reduce the volume of SYNFlood alerts? Synopsis: Although the SYNFlood event is non-filterable in RealSecure, the number of events can be controlled by editing the advanced properties for SYNFlood. This information applies to: RealSecure Network Sensor 3.2 and higher only Fix Version: N/A Related Articles: 001120-0007 Solution: Due to differences in network environments, the default installation of the RealSecure Network Sensor configures the SNYFlood decode's advanced properties with low values. To correctly configure the SYNFlood decode advanced properties: 1) Baseline the approximate half-open TCP connections that occur on the network being monitored by the sensor. 2) In the RealSecure Workgroup Manager, go to Sensor-->Properties-->select your policy and customize it using the Policy Editor. 3) On the Security Events tab under the Denial of Service category, highlight SYNFlood. 4) On the right side of the screen there is an "Advanced Properties" button. By selecting that, there will be optional parameters that are configurable. These parameters are used for "filtering" the SYNFlood events so that the Workgroup Manager is not flooded with unnecessary events. Below is a description of what the optional parameters are and their purpose: --"HighWaterMark" is the number of SYNs (i.e. half-open TCP connections) to allow to wait in each port's queue for a response before implementing a random drop algorithm to free up queue entries. This number should be smaller than the size of the listen queue for your machines by some percentage. A guideline for this is 70% of the size of your listen queue, but you will need to tweak this value to find what works best for your individual network. *To configure this value, double click on the number displayed. This is the event count that RealSecure will until it triggers the first SYNFlood event. "PacketsPerEvent" is the number of SYNFlood packets seen before a single event is sent to console/database/etc. This is typically much greater than 1 to prevent a SYNFlood from also causing the sensor to flood the console with events. *To configure this value, double click on the number. This is the number that RealSecure will count until it triggers the next SYNFlood event after the "HighWaterMark" is reached. All events after that will contain this number of half-open TCP connections. Thank you, ================================================= GEORGE NAVARRETE Technical Support Engineer Internet Security Systems: www.iss.net Phone: (404)-236-2700 or 888-447-4861 Technical Support email: [EMAIL PROTECTED] Training http://education.iss.net/ Internet Security Systems Product Knowledgebase http://www.iss.net/customer_care/knowledgebase/ ================================================= -----Original Message----- From: Adilson Lemos [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 1:22 PM To: ISS Technical Support Cc: Adilson Lemos Subject: 522877 SynFlood Configuration Dear Iss, We are receiving many attacks of SynFlood in our Site. I would like know if you will have any documentation about SynFlood Configuration on RealSecure 6.0 ( Network Sensor ). How can i do RSKILL and some advanced configuration ? Tnks in advance, Adilson Lemos Analista de Seguran�a - Globo.com [EMAIL PROTECTED] (21) 2233-1022 (21) 7842-7538 - ID 199
