Intruder Alert

Evan Jennings, IBM TPF Development

As the Internet becomes ever more pervasive in our everyday lives, we hear more and more news reports about servers and networks that go down because of malicious activity. Some of the devious attacks unleashed by hackers would make most system administrators sweat. Don't let these reports send you into a panic! TPF gives you a powerful suite of features that help you to detect, avoid, or eliminate the unwanted attention of intruders.

The functions of firewall support ( TPF PUT 11 and APAR PJ28213), connection limiting (APAR PJ28493), and traffic limiting (APAR PJ28901) combine to provide Intrusion Detection Services (IDS) and do not require any changes to application code to use them.

Firewall support lets you filter IP packets arriving from the network (Internet or intranet) based on protocol, port or IP address, or any combination thereof, defined by filtering rules in file /etc/iprules.txt. When a packet is rejected or discarded by the TPF firewall as a result of the rules, the TPF IP trace record for the packet includes a reason code. This allows you to identify and log all traffic blocked by the TPF firewall.

Speaking of TPF IP trace, there are over 20 reason codes that can appear in the IP trace for a variety of reasons besides intrusion detection, giving you another useful tool for monitoring network activity and performing problem determination.

Another form of control related to filtering that has existed since PUT 11 is the accept connection user exit (UACC), which allows the TPF installation to verify accept and activate_on_accept requests, and reject them if necessary.

Connection limiting puts a cap on the number of active connections, or sockets, that are allowed at a particular instant for a given TCP application. To use connection limiting, the application must be defined in the Network Services Database (NSD) (defined in file /etc/services) with MAXCONNIN for a TPF server or MAXCONNOUT for a TPF client. If a connection is rejected because the application is already at the connection limit, a reason code is indicated in the TPF IP trace record.

Traffic limiting gives you another tool to throttle traffic to an NSD-defined application either at the application as a whole or at the socket level. Traffic limiting is described in more detail in the "Recent TCP/IP Enhancements" TPF Systems Technical Newsletter article.

Connection limiting and traffic limiting prevent a flood of activity on one or even a handful of applications from consuming your system resources at the expense of other critical applications, so they are considered Quality of Service (QoS) functions in addition to being part of IDS. The activity that is capped can be the result of a targeted attack or just a natural burst of traffic from your user community.

A type of attack whose purpose is to stop a system from serving its users over the network or otherwise not respond normally is called a Denial of Service (DoS) attack. DoS attacks can appear in several forms. One kind is a packet flooding attack, where the recipient is simply overwhelmed with traffic to the point that normal traffic cannot flow. Most types of flood attacks are stopped by filtering, though it would be preferable to have a distributed filtering approach where the edge routers of your network have filtering rules in effect in addition to TPF. This way, flood attacks can be prevented from consuming bandwidth in your network.

Another class of DoS attack works by sending IP packets that are carefully crafted to exploit specific weaknesses known to exist in certain TCP/IP implementations. Some well-known attacks of this type for which TPF is "immunized" against include the Ping of Death (sending a huge ICMP echo message), sending IP fragments with overlapping sequence numbers, SYN attack (starting TCP handshakes, but never completing them), Land Attack (source port and IP address is the same as the destination port and IP address), and TCP RST packets received outside the advertised window. It would be unwise for us to publish a comprehensive list of DoS attacks thwarted by TPF because it would just narrow the focus of a determined hacker. Rest assured that the TPF TCP/IP stack has good protection against known attacks as well as potential future attacks.

Secure Sockets Layer (SSL) (APAR PJ27863) and Shared SSL support (APAR PJ28118) should also be mentioned. SSL is not part of IDS per se, but SSL provides tools for encrypting data at the socket level. SSL differs from the previously mentioned system functions in that it works through an application programming interface (API), so it must be coded in a C/C++ application in order to use it. What you gain over a nonsecure socket connection is data privacy (no one but the recipient can understand the data), data integrity (any tampering with the data is detected), and authentication (you know without question who you are communicating with). See < "Make Sure Your System Is Securely Fastened While Traffic Is Flowing" in the Third Quarter 2001 issue of the TPF Systems Technical Newsletter for more information about SSL.

With the proper use of the powerful tools of IDS, SSL, UACC, and the built-in DoS attack prevention, the TPF system is an extremely uninviting place for intruders.

Intruder alert canceled!