• 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

Network Security

Hardening EdgeRouter Lite – Part 3

12/05/2016 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

This blog post is part of a series on EdgeRouter Lite. You may want to check them all out!

DateTitleDescription
03/13/16My Home Router – EdgeRouter LiteQuick introduction to EdgeRouter Lite
04/09/16Ubiquiti’s EdgeOS CLI IntroductionEdgeOS CLI Primer
05/01/16How to configure EdgeRouter Lite via CLI – Part 1EdgeOS configuration guide for CLI junkies
05/01/16How to configure EdgeRouter Lite via CLI – Part 2EdgeOS configuration guide for CLI junkies
12/03/16Hardening EdgeRouter Lite – Part 1Basic management hardening
12/04/16Hardening EdgeRouter Lite – Part 2EdgeOS with two-factor authentication
12/06/16Hardening EdgeRouter Lite – Part 4Remote Access VPN with two-factor authentication

Introduction

I focused on authentication method in the first two posts of this EdgeRouter Lite series. In today’s post, I will focus on access restriction to the management plane. To accomplish this access restriction, we need to create firewall policies on the router and apply it to LAN and sub-interfaces. This post will show what you need for the firewall policy.

Management ACL

While restricting management services to listen on a single address, it is also a good practice to restrict addresses or networks allowed to reach it. The firewall on EdgeOS allows users the creation of address groups and network groups. The groups allow users include more than one address in the firewall policy. Without further ado, below is an example of a firewall policy that one can apply to EdgeRouter Lite.

Firewall group

We need to gather the source IP addresses or network prefixes that will be allowed to connect to the EdgeRouter Lite. It is good practice that these hosts are one of the most secure computers in the network.  We do not want the bad guys taking control of our router since all traffic traverses through it. For example, my Linux hosts have 2FA enabled for both SSH and console access.

The address-group allows users to add multiple IP addresses.

set firewall group address-group SSH-TRUSTED address 192.168.254.100
set firewall group address-group SSH-TRUSTED address 192.168.254.101

The network-group allows users to add network prefixes.

set firewall group network-group GUI-TRUSTED network 192.168.253.0/24
set firewall group network-group GUI-TRUSTED network 192.168.254.0/24

Firewall policy

Once we’ve created the firewall group, we are now ready to create the firewall rules.

The first three lines are what a lot of people will call this as a catch-all rule. Any traffic not defined in our firewall policy will fall under this rule.

set firewall name LAN-LOCAL default-action drop
set firewall name LAN-LOCAL description 'LAN IPv4 inbound traffic to the router'
set firewall name LAN-LOCAL enable-default-log

The next firewall rule is unnecessary, but I like to add it in the beginning. In my environment, this rule has one of the lowest numbers, so it is safe to move it at the end of the firewall policy if you feel so inclined. Alternatively, do not add this rule since the catch-all rule will drop this traffic.

set firewall name LAN-LOCAL rule 10 action drop
set firewall name LAN-LOCAL rule 10 description 'Drop invalid state'
set firewall name LAN-LOCAL rule 10 log disable
set firewall name LAN-LOCAL rule 10 state invalid enable

I will leave the next rule at your discretion. Some people like to allow ICMP for troubleshooting purposes and some people do not.

set firewall name LAN-LOCAL rule 20 action accept
set firewall name LAN-LOCAL rule 20 description 'Allow ICMP'
set firewall name LAN-LOCAL rule 20 log disable
set firewall name LAN-LOCAL rule 20 protocol icmp

The next rule depends if you run SNMP or not. I run the free PRTG Network Monitor in my environment, so I have to add it.

set firewall name LAN-LOCAL rule 30 action accept
set firewall name LAN-LOCAL rule 30 description 'Allow SNMP'
set firewall name LAN-LOCAL rule 30 destination port 161
set firewall name LAN-LOCAL rule 30 log disable
set firewall name LAN-LOCAL rule 30 protocol udp
set firewall name LAN-LOCAL rule 30 source address 192.168.200.200

These next rules are what we need to restrict source IP addresses or network prefixes that can connect to the EdgeRouter Lite. If you disable GUI access then there is no point in adding firewall rules for both HTTP and HTTPS.

set firewall name LAN-LOCAL rule 40 action accept
set firewall name LAN-LOCAL rule 40 description 'Allow SSH'
set firewall name LAN-LOCAL rule 40 destination port 22
set firewall name LAN-LOCAL rule 40 log disable
set firewall name LAN-LOCAL rule 40 protocol tcp
set firewall name LAN-LOCAL rule 40 source group address-group SSH-TRUSTED
set firewall name LAN-LOCAL rule 50 action accept
set firewall name LAN-LOCAL rule 50 description 'Allow HTTPS'
set firewall name LAN-LOCAL rule 50 destination port 443
set firewall name LAN-LOCAL rule 50 log disable
set firewall name LAN-LOCAL rule 50 protocol tcp
set firewall name LAN-LOCAL rule 50 source group network-group GUI-TRUSTED
set firewall name LAN-LOCAL rule 60 action accept
set firewall name LAN-LOCAL rule 60 description 'Allow HTTP'
set firewall name LAN-LOCAL rule 60 destination port 80
set firewall name LAN-LOCAL rule 60 log disable
set firewall name LAN-LOCAL rule 60 protocol tcp
set firewall name LAN-LOCAL rule 60 source group network-group GUI-TRUSTED

The last rule allows any traffic that is in established or related state. Check this site to understand the states.

set firewall name LAN-LOCAL rule 70 action accept
set firewall name LAN-LOCAL rule 70 description 'Allow Established'
set firewall name LAN-LOCAL rule 70 log disable
set firewall name LAN-LOCAL rule 70 protocol all
set firewall name LAN-LOCAL rule 70 state established enable
set firewall name LAN-LOCAL rule 70 state related enable

Apply the firewall policy

Now, we need to apply the firewall rule to all your LAN interfaces including sub-interfaces.

set interfaces ethernet eth1 firewall local name LAN-LOCAL
set interfaces ethernet eth2 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 10 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 50 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 100 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 200 firewall local name LAN-LOCAL

Save config

Now, we need to save the configuration by issuing commit;save command.

Verification

Try connecting to EdgeRouter Lite without logging out from your current SSH or secure HTTP connection. This ensures that you still have access to the router just in case there’s a mistake with the ACL. If you have a Network Management System (NMS), make sure that SNMP is working as well.

Final Words

Any traffic destined to the EdgeRouter Lite must be restricted. While we did it on the WAN side, we also need to secure the LAN side. As much as possible, the allowed list must be limited. Only systems that must have router access should be on the list. Finally, computers on the list should have great security controls to keep it from being compromised.

The next blog post, I am going to talk about securing the remote access VPN. The blog post will address the security concerns on my how to configure EdgeRouter Lite guide.

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

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

Hardening EdgeRouter Lite – Part 1

12/03/2016 By Andrew Roderos 6 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

This blog post is part of a series on EdgeRouter Lite. You may want to check them all out!

DateTitleDescription
03/13/16My Home Router – EdgeRouter LiteQuick introduction to EdgeRouter Lite
04/09/16Ubiquiti’s EdgeOS CLI IntroductionEdgeOS CLI Primer
05/01/16How to configure EdgeRouter Lite via CLI – Part 1EdgeOS configuration guide for CLI junkies
05/01/16How to configure EdgeRouter Lite via CLI – Part 2EdgeOS configuration guide for CLI junkies
12/04/16Hardening EdgeRouter Lite – Part 2EdgeOS with two-factor authentication
12/05/16Hardening EdgeRouter Lite – Part 3Management ACL
12/06/16Hardening EdgeRouter Lite – Part 4Remote Access VPN with two-factor authentication

Introduction

It has been a while since I talked about my EdgeRouter Lite. Since then, my configuration has changed. I will be discussing some of the configuration changes in this series of blog posts.

As the title implies, I will cover the process of hardening EdgeRouter Lite to address the security concerns one might have with my two-part blog post. This, by no means, is complete or the most secure configuration so feel free to drop me a line with your suggestions.

Note: This post is based on firmware version 1.9.

Web UI

The HTTPS service listens, by default, to all addresses assigned to router’s interfaces. We can improve security by restricting web management traffic to a single address.

set service gui listen-address 192.168.200.1

Alternatively, I could disable the service if I have no use for it.

delete service gui

One of the things I noticed in EdgeOS is that it listens to port 80 and 443. However, users that try to hit the router via HTTP will be redirected to HTTPS. The show service gui command won’t list it but when you issue show configuration commands | match “service gui” then it will show up. This behavior is OK in my opinion since it switches to secure HTTP. Though, there might be some people who will find this unacceptable. If you are one of them, the delete service gui http-port 80 command will disable this. Alternatively, one can just use the firewall to block it. I will cover the firewall configuration in future blog posts.

SSH Service

In my how to configure EdgeRouter Lite part one guide, my SSH service section has two config lines. While it touches a bit about security, I didn’t really touch on securing the service further. By default, the router’s SSH server will listen to any addresses assigned to an interface, just like the Web UI. In this section, we will instruct EdgeOS to only listen to a specific IP address.

set service ssh listen-address 192.168.200.1

Public-Key Authentication

One of the mitigation techniques for SSH brute force attack is by using SSH key authentication method. In order to do this, we will need to generate SSH keys on the client(s), load the public key on EdgeRouter, and disable password authentication.

Generating SSH keys

In this post, the host that I used to generate keys runs on Ubuntu Server 16.04.1. Generating keys on macOS and other Linux distro might be the same command. If you’re a Windows user, please research on how to generate keys using PuTTY Generator.

username@ubuntu01:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa): <just hit enter>
Enter passphrase (empty for no passphrase): <enter passphrase here>
Enter same passphrase again: <enter passphrase here>
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:a-bunch-of-characters-are-displayed-here username@ubuntu01
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|                 |
|     random      |
|   characters    |
|      are        |
|    displayed    |
|      here       |
|                 |
|                 |
+----[SHA256]-----+

Copying SSH key

There are two methods, that I know of, on how to copy the public key that we generated to the EdgeRouter. I will only cover two of them.

Method 1

This method is the easiest out of the two. This method will only work if password authentication is still enabled. If not, then you will have to use the second method.

username@ubuntu01:~$ ssh-copy-id username@ubnt.domain.local
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/username/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
********************************************************************
*************       THIS IS MY UBIQUITI EDGEROUTER     *************
*************           YOU SHALL NOT PASS!!!          *************
********************************************************************
username@ubnt.domain.local's password:
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh 'username@ubnt.domain.local'" and check to make sure that only the key(s) you wanted were added.

The public key is now copied and we are now ready to load the key. Skip the method 2 section and go to the next.

Method 2

This method is a bit more involved than the first one. The second part of this method is applicable to Windows users. It’s just a matter of copying the public key to clipboard and saving it to a file in EdgeRouter. This will be the method you’ll use going forward when you disable password authentication and need to add more public keys. Alternatively, you can enable password authentication temporarily and use the first method to add more public keys. Don’t forget to disable password authentication.

The first step is to view the public key from the host.

username@ubuntu01:~$ more ~/.ssh/id_rsa.pub
ssh-rsa a-bunch-of-characters-are-displayed-here-and-is-very-long username@ubuntu01

The next step is to copy everything. Note: It may show up as multiple lines on your screen. Make sure to paste it as a single line to a file in EdgeRouter.

sudo vi ~/.ssh/authorized_keys
ssh-rsa a-bunch-of-characters-are-displayed-here-and-is-very-long username@ubuntu01

If you are not familiar with VI/VIM editor, then use this.

bash
echo ssh-rsa a-bunch-of-characters-are-displayed-here-and-is-very-long username@ubuntu01 >> ~/.ssh/authorized_keys
exit

Loading SSH key

The next step is to load the public key to the configuration. The command covered here instructs the router to load the public key from the Linux environment to EdgeOS. This ensures that the keys will survive a reboot and/or firmware upgrade since configurations will be saved in /config directory.

loadkey username ~/.ssh/authorized_keys

We’ll delete the authorized_keys file since it is no longer needed.

sudo rm ~/.ssh/authorized_keys

Disable Password Authentication

The last step in enabling public key authentication is to disable password authentication. Right now, users are still able to log into the EdgeRouter using password. To disable this behavior, we’ll need to configure SSH daemon to only allow public key authentication.

set service ssh disable-password-authentication

For this to take effect, we’ll need to commit the changes and save the config to the config.boot file. The command below will cause SSH daemon (sshd) to restart.

commit; save

Verification

Now, we’re ready to test our EdgeRouter configuration.

Host with public key

Here’s my Ubuntu host with public key connecting to EdgeRouter Lite.

username@ubuntu01:~$ ssh username@ubnt.domain.local
********************************************************************
*************       THIS IS MY UBIQUITI EDGEROUTER     *************
*************           YOU SHALL NOT PASS!!!          *************
********************************************************************
Enter passphrase for key '/home/username/.ssh/id_rsa': <enter passphrase>
Linux ubnt 3.10.20-UBNT #1 SMP Fri Jul 29 16:51:50 PDT 2016 mips64
Welcome to EdgeOS
Last login: Fri Nov 25 10:09:27 2016 from 192.168.254.100

Depending on your host’s OS, the behavior may be different. My host likes to ask for the private key passphrase every time I try to connect to EdgeRouter Lite. This requirement of passphrase could serve as an additional layer of security. Though, this depends if the user is using a unique and secure passphrase. To modify this behavior, I had to add the identity to the key manager so I don’t have to keep typing every single time. I will leave it to your discretion if you want to do the same thing.

Installing key manager

Install keychain package as the key manager.

username@ubuntu01:~$ sudo apt-get install keychain -y

Edit the .bashrc file and add the following.

username@ubuntu01:~$ vi .bashrc
keychain id_rsa id_dsa
. ~/.keychain/`uname -n`-sh

If you are not familiar with VI/VIM, follow the commands below.

username@ubuntu01:~$ sed -i '$ a keychain id_rsa id_dsa' .bashrc
username@ubuntu01:~$ sed -i '$ a . ~/.keychain/`uname -n`-sh' .bashrc

For the change to take effect, enter the command below.

username@ubuntu01:~$ . .bashrc
 * keychain 2.8.1 ~ http://www.funtoo.org
 * Found existing ssh-agent: 2888
 * Warning: can't find id_dsa; skipping
 * Adding 1 ssh key(s): /home/username/.ssh/id_rsa
Enter passphrase for /home/username/.ssh/id_rsa: <enter passphrase>
 * ssh-add: Identities added: /home/username/.ssh/id_rsa

Now, my host is no longer asking for passphrase every time I try to connect to my EdgeRouter. Though, this will not survive a reboot. It will prompt me again to enter the passphrase when the host reboots. This is better than entering the passphrase every time, though!

username@ubuntu01:~$ ssh username@ubnt.domain.local
********************************************************************
*************       THIS IS MY UBIQUITI EDGEROUTER     *************
*************           YOU SHALL NOT PASS!!!          *************
********************************************************************
Linux ubnt 3.10.20-UBNT #1 SMP Fri Jul 29 16:51:50 PDT 2016 mips64
Welcome to EdgeOS
Last login: Fri Nov 25 12:35:33 2016 from 192.168.254.100

Host with no public key

Clients that do not have public keys saved in the EdgeRouter will no longer be able to connect.

username@ubuntu02:~$ ssh username@ubnt.domain.local
********************************************************************
*************       THIS IS MY UBIQUITI EDGEROUTER     *************
*************           YOU SHALL NOT PASS!!!          *************
********************************************************************
Permission denied (publickey).

Final Words

This post addresses some of the security concerns with my two-part blog post on how to configure EdgeRouter Lite. While there were few security bits here and there in the series, this post increases security by hardening the management plane. There will be more things we can do to enhance management security but will be covered in the future. The next post will give users an alternative to SSH public-key authentication.

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

References

Ubuntu Community QuickTips
Ubiquiti Community – SSH authorized_keys

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

Adding Two-Factor Authentication to FreeRADIUS

10/21/2016 By Andrew Roderos 16 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 my previous post, I talked about enabling two-factor authentication (2FA) for my public facing Linux host. In today’s post, I will talk about integrating Google Authenticator PAM to FreeRADIUS. As a result, any hosts that are pointed to my RADIUS server will have the 2FA functionality.

Update: Migrated FreeRADIUS with Google Authenticator to a Docker container
Update: FreeRADIUS 3.0 with Two-Factor Authentication (2FA)

Installing FreeRADIUS and Google Authenticator PAM

While there are several RADIUS software out there, FreeRADIUS is one of the most popular RADIUS software of choice in Linux. Since it has PAM library, this is also perfect for integrating it with Google Authenticator PAM. If you want to know more about FreeRADIUS, you might want to check this book out. I have not read it so read through the reviews to see if that will work for your needs.

Related: What is multi-factor authentication (MFA)?

Installing FreeRADIUS and Google Authenticator on Ubuntu 16.04 is very easy. All we need is to issue one line command. I added NTP package here since my Google Authenticator configuration is TOTP based. If one went through the Ubuntu installation properly, there might not be a need for this so long as the system is syncing to the time correctly.

$ sudo apt-get install freeradius libpam-google-authenticator -y

Configuring FreeRADIUS

After the package installation, the next step is to set up FreeRADIUS by editing configuration files. There are four config files we need to edit to complete this setup. By no means, one needs to follow the order.

First config file

The first config file that we need to edit is the /etc/freeradius/radiusd.conf file. There are two ways in configuring this and it seems that the most popular option is the one with FreeRADIUS running as root. For some people, this is not acceptable so I included instructions below where we’ll leave it as the default configuration.

Option 1 – Run as root

According to my limited research, the need to change the user and group to root is because of how both FreeRADIUS and Google Authenticator PAM works. My observation seems to indicate that FreeRADIUS will also need to access the secret key (.google_authenticator) in each user’s home directory – I could be totally wrong with this. My Linux boxes have encrypted home directories so only the owner and root can access these. That said, letting FreeRADIUS run as root will have access to the necessary files.

$ sudo vi /etc/freeradius/radiusd.conf

We’ll now need to find the lines user = and group =. The default configuration is set to freerad. Change both of them to root.

user = root
group = root

Option 2 – Use default configuration

As mentioned, we can just leave the file as default. I will explain more about this once we get to the section where we need to edit the /etc/pam.d/radiusd file.

Second config file

The the next config file that we need to edit is the /etc/freeradius/users file. This file will instruct FreeRADIUS to use PAM libraries to authenticate users as the default.

$ sudo vi /etc/freeradius/users

Add the lines found below. I usually like to add lines at the end of the file. Add the line after all the commented text of the file, just before the DEFAULT Framed Protocol == PPP line. This will ensure that this line will take precedence. I found out the hard way when I was troubleshooting an issue with L2TP over IPsec authentication.

# Instruct FreeRADIUS to use PAM to authenticate users
DEFAULT Auth-Type := PAM

Third config file

The second to the last config file on our list to be edited is the /etc/freeradius/sites-enabled/default file. This file tells FreeRADIUS to enable PAM authentication. We just need to edit one line here.

$ sudo vi /etc/freeradius/sites-enabled/default

Once the file is open, look for the following lines:

        #  Pluggable Authentication Modules.
#        pam

We now need to uncomment the pam line to enable it. It should look like this now:

        #  Pluggable Authentication Modules.
        pam

Fourth config file

Finally, the last FreeRADIUS config file that we need to change is the /etc/freeradius/clients.conf. This is where we can set up our secret key that is used by the clients to connect to the RADIUS server. Please change the default secret key to random alphanumeric characters. Use a key generator to generate the secret to make things life a little easier. For demo purposes, I will be using the default secret. To change the secret, look for secret = testing123 line.

$ sudo vi /etc/freeradius/clients.conf
<-- Output omitted for brevity -->
secret          = my_super_awesome_strong_secret
client rtr {
	ipaddr = 192.168.200.1
	secret = my_super_awesome_strong_secret 
}
Related: How to implement Duo Security MFA

As usual in Linux, when a configuration file has been changed, then the service needs to be restarted for the changes to take effect. To restart FreeRADIUS daemon, issue the sudo service freeradius restart command.

Configuring FreeRADIUS PAM

Since we instructed FreeRADIUS to use PAM to authenticate users, we need to configure the /etc/pam.d/radiusd file and instruct it to integrate Google Authenticator PAM. By default, the file will look something like this:

<-- Output omitted for brevity -->
@include common-auth
@include common-account
@include common-password
@include common-session

Option 1

If you picked the first option in the FreeRADIUS configuration section, then you need to comment those four lines above and add two lines. The file should look like this:

#@include common-auth
#@include common-account
#@include common-password
#@include common-session
auth requisite pam_google_authenticator.so forward_pass
auth required pam_unix.so use_first_pass

Option 2

If you left the /etc/freeradius/radiusd.conf file alone, then it becomes a little bit more complicated setup. Also, you will notice that my instructions are what I will consider a workaround to AppArmor (I am guessing this is the real issue). You will see why later in the next section, after the generating Google Authenticator secret key. Anyway, the /etc/pam.d/radiusd file should look like this:

#@include common-auth
#@include common-account
#@include common-password
#@include common-session
auth requisite pam_google_authenticator.so forward_pass secret=/etc/freeradius/${USER}/.google_authenticator user=freerad
auth required pam_unix.so use_first_pass

Google Authenticator Secret Key

I’ve already covered the generation of the secret key in my previous post, so look for the generating Google Authenticator secret key section. Once you are done generating secret keys, come back to this page. If you picked the first option throughout this tutorial, then skip this section and go to the verification section.

If you picked the second option, then we’ll need to do additional steps to make this work. Again, you do not have to follow the order in which they are listed here.

We first need to create a directory equal to the user account that we’re working on. In this scenario, we’ll use user account named test.

$ sudo mkdir /etc/freeradius/test

Then, we need to change the owner of the directory that we just created.

$ sudo chown freerad:freerad /etc/freeradius/test

The second to the last step is to copy the secret key to the directory that we just created.

$ sudo cp .google_authenticator /etc/freeradius/test/.google_authenticator

Finally, we need to change the owner of the file.

$ sudo chown freerad:freerad /etc/freeradius/test/.google_authenticator

If I ever learn more about AppArmor, then I will update this blog post because I think this is the real issue why it’s failing. I did try creating an AppArmor profile, but testing shows that I was still failing. When I looked at the /var/log/auth.log file, I saw an error message that looked like this:

Oct 10 21:24:53 radius radiusd(pam_google_authenticator)[18433]: Failed to update secret file "/etc/freeradius/test/.google_authenticator"

Verification

We now need to test to make sure that we can successfully authenticate. FreeRADIUS software package includes a simple tool that we can use to directly query the daemon with requests. The command format is radtest test <password+google authenticator token> localhost 18120 <RADIUS secret key>. The password and Google Authenticator token should not have space in between. Below shows the syntax that I used to test my configuration and the test result.

$ radtest test testing1234803732 localhost 18120 testing123
Sending Access-Request of id 79 to 127.0.0.1 port 1812
	User-Name = "test"
	User-Password = "testing1234803732"
	NAS-IP-Address = 127.0.1.1
	NAS-Port = 18120
	Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=79, length=20

Final Words

I’d like to speculate that a lot of people would pick the first option since the second option involves a lot more steps. Also, this isn’t a scalable solution so I think it will turn off quite a number of people. Imagine doing the steps above for multiple accounts. It’s going to be a lot of administrative work. For my purpose, this is a perfectly acceptable solution because I only have one account in my RADIUS server. It is probably an overkill to be creating a FreeRADIUS server instance for home use, but some may argue that nothing is overkill in security. The more secure you are, the better.

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

FreeRADIUS 3.0 with Two-Factor Authentication
Securing SSH with Google Authenticator

Migrated FreeRADIUS with Google Authenticator to a Docker container
Adding Two-Factor Authentication to TACACS+

References

Integrating Google Authenticator PAM module with FreeRADIUS Server
Freeradius and Google Authenticator
GitHub Google Authenticator

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

Securing SSH with Google Authenticator

10/10/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

In my old blog post, I talked about how to mitigate from persistent SSH brute force attack. While there are several options in mitigating SSH brute force attack, I opted to use the Fail2Ban option at the time. Today, I’ve decided to add another security layer to the host since this is a public facing server. This addition of security layer is based on defense in depth, which is an information assurance concept. As the title says, I will be using Google Authenticator to generate a time-based one-time password (TOTP) for two-step verification.

Related: What is multi-factor authentication?

It seems like two-factor authentication (2FA) is becoming a norm these days. More and more security professionals are pushing organizations to use 2FA for every sensitive systems and application. Understandably so, because the consensus is that password is no longer enough to protect accounts in this day and age. As a result, I’ve also decided to start implementing 2FA in my home devices.

Installing Google Authenticator PAM

Ubuntu has been my distro of choice for several years now, so all of my Linux-related tutorials have been on that. I will keep that going, mostly because I do not have time to learn another distro, like CentOS.

Installing Google Authenticator on Ubuntu 16.04 is a piece of cake. All you need is one command.

$ sudo apt-get install libpam-google-authenticator -y

Configuring SSH PAM

The Google Authenticator 2FA is accomplished by integrating into Linux’s Pluggable Authentication Modules (PAM) library. PAM is a way for programs to use an underlying authentication mechanism. With that said, we’ll need to configure PAM configuration to pass it to Google Authenticator. To do this, we need to edit the PAM configuration file for SSH.

$ sudo vi /etc/pam.d/sshd

At the bottom of the file, I added the following lines below. The first line is optional, but it’s always best to add comment lines in my opinion.

# Enable MFA using Google Authenticator PAM
auth required pam_google_authenticator.so nullok

If you want to understand the syntax, please check this site. Though, the article did not include what nullok argument means. The argument simply means that if a user hasn’t created secret key yet, then they’re still allowed to log in. My recommendation is to enable 2FA for all users so make sure to have all the users generate the secret key. Once all secret keys are generated, take out the nullok argument.

Configuring OpenSSH Daemon

The next step is to actually configure SSH to check for backend system (e.g. PAM) to use the challenge-response authentication method. To do this, we need to edit the OpenSSH configuration file.

$ sudo vi /etc/ssh/sshd_config

Once the file is open, look for the line with ChallengeResponseAuthentication no and change it to yes. Save the file and exit.

ChallengeResponseAuthentication yes

In Linux, changes to Linux configuration files require a service restart to take effect, for the most part. With that said, we need to restart SSH daemon (sshd). To restart SSH service, issue sudo service ssh restart command. Once sshd is back up, test to make sure that user can still log in without two-step verification.

Generating Google Authenticator Secret Key

The last step to make SSH 2FA work is to generate a secret key for the two-step verification. In this example, I created a test user account for demo purposes.

generating-secret-key

Use the Google Authenticator app on your mobile device and add the QR code.

Account with Google Authenticator secret key

In this example, SSH daemon is asking the user to enter Google Authenticator OTP.

$ ssh test@radius
Password: testing1234
Verification code: 664449
<-- Output omitted for brevity -->
test@radius:~$
google authenticator token

Account with no Google Authenticator secret key

Here the admin account does not have the Google Authenticator secret key yet. If one forgets to add the nullok argument, then the system will not allow user accounts without the secret key.

$ ssh admin@radius
Password:
<-- Output omitted for brevity -->
admin@radius:~$

Optional Configuration

It is probably a good idea to enable 2FA to the local login (console) too. So this way, anyone who has access to the physical machine will be subjected to two-step verification. To do this, we need to edit the login configuration file.

$ sudo vi /etc/pam.d/login

Once the file is open, add the lines below at the end of the file. Save the file and exit out.

# Enable MFA using Google Authenticator PAM
auth required pam_google_authenticator.so nullok

From now on, all user accounts with Google Authenticator secret key will need to enter a verification code.

Thoughts

Balancing security and convenience is one of the biggest dilemmas that information security professionals face. In a nutshell, making it convenient for users to access their account means it is less secure. In a perfect world (no bad guys) people would probably pick one password across all of their accounts. Since we’re not living in a perfect world, this leaves the accounts to be very insecure. If one account is compromised, then all of the other accounts could potentially be accessed by the bad guys.

The use of complex passwords and password managers are good first steps toward securing accounts. However, in today’s world, some of the information security professionals view password alone as an antiquated technique in securing accounts. As a result, a lot of online services have had multi-factor authentication feature. However, companies that provide these online services do not force accounts to use it. As a result, accounts are still at risk by relying on passwords alone.

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

Adding Two-Factor Authentication to FreeRADIUS

Reference

How to Secure SSH with Google Authenticator’s Two-Factor Authentication

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

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
  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to page 5
  • Go to Next Page »

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

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