Monday, May 27, 2013

Installing NFS on CentOS 6.2

This is a how to install the NFS service on a Linux CentOS 6.2 box and making it accessible to others. The scenario is the following:
  • Grant read-only access to the /home/public directory to all networks
  • Grant read/write access to the /home/common directory to all networks 
At the end of this guide you will get:
  • A running NFS server with various LAN shared directories
  • A active set of firewall rules allowing the access to NFS ports
  • A permanently mounted NFS shared on a CentOS / Ubuntu client     
I assume you already have:

  • a fresh running Linux CentOS 6.2 server 
  • a sudoer user, named bozz on this guide
  • an accessible RPM repository / mirror
  • a Linux client with CentOS / Ubuntu


  1. Login as bozz user on the server
  2. Check if rpcbind is installed:
  3. $ rpm -q rpcbind
    if not, install it:
    $ sudo yum install rpcbind
  4. Install NFS-related packages:
  5. $ sudo yum install nfs-utils nfs-utils-lib
  6. Once installed, configure the nfs, nfslock and rpcbind to run as daemons:
  7. $ sudo chkconfig --level 35 nfs on
    $ sudo chkconfig --level 35 nfslock on 
    $ sudo chkconfig --level 35 rpcbind on
    then start the rpcbind and nfs daemons:
    $ sudo service rpcbind start
    $ sudo service nfslock start 
    $ sudo service nfs start 
    NFS daemons
    • rpcbind: (portmap in older versions of Linux) the primary daemon upon which all the others rely, rpcbind manages connections for applications that use the RPC specification. By default, rpcbind listens to TCP port 111 on which an initial connection is made. This is then used to negotiate a range of TCP ports, usually above port 1024, to be used for subsequent data transfers. You need to run rpcbind on both the NFS server and client. 
    • nfs: starts the RPC processes needed to serve shared NFS file systems. The nfs daemon needs to be run on the NFS server only. 
    • nfslock: Used to allow NFS clients to lock files on the server via RPC processes. The nfslock daemon needs to be run on both the NFS server and client.

  8. Test whether NFS is running correctly with the rpcinfo command. You should get a listing of running RPC programs that must include mountd, portmapper, nfs, and nlockmgr:

  9. $ rpcinfo -p localhost
       program vers proto   port  service
        100000    4   tcp    111  portmapper
        100000    3   tcp    111  portmapper
        100000    2   tcp    111  portmapper
        100000    4   udp    111  portmapper
        100000    3   udp    111  portmapper
        100000    2   udp    111  portmapper
        100024    1   udp  40481  status
        100024    1   tcp  49796  status
        100011    1   udp    875  rquotad
        100011    2   udp    875  rquotad
        100011    1   tcp    875  rquotad
        100011    2   tcp    875  rquotad
        100003    2   tcp   2049  nfs
        100003    3   tcp   2049  nfs
        100003    4   tcp   2049  nfs
        100227    2   tcp   2049  nfs_acl
        100227    3   tcp   2049  nfs_acl
        100003    2   udp   2049  nfs
        100003    3   udp   2049  nfs
        100003    4   udp   2049  nfs
        100227    2   udp   2049  nfs_acl
        100227    3   udp   2049  nfs_acl
        100021    1   udp  32769  nlockmgr
        100021    3   udp  32769  nlockmgr
        100021    4   udp  32769  nlockmgr
        100021    1   tcp  32803  nlockmgr
        100021    3   tcp  32803  nlockmgr
        100021    4   tcp  32803  nlockmgr
        100005    1   udp    892  mountd
        100005    1   tcp    892  mountd
        100005    2   udp    892  mountd
        100005    2   tcp    892  mountd
        100005    3   udp    892  mountd
        100005    3   tcp    892  mountd

  10. The /etc/exports file is the main NFS configuration file, and it consists of two columns. The first column lists the directories you want to make available to the network. The second column has two parts. The first part lists the networks or DNS domains that can get access to the directory, and the second part lists NFS options in brackets. Edit /etc/exports and append the desired shares:
  11. $ sudo nano /etc/exports
    then append:
    /home/public *(ro,sync,all_squash)
    /home/common *(rw,sync,all_squash)
    • /home/public: directory to share  with read-only access to all networks
    • /home/common: directory to share with read/write access to all networks
    • *: allow access from all networks
    • ro: read-only access
    • rw: read/write access 
    • sync: synchronous access 
    • root_squash: prevents root users connected remotely from having root privileges and assigns them the user ID for the user nfsnobody. This effectively "squashes" the power of the remote root user to the lowest local user, preventing unauthorized alteration of files on the remote server. Alternatively, the no_root_squash option turns off root squashing. To squash every remote user, including root, use the all_squash option. To specify the user and group IDs to use with remote users from a particular host, use the anonuid and anongid options, respectively. In this case, a special user account can be created for remote NFS users to share and specify (anonuid=,anongid=), where is the user ID number and is the group ID number.

  12. Create the directories to be published with the correct permissions:
  13. $ sudo mkdir -p /home/public
    $ sudo chown nfsnobody:nfsnobody /home/public
    $ sudo mkdir -p /home/common
    $ sudo chown nfsnobody:nfsnobody /home/common
    it should end like this:
    $ ls -l /home/
    drwxr-xr-x. 2 nfsnobody nfsnobody  4096 Feb 20 12:55 common
    drwxr-xr-x. 7 nfsnobody nfsnobody  4096 Feb 17 14:44 public
  14. [OPTIONAL] Allow bozz user to locally write on the created directories by appending it  to nfsnobody group and granting write permissions to the group:
  15. $ sudo usermod -a -G nfsnobody bozz
    $ sudo chmod g+w /home/public
    $ sudo chmod g+w /home/common
    it should end like this:
    $ ls -l /home/
    drwxrwxr-x. 2 nfsnobody nfsnobody  4096 Feb 20 12:40 common
    drwxrwxr-x. 7 nfsnobody nfsnobody  4096 Feb 17 14:44 public
  16. Security issues. To allow remote access some firewall rules and other NFS settings must be changed. You need to open the following ports:
    • TCP/UDP 111 - RPC 4.0 portmapper
    • TCP/UDP 2049 - NFSD (nfs server)
    • Portmap static ports, Various TCP/UDP ports defined in /etc/sysconfig/nfs file.
    the portmapper assigns each NFS service to a port dynamically at service startup time, but dynamic ports cannot be protected by iptables. First, you need to configure NFS services to use fixed ports. Edit /etc/sysconfig/nfs, enter:
    $ sudo nano /etc/sysconfig/nfs
    and set:
    then restart nfs daemons:
    $ sudo service rpcbind restart
    $ sudo service nfs restart
    update iptables rules by editing /etc/sysconfig/iptables, enter:
    $ sudo nano /etc/sysconfig/iptables
    and append the following rules:
    -A INPUT -s -m state --state NEW -p udp --dport 111 -j ACCEPT
    -A INPUT -s -m state --state NEW -p tcp --dport 111 -j ACCEPT
    -A INPUT -s -m state --state NEW -p tcp --dport 2049 -j ACCEPT
    -A INPUT -s  -m state --state NEW -p tcp --dport 32803 -j ACCEPT
    -A INPUT -s  -m state --state NEW -p udp --dport 32769 -j ACCEPT
    -A INPUT -s  -m state --state NEW -p tcp --dport 892 -j ACCEPT
    -A INPUT -s  -m state --state NEW -p udp --dport 892 -j ACCEPT
    -A INPUT -s  -m state --state NEW -p tcp --dport 875 -j ACCEPT
    -A INPUT -s  -m state --state NEW -p udp --dport 875 -j ACCEPT
    -A INPUT -s  -m state --state NEW -p tcp --dport 662 -j ACCEPT
    -A INPUT -s -m state --state NEW -p udp --dport 662 -j ACCEPT
    restart iptables daemon:
    $ sudo service iptables restart
  17. Mount NFS shared directories: Install client NFS packages first:
  18.   on Ubuntu client:
    $ sudo apt-get install nfs-common
    on CentOS client:
    $ sudo yum install nfs-utils nfs-utils-lib
    inquiry for the list of all shared directories:
    $ showmount -e SERVERADDRESS
    mount server's /home/public on client's /public:
    $ sudo mkdir -p /public
    $ sudo mount SERVERADDRESS:/home/public /public
    $ df -h
    mount server's /home/common on client's /common:
    $ sudo mkdir -p /common
    $ sudo mount SERVERADDRESS:/home/common /common
    $ df -h
  19. Mount NFS automatically after reboot on the client. Edit /etc/fstab, enter:
  20. $ sudo nano /etc/fstab
    append the following line:
    #Directory                   Mount Point    Type   Options       Dump   FSCK
    SERVER_IP_ADDRESS:/home/public /public nfs hard 0 0
    SERVER_IP_ADDRESS:/home/common /common nfs hard 0 0
    to test the correctness of /etc/fstab before restarting, you can try to manually mount /public and /common:
    $ sudo mount /public
    $ sudo mount /common

    found at:

Friday, May 24, 2013

How To Break Into A Cisco ASA If You Do Not Have The Enable Password

From time to time, I get a service call asking me to break into a Cisco router or an ASA or a PIX. In most cases, the device was deployed a long time ago and nobody remembers the password. Or they have a copy of the config but the password was stored in the encrypted format.
If you have the password in encrypted format, you might luck out if it is a commonly-used value such as 8Ry2YjIyt7RRXU24 (password is blank) or 2KFQnbNIdI.2KYOU (password is “cisco”). You can try to brute force it with John the Ripper, or Cain and Abel, or some precomputed rainbow table. The time required to brute force a complex password will depend on the character set used in the password, the length of the password, and the speed of the computer that is running Cain & Abel. Might take an ice age to brute force it. Would it be worth the time?
You might have better luck with a bit of lateral thinking. Just paste the encrypted password into Google and see if anyone has posted their own config in some Google-indexed forum somewhere. If their encrypted password is the same value as your mystery password, they are using that same password. Can you ask the poster what their password is?
Other lateral puzzle approaches include: looking for other places that the password may have been stored. Let’s hope it’s not on a Post-It note underneath the keyboard. On a typical network, the documentation is all stored in the same place; a file share, a local directory, a KeePass archive. Maybe a hard copy in the server room. Some of it may not be encrypted. Many admins will use the same password in different systems. The ASA enable password might be the same as the domain administrator password. Might be in the old admin’s email archive. You never know, the sort of sensitive shit people email unencrypted to themselves. That’s the main reason I have to nuke lost Blackberrys from the corporate BES. No screen lock password on your Blackberry AND you emailed naughty photos to yourself? Dude.
You can try to guess the password. Name of company. Name of admin. Name of admin’s dog/cat/child/soccer team/favorite pornstar.
If you have physical access to the ASA, you can probably reset the password. Pretty painless. Just boot into ROMMON mode, change the configuration register value to 0×41 so that the ASA boots without loading the startup config. This means you’re in without needing a password. Then you can copy the startup config into the running config, and you can change the password.

Step-by-Step Instructions

Reboot the ASA. When you see the following text, press the BREAK or ESC key.
Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.
You are now in ROMMON mode, as indicated by the prompt.
rommon #0>
Type confreg.
rommon #0> confreg

Current Configuration Register: 0x00000001
Configuration Summary:
 boot default image from Flash
Take note of the value of the Current Configuration Register. You are going to be prompted to answer several questions, and based on your answers, the ASA’s Configuration Register is going to be changed to a different value. You’ll want to set the Configuation Register back to its original value after you have reset the ASA password.
Do you wish to change this configuration? y/n [n]: y
enable boot to ROMMON prompt? y/n [n]:
enable TFTP netboot? y/n [n]:
enable Flash boot? y/n [n]: y
select specific Flash image index? y/n [n]:
disable system configuration? y/n [n]: y
go to ROMMON prompt if netboot fails? y/n [n]:
enable passing NVRAM file specs in auto-boot mode? y/n [n]:
disable display of BREAK or ESC key prompt during auto-boot? y/n [n]:

Current Configuration Register: 0x00000041
Configuration Summary:
 boot default image from Flash
 ignore system configuration

Update Config Register (0x41) in NVRAM...
Type boot. Now the ASA is going to boot the OS, but it will load the default config instead of the startup config.
rommon #1> boot
Get into privileged EXEC mode and hit ENTER when prompted for the enable password. Then copy the startup config into the running config.
ciscoasa> en
ciscoasa# copy start run

Destination filename [running-config]?
Get into global configuration mode and make the changes that you want, e.g. change the enable password. You have total access now, so you can change anything that you want.
ciscoasa# conf t
ciscoasa(config)# enable password cisco
When you have finished making all the changes to the config, reset the Configuration Register back to its original value and save the config.
ciscoasa(config)# config-register 0x1
ciscoasa(config)# wr mem

What is the Configuration Register?

The Configuration Register value is a hex value that specifies various boot parameters for the ASA, such as which boot image to use, whether or not to boot the startup config, or whether to perform the ROMMON countdown.
You can set it while you are in ROMMON mode with the confreg command. For example, you could type confreg 0×41 and you won’t be prompted to answer all those questions in the instructions above. (Because the questions only serve as a human-friendly way to formulate the value of the Configuration Register. By specifying “0×41″, you have already provided the value.) However, if you just type confreg, it will display the current value of the Configuration Register. This is important if you need to find out the existing value of the Configuration Register.
rommon #0> confreg 0x41
You can also set the value of the Configuration Register while you are in the global configuration mode with the config-register command.
ciscoasa# conf t
ciscoasa(config)# config-register 0x1
found at 

Thursday, May 23, 2013

QOS Priority Levels

One of the most feared technologies by CCIE candidates is QOS (Quality of Service). This is understandably because most first world countries seldom have problems with bandwidth or getting more if needed. So the necessity for juggling traffic around, by means of QOS strategies is almost non existent. On the other hand, engineers in developing countries tend to be familiar with various QOS technologies, because of frequent bandwidth shortages as a result of the high bandwidth costs.

Here is a concise table listing the all the values for both BYTE fields:

TOS-BYTE = (3bits IP PREC + 5bits legacy)

IP Precedence  Description
IP PREC Binary
(3 bits)
IP PREC Decimal Value
FLASH 011 3


DiffServ Field = (6bits DSCP + 2bits ECN)

DSCP PHB Groups (8x + 2y) DSCP-Field Binary (6 bits) DSCP-Field Decimal (6 bits) DS-Field Binary (1 byte) DS-Field Decimal Format DS-Field Hex Value
Default 000 000 0 000 000 00 0 0×0
CS1 001 000 8 001 000 00 32 0×20
AF11 001 010 10 001 010 00 40 0×28
AF12 001 100 12 001 100 00 48 0×30
AF13 001 110 14 001 110 00 56 0×38
CS2 010 000 16 010 000 00 64 0×40
AF21 010 010 18 010 010 00 72 0×48
AF22 010 100 20 010 100 00 80 0×50
AF23 010 110 22 010 110 00 88 0×58
CS3 011 000 24 011 000 00 96 0×60
AF31 011 010 26 011 010 00 104 0×68
AF32 011 100 28 011 100 00 112 0×70
AF33 011 110 30 011 110 00 120 0×78
CS4 100 000 32 100 000 00 128 0×80
AF41 100 010 34 100 010 00 136 0×88
AF42 100 100 36 100 100 00 144 0×90
AF43 100 110 38 100 110 00 152 0×98
CS5 101 000 40 101 000 00 160 0xA0
EF 101 110 46 101 110 00 184 0xB8
CS6 110 000 48 110 000 00 192 0xC0
CS7 111 000 56 111 000 00 224 0xE0
The CS (Class-Selector) codepoints above are in the form ‘xxx000′. The first three bits ‘xxx’ are the IP precedence bits for backwards compatibility, while the last 3 bits are set to zero. Each IP precedence value is mapped to a DiffServ value known as Class-Selector codepoints. If a packet is received from a non-DiffServ aware router that used IP precedence markings, the DiffServ router can still understand the encoding as a Class-Selector codepoint.
The DiffServ model also introduced two types of forwarding classes : AF & EF.
The EF (Expedited Forwarding) traffic is often given strict priority queuing above all other traffic classes. The design aim of EF is to provides a low loss, low latency, low jitter, end-to-end expedited service through the network. These characteristics are suitable for voice, video and other real-time services.
The AF (Assured forwarding) behavior allows the operator to provide assurance of delivery as long as the traffic does not exceed some subscribed rate. Traffic that exceeds the subscription rate faces a higher probability of being dropped if congestion occurs. The AF per-hop behavior group defines 4 separate AF Classes. Within each Class(1 to 4), packets are given a drop precedence (high =3 , medium =2  or low =1).  The 1st three bits of the six-bit DSCP field define the Class, the next two bits define the Drop-Probability, and the last bit is reserved (= zero). AF is present in the format AFxy, where ‘x’ represents the AF-Class (HIGHER class value is more PREFERRED) and ‘y’ represents the Drop-Probability (HIGHER value is more likely to be DROPPED).
AF23, for example, denotes class 2 and a high drop preference of 3. If AF23 was competing with AF21, AF23 will be dropped before AF21, since they in the same class. But if you had AF33 & AF21, AF33 is a more important class, therefor AF21 will be dropped first.
A nice formula to work out the decimal value of the AF bits, will be 8x+2y. Example AF31 = (8*3) + (2*1) , thus AF31 = 26.
Optionally you dont have to match any of the predefined DiffServ values. You can match any of the 64 DSCP values (0-63), by configuring just that decimal value.

  • The second last heading “DS-Field Decimal Value is synonymous with the TOS-Byte decimal field. This is the value used in extended pings to generate ICMP traffic with a specific QOS value.
  • That last heading “DS-Field HEX Value is the value you will see/use in a Verbose Netflow output.
found at:


Internet Storm Center Infocon Status

Internet Storm Center Infocon Status
Internet Storm Center Infocon Status