Utilize Traffic Normalization - McAfee M-1250 - Network Security Platform Manual

McAfee® Network Security Platform 6.0
•
•
•
•
•

Utilize traffic normalization

Traffic normalization—available when the system is operating in inline mode—removes
any traffic protocol ambiguities, protecting the end systems by cleaning up potentially
harmful traffic in real time. Traffic normalization consists of two Sensor techniques:
cleaning up malformed packets, and dropping illegal packets—for example, packets where
the IP header is smaller than 20bytes, IP fragments smaller than 64K, and so on. Traffic
normalization also thwarts any attempts to evade the system while boosting attack
detection accuracy. This feature, also known as protocol scrubbing or packet scrubbing
allows Network Security Platform systems to prevent hackers from fingerprinting a host
system. Often attackers send abnormal traffic in the hope that the end system responds in
a way that allows the attacker to determine what environments and technologies are
deployed at a particular site. This makes it easier to launch subsequent attacks against
known vulnerabilities in host network hardware or software resources.
Specifically, when enabled, normalization does the following:
•
•
In both cases, Network Security Platform performs an incremental checksum of the TCP
header and regenerates the CRC integrity check value.
Note:
Settings / Sensor_Name > Advanced Scanning > TCP Settings
Option
Each rule has a response action associated with it. Response actions include
drop
(discard silently), and
Rules are analyzed from the top down and work on a first-match basis. That is,
Network Security Platform responds according to the response action associated with
the first rule it matches - no subsequent rules are considered. It follows that the most
specific rules should be added to the top of the list.
Network Security Platform ACLs are stateful. That is, connections are tracked, so if
you explicitly permit outbound HTTP requests, for example, inbound HTTP responses
that are part of the same flow are implicitly permitted as well.
Knowing your traffic is important before configuring an ACL. There are cases where
you may have to set two rules where one rule might seem sufficient. For example,
some FTP servers are configured to send AUTH requests to the client immediately
after the initial TCP handshake. AUTH requests use IDENT, thus are negotiated on a
different port (113). If you apply an outbound "deny all" ACL rule, the FTP connection
originated inbound takes a while to get established. This is because the AUTH
request (SYN) is outbound and is denied by the ACL rule.
ACLs follow strict rules of inheritance. ACL rules created at the Sensor level are
inherited at the physical port/port pair and interface level. Port-level rules are inherited
by the interface and sub-interface levels. Interface rules only apply to interfaces, and
sub-interface rules only apply to sub-interfaces.
When the TCP Timestamp option is not negotiated in the SYN/SYN_ACK packet for a
connection, but appears in any of the packets for the rest of the connection, the TCP
Timestamp is removed from the headers of these packets.
The MSS option is permitted only in the SYN/SYN_ACK packets for a TCP
connection. If any other packets in the flow contain the MSS option, the Sensor
removes it.
Packet scrubbing must be manually enabled (navigate to
); packet dropping of illegal packets is default Sensor behavior.
deny
(send a TCP reset to the source).
and enable
19
Block attacks
permit
,
/ My Company / IPS
Normalization On/Off