CALIFORNIA SOFTWARE LABS

Transcription

1 Real-time Implementation of NAT and Firewall in VxWorks CALIFORNIA SOFTWARE LABS R E A L I Z E Y O U R I D E A S California Software Labs 6800 Koll Center Parkway, Suite 100 Pleasanton CA 94566, USA. Phone (925) Fax (925) info@cswl.com

2 Real-time Implementation of NAT and Firewall in VxWorks A Technical Report Technical Expertise Level : Intermediate Requires knowledge of : C, TCP/IP Protocol, and VxWorks INDEX INTRODUCTION... 3 TCP/IP STACK IN VXWORKS... 3 WORKING OF THE VXWORKS' NETWORK STACK... 3 NAT AND FIREWALL IN VXWORKS... 5 NETWORK ADDRESS TRANSLATORS (NAT)... 5 HOW NAT WORKS?... 6 NETWORK ADDRESS PORT TRANSLATORS (NAPT)... 7 FIREWALL... 8 ADDING NAT AND FIREWALL TO THE TCP/IP STACK IN VXWORKS... 8 PACKET CAPTURING IN VXWORKS... 9 ETHERHOOK... 9 IPFILTERHOOK OUR SOLUTION TO NAT AND FIREWALL PACKET MANIPULATION FOR NAT AND FIREWALL CONCLUSION REFERENCES CSWL Inc, Pleasanton, California - 2 -

3 INTRODUCTION This paper details the concept of Network Address Translators (NAT) and firewalls and how they can be integrated in VxWorks. TCP/IP stack in VxWorks Wind River s real-time operating system, VxWorks comes with a full-featured, BSD 4.4-compliant TCP/IP stack. It has complete routing support and is scalable, so developers can build products ranging from IP routing devices to full TCP/IP, SNMP-managed systems. Figure below shows the layered architecture of TCP/IP stack. Figure-1 VxWorks TCP/IP stack Working of the VxWorks' network stack VxWorks allocates and initializes memory for the network stack at network initialization time. Out of this pre-allocated memory, the network stack uses the netbuflib routines to set up a memory pool. From this memory pool, the network stack gets the memory needed for data transfer. The netbuflib routines deal with data in terms of mblk structures, clblk structures and clusters. The mblk and clblk structures provide information necessary to CSWL Inc, Pleasanton, California - 3 -

4 manage the data stored in clusters. The clusters, which come in different sizes, contain the data described by the mblk and clblk structures. By default, the VxWorks network stack creates six pools for clusters ranging in size from 64 bytes to 2048 bytes. The mblk structure is the primary vehicle through which you can access data in a memory pool. Because, the mblk structure merely references the data, this lets network layers communicate data without actually having to copy the data. In addition, data can be chained using mblks. Thus, you can pass an arbitrarily large amount of data by passing the mblk at the head of an mblk chain. Figure 2 shows the presentation of 2 packets to the TCP layer. Figure-2 Presentation of two packets to the TCP layer CSWL Inc, Pleasanton, California - 4 -

5 To support chaining across multiple packets, the mblk structure contains two members that support chaining. One member points to the next mblk in the current packet. The other member points to the head mblk in the next packet if any. The clblk structure points to the cluster where the data is stored. NAT and Firewall in VxWorks The default TCP/IP stack that ships with VxWorks does not have firewalling and network address translation capabilities. However, these features can be plugged into an existing TCP/IP stack in VxWorks. Network Address Translators (NAT) One of the most compelling problems facing the IP Internet is the depletion of IP addresses. Though there had been various solutions to overcome this catastrophe, the most promising among them has been the concept of "address reuse". The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. To set up a NAT, one need to define which is the "internal" and the external interface. The "internal" interface is the network adapter connected to the network with private IP addresses, which needs to be changed for communicating with the Internet. The "external" interface is configured with a valid private (globally unique) Internet address. CSWL Inc, Pleasanton, California - 5 -

6 For example, the internal interface might have an IP # of and be connected to the Ethernet, whilst the external interface might be a PPP connection with an IP number of How NAT works? NAT s basic operation is as follows: At each exit point between a stub domain and a backbone, NAT is installed. When a host from within the stub domain wishes to communicate with a machine in the Internet, the NAT translates the private IP address of the local machine to its globally unique IP address. In the scenario described in figure -3, when the local host sends a packet to a machine with the IP address , NAT replaces the source IP address in the packet ( ), with its globally unique IP address ( ) and transmits it. Since the source IP address has been modified in the packet, the response for this packet would be sent to the NAT. The NAT then replaces the destination IP address in the packet with the IP address of the local host and transmits the packet to the host in the stub domain. This address translation is totally transparent to the local host. CSWL Inc, Pleasanton, California - 6 -

7 Network Address Port Translators (NAPT) One of the drawbacks of the earlier solution is that the number of local machines that can be connected to the Internet simultaneously is limited to the availability of globally unique IP addresses in the NAT. To overcome this limitation, the NAT can be extended further to enable port translations as well, apart from address translations. This is known as masquerading or Network Address Port Translation (NAPT). In NAPT the port number of the local host in the TCP or UDP header is also translated before the packet is sent out of the stub domain to the Internet. Consider the following scenario. Machine Local Host A from the local stub domain having an IP address of sends a packet to a machine with as its IP address. Let us assume that the local machine uses port 1034 to initiate a TCP session with the machine at Hence the source port in the packet would be 1034 and the destination port number would be 80 (HTTP request). Similarly, another machine from the local stub domain, say Local Host B with the IP address initiates a TCP session to the machine at Let the port that this machine uses to initiate this session be Hence the source port in the packet would be 1500 and the destination port number would be 80. When the source address alone of both these packets is replaced with the unique IP address of the NAT ( ), an ambiguity would arise while mapping the response packets. The NAT would not be able to determine whether the response packet is destined for Local Host A or for Local Host B. CSWL Inc, Pleasanton, California - 7 -

8 To resolve this ambiguity, the source ports of the local machines are also translated before the packet is sent to the Internet. The port numbers that are used to replace the actual port numbers in the IP packet are unique for each session. In the above scenario, the port number of Local Host A could be changed from 1034 to say 5001 and that of Local Host B could be modified to When the NAT receives the response packets, it would be able to determine by checking the destination port number in the IP packet. If the destination port number is 5001, the NAT could conclude that the packet was actually destined for Local Host A. Whereas if the destination port number in the response packet was 5002, the NAT could map the packet to Local Host B by replacing the destination IP address and the destination port number to 1034(the port number used by Local Host B to initiate this session). Firewall Any device that controls network traffic for security reasons can be called a firewall. A firewall puts up a barrier that controls the flow of traffic between networks. The most basic firewalls are built on routers and work in the lower layers of the network protocol stack. Packets are first checked and then either dropped or allowed to enter based on various rules and specified criteria. Adding NAT and Firewall to the TCP/IP stack in VxWorks To add NAT and firewall to an existing TCP/IP stack in VxWorks, one should manipulate IP packets at the exit point between a local stub domain and the Internet. IP packets can be captured by hooking into the TCP/IP stack. The IP header and TCP/UDP headers can be stripped from the packet and checked against the firewall rules. Address translation needs to be performed on the packet before transmitting it to the Internet and before delivering it to the local network. CSWL Inc, Pleasanton, California - 8 -

9 Packet capturing in VxWorks VxWorks provides two hooks by which, we could capture packets in the network. These hooks are: EtherHook IpFilterHook VxWorks provides two libraries using which these hooks could be implemented. The EtherHook can be implemented using etherlib and the IpFilterHook can be implemented using ipfilterlib. EtherHook The EtherHook provides direct access to raw Ethernet packets. Incoming and outgoing packets can be examined or processed using the hooks etherinputhookadd() and etheroutputhookadd(). etherinputhookadd(): This function adds a routine to receive all Ethernet input packets. Synopsis: STATUS etherinputhookadd() ( FUNCPTR inputhook, /*Routine to receive Ethernet input packets*/ Char* pname, /*Name of device*/ Int uint /*unit of device*/ ) CSWL Inc, Pleasanton, California - 9 -

10 This routine adds a hook routine (inputhook) that will be called for every Ethernet packet that is received. The calling sequence of the input hook routine is: BOOL inputhook ( struct ifnet pif, /*interface packet was received on*/ char *buffer, /*received packet*/ int length /*length of received packet*/ ) etheroutputhookadd(): This function adds a routine to receive all Ethernet output packets. Synopsis STATUS etheroutputhookadd ( FUNCPTR outputhook /*routine to receive Ethernet output*/ ) This routine adds a hook (outputhook) and this function would be called for every Ethernet packet that is transmitted. This routine is immediately called immediately before transmission. The calling sequence of the output hook routine is: BOOL outputhook ( struct ifnet pif, /*interface packet will be sent on*/ CSWL Inc, Pleasanton, California

11 char *buffer, /* packet to transmit*/ int length /*length of packet to transmit*/ ) After the processing the Ethernet packet, both the hook routines should either return true or false. The hook should return true if it has handled the packet and no further action should be taken with it. It should return false if normal processing of the packet should take place. IpFilterHook The IpFilterHook provides direct access to IP packets. The input hook can be used to receive, examine and process raw IP packets that are part of IP (Internet Protocol) protocols. This hook can be added using the IpFilterHookAdd() function that is provided in the ipfilterlib library. ipfilterhookadd(): Synopsis STATUS ipfilterhookadd ( FUNCPTR IpFilterHook ) /*routine to receive raw ip packets*/ This routine adds a hook routine that will be called for every IP packet that is received. The filter hook function will be executed in the context of tnettask, which runs at priority 50. The calling sequence of the filter hook routine is: CSWL Inc, Pleasanton, California

12 BOOL IpFilterHook ( struct ifnet *pif, /*interface packet was received on*/ struct mbuf **pptrmbuf, /*pointer to pointer to an mbuf chain*/ struct ip **pptriphdr, /*pointer to pointer to IP header*/ int iphdrlen /* IP packet header length*/ ) The hook routine should return TRUE if it has handled the input packet and no further action should be taken with it. If returning TRUE the ipfilterhook is responsible for freeing the mbuf chain by calling m_freem(*pptrmbuf). If the IpFilterHook returns false, normal IP processing continues i.e., options processing, IP checksum computation etc. pptriphdr is a pointer to a pointer to a IP header. The pointer to the ip header is obtained by de-referencing pptriphdr. The ip header is used to examine and process the fields in the ip header. The fields ip_len, ip_id and ip_offset in the ip header are converted to the host byte order from the network byte order before a packet is handed to the filter hook. Our solution to NAT and Firewall Given the two possible solutions for NAT in VxWorks, our solution to NAT and firewall is by using the IpFilterHook. Why not EtherHook? There are a couple of disadvantages in using the ether hook. They are: Only certain VxWorks network drivers support ether hooks CSWL Inc, Pleasanton, California

13 Requires IP checksum adjustment: If ether hooks are used, the packet is manipulated below the IP layer. Hence the IP checksum has to be adjusted accordingly. This is not required if the ipfilterhook is used as the IP layer performs this IP checksum computation once the packet is returned to the IP stack from the hook routine. Packet manipulation for NAT and Firewall Once the hook routine gets the IP packet, the NAT should strip the IP header and the TCP/UDP headers from the packet. The protocol field in the IP header of the packet is used to determine whether it is a TCP or a UDP packet. Fire walling and address translation is performed based on the information obtained from the headers. The NAT uses a mapping table to perform address translations. Whenever a machine in the local network initiates a new session is initiated, the NAT dynamically adds a new entry to the mapping table. This entry is used to perform address translation A typical mapping table used for NAT would look like the following: NAT Mapping Table Real Src IP addr Real Src port Dest IP addr Dest port NAT IP addr NAT port Manipulating outgoing packets: Since the firewall rules are based on local IP numbers, outgoing packets are checked against the firewall rules before performing address translation. If the firewall rules allow the packet to be transmitted, the local IP address (private IP address) is replaced by the globally unique IP address of the NAT and the source CSWL Inc, Pleasanton, California

14 port number in the packet is replaced by a unique port number assigned by NAT for this session. The NAT first checks the mapping table to find an entry corresponding to this session. If such a mapping exists, the NAT replaces the source IP address and the source port number in the packet with the NAT IP address and the NAT port number specified in this mapping entry. If such a mapping is not available for this session, NAT creates one and uses it for address translation. Since the IP address and the source port number have been modified in the packet, the TCP/UDP checksum has to be recomputed accordingly. Manipulating incoming packets: For an incoming packet, address translation is done before checking it against the firewall rules. The NAT looks for an entry in the mapping table by comparing the destination IP, destination port, NAT IP and NAT port in the mapping table with the source IP, source port number, destination IP and destination port number in the IP packet. NAT replaces the destination IP address in the packet with the Real Src Ip addr entry and the destination port number with the Real Src port entry. Since the destination IP address and the port number have been modified, the TCP/UDP checksum is adjusted before sending the packet to the appropriate host in the local domain. CSWL Inc, Pleasanton, California

15 Conclusion Even though the Network stack in VxWorks lacks NAT and Firewall modules, we can add them using the filter hook. Our small footprint implementation of NAT and Firewall modules when tested performed well. References 1. RFC1631 The IP Network Address Translator (NAT) 2. RFC 791 Internet Protocol (IP) 3. RFC 793 Transmission Control Protocol (TCP) Copyright Notice: 2002 California Software Labs. All rights Reserved. The contents on the document are not to be reproduced or duplicated in any form or kind, either in part or full, without the written permission of California Software labs. Product and company names mentioned here in are the trademarks of their respective companies. CSWL Inc, Pleasanton, California