TCP Stream Reassembly

The stream preprocessor collects and reassembles all the packets that are part of a TCP session’s server-to-client communication stream, client-to-server communication stream, or both. This allows the rules engine to inspect the stream as a single, reassembled entity rather than inspecting only the individual packets that are part of a given stream.

Stream reassembly allows the rules engine to identify stream-based attacks, which it may not detect when inspecting individual packets. You can specify which communication streams the rules engine reassembles based on your network needs. For example, when monitoring traffic on your web servers, you may only want to inspect client traffic because you are much less likely to receive malicious traffic from your own web server.

In each TCP policy, you can specify a comma-separated list of ports to identify the traffic for the stream preprocessor to reassemble. If adaptive profile updates are enabled, you can also list services that identify traffic to reassemble, either as an alternative to ports or in combination with ports.

You can specify ports, services, or both. You can specify separate lists of ports for any combination of client ports, server ports, and both. You can also specify separate lists of services for any combination of client services, server services, and both. For example, assume that you wanted to reassemble the following:

  • SMTP (port 25) traffic from the client

  • FTP server responses (port 21)

  • telnet (port 23) traffic in both directions

You could configure the following:

  • For client ports, specify 23, 25

  • For server ports, specify 21, 23

Or, instead, you could configure the following:

  • For client ports, specify 25

  • For server ports, specify 21

  • For both ports, specify 23

Additionally, consider the following example which combines ports and services and would be valid when adaptive profile updates are enabled:

  • For client ports, specify 23

  • For client services, specify smtp

  • For server ports, specify 21

  • For server services, specify telnet

Negating a port (for example, !80) can improve performance by preventing the TCP stream preprocessor from processing traffic for that port.

Although you can also specify all as the argument to provide reassembly for all ports, Cisco does not recommend setting ports to all because it may increase the amount of traffic inspected by this preprocessor and slow performance unnecessarily.

TCP reassembly automatically and transparently includes ports that you add to other preprocessors. However, if you do explicitly add ports to TCP reassembly lists that you have added to other preprocessor configurations, these additional ports are handled normally. This includes port lists for the following preprocessors:

  • FTP/Telnet (server-level FTP)

  • DCE/RPC

  • HTTP Inspect

  • SMTP

  • Session Initiation Protocol

  • POP

  • IMAP

  • SSL

Note that reassembling additional traffic types (client, server, both) increases resource demands.