Chris Paquin

AI, Virtualization, Containers, Infrastructure, Linux

Tag: service

  • HomeLab: Simple DHCP Service Configuration on a Cisco Router

    Cartoon-golfer-009Sometimes when I learn something new in the world of technology, I am often amazed that something that I assumed was technically advanced is rather quite simple.

    Such is the case with configuring DHCP on a Cisco Router. I mean, is it just me or do network guys sometimes act as if everything that they do is takes elite technical skills and tons of experience. Don’t get me wrong, I know that networking is not exactly easy. But can we just agree to admit that once in a while some things are easier done than said. Anyway, for me this was the case with configuring a DHCP pool on a Cisco Router.

    In this instance I was working on getting a new virtual machine up and running on my ESXi host. This particular appliance needed to boot via dhcp so you could access its web interface. So I jumped on my 2621xm and created the pool.

    First we enable the dhcp service

    r-2621-1(config)#service dhcp

    Then we create a pool

    r-2621-1(config)#ip dhcp pool LabPool
    r-2621-1(dhcp-config)#network 10.2.0.1 255.255.255.0

    Next we set a few bits and bobbles so that clients can route.

    r-2621-1(dhcp-config)#dns-server 10.2.0.71
    r-2621-1(dhcp-config)#default-router 10.2.0.1
    r-2621-1(dhcp-config)#domain-name localdomain

    In this case I wanted to exclude a bunch of ips from the range

    r-2621-1(dhcp-config)#ip dhcp excluded-address 10.2.0.1 10.2.0.100

    Now save your config with copy run start.

    The command below shows me all my dhcp clients

    r-2621-1#show ip dhcp binding
    Bindings from all pools not associated with VRF:
    IP address          Client-ID/              Lease expiration        Type
    Hardware address/
    User name
    10.2.0.101          0050.569a.7dbe          Oct 16 2013 11:21 PM    Automatic

    This handy command shows me information pertaining to my pool

    r-2621-1#show ip dhcp pool

    Pool LabPool :
    Utilization mark (high/low)    : 100 / 0
    Subnet size (first/next)       : 0 / 0
    Total addresses                : 254
    Leased addresses               : 1
    Pending event                  : none
    1 subnet is currently in the pool :
    Current index        IP address range                    Leased addresses
    10.2.0.102           10.2.0.1         – 10.2.0.254        1
    r-2621-1#show ip dhcp conflict

    Related articles

    HomeLab: Simple Cisco EIGRP Setup
    Cisco DHCP Client Lease Time
    HomeLab: Simple SSH Setup on a Cisco Router
    HomeLab: Cisco 2621 Router Password Recovery/Factory Reset
    Configuring InterVLAN Routing on a Layer 3 Switch and providing DHCP to multiple subnets Part 1

  • A Simple Introduction to TCP Wrappers

    0993fb024232491eIn the world of Linux there are numerous ways that you can configure a Linux server to allow or deny access to a service, and while many people like to rely solely on Iptables, I wanted to take the opportunity to get my feet wet with TCP Wrappers. Note that this post is not meant to be the be-all end-all post on tcp wrappers. I am not going to review each and every configuration option, and trust me there are quite a few. Rather this is going to be a simple post which explains how to use tcp wrappers.

    TCP Wrappers Configuration Files

    First off you need to know that there are two configuration files for TCP wrappers. They are listed below.

    #/etc/hosts.allow

    #/etc/hosts.deny

    To determine if a remote host is allowed to access a local service, the hosts.allow file referenced first, then the hosts.deny is referenced. Each file is read from the top down.

    Rules in the hosts.allow take precedence over rules in the hosts.deny. Access will be granted for rules in the /etc/hosts.allow, and denied for rules in the /etc/hosts.deny ( note that this is not always the case, however this is how most people use tcpwrappers)

    Basic rules are configured using the format below

    <daemon list> : <client list> [: <option> : <option> ]

    Below is a very simple and basic rule for sshd. In this example we want to allow all hosts in the domain fatmin.com to have access to sshd, and we want to deny sshd access to everyone else.

    So in the /etc/hosts.allow

    sshd : *.fatmin.com

    and in /etc/hosts.deny

    sshd: ALL

    Creating Rule Matching Patterns

    Ok, so what I have shown you above is a very simple example using a very simple matching rule, however there are actually quite a few ways to format a rule lets review a few of the more common ones that you might see.

    Match by Hostname – All hosts below in the domain fatmin.com matched. Vsftpd is specified service

    vsftpd: .fatmin.com

    Match by IP address – All hosts in 192.168.x.x are matched. Vsftpd is specified service

    vsftpd: 192.168.

    Match by IP/Subnet – All hosts in 192.168.0.0/24 are matched. Vsftpd is specified service

    vsftpd: 192.168.0.0/255.255.255.0

    Match All – All Services and Hosts are matched.

    ALL : ALL

    What Services Use TCP Wrappers

    Initially TCP Wrapper only “wrapped” services that were configured as part of inet.d, or xinet.d, but over time more and more processes have been configured to use librap.so. The example below shows how see if a daemon used libwrap, and can therefore be allowed or blocked via tcpwrappers.

    Below we are locating the sshd binary and seeing if it uses libwrap. Which is does.

    # whereis sshd

    # ldd /usr/sbin/sshd | grep wrap
    libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f03f005d000)

    Below we are locating the smbd binary and seeing if it uses libwrap. Which is does not.

    # whereis smbd

    # ldd /usr/sbin/smbd | grep wrap

    Instead of checking one service at a time you can run the command below. Note that if a service is not installed, it will not show up

    # strings -f /usr/sbin/* |grep hosts_access
    /usr/sbin/rpc.mountd: hosts_access
    /usr/sbin/sshd: hosts_access
    /usr/sbin/tcpd: hosts_access_verbose
    /usr/sbin/tcpdmatch: hosts_access_verbose
    /usr/sbin/vsftpd: hosts_access
    /usr/sbin/xinetd: hosts_access

    Note that httpd, samba (smb) and nfs are not configured by default to use tcpwrappers (however it can be done but that is outside the scope of this post)

    Configuration Examples

    Below are are few more configuration examples that might be useful for reference.

    Allow tftpd access from fatmin, and block everyone else.

    #/etc/hosts.allow

    in.tftpd : .fatmin.com

    #/etc/hosts.deny

    in.tftpd : .ALL

    Allow SSH access from fatmin.com, but block from example.com. Also send log to sshd.log

    #/etc/hosts.allow

    sshd: .fatmin.com

    #/etc/hosts.deny

    sshd : .example.com  \
    : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
    : deny

    Block tfpd access for all of fatmin.com except for server1.fatmin.com. Note that there is no corresponding hosts.allow entry needed.

    #/etc/hosts.deny

    tftpd .fatmin.com EXCEPT server1.fatmin.com

  • RHEL6 – Simple Iptables How To

    Firewall supportYour mother and I were talking last night about how important it is to properly configure Iptables, and how despite that fact, many just choose to disable it. So today we are going to discuss iptables.

    Overview:

    By far the easiest way to setup a simple firewall using Iptables is to use system-config-firewall, or system-config-firewall-tui. I prefer this method as iptables can be a bit confusing on the command line and in its config file (/etc/sysconfig/iptables) is not exactly user friendly. At the very least you can create a basic set of rules and then customize by hand. Lets take a look at the file in its default form on my RHEL 6 box.

    But before we do that, lets review a couple of terms that we need to know.

    1. INPUT – are inbound packets
    2. OUTPUT are outbound packets
    3. FORWARD – packets from another machine that the firewall should forward (like to a vm on the host).
    4. ACCEPT – the packet is accepted
    5. DROP – the packet is dropped as if it never existed
    6. REJECT – the packed is rejected and and error message is returned to sender
    7. RULE – the basic building block — tells the firewall what to do with a packet
    8. CHAIN – a list of all rules which will be checked in order from first to last
    9. POLICY – the default action, like accept, drip, reject, forward

    Now that you have memorized the list above, here is my /etc/sysconfig/iptables.

    # Firewall configuration written by system-config-firewall
    # Manual customization of this file is not recommended.
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
    -A INPUT -j REJECT –reject-with icmp-host-prohibited
    -A FORWARD -j REJECT –reject-with icmp-host-prohibited.

    Now lets run system-config-firewall tui and enable apache and ftp, plus we want to configure our box to respond to ICMP ping requests. This process is pretty self explanitory once you start.

    Once that is done lets view /etc/sysconfig/iptables again.

    # Firewall configuration written by system-config-firewall
    # Manual customization of this file is not recommended.
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
    -A INPUT -p icmp -m icmp –icmp-type echo-request -j REJECT –reject-with icmp-host-prohibited
    -A INPUT -p icmp -m icmp –icmp-type echo-reply -j REJECT –reject-with icmp-host-prohibited
    -A INPUT -p icmp -m icmp –icmp-type destination-unreachable -j REJECT –reject-with icmp-host-prohibited
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 21 -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
    -A INPUT -j REJECT –reject-with icmp-host-prohibited
    -A FORWARD -j REJECT –reject-with icmp-host-prohibited
    COMMIT

    Iptables Command:

    The iptables command can be used in several different ways.

    List the current rules in use, similar to viewing the /etc/sysconfig/iptables file

    #iptables -L

    To set a default policy use iptables -P, in the example below we are setting the default INPUT policy to DROP.

    #iptables -P INPUT DROP

    Now lets say we want to delete all our existing rules, note that i did not say policy

    #iptables -F

    To add a rule use iptables -a, for example lets say you have a default policy of INPUT DROP but we want to accept all established and related packets. Note that -m must be used when adding rules to a chain as it forces modprobe to load any necessary modules.

    #iptables -A INPUT -m state –state ESTABLISHED, RELATED

    Now lets say that we want to reject all packets from 192.168.10.10. Note -j specifies the action that the rule is to take — in the case below, REJECT

    #iptables -A INPUT -s 192.168.10.10 -j REJECT

    Now lets say we want to ACCEPT all ICMP traffic from our local subnet. The -p is protocol

    #iptables -A INPUT -p ICMP -s 192.168.1.0/24 -j ACCEPT

    Please note that under RHEL you can use following commands to save firewall rules.Make sure that you do this before you restart iptables.

    #service iptables save