• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

Linux

SSH Brute Force Attack

01/01/2016 By Andrew Roderos 2 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Almost every day, I log in to my Ubuntu Server edition distro and one day I noticed something odd with the disk space. I noticed that it shot up from around 50% to 80% of 6.5GB. I’ve had this server since Hardy Heron days (8.04), it is now on Trusty Thar (14.04.3) Bionic Beaver (18.04.1), and never once it consumed more than 60% of the allocated disk space. That said, I was curious why all of a sudden the disk space became so big when I did not even install new packages.

The df -ah command was not very helpful since it only listed that root directory was consuming ~80%. I needed to figure out which directory was actually consuming those ~30% of disk space. After doing a web search, I found a command that allowed me to discover an important log that I should have known from the beginning.

$ sudo du -a / | sort -n -r | head -n 10
3571449	/
2589064	/var
2065580	/var/log
1762760	/var/log/btmp.1
613604	/usr
304008	/lib
274824	/var/cache
239600	/var/lib

Brute Force Attack Discovery

This was when I discovered the /var/log/auth.log file. Yes, I am still a Linux newbie. Every authentication attempt is listed here and also their IP address. That’s when I saw a bunch of SSH connections from different IP addresses I do not recognize and different usernames that the system does not even have or has been disabled. Most of the username I’ve seen are ubnt (Ubiquiti’s username on a lot of their products), pi, admin, etc. There was one IP address that has been brute forcing my box for a month without me knowing! Below is a snippet of my compressed auth.log file.

$ zcat /var/log/auth.log.4.gz | grep -v CRON | tail -n 500
Dec 29 06:43:17 ubuntu sshd[17503]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.54 user=root
Dec 29 06:43:18 ubuntu sshd[17501]: message repeated 2 times: [ Failed password for root from 43.229.53.54 port 59428 ssh2]
Dec 29 06:43:18 ubuntu sshd[17501]: Received disconnect from 43.229.53.54: 11:  [preauth]
Dec 29 06:43:18 ubuntu sshd[17501]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.54  user=root
Dec 29 06:43:18 ubuntu sshd[17521]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.54  user=root
Dec 29 06:43:18 ubuntu sshd[17523]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.54  user=root
Dec 29 06:43:20 ubuntu sshd[17509]: message repeated 2 times: [ Failed password for root from 43.229.53.54 port 11637 ssh2]
Dec 29 06:43:20 ubuntu sshd[17509]: Received disconnect from 43.229.53.54: 11:  [preauth]
Dec 29 06:43:20 ubuntu sshd[17509]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.54  user=root
Dec 29 06:43:20 ubuntu sshd[17521]: Failed password for root from 43.229.53.54 port 22024 ssh2
Dec 29 06:43:20 ubuntu sshd[17511]: message repeated 2 times: [ Failed password for root from 43.229.53.54 port 11819 ssh2]

Options

There are several options one can implement to mitigate SSH brute force attack. One option is to not allow passwords and just use SSH keys. This is not a good option for me because I want to use this server with any computer and without using any type of keys. That said, password-based authentication is what I need. Another option is to implement two-factor authentication (2FA), which I covered here.

Firewall Option

Initially, I decided to start blocking the IP addresses I’ve seen in auth.log using my PA-200. It worked for a while, but every day I see new IPs popping. I then decided to implement Geo-based IP rule to lower the amount of attack. While it lessens the attacks significantly, I still needed something to help with the attacks that still goes through the firewall.

Enter Fail2ban

This was suggested by a friend of mine, @guerilla7. Thanks, Ron! Fail2ban scans log files (eg. /var/log/auth.log) and bans IPs (using iptables) that show malicious signs – too many password failures, seeking for exploits, etc. By default, Fail2ban monitors the /var/log/auth.log only. Obviously, this can be configured so that it can monitor more log files.

Installation and Configuration

The installation of Fail2ban will vary depending on your distro. Since Ubuntu is Debian based distro, the package manager is apt-get. It is very simple to install in Ubuntu. The command below is how to install the software and its dependencies.

$ sudo apt-get install fail2ban

Once everything is installed, it is time to configure Fail2ban. But, before we edit the configuration file that Fail2ban uses, it is a good idea to use a different file for custom configurations since the original configuration file can be overwritten by updates. That said, we need to create a copy of the configuration file.

$ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Once copied, we are now ready to configure the jail.local file.

$ sudo vi /etc/fail2ban/jail.local

The configuration file is around 480 lines (including comments), but don’t be afraid because only a few lines will be changed. Of course, that depends on one’s needs. For my needs, I only touched four lines and are listed below.

ignoreip = 127.0.0.1/8 192.168.1.0/24
bantime = -1
findtime = 31536000
maxretry = 3

The ignoreip is basically the whitelist.

The bantime sets the length of time that a client will be banned for failed authentication attempts. The negative value sets it forever. This feature was added to version 0.6.1 (03/2006).

The maxretry and findtime parameters work together in establishing the conditions under which a client is determined by an unauthorized user. By default, the findtime is set to 600 seconds (10 minutes) and maxretry to 3 attempts. This means that Fail2ban will ban an unauthorized user when it attempts to log in three times within 10-minute window. Above configuration is 365-day window. This should cover slow brute force attacks but the majority of the brute force attacks I have seen are within 2-second window.

The changes on the configuration file will not take effect until the restart so sudo /etc/init.d/fail2ban restart must be issued.

Optional Configurations

Feel free to skip these configurations if you don’t find them useful.

Persistent Ban

While the above changes are good enough, the bans are not persistent. Once the server or Fail2ban service was restarted, the banned IPs will not survive. Some will be fine with that configuration, but that is unacceptable for me. I want to be the one who will unban IP addresses not because the server or service was restarted.

Update: As of Fail2ban 0.9.x, the bans are now persistent, by default, after reboot or restart. It now maintains a database found in /var/lib/fail2ban/fail2ban.sqlite3 file. That said, for new installs, there is no need to modify the iptables-multiport.conf file. However, if you already have existing ip.blacklist file, then you may want to still modify the iptables-multiport.conf file.

If you want to verify, look at the fail2ban.conf file and look for the dbfile section. You’ll also see the dbpurgeage section that has a 1-day setting. I think this setting is ignored so long as the bantime is set to any negative number.

$ cat /etc/fail2ban/fail2ban.conf
<-- Output omitted for brevity -->
# Options: dbfile
# Notes.: Set the file for the fail2ban persistent data to be stored.
#         A value of ":memory:" means database is only stored in memory
#         and data is lost when fail2ban is stopped.
#         A value of "None" disables the database.
# Values: [ None :memory: FILE ] Default: /var/lib/fail2ban/fail2ban.sqlite3
dbfile = /var/lib/fail2ban/fail2ban.sqlite3
# Options: dbpurgeage
# Notes.: Sets age at which bans should be purged from the database
# Values: [ SECONDS ] Default: 86400 (24hours)
dbpurgeage = 1d

First Step

The first step in making the ban persistent is to create a file where the list of banned IPs will be added. So that when the service gets restarted, for whatever reason, the software will load the file and issue the proper commands to re-ban the IPs. To create the file, issue the sudo touch /etc/fail2ban/ip.blacklist command. This will create a blank file called ip.blacklist. Feel free to call it different than mine but make sure to use the same file name on the configuration on the next step.

Second Step

The second step is to verify that we are actually going to edit the right configuration file. This is done by viewing the /etc/fail2ban/jail.local file and look for the first banaction = iptables-multiport configuration. At this time of writing, Fail2ban 0.8.11-1 on Ubuntu 14.04.3 is using iptables-multiport, which points to the iptables-multiport.conf file. It’s always a good idea to save a backup configuration, so issue the sudo cp /etc/fail2ban/action.d/iptables-multiport.conf /etc/fail2ban/action.d/iptables-multiport.conf.bak command.

Once completed, we can now move on to the final step. Edit the configuration iptables-multiport.conf file. To edit the iptables-multiport configuration file, issue the sudo vi /etc/fail2ban/action.d/iptables-multiport.conf command. The configuration file has around 70 configuration lines including the comments. There are only two configuration sections that we need to edit. These two are the actionstart and actionban section. The configuration will look as below.

actionstart = iptables -N fail2ban-<name>
              iptables -A fail2ban-<name> -j RETURN
              iptables -I <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
              # This configuration loads the ip.blacklist file every time Fail2ban service is started.
              if [ -f /etc/fail2ban/ip.blacklist ]; then cat /etc/fail2ban/ip.blacklist | grep -e <name>$ | cut -d "," -s -f 1 | while read IP; do iptables -I fail2ban-<name> 1 -s $IP -j DROP; done; fi
actionban = if ! iptables -C fail2ban-<name> -s <ip> -j DROP; then iptables -I fail2ban-<name> 1 -s <ip> -j DROP; fi
            # Add offenders to ip.blacklist file, if it is not already there yet.
            if ! grep -Fxq '<ip>,<name>' /etc/fail2ban/ip.blacklist; then echo '<ip>,<name>' >> /etc/fail2ban/ip.blacklist; fi

Update: Jim commented that the Fail2ban 0.9.3 on Ubuntu 16.04 changed from fail2ban to f2b. Thanks for the comment Jim!

actionstart = iptables -N f2b-<name>
              iptables -A f2b-<name> -j RETURN
              iptables -I <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>
              # This configuration loads the ip.blacklist file every time Fail2ban service is started.
              if [ -f /etc/fail2ban/ip.blacklist ]; then cat /etc/fail2ban/ip.blacklist | grep -e <name>$ | cut -d "," -s -f 1 | while read IP; do iptables -I f2b-<name> 1 -s $IP -j DROP; done; fi
actionban = if ! iptables -C f2b-<name> -s <ip> -j DROP; then iptables -I f2b-<name> 1 -s <ip> -j DROP; fi
            # Add offenders to ip.blacklist file, if it is not already there yet.
            if ! grep -Fxq '<ip>,<name>' /etc/fail2ban/ip.blacklist; then echo '<ip>,<name>' >> /etc/fail2ban/ip.blacklist; fi

Update: With Fail2ban 0.10.2 on Ubuntu 18.04, the default config was slightly changed. However, the line that we added on previous versions remains the same.

actionstart = <iptables> -N f2b-<name>
              <iptables> -A f2b-<name> -j <returntype>
              <iptables> -I <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>
              # This configuration loads the ip.blacklist file every time Fail2ban service is started.
              if [ -f /etc/fail2ban/ip.blacklist ]; then cat /etc/fail2ban/ip.blacklist | grep -e <name>$ | cut -d "," -s -f 1 | while read IP; do iptables -I f2b-<name> 1 -s $IP -j DROP; done; fi
actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>
            # Add offenders to ip.blacklist file, if it is not already there yet.
            if ! grep -Fxq '<ip>,<name>' /etc/fail2ban/ip.blacklist; then echo '<ip>,<name>' >> /etc/fail2ban/ip.blacklist; fi

Since we’ve made a modification to a configuration file, we need to restart the service by issuing sudo /etc/init.d/fail2ban restart or sudo service fail2ban restart command.

Note: I haven’t figured out why the IPs in the ip.blacklist file do not load after reboot or service restart. It will only add the list once a new failed SSH attempt has been made.

DROP vs REJECT

At the time this post was written, fail2ban used DROP as the default block type. Now, they changed the behavior to REJECT with an ICMP message of unreachable.

The biggest difference between the two is that DROP won’t send anything, while REJECT will send a message back to the source.

If you want to change the block type to DROP, then edit the /etc/fail2ban/action.d/iptables-common.conf file. The configuration below shows that I commented out the default behavior and changed it to DROP instead.

$ sudo more /etc/fail2ban/action.d/iptables-common.conf | grep "blocktype = "
# blocktype = REJECT --reject-with icmp-port-unreachable
blocktype = DROP
# blocktype = REJECT --reject-with icmp6-port-unreachable
blocktype = DROP

Verification

Depending on how often the attack occurs, check the iptables after several hours or a day. To check the iptables, issue the command below.

$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-ssh  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Chain fail2ban-ssh (1 references)
target     prot opt source               destination
DROP       all  --  43.229.53.54         0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Manually unbanning an IP address

To unban an IP address, issue the command below.

$ sudo fail2ban-client set <jail_name> unbanip <ip_address>
# Example using Fail2ban 0.8.11
$ sudo fail2ban-client set ssh unbanip 43.229.53.54
43.229.53.54
$ sudo fail2ban-client reload
# Example using Fail2ban 0.9.3 and 0.10.2
$ sudo fail2ban-client set sshd unbanip 43.229.53.54
43.229.53.54
$ sudo fail2ban-client reload

While the command above is enough without the optional configuration (discussed above), this command is not the only thing needed with the optional configuration since the ip.blacklist file still contains the IP address that we’re trying to unban. If the server or service was restarted, then the IP address will be banned again. That said, it is necessary to take it out from the ip.blacklist file. To do this, issue the command below.

$ sudo sed --in-place '/<ip>,<name>/d' /etc/fail2ban/ip.blacklist
# Example
$ sudo sed --in-place '/43.229.53.54,ssh/d' /etc/fail2ban/ip.blacklist
$ sudo fail2ban-client reload

When unbanning fails

When someone issues the sudo fail2ban-client reload command then there is a very high chance that the user will encounter an error message similar to the one below.

$ sudo fail2ban-client set ssh unbanip 58.218.211.198
ERROR  NOK: ('IP 58.218.211.198 is not banned',)
IP 58.218.211.198 is not banned
# Example using Fail2ban 0.10.2
$ sudo fail2ban-client set sshd unbanip 58.218.211.198
ERROR  NOK: ('IP 58.218.211.198 is not banned',)
IP 58.218.211.198 is not banned

The IP can be still unbanned by the following:

$ sudo sed --in-place '/58.218.211.198,ssh/d' /etc/fail2ban/ip.blacklist
$ sudo fail2ban-client reload
$ sudo iptables -L -n | grep 58.218.211.198

Let’s say deleting the IP address from the blacklist file and reloading fail2ban didn’t work like what I experienced recently. The IP address that I was trying to unban kept coming back. I had to find another way to unban it using the iptables command. Here’s what I did to unban the IP address.

$ sudo iptables -L -n --line-numbers | grep 58.218.211.198
655    DROP       all  --  58.218.211.198       0.0.0.0/0
$ sudo iptables -D fail2ban-ssh 655
$ sudo iptables -L -n --line-numbers | grep 58.218.211.198
$ sudo fail2ban-client reload
$ sudo iptables -L -n --line-numbers | grep 58.218.211.198
# Example using 0.10.2
$ sudo iptables -L -n --line-numbers | grep 58.218.211.198
655    DROP       all  --  58.218.211.198       0.0.0.0/0
$ sudo iptables -D f2b-sshd 655
$ sudo iptables -L -n --line-numbers | grep 58.218.211.198
$ sudo fail2ban-client reload
$ sudo iptables -L -n --line-numbers | grep 58.218.211.198

Though, this seems to be a very rare occasion since I tried unbanning another IP address using the method in the manually unbanning section and it worked just fine.

Thoughts

This is exactly the software I was looking for. It is automated which means I no longer need to check auth.log and block it on my Ubiquiti EdgeRouter Lite. I did transfer the rules from my PA-200 to my new router/firewall, however. Though, I am still getting used to the creation of firewall rules because it is not as intuitive as creating rules on Cisco ASA or Palo Alto Networks firewall. While this software automatically blocks failed attempts, it does not protect from weak passwords. It is still recommended to use strong passwords.

UPDATE: I no longer use the EdgeRouter to protect my DMZ – I now use pfSense. The PA-200 will eventually be used on some user traffic but will be limited. Mostly, to learn more about how to configure it.

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

Want to learn more about Linux System Administration?

UNIX and Linux System Administration Handbook, 4th Edition

References

List based permanent bans with fail2ban
How To Protect SSH with fail2ban on Debian 7
How to unban an IP properly with fail2ban

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Damn Small Linux VM For Home Lab

09/01/2015 By Andrew Roderos 1 Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Download my Damn Small Linux OVA here (mirror link). Note: OVA was exported from a VMware ESXi 6.0 host. It might need to be converted for a different hypervisor.

I am getting ready to build my F5 BIG-IP Application Delivery Controller, commonly known as load balancer, home lab and one of the things I need for the lab is to have servers in the internal network side. While I have some Linux VMs already in production, they are not that small compared to Damn Small Linux. I’ve heard and/or read about this distro a long time ago, but never really bothered to check it out until now.

What is Damn Small Linux?

Damn Small Linux is a very versatile 50MB mini desktop oriented Linux distribution. DSL was originally developed as an experiment to see how many usable desktop applications can fit inside a 50MB live CD. It was at first just a personal tool/toy. But over time Damn Small Linux grew into a community project with thousands of development hours put into refinements including a fully automated remote and local application installation system and a very versatile backup and restore system which may be used with any writable media including a USB device, floppy disk, or a hard drive.

VM Hardware Specs

For this install, I used the following:

RAM = 64MB – Using 32MB of vRAM was too slow for my taste.

HDD = 128MB – I didn’t test if I can go smaller using Frugal Install. Make sure to use IDE because SCSI won’t work. One could try to play with boot options to make it work but IDE is fine.

CPU = 1 x vCPU and 1 x core

NIC = 1 x vNIC – Network adapter is set to Flexible

How to install Damn Small Linux?

If one has to create his own version, please follow the steps below. Obviously, change the values for one’s needs.

1. Boot the ISO. You will be greeted like the one on the screenshot. Type dsl 2 on the boot prompt.

first boot

2. Once booted, run cfdisk. Prompt will show something like root@tty1[/]#. Type cfdisk there and hit enter key.

3. A new prompt will show. Type y and hit enter.

No partition table or unknown signature on partition table
Do you wish to start with a zero table [y/N] ?y

4. A new screen will appear.

cfdisk

5. Hit tab to go to the [New] option.

cfdisk new

6. A new screen will show up with three options: Primary, Logical, and Cancel. Select [Primary] and hit enter.

cfdisk primary

7. A new screen will show Size (in MB). Type 75.

cfdisk 75

8. A new screen will show three options: Beginning, End, and Cancel. Select [Beginning] and hit enter.

cfdisk beginning

9. Make hda1 bootable. Select [Bootable] option and hit enter.

cfdisk bootable

10. Select the Free Space partition by hitting the down arrow key. Follow step 6, 7, 8, and 9. For step 8, change it to 25.

11. Change the file system type of hda2 to swap. Tab (or right arrow key) to [Type].

cfdisk hda2 type

12. Type 82 and hit enter.

cfdisk hda2 filesystem

13. Select the Free Space partition by hitting the down arrow key. Follow step 6, 7, 8, and 9. Size will be the remaining one.

14. Once completed, select [Write] option by hitting tab or right arrow and hit enter. A new screen will show up and type yes and hit enter.

cfdisk write yes

15. Exit out of the cfdisk utility. Select [Quit] and hit enter.

16. Prepare the partitions and power off.

root@tty1[/]# mke2fs /dev/hda1
root@tty1[/]# mke2fs /dev/hda3
root@tty1[/]# mkswap /dev/hda2
root@tty1[/]# swapon /dev/hda2
root@tty1[/]# poweroff

17. Once completely powered off, turn it back on and let it boot. May need to manually power it off. By powering it off, it will not eject the ISO on the next boot. Boot will fail without the ISO since the OS is not installed yet. Once booted, one will be greeted by an old fashioned GUI.

first gui boot
install dsl

18. Install Damn Small Linux (DSL). Right click somewhere in the desktop and go to Apps > Tools > Frugal Install > Frugal Grub Install.

19. A terminal window appears. Follow the steps shown on the screenshot or the text below.

frugal grub install
Enter the target partition to hold image (EXAMPLE: hda2): hda1
Install from:
[L]iveCD or Frugal Install
[P]endrive
Local [I]so File
Fetching latest iso from [W]eb
From Poormans via [B]ootfloppy
Choose (l/p/i/w/b): l
Enter partition to be used for MyDSL extensions.(EXAMPLE: hda3): hda3
List boot options:
Example: vga=normal toram tz=US/Pacific ssh fuse: <hit enter>
Choose language/keyboard if other than english:
Example: cs da de es fr nl it pl ru sk: <hit enter>
For INSTALL answer y to format, for UPGRADE answer n.
Format the target partition /dev/hda1 (y/..)? y
Last change to exit before destroying all data on /dev/hda1
Continue (y/..)? y
Formatting /dev/hda1
<-- Output ommitted for brevity -->
Grub Installation Completed.
Press Enter key.

20. Power off the system. Open a terminal and issue sudo poweroff command.

21. Before turning on the VM, remove the ISO to verify that the installation was successful and it boots from the hard disk. Let it boot or just hit enter to boot instantly.

22. DSL X Setup. Go to Cancel option and hit enter.

23. Edit the GRUB menu. Open a terminal window.

dsl@box:~$ sudo su
[/home/dsl]# mount /mnt/hda1
[/home/dsl]# vi /mnt/hda1/boot/grub/menu.lst

Comment out all the title, kernel, and initrd lines. One could technically remove everything but for backup purposes, just comment them out. Once commented out, add a customized DSL. Once added, save and quit.

default 0
timeout 3
title DSL
kernel /boot/linux24 root=/dev/hda1 quiet vga=normal noacpi noscsi frugal dma toram restore=hda3 home=hda3 opt=hda3 host=DSL dsl mydsl=hda3
initrd /boot/minirt24.gz

Sample GRUB menu.lst file.

grub menu

24. Reboot DSL.

25. DSL X Setup is going to pop up again. Just hit cancel.

Optional

The OVA file has all the ones mentioned below so download it to save some time.

Want to stop Dillo browser from starting up every time DSL boots up?

Edit the .xinitrc file. Find the line where it says dillo and comment that line out. Please use the screenshot below as a reference.

dsl@box:~$ sudo su
[/home/dsl]# vi .xinitrc
xinitrc

Want Monkey Web Server to start  automatically during boot up?

Edit bootlocal.sh file. This file is like autoexec.bat in DOS. Add the line below.

[/home/dsl]# vi /opt/bootlocal.sh
/opt/monkey/bin/banana start

Want SSH Daemon to start automatically during boot up?

Edit bootlocal.sh file. Add the line below.

[/home/dsl]# vi /opt/bootlocal.sh
/etc/init.d/ssh start

Thoughts

I spent several hours researching and playing with DSL to get a perfect base VM, but I eventually decided to leave it alone. It’s only going to be used for my F5 load balancer lab, so why spend more time into it. Did I need to do all this? Probably not. I could have cloned a base Ubuntu Server VM with LAMP installed but I really wanted a small Linux VM. It’s perfect for resource constraint machines, not that my ESXi host is, like notebooks.

This is far from perfect DSL install since I couldn’t figure out how to make my password changes permanent. Also, the SSH keys gets generated every boot up so when I connect via SSH, I kept getting new keys every time the server gets rebooted. Yes, one of the links listed below have a way to auto start SSH daemon, but it won’t start because the SSH keys need to be generated. Launching sshd at boot does not necessarily mean it will be successful. No SSH keys, no workie.

References

Frugal Install
Bootlocal.sh
Monkey Web Server

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Cleaning Up Boot Partition

08/19/2013 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

It seems like every single week I have to update my Ubuntu 12.04 Server edition. I configured it to do automatic updates now. Though, I still have to do it manually most of the time. At one point, my boot partition ran out of space and all updates kept failing. I didn’t know at the time why it was failing so I ignored for a few weeks. When I finally paid attention to the issue. I found out that my boot partition was almost full. Apparently, my Linux had warned me every time I logged in to the server since it was on the message of the day page but I normally do not pay to it so it was ignored.

How Did It Get So Big

Well, apparently, Ubuntu holds on to the old kernel when you do sudo apt-get dist-upgrade so whenever it gets updated, it decides to keep the old ones on the boot partition. I didn’t know it at the time so I was really surprised that the boot partition got to a point that I couldn’t update my Ubuntu box. Below is the /etc/motd output that I get whenever I SSH’d to the box. When I was getting an error message that I didn’t have space, I was really confused because if you look at the usage of section of the MOTD it said 43.2% of 6.62GB. But, what I didn’t know at the time was that value was only for the root partition and not for the boot.

login as: networkjutsu
networkjutsu@192.168.1.222's password:
Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-52-generic x86_64)
 * Documentation:  https://help.ubuntu.com/
  System information as of Mon Aug 19 19:33:43 PDT 2013
  System load:  0.68              Processes:           76
  Usage of /:   43.2% of 6.62GB   Users logged in:     1
  Memory usage: 32%               IP address for eth0: 192.168.1.222
  Swap usage:   0%
 The warning will show up here if I am not mistaken talking about /boot partition.
  Graph this data and manage this system at https://landscape.canonical.com/
Last login: Mon Aug 19 19:33:15 2013

Checking Hard Disk Space?

To check hard disk space on Ubuntu Linux, type df -ah on the CLI. Below is the output of my Ubuntu box.

networkjutsu@ubuntu:~$ df -ah
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu-root  6.7G  2.9G  3.5G  46% /
proc                        0     0     0    - /proc
sysfs                       0     0     0    - /sys
none                        0     0     0    - /sys/fs/fuse/connections
none                        0     0     0    - /sys/kernel/debug
none                        0     0     0    - /sys/kernel/security
udev                      79M  4.0K   79M   1% /dev
devpts                      0     0     0    - /dev/pts
tmpfs                     36M  244K   35M   1% /run
none                     5.0M     0  5.0M   0% /run/lock
none                      88M     0   88M   0% /run/shm
/dev/sda1                228M  140M   76M  65% /boot

As you can see above, this particular box has used up 65% of the boot partition. This needs to be cleaned up or I’ll eventually run into the same issue as mentioned earlier.

Boot Partition Contents

At the time, I was curious what are taking up my boot partition so I issued ls -l command and found a similar output as shown below.

networkjutsu@ubuntu:~$ ls -hl /boot
total 136M
-rw-r--r-- 1 root root 773K Apr 10  2012 abi-3.2.0-23-generic
-rw-r--r-- 1 root root 775K Nov 15  2012 abi-3.2.0-34-generic
-rw-r--r-- 1 root root 775K Jan  8  2013 abi-3.2.0-36-generic
-rw-r--r-- 1 root root 775K Jan 24  2013 abi-3.2.0-37-generic
-rw-r--r-- 1 root root 777K Jun 18 11:20 abi-3.2.0-49-generic
-rw-r--r-- 1 root root 777K Jul 26 10:08 abi-3.2.0-52-generic
-rw-r--r-- 1 root root 137K Apr 10  2012 config-3.2.0-23-generic
-rw-r--r-- 1 root root 138K Nov 15  2012 config-3.2.0-34-generic
-rw-r--r-- 1 root root 138K Jan  8  2013 config-3.2.0-36-generic
-rw-r--r-- 1 root root 138K Jan 24  2013 config-3.2.0-37-generic
-rw-r--r-- 1 root root 138K Jun 18 11:20 config-3.2.0-49-generic
-rw-r--r-- 1 root root 138K Jul 26 10:08 config-3.2.0-52-generic
drwxr-xr-x 3 root root 5.0K Aug 19 19:31 grub
-rw-r--r-- 1 root root  15M Dec 15  2012 initrd.img-3.2.0-23-generic
-rw-r--r-- 1 root root  15M Dec 15  2012 initrd.img-3.2.0-34-generic
-rw-r--r-- 1 root root  15M Feb  7  2013 initrd.img-3.2.0-36-generic
-rw-r--r-- 1 root root  15M Feb  7  2013 initrd.img-3.2.0-37-generic
-rw-r--r-- 1 root root  15M Jul 19 20:33 initrd.img-3.2.0-49-generic
-rw-r--r-- 1 root root  15M Aug 19 19:32 initrd.img-3.2.0-52-generic
drwxr-xr-x 2 root root  12K Dec 15  2012 lost+found
-rw-r--r-- 1 root root 173K Nov 27  2011 memtest86+.bin
-rw-r--r-- 1 root root 175K Nov 27  2011 memtest86+_multiboot.bin
-rw------- 1 root root 2.8M Apr 10  2012 System.map-3.2.0-23-generic
-rw------- 1 root root 2.8M Nov 15  2012 System.map-3.2.0-34-generic
-rw------- 1 root root 2.8M Jan  8  2013 System.map-3.2.0-36-generic
-rw------- 1 root root 2.8M Jan 24  2013 System.map-3.2.0-37-generic
-rw------- 1 root root 2.8M Jun 18 11:20 System.map-3.2.0-49-generic
-rw------- 1 root root 2.8M Jul 26 10:08 System.map-3.2.0-52-generic
-rw------- 1 root root 4.8M Apr 10  2012 vmlinuz-3.2.0-23-generic
-rw------- 1 root root 4.8M Nov 15  2012 vmlinuz-3.2.0-34-generic
-rw------- 1 root root 4.8M Jan  8  2013 vmlinuz-3.2.0-36-generic
-rw------- 1 root root 4.8M Jan 24  2013 vmlinuz-3.2.0-37-generic
-rw------- 1 root root 4.8M Jun 18 11:20 vmlinuz-3.2.0-49-generic
-rw------- 1 root root 4.8M Jul 26 10:08 vmlinuz-3.2.0-52-generic

As shown, there are a lot of older kernel version (vmlinuz) still on the boot partition. In theory, rm command should work but it’s not as clean as running the dpkg command.

Cleaning It Up

As already mentioned, the quickest and probably the best way to clean this up is to issue the command shown below. There are a lot of ways to do this but I prefer this command since it’s only one line of command. When I first had to clean up the boot partition, I actually used several commands to clean it up. This one is just one line of command and you’re good to go. I’ve included the whole output just to show a similar screen that you’ll see.

networkjutsu@ubuntu:~$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge 

[sudo]
password for networkjutsu:
Reading package lists…
Done
Building dependency tree Reading state information…
Done
The following packages will be REMOVED:
linux-headers-3.2.0-23*
linux-headers-3.2.0-23-generic*
linux-headers-3.2.0-34*
linux-headers-3.2.0-34-generic*
linux-headers-3.2.0-36*
linux-headers-3.2.0-36-generic*
linux-headers-3.2.0-37*
linux-headers-3.2.0-37-generic*
linux-headers-3.2.0-49*
linux-headers-3.2.0-49-generic*
linux-image-3.2.0-23-generic*
linux-image-3.2.0-34-generic*
linux-image-3.2.0-36-generic*
linux-image-3.2.0-37-generic*
linux-image-3.2.0-49-generic*
0 upgraded, 0 newly installed, 15 to remove and 0 not upgraded. After this operation, 1,084 MB disk space will be freed. (Reading database … 180798 files and directories currently installed.)
Removing linux-headers-3.2.0-23-generic …
Removing linux-headers-3.2.0-23 …
Removing linux-headers-3.2.0-34-generic …
Removing linux-headers-3.2.0-34 …
Removing linux-headers-3.2.0-36-generic …
Removing linux-headers-3.2.0-36 …
Removing linux-headers-3.2.0-37-generic …
Removing linux-headers-3.2.0-37 …
Removing linux-headers-3.2.0-49-generic …
Removing linux-headers-3.2.0-49 …
Removing linux-image-3.2.0-23-generic …
Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic update-initramfs:
Deleting /boot/initrd.img-3.2.0-23-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic Generating grub.cfg …
Found linux image: /boot/vmlinuz-3.2.0-52-generic
Found initrd image: /boot/initrd.img-3.2.0-52-generic
Found linux image: /boot/vmlinuz-3.2.0-49-generic
Found initrd image: /boot/initrd.img-3.2.0-49-generic
Found linux image: /boot/vmlinuz-3.2.0-37-generic
Found initrd image: /boot/initrd.img-3.2.0-37-generic
Found linux image: /boot/vmlinuz-3.2.0-36-generic
Found initrd image: /boot/initrd.img-3.2.0-36-generic
Found linux image: /boot/vmlinuz-3.2.0-34-generic
Found initrd image: /boot/initrd.img-3.2.0-34-generic
Found memtest86+ image: /memtest86+.bin done
Purging configuration files for linux-image-3.2.0-23-generic …
Examining /etc/kernel/postrm.d . run-parts:
executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic run-parts:
executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
Removing linux-image-3.2.0-34-generic …
Examining /etc/kernel/postrm.d . run-parts:
executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-34-generic /boot/vmlinuz-3.2.0-34-generic update-initramfs:
Deleting /boot/initrd.img-3.2.0-34-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-34-generic /boot/vmlinuz-3.2.0-34-generic
Generating grub.cfg …
Found linux image: /boot/vmlinuz-3.2.0-52-generic
Found initrd image: /boot/initrd.img-3.2.0-52-generic
Found linux image: /boot/vmlinuz-3.2.0-49-generic
Found initrd image: /boot/initrd.img-3.2.0-49-generic
Found linux image: /boot/vmlinuz-3.2.0-37-generic
Found initrd image: /boot/initrd.img-3.2.0-37-generic
Found linux image: /boot/vmlinuz-3.2.0-36-generic
Found initrd image: /boot/initrd.img-3.2.0-36-generic
Found memtest86+ image: /memtest86+.bin done
Purging configuration files for linux-image-3.2.0-34-generic …
Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-34-generic /boot/vmlinuz-3.2.0-34-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-34-generic /boot/vmlinuz-3.2.0-34-generic
Removing linux-image-3.2.0-36-generic …
Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-36-generic /boot/vmlinuz-3.2.0-36-generic update-initramfs:
Deleting /boot/initrd.img-3.2.0-36-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-36-generic /boot/vmlinuz-3.2.0-36-generic
Generating grub.cfg …
Found linux image: /boot/vmlinuz-3.2.0-52-generic
Found initrd image: /boot/initrd.img-3.2.0-52-generic
Found linux image: /boot/vmlinuz-3.2.0-49-generic
Found initrd image: /boot/initrd.img-3.2.0-49-generic
Found linux image: /boot/vmlinuz-3.2.0-37-generic
Found initrd image: /boot/initrd.img-3.2.0-37-generic
Found memtest86+ image: /memtest86+.bin done
Purging configuration files for linux-image-3.2.0-36-generic …
Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-36-generic /boot/vmlinuz-3.2.0-36-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-36-generic /boot/vmlinuz-3.2.0-36-generic
Removing linux-image-3.2.0-37-generic …
Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-37-generic /boot/vmlinuz-3.2.0-37-generic update-initramfs:
Deleting /boot/initrd.img-3.2.0-37-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-37-generic /boot/vmlinuz-3.2.0-37-generic Generating grub.cfg …
Found linux image: /boot/vmlinuz-3.2.0-52-generic Found initrd image: /boot/initrd.img-3.2.0-52-generic
Found linux image: /boot/vmlinuz-3.2.0-49-generic Found initrd image: /boot/initrd.img-3.2.0-49-generic
Found memtest86+ image: /memtest86+.bin done Purging configuration files for linux-image-3.2.0-37-generic …
Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-37-generic /boot/vmlinuz-3.2.0-37-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-37-generic /boot/vmlinuz-3.2.0-37-generic Removing linux-image-3.2.0-49-generic …
Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-49-generic /boot/vmlinuz-3.2.0-49-generic update-initramfs:
Deleting /boot/initrd.img-3.2.0-49-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-49-generic /boot/vmlinuz-3.2.0-49-generic
Generating grub.cfg …
Found linux image: /boot/vmlinuz-3.2.0-52-generic
Found initrd image: /boot/initrd.img-3.2.0-52-generic
Found memtest86+ image: /memtest86+.bin done
The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old you may need to re-run your boot loader[grub] The link /initrd.img.old is a damaged link
Removing symbolic link initrd.img.old you may need to re-run your boot loader[grub]
Purging configuration files for linux-image-3.2.0-49-generic …
Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-49-generic /boot/vmlinuz-3.2.0-49-generic run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-49-generic /boot/vmlinuz-3.2.0-49-generic

Verification

To verify that the command worked, issue both commands. Though, the first command will be fine.

networkjutsu@ubuntu:~$ df -ah
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu-root  6.7G  1.7G  4.7G  27% /
proc                        0     0     0    - /proc
sysfs                       0     0     0    - /sys
none                        0     0     0    - /sys/fs/fuse/connections
none                        0     0     0    - /sys/kernel/debug
none                        0     0     0    - /sys/kernel/security
udev                      79M   12K   79M   1% /dev
devpts                      0     0     0    - /dev/pts
tmpfs                     36M  244K   35M   1% /run
none                     5.0M     0  5.0M   0% /run/lock
none                      88M     0   88M   0% /run/shm
/dev/sda1                228M   27M  189M  13% /boot
networkjutsu@ubuntu:~$ ls -al /boot
total 23544
drwxr-xr-x  4 root root     2048 Aug 19 20:18 .
drwxr-xr-x 23 root root     4096 Aug 19 20:18 ..
-rw-r--r--  1 root root   795365 Jul 26 10:08 abi-3.2.0-52-generic
-rw-r--r--  1 root root   140629 Jul 26 10:08 config-3.2.0-52-generic
drwxr-xr-x  3 root root     5120 Aug 19 20:18 grub
-rw-r--r--  1 root root 14819736 Aug 19 19:32 initrd.img-3.2.0-52-generic
drwxr-xr-x  2 root root    12288 Dec 15  2012 lost+found
-rw-r--r--  1 root root   176764 Nov 27  2011 memtest86+.bin
-rw-r--r--  1 root root   178944 Nov 27  2011 memtest86+_multiboot.bin
-rw-------  1 root root  2893555 Jul 26 10:08 System.map-3.2.0-52-generic
-rw-------  1 root root  4978224 Jul 26 10:08 vmlinuz-3.2.0-52-generic

Thoughts

I am actually surprised that Ubuntu chose to keep the older kernel when doing an update. I wish in the future release that they will include the uninstall of the older kernel so I won’t have to do this every time I am running out of boot partition space. Yes, I can redo the partition but it will eventually fill up anyway so it’s a wasted effort in my opinion.

Reference

Ubuntu Forum

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

How to configure tac_plus (TACACS+ daemon) on Ubuntu Server

10/01/2011 By Andrew Roderos 9 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

In this blog post, I will cover on how to build and configure TACACS+ on Ubuntu Server using tac_plus. While this is an old blog post, the instructions covered here are still valid in Ubuntu Server 16.04 LTS. I highly recommend that you integrate two-factor authentication (2FA) as well, which is covered here.

If you are looking for an alternative to Cisco Secure Access Control Server (ACS) and how to implement it, then you came to the right place. Since you are looking for an alternative, I think it is safe to assume that you’ve seen how much is the price tag of Cisco Secure ACS (EoS/EoL now – functionality is now on Cisco ISE) and you think it’s too expensive for your network – my quote was $17K. A lot of companies do not have a budget for something like that. The Great Recession also didn’t help since a lot more companies are tightening their belt, especially in IT projects and that’s not something new.

Related: Adding Two-Factor Authentication (2FA) to TACACS+ running on Ubuntu 16.04

Having said all of that, how can Network Engineers harden the networking devices that is also cost efficient? Well, let’s thank Cisco for that by releasing the source code of TACACS+ back in the day and of course the open source community. The source can still be downloaded from Cisco’s FTP site. Cisco has not updated this source code for probably more than a decade but Open Source community has made some changes to it so features may be better than the source code. However, if you’re just looking for a simple AAA (Authentication Authorization Accounting) then tac_plus will be fine. This is actually one of the topics in a Cisco Press book called Network Administrators Survival Guide.

Tac_plus is a TACACS+ daemon for Linux that is based on the original Cisco TACACS+ source code.

Security is paramount to any organization, so hardening the organization’s networking devices add a layer to organization’s security. A security enthusiast once told me that security is more effective if you deploy in several layers. By deploying security in layers, organizations can mitigate security risks. Cisco Secure ACS can add a layer to organization’s security by providing AAA. The appliance or software serves as NAS (Network Access Server) and it supports two security protocols, RADIUS (Remote Access Dial-In User Service) and TACACS (Terminal Access Controller Access Control Server).

Related: Deploying TACACS+ on a Docker container

The main difference between the two protocols is how they encrypt the packet. RADIUS only encrypts the password and the rest are unencrypted, so the username, authorized services, and accounting can be captured. On the other hand, TACACS+ encrypts the entire packet which is more secure. If you are tasked to deploy AAA in your organization, make sure that you opt with the TACACS+ implementation and not RADIUS.

This article will talk about how to deploy TACACS+ using the publicly available source code from Cisco. Without further delay, here’s the tutorial on how to implement TACACS+.

What’s needed

In this tutorial, you will need the following:

  • Know how to download, install, and update the latest Ubuntu Linux (latest at this time of writing is Ubuntu 11.04 – preferably  Server Edition).
  • Know how to use VI editor or any text editor under Linux environment.
  • Physical machine(s) or virtual machine(s)
  • 6GB hard drive space is more than enough. Though, if you’re concern of keeping tons of accounting logs, then please feel free to increase the size.
  • 256MB of RAM should be enough. Start small and monitor your memory usage.

Instructions

Below are the steps in successfully implementing TACACS+ to your routers and switches.

Download, Install and Update

Download, install and update Ubuntu 11.04 Server Edition on your machine(s). While one machine is enough, I suggest deploying two for backup. If getting another physical/virtual machine is an issue, then do not worry about it. There is a backup user account that will be created in this tutorial, so when the TACACS+ is not available Network Administrators/Technicians/Engineers can still authenticate and issue commands.

Download and install  TACACS+. To download TACACS+, issue the command below:

sudo apt-get install tacacs+

Edit tac_plus Configuration File

Once installed, you’re now ready to edit the tac_plus configuration file. I will try to break down the configuration file to explain what it does.

Using VI editor to edit the configuration file. Feel free to use nano or other text editors available.

admin@ubuntu:~$ vi /etc/tacacs+/tac_plus.conf

The default configuration of the TACACS+ accounting log is /var/log/tac_plus.acct. Feel free to change this to your liking. However, I suggest you change the read and write permissions using chmod, so that only certain users or groups are allowed to edit or view the file.

accounting file = /var/log/tac_plus.acct

Define TACACS+ Key

Define your TACACS+ key here. Remember this key since it will be used later on your AAA configuration.

key = tacacskey123

User Accounts And Groups

In this section, I will create three user accounts and assign them to their proper group.

#*************************
#***USERS ACCOUNTS HERE***
#*************************
user = NetworkEngineer1 {
        member = Network_Engineers
}
user = FieldTech1 {
        member = Field_Techs
}
user = Manager1 {
        member = Managers
}

In this tutorial, I will not use the built-in DES encryption of TACACS+ daemon. Due to the fact that DES has been cracked back in the late 90s. I will be using Linux’s default authentication and incorporate that to tac_plus.conf.

This section will create groups, specify their authentication method (in this case using /etc/passwd – Linux user authentication), and what authorized commands are available to the groups.

Network engineers have all commands available to them. The default service = permit parameter tells TACACS+ daemon that all commands are allowed for this group. The login = file /etc/passwd parameter tells the daemon to look for the user account and password matches in the file. If it matches, allow the account to log in to the router and switch. The enable = file /etc/passwd tells the daemon that it needs to match the password of the user account. If it matches, allow to enter privileged EXEC mode, also known as enable mode.

#*************************
#***   GROUPS HERE     ***
#*************************
group = Network_Engineers {
        default service = permit
        login = file /etc/passwd
        enable = file /etc/passwd
}

Permissions

Field Technicians, on the other hand, has a default service = deny parameter which tells the daemon that all other commands except for user EXEC commands are allowed. Having said that, you will need to permit the commands that they’re allowed to use. Service = exec and priv-lvl = 2 allows us to give a higher privilege than an ordinary user. We do not want to give this group a privilege level of 15, meaning the same level as the network engineers. I will not explain all the parameters here since I believe they’re pretty much self-explanatory for an IT professional who knows Cisco IOS.

group = Field_Techs {
        default service = deny
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
        priv-lvl = 2
        }
        cmd = enable {
                permit .*
        }
        cmd = show {
                permit .*
        }
        cmd = do {
                permit .*
        }
        cmd = exit {
                permit .*
        }
        cmd = configure {
                permit terminal
        }
        cmd = interface {
                permit .*
        }
        cmd = shutdown {
                permit .*
        }
        cmd = no {
                permit shutdown
        }
        cmd = speed {
                permit .*
        }
        cmd = duplex {
                permit .*
        }
        cmd = write {
                permit memory
        }
        cmd = copy {
                permit running-config
        }
}

Managers are given access as well, however, the only privilege EXEC mode allowed is show running-config. Feel free to add more commands necessary for your boss and/or your boss’ boss.

group = Managers {
        default service = deny
        login = file /etc/passwd
        enable = file /etc/passwd
        service = exec {
        priv-lvl = 2
        }
        cmd = enable {
                permit .*
        }
        cmd = show {
                permit .*
        }
        cmd = exit {
                permit .*
        }
}

Creating a test user account and the group might be a good idea, so you can test things out that have been added to this configuration. This particular test user will only have a cleartext password.

user = test {
        member = Test_Group
}
group = Test_Group {
        default service = deny
        service = exec {
        priv-lvl = 2
        login = password1
        enable = password1
}

Restart tac_plus Daemon

Most of the time in Linux/Unix environment, you need to restart the daemon before your configuration will take effect.

admin@ubuntu:~$ sudo /etc/init.d/tacacs_plus restart
password for admin:
 * Restarting TACACS+ authentication daemon tacacs+                      [ OK ]
admin@ubuntu:~$

User Accounts

It is now time to create the user account under Linux.

admin@ubuntu:~$ sudo adduser test
Adding user `test' ...
Adding new group `test' (1001) ...
Adding new user `test' (1001) with group `test' ...
The home directory `/home/test' already exists.  Not copying from `/etc/skel'.
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for test
Enter the new value, or press ENTER for the default
	Full Name []:
	Room Number []:
	Work Phone []:
	Home Phone []:
	Other []:
Is the information correct? [Y/n] y

Change Password

For the password, please use the organization’s standard on default passwords. Always remind the users to change their password when they first log in. To change the password, have the user issue the command below.

test@ubuntu:~$ passwd
Changing password for test.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

If I am showing you how to add a Linux user account, then I should be showing you how to remove an account as well, since all organizations lose good and/or bad employees all the time. Not deleting an account is a big no-no and obviously a huge security risk.

admin@ubuntu:~$ sudo deluser test
 password for admin: Removing user `test' ... Warning: group `test' has no more members. Done.

Changing IP Address

When you first install Ubuntu, it uses DHCP and that’s not a great idea for a server – at the time of writing. You will need to change the IP configuration on this server, so you can specify the IP of the TACACS server(s) on routers and switches.

admin@ubuntu:~$ sudo vi /etc/network/interfaces

Look for the following:

# The primary network interface
auto eth0
iface eth0 inet dhcp

Once found, change it to something similar:

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.10.100
        netmask 255.255.255.0
        network 192.168.10.0
        broadcast 192.168.10.255
        gateway 192.168.10.254

Again, if you change something it needs to be restarted.

admin@ubuntu:~$ sudo /etc/init.d/networking restart
 * Reconfiguring network interfaces...                                   [ OK ]
admin@ubuntu:~$

If you chose to have two TACACS+ servers and you used a VM, then you don’t need to do a whole lot. Just clone your TACACS+ VM, change the hostname and IP address and you’re done. Make sure your two TACACS+ VMs are not on the same physical host, so your implementation is fault tolerant.

Cisco Configuration

The how to configure AAA on Cisco routers and switches is covered here and the how to configure AAA on Cisco ASA is covered here. To create ACL on tac_plus, please see this post.

Final Words

TACACS+ is now ready to go. Congratulations, you just accomplished one part of hardening your organization’s networking devices!

Do not be afraid of Linux. There are a lot of freebies out there that can help your organization to save money on network tools and etc. Being free, it won’t be as fancy as the paid software but it will get the job done.

I hope this tutorial has been helpful and thank you for reading!

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

You might also like to read

TACACS+ (tac_plus daemon) ACL
Adding two-factor authentication (2FA) to TACACS+
How to configure AAA on Cisco router/switches
Enabling AAA on Cisco ASA

Reference

TACACS+ and RADIUS Comparison

Want to learn more about AAA?

AAA Identity Management Security

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email
  • « Go to Previous Page
  • Go to page 1
  • Go to page 2

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use