Permissive packet filtering
You can construct a packet filter so that it stops packets destined for specified services from passing through an interface. This allows access to all services except those that you specifically block because they may be used to attack your site's systems. A drawback with this approach is that it may implicitly allow an attack on an internal server which is providing a service of which you have no knowledge. ``A packet filter that blocks a limited number of services'' shows a filter that drops packets that are destined for the telnetd, ftpd and rlogind servers but which allows packets for all other services to pass. A packet filter that blocks a limited number of services NOTE: As the normal operation of a permissive packet filter is to prevent access to local services from outside, you will usually apply such a filter to the incoming stream of a gateway interface. For PPP, this corresponds to the passin filter. ``Services which you may wish to restrict'' lists some services to which you may want to consider restricting access using a packet filter. Services which you may wish to restrict Service Port/protocol Description systat 11/tcp Display output from ps systat 11/udp Display output from ps netstat 15/tcp Display output from netstat netstat 15/udp Display output from netstat telnet 23/tcp telnet server (in.telnetd) port nameserver 53/tcp DNS server (in.named) port nameserver 53/udp DNS server (in.named) port tftp 69/udp TFTP server (in.tftpd) port finger 79/tcp finger server (in.fingerd) port link 87/tcp ttylink port sunrpc 111/tcp RPC bind server (rpcbind) port sunrpc 111/udp RPC bind server (rpcbind) port exec 512/tcp Remote execution server (in.rexecd) port login 513/tcp Remote login server (in.rlogind) port shell 514/tcp Remote shell server (in.rshd) port printer 515/tcp Print services port uucp 540/tcp UUCP daemon port nfsd 2049/udp NFS server daemon (nfsd) port xserver0 6000/tcp First X server port NOTE: TFTP service is probably most vulnerable to attack. If possible, block access to TFTP from outside your organization's networks. See also: filter(4) inetd(1Mtcp) inetd.conf(4tcp) services(4tcp)

Ddosing your victim
G-48: TCP SYN Flooding and IP Spoofing Attacks September 20, 1996 18:00 GMT PROBLEM: Two "underground magazines" for intruders have recently published code to conduct denial-of-service attacks by creating TCP "half open" connections. PLATFORM: Any system connected to the Internet and providing TCP-based network services such as a Web server, FTP server, or mail server is potentially subject to this attack. DAMAGE: Systems providing TCP-based services to the Internet community may be unable to provide those services while under attack and for some time after the attack ceases. SOLUTION: See the bulletin below for information on how to protect your site from these attacks. VULNERABILITY Scripts are actively being used to attack sites connected to ASSESSMENT: the Internet. TCP services are not harmed by the attack, only the ability to provide those services is impaired. But, these attack scripts are widely available, so the available solutions should be considered for all systems providing critical services. [Begin CERT Bulletin] ============================================================================= CERT(sm) Advisory CA-96.21 Original issue date: September 19, 1996 Last revised: -- Topic: TCP SYN Flooding and IP Spoofing Attacks ------------------------------------------------------------------------------ *** This advisory supersedes CA-95:01. *** Two "underground magazines" have recently published code to conduct denial-of-service attacks by creating TCP "half-open" connections. This code is actively being used to attack sites connected to the Internet. There is, as yet, no complete solution for this problem, but there are steps that can be taken to lessen its impact. Although discovering the origin of the attack is difficult, it is possible to do; we have received reports of attack origins being identified. Any system connected to the Internet and providing TCP-based network services (such as a Web server, FTP server, or mail server) is potentially subject to this attack. The consequences of the attack may vary depending on the system; however, the attack itself is fundamental to the TCP protocol used by all systems. If you are an Internet service provider, please pay particular attention to Section III and Appendix A, which describes step we urge you to take to lessen the effects of these attacks. If you are the customer of an Internet service provider, please encourage your provider to take these steps. This advisory provides a brief outline of the problem and a partial solution. We will update this advisory as we receive new information. If the change in information warrants, we may post an updated advisory on comp.security.announce and redistribute an update to our cert-advisory mailing list. As always, the latest information is available at the URLs listed at the end of this advisory. - ----------------------------------------------------------------------------- I. Description When a system (called the client) attempts to establish a TCP connection to a system providing a service (the server), the client and server exchange a set sequence of messages. This connection technique applies to all TCP connections--telnet, Web, email, etc. The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. Here is a view of this message flow: Client Server ------ ------ SYN--------------------> <--------------------SYN-ACK ACK--------------------> Client and server can now send service-specific data The potential for abuse arises at the point where the server system has sent an acknowledgment (SYN-ACK) back to client but has not yet received the ACK message. This is what we mean by half-open connection. The server has built in its system memory a data structure describing all pending connections. This data structure is of finite size, and it can be made to overflow by intentionally creating too many partially-open connections. Creating half-open connections is easily accomplished with IP spoofing. The attacking system sends SYN messages to the victim server system; these appear to be legitimate but in fact reference a client system that is unable to respond to the SYN-ACK messages. This means that the final ACK message will never be sent to the victim server system. The half-open connections data structure on the victim server system will eventually fill; then the system will be unable to accept any new incoming connections until the table is emptied out. Normally there is a timeout associated with a pending connection, so the half-open connections will eventually expire and the victim server system will recover. However, the attacking system can simply continue sending IP-spoofed packets requesting new connections faster than the victim system can expire the pending connections. In most cases, the victim of such an attack will have difficulty in accepting any new incoming network connection. In these cases, the attack does not affect existing incoming connections nor the ability to originate outgoing network connections. However, in some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative. The location of the attacking system is obscured because the source addresses in the SYN packets are often implausible. When the packet arrives at the victim server system, there is no way to determine its true source. Since the network forwards packets based on destination address, the only way to validate the source of a packet is to use input source filtering (see Appendix A). II. Impact Systems providing TCP-based services to the Internet community may be unable to provide those services while under attack and for some time after the attack ceases. The service itself is not harmed by the attack; usually only the ability to provide the service is impaired. In some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative. III. Solution There is, as yet, no generally accepted solution to this problem with the current IP protocol technology. However, proper router configuration can reduce the likelihood that your site will be the source of one of these attacks. Appendix A contains details about how to filter packets to reduce the number of IP-spoofed packets entering and exiting your network. It also contains a list of vendors that have reported support for this type of filtering. NOTE to Internet Service Providers: We STRONGLY urge you to install these filters in your routers to protect your customers against this type of an attack. Although these filters do not directly protect your customers from attack, the filters do prevent attacks from originating at the sites of any of your customers. We are aware of the ramifications of these filters on some current Mobile IP schemes and are seeking a position statement from the appropriate organizations. NOTE to customers of Internet service providers: We STRONGLY recommend that you contact your service provider to verify that the necessary filters are in place to protect your network. Many networking experts are working together to devise improvements to existing IP implementations to "harden" kernels to this type of attack. When these improvements become available, we suggest that you install them on all your systems as soon as possible. This advisory will be updated to reflect changes made by the vendor community. IV. Detecting an Attack Users of the attacked server system may notice nothing unusual since the IP-spoofed connection requests may not load the system noticeably. The system is still able to establish outgoing connections. The problem will most likely be noticed by client systems attempting to access one of the services on the victim system. To verify that this attack is occurring, check the state of the server system's network traffic. For example, on SunOS this may be done by the command: netstat -a -f inet Too many connections in the state "SYN_RECEIVED" indicates that the system is being attacked. ........................................................................... Appendix A - Reducing IP Spoofed Packets 1. Filtering Information - ------------------------- With the current IP protocol technology, it is impossible to eliminate IP-spoofed packets. However, you can take steps to reduce the number of IP-spoofed packets entering and exiting your network. Currently, the best method is to install a filtering router that restricts the input to your external interface (known as an input filter) by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network to prevent a source IP spoofing attack from originating from your site. The combination of these two filters would prevent outside attackers from sending you packets pretending to be from your internal network. It would also prevent packets originating within your network from pretending to be from outside your network. These filters will *not* stop all TCP SYN attacks, since outside attackers can spoof packets from *any* outside network, and internal attackers can still send attacks spoofing internal addresses. We STRONGLY urge Internet service providers to install these filters in your routers. In addition, we STRONGLY recommend customers of Internet service providers to contact your service provider to verify that the necessary filters are in place to protect your network. 2. Vendor Information - ---------------------- The following vendor(s) have reported support for the type of filtering we recommend and provided pointers to additional information that describes how to configure your router. If you need more information about your router or about firewalls, please contact your vendor directly. Cisco ----- Refer to the section entitiled "ISP Security Advisory" on http://www.cisco.com for an up-to-date explanation of how to address TCP SYN flooding on a Cisco router. NOTE to vendors: If you are a router vendor who has information on router capabilities and configuration examples and you are not represented in this list, please contact the CERT Coordination Center at the addresses given in the Contact Information section below. We will update the advisory after we hear from you. 3. Alternative for routers that do not support filtering on the inbound side - ---------------------------------------------------------------------------- If your vendor's router does not support filtering on the inbound side of the interface or if there will be a delay in incorporating the feature into your system, you may filter the spoofed IP packets by using a second router between your external interface and your outside connection. Configure this router to block, on the outgoing interface connected to your original router, all packets that have a source address in your internal network. For this purpose, you can use a filtering router or a UNIX system with two interfaces that supports packet filtering. Note: Disabling source routing at the router does not protect you from this attack, but it is still good security practice to follow. On the input to your external interface, that is coming from the Internet to your network, you should block packets with the following addresses: * Broadcast Networks: The addresses to block here are network 0 (the all zeros broadcast address) and network 255.255.255.255 (the all ones broadcast network). * Your local network(s): These are your network addresses * Reserved private networks: The following networks are defined as reserved private networks and no traffic should ever be received from or transmitted to these networks through a router: 10.0.0.0 127.0.0.0 172.16.0.0 192.168.0.0