0blivion nº2:(PACKETS.txt):15/03/2000 << Back To 0blivion nº 2

<< Prev file: NEWS2.txt

Next file: PING.TXT >>

_____________________________________________________ / Oblivion Underground Magazine \ / Issue 2 15/04/2000 \ ▌ Introduction to Packets and Firewalls ▌ \ by Slider / \_____________________________________________________/ - SOF - AN INTRODUCTION TO PACKETS AND FIREWALLS - An Introduction to IP Packets Normally, a firewall does not look at the content of a packet, but only at the header. An IP packet consists of a formatted header, followed by the packet payload. The payload itself may include a further header containing session-level protocol information (for example, a TCP or UDP header). The following are the important fields in the IP header: - The source address - The destination address - The fragmentation indicator (in the flag field) - The protocol ID The source address, destination address and protocol ID are used by the firewall filters to define which machines can access which particular service. The fragmentation indicator is used to instruct a Firewall on how to handle fragmented packets. Different types of networks support different maximum packet sizes, so sometimes a router has to break a packet into smaller fragments to pass it from one network to another. The packet-filtering firewalls have to be aware of packet fragmentation because only the first fragment contains the header information of higher-layer protocols, such as UDP and TCP. Later fragments in a packet could override header fields, such as the source and destination port. The IP specifications allow packets of very small sizes. The minimum packet size that can be sent is 68 octets. The problem here is that this packet size is not enough to carry the complete information for upper layer protocols. This leads to an attack technique called the tiny fragment attack. The reassembly algorithm contains a mechanism by which later fragments can overwrite the data portions of previous fragments. An attacker could create a series of packets in which the first fragment will be allowed by the filter, but later fragments will overwrite relevant information (such as TCP source and destination ports). In this way the filtering rules can be bypassed if you allow fragmented packets. This is called the overlapping fragment attack. Ideally you should configure your firewall to only support nonfragmented packets. - An Introduction to ICMP Packets ICMP is a protocol designed to communicate errors and information between hosts that are processing IP datagrams. You can find the specification of ICMP in RFC 792. It is used for purposes like informing that a host is unreachable or that a sender is sending packets too fast. The ICMP messages that most people are familiar with are the ones that are generated by the ping command, but in fact there are many different types of ICMP messages. Ping generates an ICMP echo request message and expects to receive an echo reply message in response. Echo request is a relatively safe message, but any of the ICMP messages can be used by an outsider in order to gain some knowledge of your network or to directly attack your system. Also, like every protocol that you allow, ICMP messages can be used to overwhelm your systems in a denial of service attack. Each ICMP message consists of a type plus a code, both of which are small integer values. Unlike the higher layer protocols, such as TCP or UDP, there is not a source port nor a destination port, just the message type and code. When configuring firewall filters you could disable all ICMP messages in both directions, if you don't care about the different types of message. This may make it difficult for you and your users to troubleshoot access problems, but will be safer and simpler for you. You also have to consider that some ICMP messages are used by network management applications (principally echo and address mask). * Echo and Echo Reply Messages Description: The echo (also called echo request) message is used to check if a host is up or down. When a host receives the request, it sends back an echo reply message. These messages are usually generated by a ping command, but may also be generated by a network management station that is polling the nodes of a network. Firewall Considerations: Echo request can be used by an outsider to map your network. I suggest you allow the outgoing echo request and incoming echo reply. Disable the incoming echo request and outgoing echo reply. You could consider enabling this facility to some key hosts, such as the router of your network provider. You might allow incoming pings to the nonsecure adapter of the SNG. * Destination Unreachable Message Description: These messages are generated by hosts or intermediate routers in order to notify that a session cannot be established. Firewall Considerations: An outsider can force nodes of your network to generate these packets in order to obtain knowledge of your network; for example, they can use a port scanner to learn which services you are providing. If you reply with a port unreachable, they will know that you are not providing this service (this type of information can also be gathered for TCP services by using stealth scanning). You should receive these messages, as they may provide useful information for troubleshooting. You should only send them through the secure interface, because if you send them through the nonsecure interface, it will help outsiders to map the services that you are offering. * Source Quench Message Description: This message is generated by a host or a router when it wants the sender to slow down the rate at which it is sending packets. The IP stack passes this packet to the upper layers, and they are responsible for slowing the rate down. Firewall Considerations: This message could be used by an attacker (probably combined with IP spoofing) in order to make a very effective denial of service attack. Unfortunately it is more often a legitimate message, so if you decide to filter it, you may cause problems due to lost packets. I suggest you allow it to be sent and received, but also log the received messages for later analysis. * Redirect Message Description: This message is generated by a router when it receives a packet from a host and forwards the packet to another router that is on the same network as the host from which it received the packet (not the original sender, the last hop sender). This message is intended to modify the routing table of the receiver so that the router does not have to do unnecessary work. Suppose that machine M1 in network N1 wants to send a packet to machine M2 in network N2. As it is not directly connected to network N2, it looks at its own routing table in order to find who it must send the packet to. So it sends the packet to router R1 Router, R1 receives the packet. As it is not directly connected to network M2, it looks at its own routing table in order to find who it must send the packet to. It forwards the packet to router R2, Router R1 realizes that it sent the packet through the same interface on which it was received. So instead of R1 receiving messages for M2 from M1 and then resending them to router R2, it sends a redirect message to M1 telling it to use R2 as the router in order to reach M2. Machine M1 receives the ICMP redirect message from R1 and updates its routing table in order to be more efficient. Firewall Considerations: Redirect has, as described, a very specific legal use. However it can be abused by a cracker to subvert the routing table and thereby allow IP address spoofing. Redirect is not supposed to cross a router (the packet is only sent when the sender and both routers are on the same physical network). It may be legal to receive this in the firewall directly if your routing tables are not properly set up. For the same reason, you might allow the firewall to send this type of message. My recommendation is to send and log this packet, but not to receive it, as your routing tables should be determined only by you. It is also recommended to notify the owners of the machines to which you sent redirects so that they can correct their routing tables. * Time Exceeded Message Description: Time to live exceeded is generated by a router when it has to forward a packet with a time to live (TTL) value of zero. Fragment reassembly time exceeded is generated by a host when it does not receive all the fragments needed to reassemble a packet. Firewall Considerations: Enable this for incoming packets so your hosts can perform error recovery. For outgoing packets, allow all fragment reassembly time exceeded messages but not the TTL exceeded messages. The reason that I recommend blocking TTL exceeded messages from going from the secure network to the nonsecure network is that an attacker can use a tool called traceroute to find out which hosts are the routers in your network. This tool manipulates the TTL option of a UDP packet, in order to receive an ICMP TTL exceeded message in response Blocking the outgoing TTL messages will help you hide your network structure. * Parameter Problem Message Description: This message is generated when a host that is processing a packet finds a problem in the header parameters that forces the packet to be discarded. Firewall Considerations: An outsider will gain no information with this packet, so allow it to flow in both directions in order to report problems. * Time Stamp and Time Stamp Reply Message Description: The time stamp message is used to know the time in milliseconds since midnight. It receives as an answer a time stamp reply message. Firewall Considerations: This protocol may be used by an attacker as a mapping tool (an alternative to ping). I didn't find any reason for allowing it. * Information Request Message Description: This message is used by a host that is booted across the network to learn in which IP network it is located. It sends an information request packet with both the source and target fields set to zero. The replying host will send the reply with the complete address specified, so the host will now know which IP address it must use. These messages are obsoleted by new protocols, like RARP, BOOTP and DHCP. Firewall Considerations: This message is for local networks only, so it does not need to cross a router. The firewall should not generate requests, because it knows its IP interfaces, and certainly there is some better place to generate the replies than your firewall, so block it. * Address Mask Request and Address Mask Reply Description: The address mask request message is sent when a node wants to know the address mask of an interface. It expects to receive as an answer an address mask reply message containing the mask of that interface. Firewall Considerations: This message can be used by outsiders to learn the topology of your network. There were also cases in which a TCP/IP stack took inappropiate actions when it received an unsolicited address mask reply. The address mask request message may be generated by a network management station, such as Netview for AIX. AIX 4.1.4 by default will not answer this request unless you explicitly enable this using the no command icmpaddressmask option. Do not allow them in any direction. * Router Advertisement and Router Solicitation Message Description: These messages are used by hosts in order to dynamically discover the routers in a network. It is specified in RFC 1256, and the current status of the protocol is elective (as listed at the time of writing in the latest RFC of Internet Official Protocol Standards, RFC 1880). When the host boots, it sends a router solicitation message in order to discover the neighboring routers. The routers reply with router advertisement messages. The router also advertises periodically its routes in an unsolicited way. Firewall Considerations: These messages are supposed to be for local networks only. They may be received by your firewall, but you should not trust any information they give you. Block these messages. * Domain Name Request and Domain Name Reply Messages Description: These messages are used by hosts in order to learn the domain associated with an address. The host sends a domain name request message and receives as an answer a domain name reply. It is specified in RFC 1788, and the current status of the protocol is experimental. The idea of this protocol is to substitute the IN-ADDR domain defined in the domain name server (the one that is used in order to translate IP addresses to domain names). Using this protocol, each host will be responsible for the translation of its own IP addresses. The RFC requires every host to implement an ICMP domain name server and also suggests that every host should implement an application for sending the ICMP domain request. Firewall Considerations: Block it, because it is not currently used. * Traceroute Message Description: This message is used in order to implement traceroute (a useful network debugging tool) in a more efficient way. It is specified in RFC 1393, and the current status of the protocol is experimental. The implementation has two parts: - A new IP option - The new ICMP traceroute packet When a host wants to discover the path to a node, it sends a packet (for example, an ICMP echo request) with the new IP option. Then every router that forwards the packet will also send an ICMP traceroute message to the sender, informing it whether the packet was succesfully forwarded or if it was discarded. Firewall Considerations: Incoming, (used to trace routes from the secure network to the unsecure network) this packet can be allowed. If you want to hide your internal network structure (you probably should), the outgoing packet must be blocked. - An Introduction to TCP Packets TCP is the transport layer protocol that is used by most IP applications. For example, ftp, telnet, smtp (mail) and http (World Wide Web) are all higher-layer protocols that use the TCP transport layer. TCP is defined in RFC 793. There are going to be future texts about these in Oblivion mag and on my website. TCP provides the application with a reliable end-to-end connection. It takes care of retransmission, lost and duplicate packets and reordering of packets. When a host establishes a connection to another machine using TCP/IP, both hosts will be able to use the same connection in order to send information (that is, it is a two way channel). From the firewall point of view, the most important parts of the TCP packet are the source port, destination port and ACK bit. The source port and the destination port are used to identify which process is using a TCP connection. A TCP/IP connection is uniquely defined by: < Source Address, Source Port, Destination Address, Destination Port > There are some particular ports that are reserved for specific applications, while others are dynamically allocated for the processes that need them. The reserved ports are normally referred to as well-known ports. For example, port number 23 is reserved for incoming Telnet connections. Port numbers below 1023 are usually described as privileged, meaning that an application needs root authority to use them. This is only a convention, so you cannot base your security policy on it, but one side-effect is that the client end of a TCP session normally uses a port number above 1023. - How a TCP connection is established. A TCP session is initiated by a three-way synchronization sequence The acknowledgement (ACK) flag is used by one end of a session to tell the other end that its previous packet was received. The result is that the only packet in the TCP/IP session without the ACK flag set is the SYN packet that creates the session in the first place. So when a connection is created, the first packet does not have the ACK flag set, but all the following packets will have it. Firewall rules use this to control the direction in which a session can flow. If we want to prevent someone from creating connections from the outside (unsecure network) to the inside, we can specify a rule with a protocol specification of tcp/ack. This will block the first packet, thereby preventing the establishment of a connection. This is an effective way to prevent unwanted sessions from being established from outside the secure network. However, for complete security, you should aim to use proxy servers or SOCKS wherever possible. - Use and Abuse of TCP Ports If a service normally uses a well-known protocol, that does not mean that it can not use another port. For example, the Telnet server usually uses port 23, but nothing prevents it to be run on another port, for example, port 5234. This must be considered because it might be used to circumvent the firewall restrictions, either by an outsider or an insider. Often, holes in the firewall security are not directly created by attackers, but by unhappy insiders who consider the firewall to be unnecessarily restrictive. An insider that wants to provide an outside access that is not permitted may use a nonstandard port in order to do it. For example, if you prevent your users from providing HTTP servers but allow connections from outside to nonprivileged ports, a user can provide HTTP access using port 5234. * Source Porting An outside privileged port might be used by an outsider to circumvent your security policy. If, for example, you allow outside access from tcp/20 (a port usually used by an FTP server for data transfer), an outsider may use this port in order to run another service, for example, a Telnet client. Use of the tcp/ack protocol flag can prevent incoming connections, but if you allow an incoming connection from a particular port (as is needed if you want to provide FTP access for your users without implementing a proxy), you will open a security hole in your firewall. * Stealth Scanning We have seen how a firewall can control the direction of TCP connections using the ACK bit of the packets. When you want to disable a connection from one direction or the other, you just block the first packet (the one that does not contain the ACK bit), preventing the establishment of the connection. If an outsider is trying to scan your network in order to discover which machines you have and which services you provide, they will use a port scanner. Usually port scanners try to open a connection to the port. If you use the ACK bit checking in the firewall, this will block the attack. However, it is possible to scan a network without sending any packet with the SYN bit on. In order to do this, the attacker sends a packet that looks like something from the middle of a legitimate session, that is, with the ACK bit on. If the destination port is active, the host will realize that it is not part of a session in progress and send a reset response. If the port is not active, there will be no response. Other types of TCP packets may be used to perform similar types of scanning, such as a packet with SYN:FIN, ACK i n the header or one with the flag field set to 0. All of these packets will be rejected, but the fact that they are rejected provides some information about the target machine. This is called stealth scanning. If you want to allow IP forwarding on the firewall and rely on the SYN control, you must be aware that your network might be scanned using these techniques. Should you care about this? After all, the attacker cannot establish a useful session this way. The danger is, that it provides a way of mapping the contents of your secure network. This knowledge may not be directly useful, but it can become useful if combined with some other back door access. The lesson is this: wherever possible your firewall should be completely dual-homed and not allow any IP routing. - An Introduction to UDP Packets UDP, like TCP, is a transport layer protocol, but it is less widely used by applications. Common applications using UDP include the domain name service (DNS) and the simple network management protocol (SNMP). These are going to be also discussed in Oblivion mag at a later date. Unlike TCP, UDP does not provide the application with a reliable end-to-end connection. Once a UDP packet has been sent, the sender has no knowledge about whether it has arrived or not. It is therefore up to the application to provide acknowledgment and sequence control, if required. UDP is connectionless. That is, each message is a separate entity with no expectation of responses or subsequent request messages. Applications will often mimic the operation of a connection-oriented protocol, for example, a client may use a dynamically allocated port to send a message, and then listen on that same port for a response. From the firewall point of view, the only important parts of the UDP packet are the source port and destination port. The source port and the destination port are used to identify which process is using a UDP connection. A UDP/IP connection is uniquely defined by: < Source Address, Source Port, Destination Address, Destination Port > As in the case of TCP, certain well-known ports are reserved for specific applications. For example, DNS uses port 53, and SNMP uses ports 161 and 162. Because of its connectionless nature, UDP does not have the three-way synchronization sequence of TCP. This means that we do not have the ability to create rules based on the direction in which a session is established. As a result you should avoid routing UDP sessions through the firewall directly. If you do allow them through, you should only allow specific pairs of known end points. Slider. - EOF - This file was written on a Hewlett Packard 620LX running Windows CE, unfortunatly im having problems with alinging the text so dont diss it ok. I decided to write this due to the fact that not many people know about Connections and different packets, and what is good and what is not good, And to exploit them. Shouts : To all that know me. Dont worry about the text alignment any more. Before the magazine is distributed I align all the files to 78 charecters wide so they *should* look great on any type of system. If you encounter any problems please email me and I will look into it for you......cyberoptix@email.com