Top

A Linux User Reference

Search tips
  • search ignores words that are less than 4 characters in length
  • searches are case insensitve
  • if a search does not return anything try it in Boolean mode then Query expansion mode by checking the appropriate radio button e.g. searching for 'cron' in just the Administration category returns nothing - presumably because the 50% threshold is reached. Boolean mode ignores this threshold so a search for 'cron' returns several hits
  • in Boolean mode preceding a word with a '+' means the result must include that word, a '-' means it must not
  • in Boolean mode '+crontab -anacron' means match articles about crontab that DO NOT mention anacron
  • to match a phrase e.g. 'manage system' check the Boolean mode radio button and enclose the phrase in quotes "some phrase ..."
  • in Query expansion mode the search context is expanded beyond the keywords you entered - relevancy of hits may well be degraded

NETWORK CONFIGURATION

VPN

  • Virtual Private Networks

    Virtual private networks (VPNs) allow for secure communications over public networks such as the Internet.

    There are several implementations such as IPSEC, OpenVPN, VPND, SSH, many Cisco Routers ... The first two are covered in the following articles. These 'traditional' VPNs establish an encrypted (private) communications tunnel between two end-points over a public network.

    Competing with the traditional is SSL VPN (Secure Sockets Layer virtual private network) - a form of VPN that can be used with a standard Web browser.

    SSL VPN does not require client side software. Coomunications between two end-points is encrypted using SSL protocol (e.g. https) or its successor, the Transport Layer Security (TLS) protocol.

  • Bridged and routed VPNs

    Functionally very similar. Major difference being that a routed VPN will not pass IP broadcasts while a bridged VPN will.

    Bridged

    Must always use '--dev tap' on both ends of the connection.

    Routed

    Can use either '--dev tap' or '--dev tun' though must use the same on both ends of the connection. '--dev tun' tends to be slightly more efficient in terms of routing.

  • Set up a secure OpenVPN VPN

    Scenario

    • establish a VPN tunnel between a server endpoint of 10.8.0.1 (IP 198.168.0.2) and a client endpoint of 10.8.0.2 (IP 198.168.0.5).
    • provide encrypted communication between client and server over UDP port 1194 (default OpenVPN).

    Generate a static key and transfer it to destination machine

    # openvpn --genkey --secret static.key
    # rsync -t static.key root@192.168.0.5:/etc/openvpn/
    

    Make a tunnel on both Client and Server systems

    # openvpn --mktun --dev tun0
                                         (or)
    # mknod /dev/net/tun0 c 10 200
    # modprobe tun
    

    A tunnel is a network device.

    Configure the tunnel on Server

    # ifconfig tun0 pointopoint 10.8.0.1 10.8.0.2
    tun0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:10.8.0.2  P-t-P:10.8.0.1  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
    

    Configure the tunnel on client

    # ifconfig tun0 10.8.0.2 10.8.0.1
    

    Add a firewall rule if required - allow all traffic to/from tun device

    # iptables -A INPUT -i tun+ -j ACCEPT                     
    

    On both client and server.

    Connect using the preconfigured tun device

    # openvpn --remote 192.168.0.2 --dev tun0 --verb 9         (On client)
                                                               (or)
    # openvpn --remote 192.168.0.5 --dev tun0 --verb 9         (On server)
    # ping 10.8.0.2                                            (Test the connection)
    

    This creates an OPEN channel, no security at al.l

    Remove a tunnel

    # openvpn --rmtun --dev tun0
    

    On both client and server.

    From scratch using just openvpn and using the static key

    Create the tunnel

    # openvpn --mktun --dev tun0
    

    Configure and connect

    # openvpn --remote 192.168.0.5 --dev tun0 ifconfig 10.8.0.2  10.8.0.1 --secret /etc/openvpn/static.key
    
    # route -n
    10.8.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    
  • Transport Layer Security (TLS)
    • A protocol used to establish a secure connection between a client and a server.
    • It establishes a PKI (public key infrastructure, X509) which consists of:

      • A separate local certificate (public key) and private key for the server and each client
      • A master Certificate Authority (CA or root certificate) certificate and key which is used to sign each of the server and client local certificates
      • A peer-to-peer application. The designation of client or server is only for the purpose of negotiating the TLS control channel

    The CA or root certificate file can have multiple certificates concatenated into a single .pem file.

    When two OpenVPN peers connect

    • Each presents its local certificate to the other
    • Each peer checks that the presented certificate was signed by the master root certificate (specified in --ca)
    • If check on both peers succeeds => TLS negotiation will succeed
    • Both peers will exchange temporary session keys, the tunnel will begin passing data
  • Using TLS with self-signed certificates

    Create own Certificate Authority (CA) certificate and private key

    # openssl req -nodes -new -x509 -keyout ca.key -out ca.crt
    

    CA certificate → 'ca.cert', Private key → ca.key

    Set the certificate variable to point to the new root certificate - /usr/lib/ssl/openssl.cnf

    [ CA_default ]
    dir   = /etc/openvpn                      # Where everything is kept
    certs   = $dir/certs                      # Where the issued certs are kept
    crl_dir   = $dir/crl                      # Where the issued crl are kept
    database  = $dir/index.txt                # database index file
    new_certs_dir  = $dir/newcerts            # default place for new certs
    certificate  = $dir/ca.crt                # The CA certificate
    serial   = $dir/serial                    # The current serial number
    private_key  = $dir/ca.key                # The private key
    x509_extensions = usr_cert                # The extensions to add to the cert
    
    [ req ]
    default_keyfile  = dh1024.pem
    

    Generate Diffie Hellman parameters' file - can be considered public

    # openssl dhparam -out dh1024.pem 1024
    

    Generate a local certificate signing request (server.csr) and private key (server.key) for the server

    # openssl req -nodes -new -keyout server.key -out server.csr
    

    Generate a local certificate signing request (client1.csr) and private key (client1.key) for each client

    # openssl req -nodes -new -keyout client1.key -out client1.csr
    

    Sign each certificate signing request using the CA private key (ca.key)

    If first time

    # touch /etc/openvpn/index.txt
    # echo 01 > /etc/openvpn/serial
    

    and then or if not the first time

    # openssl ca -out server.crt -in server.csr
    # openssl ca -out client1.crt -in client1.csr
    

    Copy/move the CA key signed certificate, private key and the public CA certificate to client

    File Description Copied to
    ca.cert Root CA certificate server and all clients
    ca.key Root CA key server (key signing machine only), is secret
    dh{x}.pem Diffie Hellman params server
    server.crt Server certificate server
    server.key Server key server, is secret
    client.crt Client certificate client
    client.key Client key client, is secret
    # rsync -t /etc/openvpn/client.crt <user>@<client1>:/etc/openvpn
    # rsync -t /etc/openvpn/client.key <user>@<client1>:/etc/openvpn
    # rsync -t /etc/openvpn/ca.crt <user>@<client1>:/etc/openvpn
    

    Initiate a connection - on client

    # openvpn --remote192.168.0.2 --dev tun1 --ifconfig 10.8.0.2 10.8.0.1 --tls-client  \
    --ca ca.crt --cert client.crt --key client.key --reneg-sec 60
                                                                           (or on server)
    # openvpn --remote 192.168.0.5 --dev tun1 --ifconfig 10.8.0.1 10.8.0.2 --tls-server \
    --dh dh1024.pem --ca ca.crt --cert server.crt --key  server.key --reneg-sec 60
    
  • Routing over a secure tunnel
    • Route a subnet over the secure tunnel.
    • Client and Server have two interfaces - one to the internet, the other to their own private networks.
    Aim

    securely connect both private networks. Client's private subnet is 10.0.0.0/24, Server's is 10.0.1.0/24

    Enable IP forwarding on both client and server

    # echo 1 > /proc/sys/net/ipv4/ip_forward
    

    Enable TUN packet forwarding through the firewall(s)

    # iptables -A FORWARD -i tun+ -j ACCEPT
    

    Add the routes

    # route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.4.0.2     (On client)
    # route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.4.0.1     (on server)
    

    Openvpn firewall examples

    # iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT    (Allow a specific host access)
    # iptables -A INPUT -p udp --dport 1194 -j ACCEPT               (Any host, quite secure if using HMAC)
    # iptables -A INPUT -i tap+ -j ACCEPT                           (Allow input packets from tap devices)
    # iptables -A INPUT -i tun+ -j ACCEPT                           (Allow input packets from tun devices)
    # iptables -A FORWARD -i tap+ -j ACCEPT                         (Allow input packets from tap devices to be
                                                                    forwarded to hosts on the local network)
    # iptables -A FORWARD -i tun+ -j ACCEPT                         (Allow input packets from tun devices to be
                                                                    forwarded to hosts on the local network)
    

    Stateful firewalls

    # openvpn --ping n ....
    

    Will be guaranteed to send a packet to its peer at least once every 'n' seconds. If 'n' is less than the stateful firewall connection timeout then one is able to maintain an OpenVPN connection indefinitely without explicit firewall rules.

  • Set up a VPN with SSH and PPP
    ssh

    Creates a tunnel connection which pppd can use to run TCP/IP traffic through.

    pty-redir

    A utility to get 'ssh' and 'pppd' to work well together. It allows the redirection of standard in and standard out to a pseudo tty.

    On the Server

    Create a VPN user with /usr/bin/pppd as the shell - /etc/passwd

    vpn_user:*:1004:101:VPN User,,,:/home/vpn-users:/usr/sbin/pppd
    
    On Client

    Create a link by running 'pppd' through a pseudo terminal that is created by 'pty-redir' and connected to ssh.

    Run ssh, redirecting its input and output to pppd

    # /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish \
    -i /root/.ssh/identity.vpn -l joe > /tmp/vpn-device
    # sleep 10
    
    # /usr/sbin/pppd `cat /tmp/vpn-device`
    # sleep 15
    
    # /sbin/route add -net 172.16.0.0 gw vpn-int.mycom.com netmask 255.240.0.0
    # /sbin/route add -net 192.168.0.0 gw vpn-int.mycom.com netmask 255.255.0.0
    
  • Internet Protocol security (IPsec)

    Security for the Internet Protocol.

    FreeS/WAN - is the linux implementation of IPSEC. The FreeS/WAN implementation has three main parts:

    KLIPS

    Kernel IPSEC, implements AH, ESP and packet handling within the kernel.

    Pluto

    An IPSEC IKE daemon, implements IKE. Various scripts provide an administrator interface to the machinery. Authenticates and negotiates the secure tunnels with other systems

    Communication Protocols

    Three protocols are used in an IPSEC implementation

    Protocol Description
    ESP (Encapsulating Security Payload) Encrypts and/or authenticates data
    AH (Authentication Header) Provides a packet authentication service
    IKE (Internet Key Exchange) Negotiates connection parameters, keys, for the other two protocols
  • IPsec configuration
    /etc/ipsec.conf

    The IPsec configuration file /etc/ipsec.conf is divided into three parts:

    Connection specifications

    One or more connection sections. Each connection section starts with conn where is an arbitrary name which is used to identify the connection.

    Connection defaults

    Starts with conn %default. Each parameter in it is global, a parameter of the same name in another section overrides it. All %default sections must precede all non-%default sections of that type.

    Config section

    Starts with config setup and contains information used when starting the application.

    Create an authentication keypair - on each gateway

    # ipsec newhostkey --output /etc/ipsec.secrets --hostname test.my-lan.com
      : RSA {
      # RSA 2192 bits   test.my-lan.com   Mon Feb  2 14:30:43 2009
      .......
            }
    
    # chmod 600 /etc/ipsec.secrets
    

    Get the leftrsasigkey - the local Linux FreeS/WAN gateway

    # ipsec showhostkey --left
      # RSA 2192 bits   test.my-lan.com   Mon Feb  2 14:30:43 2009
      leftrsasigkey=0sAQOIMlk .....
    

    Logon onto right (remote) gw and get the rightrsasigkey

    # ipsec showhostkey --right
    

    On left (local) gw, configure the gw - /etc/ipsec.conf

    # basic configuration
    
    config setup
       interfaces="ipsec0=eth0"
       klipsdebug=none
       plutodebug=none
       plutoload=%search
       plutostart=%search
       uniqueids=yes                   # Close down old connection when new one using same ID shows up
                                       # 'plutoload=%search' and 'plutostart=%search'
                                       # tell the pluto daemon to search the conf. file for 'auto=' statements
                                       # all connections with 'auto=add' will be loaded in the pluto database
                                       # all connections with 'auto=start' will be started.
    
    # defaults that apply to all connection descriptions
    conn %default
       keyingtries=0                   # How persistent to be in (re)keying negotiations (0 means very).
       authby=rsasig                   # How to authenticate gateways
    
    # VPN connection for head office and branch office
    conn head-office
       leftid=@head.example.com        # Identity we use in authentication exchanges
       leftrsasigkey=0x175cffc641f...
       left=45.66.9.170
       leftnexthop=45.66.11.254
       leftsubnet=192.168.11.0/24
       rightid=@branch.example.com     
       rightrsasigkey=0xfc641fd6d9...
       right=17.120.138.134
       rightnexthop=17.120.138.1
       rightsubnet=192.168.0.0/24
       auto=start                      # Start automatically when ipsec is loaded
    

    The above connection section 'conn head-office' represents the following layout:

                     subnet 192.168.11.0/24          (Leftsubnet)
                               |
                     interface 192.168.11.xxx
                      [left gateway machine]
                     interface 45.66.9.170           (Left)
                               |
                     interface 45.66.11.254          (Leftnexthop)
                            [router]
                     interface we don't know
                               |
                            INTERNET
                               |
                     interface we don't know
                            [router]
                     interface 17.120.138.1          (Rightnexthop)
                               |
                     interface 17.120.138.134        (Right)
                      [right gateway machine]
                     interface 192.168.0.xxx
                               |
                     subnet 192.168.0.0/24           (Rightsubnet)
    
    • The leftid and leftrsasigkey are used in authenticating the left participant.
    • The leftrsasigkey is the public key of the left participant.
    • The private key is stored in the /etc/ipsec.secrets file and should be kept secure.

    Which participant is considered left or right is arbitrary. IPSEC figures out on which it is running on based on internal information. This permits identical connection specifications to be used on both ends.

    Copy the section or if no other changes the whole of ipsec.conf to the right (remote) gw

    # scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf
    

    Start connection - On left (local) gw

    # ipsec auto --up net-to-net
    .....
    004 "net-net" #224: STATE_QUICK_I2: sent QI2, IPsec SA established
    
    Do not MASQuerade or NAT packets to be tunneled

    If masquerading or NAT'ing on either gateway then packets that are intended for tunnelling may well get exempted. Than can add a rule something like

    # iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d ! 192.0.2.128/29 -j MASQUERADE
    

    Do not masquerade anything coming from the tunneled network destined for the other end of the tunnel via eth0.

  • IPsec Road Warrior
    /etc/ipsec.conf

    For 'Roaming laptop' - one Linux box with a static IP, a Linux laptop with a dynamic IP.

    Get the gateway's static IP, the IP range of the subnet behind that gateway and a name by which each side can identify itself for IPsec negotiations.

    On laptop, get/print leftrsasigkey and configure - /etc/ipsec.conf

    conn road
        left=%defaultroute                 # Picks up dynamic IP
        leftnexthop=%defaultroute
        leftid=@road.example.com           # Laptop's id
        leftrsasigkey=0sAQPIPN9uI...       # Laptop's rsakey
        right=192.0.2.9                    # Remote information - gw static IP
        rightsubnet=10.0.0.0/24
        rightid=@xy.example.com
        rightrsasigkey=0sAQOnwiBPt...      # Gateway's rsakey
        auto=add                           # Authorises but doesn't start this 
                                           # connection at startup
    

    @<FQDN> can be a made-up name

    On gateway, get/print rightrsasigkey and configure /etc/ipsec.conf

    conn road
        left=192.0.2.9                     # Gateway's IP
        leftid=@xy.example.com             # Gateway's id
        leftsubnet=192.0.2.128/29
        leftrsasigkey=0sAQOnwiBPt...       # Gateway's rsakey
        rightnexthop=%defaultroute         # correct in many situations
        right=%any                         # Wildcard: we don't know the laptop's IP
        rightid=@road.example.com
        rightrsasigkey=0sAQPIPN9uI...      # laptop's rsasigkey
        auto=add                           # laptop only: can replace auto=add with 
                                           # auto=start, connect on-boot
    

    Start connection, must start the connection from the Road Warrior side - the laptop

    # ipsec auto --start road
    

    Multiple Road Warriors

    For RSA keys:

    • Can add as many Road Warriors as you like.
    • The left/rightid parameter lets Linux FreeS/WAN distinguish between multiple Road Warrior peers, each with its own public key.

    For shared secrets (PSK):

    • Can only define one Roadwarrior connection
    • All PSK road warriors must therefore share one secret.