Contact:[email protected]
http://www.sans.org/infosecFAQ/encryption/remote_admin.htm Using IPSec for Remote Administration on Linux Firewalls Danny Chang August 2, 2000 Introduction The corporate security administration function includes among many other daily tasks, the remote administration of firewalls or proxy servers from a central location. The task of remotely logging on and administrating Linux firewalls presented a problem for my organization. We have used other firewall set-ups like CheckPoint VPN-1 and Cisco routers configured to use VPN either as a plugin or software application that came with the firewall or router package, but we did not have any secured channel established to administer our Linux firewalls from the security administration console. As we all know without a VPN or secured channel, all traffic is not encrypted including, administrator passwords. Background We experimented with different approaches to provide a cost-effective method of remote logon activities including SSH scripting and S/WAN IPSec implementation but due to the private network we are using for our core business, we have chosen a simple solution provided by NIST Cerberus IPSec and the PlutoPlus IKE software for encapsulation or tunneling between our Linux firewalls and the security console. Also, we are currently using IPv4 and not IPv6. [By the end of August 2000, the Cerberus software will be made available to the public.] We have chosen Cerberus because of its built-in user interface and web-based tester (WIT) for interoperability testing capability. More importantly, NIST Advanced Networking Technologies Division has provided substantial research in IPSec, and has incorporated IPv6 standardization in the Cerberus software. We have come to realize that VPN is the answer or solution to our specific problem. VPN can be used with the following types of network communications and configurations: Peer-to-Peer Client-Server Protected Workgroup Protected Enterprise Protected Inter-Enterprise VPN and Remote Access IPSec and Linux firewalling Linux firewalling chains consisting of three chains, the input, output and forward, and other user defined chains that provide different functionality. A chain is a checklist of rules. Each rule determines how the packets are handled either masquerade, redirect, accept, deny, reject or return. These rules are based on the security policies established by the security administrator. Linux uses the Ipchains built into recent Linux kernels' distributions for firewalling. Many commercial firewalls today support VPN functionality in their firewall products. As a result, vendors came out with their own ways of implementing IP encryption. I will highlight how IPSec is implemented in general as it is applied to "Our Solution". The starting point for implementing IPSec in firewalls is how to apply the rules to the AH (Authentication) or the ESP (Encapsulating) header. These packets are screened or filtered for AH or ESP based on IP addresses. After the initial installation, the SADB database has to be loaded. At this point there are "one-sided" Security Associations established, then the same procedure has to be followed on all machines (hosts/gateways). Implementing Cerberus for Linux The NIST Cerberus IPSec Reference Implementation for Linux was developed based on the current ESP and AH specifications and other RFCs and IPv6 Standards. The main components of the reference module are the Security Association Database (SADB), the IPSec protocol engine, the cryptographic transforms and algorithms, and the interface to IP. The SADB management routine is used to process database requests (add, delete, get) from user space via a Linux netlink socket. The particular Linux file used by the SADB is /dev/ipsec defined in /usr/src/linux/include/net/netlink.h. The IPSec protocol engine is used to process the in-bound and out-bound ESP and AH requests as specified by the firewall filtering rules in the above section. By specifying the NULL_SA protocol which means not having any Security Associations, the workstation can access other network traffic and other VPNs. Cerberus IPSec also provides end-to-end tunneling that can be used for internet or modem connections. The transforms or algorithms are the IPSec internal objects for the four functions associated with the in-bound and out-bound functions and SADB functions described in the above section. The cryptographic algorithms are for encrypting and decrypting data with keys generated by one of the encryption methods (e.g., DES-CBC, Blowfish-CBC, HMAC-MD5, etc.) Please refer to the diagram below provided by NIST's ANTD on their web site: http://www.antd.nist.gov/itg/cerberus/ for the flow information and other resources. The Cerberus software also provides a user interface to configure the settings required. We experimented with it and found it to be very user friendly and are pleased with the documentation and patches provided on their web site. Our implementation of the Cerberus software was a success and the user interface has generated the following statement to show our implementation. The statement and its arguements are used to generate an "Add" request to the SADB database with the source and destination IP address and the SPI value (2001) specified for the peers. The encryption key is recorded as a 16 bytes key for the key exchanges used in data encryption. The following is the SADB statement for adding SPI peers into the database: sadb -v add d 150.123.48.4 32 2001 150.123.48.4 2001 1 0 1 50 0 0 7 0 16 0123456789abcdef0123456789abcdef 132 0 0 3 Explanations of the above statement: # local_spi 2001 # address_family INET # destination 150.123.48.4 # addr_prefix 32 # ipsec_peer 150.123.48.4 # peer_spi 2001 # flags [MTLIO] # sequence_number 160676 # lifetime-B N/A # lifetime-T N/A # protocol ESP(50) # linked-protocol 0 # linked-spi 0 # algorithm ESP_NULL(7) # IVEC_length 0 # key_len 0 # algorithm HMAC_MD5_96(132) # IVEC_length 0 # auth_data_length 3 # key_len 16 # key 0123456789abcdef0123456789abcdef # # syntax usage: sadb [ -nsv ] get # [p[rot] # # OR # # [d[est] # [# local-spi(hex) # protocol] # 50 - ESP # 51 - AH # 2 - NULL_SA # OR # # usage: sadb [ -nsv ] [add|set] # [p[rot] <0-3> <0-3>] # 0 - protected traffic only # 1 - Allow unprotected traffic # 2 - Allow assoc. w/ no security # 3 - 1 & 2 # (inbound followed by outbound) # # OR # # [d[est] prefix_len(32 if not prefix) local-spi(hex) peer-spi(hex) # tunnel-flag check-replay-flag initial-sequence-number # {protocol 2 - NULL_SA 50 - ESP 51 - AH } { linked-protocol 0 - no link 50 - ESP 51 - AH } # linked-local-spi(hex) # # AND one of the following sets of parameters # # (ESP Specific Parameters) # crypto-alg-id # 1 - DES/CBC-RFC1829 # 2 - DES/CBC # 3 - 3DES/CBC (New) # 4 - RC5/CBC # 5 - Blowfish/CBC # 6 - IDEA/CBC # 7 - ESP_NULL (New) # 252 - Cipher Test # crypto-iv-length crypto-key length (# bytes) crypto-key # auth-alg-id # 0 - none # 132 - HMAC-MD5-96 # 133 - HMAC-SHA-1-96 # 253 - Authenticator Test # auth-iv-length # auth-key length (# bytes) # auth-key (empty if length=0) # auth-data-length # # OR # # (AH Specific Parameters) # auth-alg-id # 128 - MD5-RFC1828 # 129 - SHA-RFC1852 # 130 - Orig. HMAC-MD5(128) # 131 - Orig. HMAC-SHA-1(192) # 132 - HMAC-MD5-96 # 133 - HMAC-SHA-1-96 # 253 - Authenticator Test # auth-iv-length # auth-key length (# bytes) # auth-key # auth-data-length # # OR # # usage: sadb [ -nsv ] delete d[est] # # local-spi(hex) # protocol # 2 - NULL_SA # 50 - ESP # 51 - AH # # OR # # usage: sadb [ -nsv ] flush Conclusion The benefits of using the NIST Cerberus IPSec Reference Implementation together with its flexibility and enhanced options has outweighed some hindrance from public domain software development. We found that it enabled us to remotely administer our Linux firewalls by having sensitive data like passwords and security parameters encrypted during the logon process. It not only serves as a secured tunnel for traffic between the firewall host and the security console but also helped us to secure our LAN and WAN networks. Also, we do not have to implement any vendor-specific VPNs that will increase our training and ownership costs, and throughput on our private networks. References Russell, Rusty. "Linux IPCHAINS - HOWTO." 4 July 2000. URL: http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html (1 Aug. 2000) Regan, Jeff. "An Introduction to Using Linux as a Multipurpose Firewall." 9 Feb. 2000. URL: http://www2.linuxjournal.com/lj-issues/issue71/3546.html (24 July 2000) Glenn, Rob, Sheila Frankel. "NIST Cerberus, An IPsec Reference Implementation for Linux." URL: http://www.antd.nist.gov/itg/cerberus/ (1 Aug. 2000) Intel, "IP Security: Building Block for the Trusted Virtual Network." 6 June 2000. URL: http://developer.intel.com/design/security/ipsec/NewNPDWP_Final.html (1 Aug. 2000) Back to the Index