Test Case Synopsis

The test case that we have is to build a web application for testimonials. That’s the easiest one that I could think of to cover the topics I want to discuss. The web application will have the following features:

• Login Page: Which restricts website access to registered users
• Home Page: Main page for the registered users with a welcome message and website instructions
• Testimonial Page: Testimonial Page which displays all the testimonials from database entered by the users and option to save new testimonials in the database
• Log Out: To gracefully logout of the website

We will also add a simple HTML template to the website which would cover the templates and layouts concept in Mojolicious.

Without further adieu, let’s begin building this project.

Create full_app project

In our previous tutorial on Mojolicious, we created “Hello World” web app with lite_app. This time we will build this project with full_app. To create a full_app, open the terminal and enter the below command:

mojo generate app myWebSite

This will create a directory called myWebSite with the below folder structure:

Lets understand the below components from the above screenshot

• lib
• myWebSite.conf
• public
• script
• t
• templates

lib

The library directory is probably the most crucial directory which holds all your programming code. Your Controller and Model logic goes here. The logic to handle any action on your webpage will be somewhere in this directory.

Your routes and page-actions are sent to the file myWebSite/lib/myWebSite.pm which then invokes the relevant Controller and Model to handle your requests.

myWebSite.conf

This is the master configuration file for your web app. You can add secret phrases for signed cookies, mention the number of workers that you want webservers to run, the port that your application should run on, database connection details, so on and so forth.

public

You can find all your static pages here. Along with the static pages, all publicly available components like your css, images or any other media goes into this directory.

script

Script to start your web site is present in this directory. You run you web app using the script/myWebSite file present in this directory.

t

Folder dedicated for your test scripts.

templates

Directory which holds the templates and layouts used by your web app.

I will not go in detail about the theory as you can always read more about it in the official website of Mojolicious. Let us proceed with our project.

Let’s go ahead and run this sample web app as it is, using the development web server morbo:

morbo myWebSite/script/myWebSite

Since we don’t see any errors, let’s fire up the browser and check our page (I have SSH Tunnel enabled, so I can access the webpage with localhost IP and default port(3000):

Our Website is running fine.

How did our website’s content get rendered ? Let us understand the flow of events. First, let me just remind you how the structure of your web application looks like:

Below diagram shows the flow of events from different files when you access your web page:

Whenever you access any web page built in mojolicious, the first file that gets called is the library file: lib/myWebSite.pm. The line $r->get('/')->to('example#welcome'); in the file basically tells to go to the controller Example.pm and execute the welcome sub-routine. Controllers, as you can see in the above screenshot are stored in lib/myWebSite/Controller.

In the controller we see the below lines:

# Render template "example/welcome.html.ep" with message
$self->render(msg => 'Welcome to the Mojolicious real-time web framework!');

This basically tells Mojolicious to set a value to the variable $msg and render the template. But which template ? We don’t see any template name mentioned in the controller, then which page is getting rendered?? Well, since no template is explicitly called Mojolicious will look for the template is the path similar to the controller path: example/welcome. In the above directory structure, we can see a template: template/example/welcome.html.ep, that’s what is getting rendered in the home page now. Ofcourse, you can explicitly mention the template name in the controller and it will exactly behave the same way. Just pass the template name like this:

  $self->render(msg => 'Welcome to the Mojolicious real-time web framework!',template => "example/welcome");

I prefer explicitly mentioning the template names in my controller, to avoid any confusion.

Now that we know that our main page’s content is being displayed by myWebSite/templates/example/welcome.html.ep and the contents looks like this:

% layout 'default';
% title 'Welcome';
<h2><%= $msg %></h2>
<p>
  This page was generated from the template "templates/example/welcome.html.ep"
  and the layout "templates/layouts/default.html.ep",
  <%= link_to 'click here' => url_for %> to reload the page or
  <%= link_to 'here' => '/index.html' %> to move forward to a static page.
</p>

We will change it to add our content:

% layout 'default';
% title 'Home Page';
<h2><%= $msg %></h2>
<p> This is my personal site built with Mojolicious. You can provide testimonials using the link <a href="#">here</a>. 
</p>

If you notice that the heading in the above html content is displayed by the variable $msg. This was set by our controller: myWebSite/lib/myWebSite/Controller/Example.pm. Let us open the controller file and change the below line:

# Render template "example/welcome.html.ep" with message
$self->render(msg => 'Welcome to the Mojolicious real-time web framework!');

to

# Render template "example/welcome.html.ep" with message
$self->render(msg => 'Welcome to My Personal Website!',template => "example/welcome");

Not only did I change the heading, I also explicitly mentioned which template to render.

Lets run our web app with morbo:

morbo myWebSite/script/myWebSite

Refresh our web browser:

Working as expected. Before we wind up, lets just change the default controller and template files to our customized file names:

cp myWebSite/lib/myWebSite/Controller/Example.pm myWebSite/lib/myWebSite/Controller/CustomController.pm

mkdir myWebSite/templates/myTemplates

cp myWebSite/templates/example/welcome.html.ep myWebSite/templates/myTemplates/homepage.html.ep

New Controller Name : myWebSite/lib/myWebSite/Controller/CustomController.pm
New Template Name : myWebSite/templates/myTemplates/homepage.html.ep

Open the new controller(CustomController.pm) and change the first line to reflect the new controller name, from:

package myWebSite::Controller::Example;

to

package myWebSite::Controller::CustomController;

Now change the below line in the same file to point to our newly created template: myTemplates/homepage

# Render template "example/welcome.html.ep" with message
$self->render(msg => 'Welcome to My Personal Website!',template => "example/welcome");

to

# Render template "myTemplates/homepage.html.ep" with message
$self->render(msg => 'Welcome to My Personal Website!',template => "myTemplates/homepage");

Finally, open the main library file: myWebSite/lib/myWebSite.pm and change the below line to call our now custom controller rather than the default:

$r->get('/')->to('example#welcome');

to

$r->get('/')->to('CustomController#welcome');

Lets start our web app and refresh the browser:

morbo myWebSite/script/myWebSite

You will not see any changes since we didn’t change the content. But we also didn’t see any errors that means we have achieved what we want.

We successfully created the home page of your website. In the next session, we will learn about templates and layouts. We will try to add some color to our dull home page that we created in this article.

The post Mojolicious (Part 1): Build Full App appeared first on The Curious Technoid.

Syntax

Below is the syntax used to create a SSH Tunnel:

ssh -N -L LOCAL_PORT:HOST:HOST_PORT USER_NAME@REMOTE_SERVER

• -Nrestricts you from inputting any command after the connection is established, this is preferred while using SSH Tunneling
• -L tells SSH that it’s local port forwarding
• LOCAL_PORT The port we will use locally
• HOST The host address in the remote server. Usually localhost / 127.0.0.1 to access the application running in remote server.
• HOST_PORT The port number of the host address where the application is running
• USER_NAME User Name of the remote server
• REMOTE_SERVER Remote Server IP Address or hostname

Use Case: Connecting to remote database

If you host your websites in one of the remote VPS servers, you would have stumbled upon the issue of connecting to the database from your local Desktop. I can access the database locally by opening the DB ports in firewall. But, what if I don’t like opening the DB ports ? The solution: SSH Tunneling. We can create a SSH Tunnel from our local Desktop to the VPS server using SSH. Port forward to the remote DB ports, after which we should be able to connect to the database in the remote server as if they are installed locally.

For the purpose of this demo, I have created a new server in digital ocean and have installed mariaDB database in it.

Setup

Local Desktop:
Operating System: macOS Catalina
Database Client: sequel Pro

Remote Server:
Provider: Digital Ocean
Operating System: Fedora 31 (Cloud Edition)
Database Server: mariaDB

Create SSH Tunnel

First we will create the SSH Tunnel by running the below command in terminal:

ssh -N -L 2000:127.0.0.1:3306 demo@161.35.77.93 -i ~/.ssh/id_curioustechnoid

• 2000 is the local port that we will use in the client
• 127.0.0.1 is the Remote Server localhost. This is nothing but localhost in the remote server
• 3306 is the Remote Server mariaDB Port
• demo is the Remote SSH User Name.
• 161.35.77.93 This is the Remote Server IP Address
• ~/.ssh/id_curioustechnoid is the private SSH Key used to connect to server. Read more about SSH Keys here.

Change the values based on your setup. If all the options are provided correctly we should have an active SSH Tunnel created.

What the above command did is that it created a SSH Tunnel which port forwards any request on port 2000 to the remote server’s port 3306. In our case mariaDB is running in the default port 3306 in the remote server. In the above command, we are using SSH Keys to connect to the server. It’s strongly recommended to use SSH Keys to connect to remote servers instead of username/password. Click here to know more about SSH Keys.

Connect to database

We now have encrypted connection established between local and remote server using the above SSH Tunnel command. Lets try to connect to the database in the remote server.

I will be using sequelPro database client and will connect to root database user. Enter the following details in connection section:

We have successfully connected to the remote database using SSH Tunneling. You would have noticed that we are using localhost(127.0.0.1) and localport(2000) to connect to the database hosted in remote server. The practical usage of this concept in limitless.

Hope this article helps you in using SSH Tunnels. Please feel free to share your experience or your issues in the comment section below. Happy to help!

The post SSH Tunneling (Port Forwarding) – a use case appeared first on The Curious Technoid.

If you are not aware, fail2ban is a brute-force attack mitigation tool. This post will guide you to quickly install fail2ban with basic configuration. In this article I will be showing how to configure fail2ban for SSH brute-force attacks.

Let’s cut to the chase and start installing fail2ban.

For the purpose of this demonstration I shall be using Fedora 31. You should be able to find similar commands in your respective distros.

Installation

Installation is pretty straight forward similar to installing any other software in Linux. I will use the DNF package manager which is the default for Fedora now.

dnf install fail2ban -y

Configuration

In fail2ban, setup for a particular service like SSH is called as jail. Like any intruder being put into a jail, any intruder attempting to gain access to your server via SSH would be put inside “SSHD jail” and anyone trying to gain access via SFTP would be put inside “SFTP jail”. Controlling the parameters to be “eligible” to be put into these jails are handled by jail configuration file.

There are 2 configuration files in fail2ban:

• /etc/fail2ban/jail.conf
• /etc/fail2ban/fail2ban.conf

It is recommended not to edit these files, but to create a copy of them with ‘.local’ file extension. Once you have created the copy change the desired values in those files.

fail2ban.conf file has the configuration to control fail2ban’s behaviour. For instance you can set the log level parameters here.
jail.conf file is where you enable services (like ssh, sftp, apache) which you wish to monitor for intrusion. You also define criteria’s on when to block the IPs.

Below are the brief steps I usually follow to setup fail2ban to mitigate SSH brute-force attacks on my servers.

1. Create ‘local’ copies of config files:

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

2. Enable SSHD jail in jail.local file

First run the below command to check the active jails configured(should be none obviously):

fail2ban-client status

Since this is a fresh installation we can see that no jail has been configured.

Open the jail.conf using your favorite editor(obviously it’s vim!). Find the section where it says [sshd]. You might find 2 entries, 1 commented and the other uncommented, go to the uncommented entry which should look like this:

Change it to make it look something like this:

#
# SSH servers
#

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode   = normal
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3

What did we exactly do here ?

• enabled : This enables the SSHD jail for fail2ban to keep monitoring the SSH connections to your server.
• maxretry : This defines how many incorrect password tries will you allow users trying to connect to your server via SSH. Beyond this, fail2ban will block them.

3. Additional Configuration

You can skip to step 4, if you want to ignore the below additional configurations but trust me you would want to know about these steps

I prefer to change few other parameters in jail.local when I setup fail2ban.

Ignoring IPs from being blocked

I have this habit of adding my own IPs to exception list so that I never get blocked by fail2ban. You might want to add your work IPs to this list so that you don’t get blocked while connecting from office in case you enter incorrect credentials multiple times. To add the the IPs that you want to exclude from monitoring, add them to the ignoreip parameter.

Uncomment and change the below line in jail.local

#ignoreip = 127.0.0.1/8 ::1

to

ignoreip = 127.0.0.1/8 ::1 192.168.1.119

Assuming that my local IP that I want to exclude from blocking is 192.168.1.119, fail2ban will not “ban” this IP no matter how many times I enter incorrect credentials. You can add any number of IPs separated by space or comma.

Changing bantime and findtime

Fail2ban gives you the ability to customize certain things like When to Ban? How long to Ban?

findtime parameter instructs fail2ban, within what duration should the “maxretry” value be checked. We had set the maxretry value(in sshd setup above) to 3, lets say we set findtime value to 60mins. So within 60mins if there are 3 incorrect attempts to login, then source IP gets added to ban list.

bantime parameter defines how long the IP should be banned, you may wish to ban the IP for a day, a week or a month. This parameter instructs fail2ban the same thing.

For example, lets say our maxretry value is 3 in SSHD configuration. You want to ban users if he enters incorrect password 3 times within a span of 10mins and block him from further attempting to try logging in for 3 days. You will change the value as below:

findtime = 10m

bantime = 76h

Enable logging via systemd journals

Fedora has a problem where unless logging is directed via systemd journald, it throws an error while starting fail2ban. To avoid this issue, you need to tell fail2ban to log via systemd journald by changing the below parameter:

backend = auto

to

backend = systemd

Tell fail2ban to use firewalld to block the IPs

I use firewalld as my firewall management tool so I tell fail2ban to use it to block the IPs by changing the below parameter

# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to define
# action_* variables. Can be overridden globally or per
# section within jail.local file
banaction = iptables-multiport
banaction_allports = iptables-allports

changed to:

# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to define
# action_* variables. Can be overridden globally or per
# section within jail.local file
banaction = firewallcmd-ipset
banaction_allports = firewallcmd-ipset

Verify and start fail2ban

Once we have all the changes done, we can verify our setup by running the command:

fail2ban-client -x start

fail2ban will tell us that set up in looking good.

Next step is to enable fail2ban so that it starts at boot time automatically. Then we proceed to start the fail2ban service to start monitoring all SSH connections.

Enable fail2ban so that it automatically starts at boot time

systemctl enable fail2ban.service

Start fail2ban service using the command:

systemctl start fail2ban.service

Make sure fail2ban is running fine

systemctl status fail2ban.service

Congratulations! We just enabled SSH jail to start monitoring all SSH connections to your server. You can check your ssh jail status by running the below command:

fail2ban-client status

You can check all the blocked IPs by running the command:

fail2ban-client status sshd

You can find the jail.local file with all the configuration discussed in this article here.

Some useful commands to keep in mind

• Check all services monitored by fail2ban: fail2ban-client status
• Check the blocked IP List by ssh jail: fail2ban-client status sshd
• Remove blocked IPs: fail2ban-client set sshd unbanip 192.168.143.191
• Remove all blocked IPs: fail2ban-client unban --all

Enable Debugging

In case you stumble upon any issues, we can enable debugging to get more information.

1. Open the file: /etc/fail2ban/fail2ban.local and change the below parameter

loglevel = INFO

Change to

loglevel = DEBUG

2. Restart the service

systemctl restart fail2ban

3. Monitor the debug messages by looking at the log file which be found at: /var/log/fail2ban.log

tail -f /var/log/fail2ban.log

If you wish to see fail2ban in action, I suggest you head to the video tutorial that I created regarding fail2ban setup. You can drag the video to go directly to 06:32 to see fail2ban in action skipping all the setup which we already discussed in this article.

The post Secure your computer using fail2ban appeared first on The Curious Technoid.