Secure network daemons using TCP wrapper on Ubuntu

As many blogposts point out that network daemon like sshd can be protected via configurations in two files /etc/hosts.deny and /etc/hosts.allow.

What about httpd or nignx? They provide web services to the network clients and it seems that TCP wrapper doesn't restrict access to these daemons.

TCP wrapper would only be effective when the network daemon has dependency over library like libwrap.so. To check whether a daemon relies on libwrap.so library. Issue the following command will do the job:

$ ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /lib/.../libwrap.so.0 (0xb55a5000) 

Daemon like sshd does rely on this TCP wrapper library so can be managed by chainging configurations in both /etc/hosts.deny and /etc/hosts.allow.

However, ldd test failed to display TCP wrapper dependency for daemon like httpd and nginx. This explains why TCP wrapper poses no action over these two daemon even with similar configurations.

Just keep in mind that checking dependency library for the daemons before trying to secure them using TCP wrapper.

Nginx php-fpm security.limit_extension issue

Just found something weird while tweaking the configurations in Nginx PHP-FPM. URL via https suddenly went offline and the server log shows something as follows:

[error] 18292#0: *1 FastCGI sent in stderr: "Access to the script '/usr/share/nginx/html' has been denied (see security.limit_extensions)", client: x.x.x.x, server: localhost, request: "GET /index.php HTTP/1.1", host: "xxx.net"

Although people suggest to turn off security.limit_extensions by setting it to nothing, it really raise me a bit of security concern.

It ends up there's one line in the config file /etc/nginx/sites-enabled/default which causes the error:

#
#
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;

Comment it out is okay while the .php page loads fine if it's changed to something else:

# Fix for missing params and blank php page display problems
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO          $fastcgi_path_info;
#fastcgi_param PATH_TRANSLATED    $document_root$fastcgi_path_info;
fastcgi_param PATH_TRANSLATED    $document_root$fastcgi_script_name;

Reloading nginx server again and things are loaded up properly!

Adding Fail2Ban UFW Portscan Filter on Ubuntu

To further prevent portscan from bad bots around the world, there's a way of making use of Fail2Ban filter.

Assuming Fail2Ban is in place, edit the config file as below;

$ sudo nano /etc/fail2ban/jail.local

Add new section in jail.local:

[ufw-port-scan]

enabled   = true
ignoreip  = 127.0.0.1/8
port      = all
filter    = ufw-port-scan
banaction = ufw
logpath   = /var/log/ufw.log
maxretry  = 20

Create new filter as follows:

$ sudo nano /etc/fail2ban/filter.d/ufw-port-scan.conf

Add new lines in ufw-port-scan.conf:

[Definition]
failregex = .*\[UFW BLOCK\] IN=.* SRC=
ignoreregex =

Create ban action config file as follows:

$ sudo nano /etc/fail2ban/action.d/ufw.conf

Add new lines in ufw.conf:

[Definition]
actionstart =
actionstop =
actioncheck =
actionban = ufw insert 1 deny from  to any
actionunban = ufw delete deny from  to any

Have a service restart and it's good to go.

$ sudo service fail2ban restart

It's possible to run a test for the regex rule as well:

$ fail2ban-regex /var/log/ufw.log '.*\[UFW BLOCK\] IN=.* SRC='

Then you might get some results back like these:

Running tests

=============

Use   failregex line : .*\[UFW BLOCK\] IN=.* SRC=

Use         log file : /var/log/ufw.log.1

Results

=======

Failregex: 163 total

|-  #) [# of hits] regular expression

|   1) [163] .*\[UFW BLOCK\] IN=.* SRC=

`-

Ignoreregex: 0 total

Date template hits:

|- [# of hits] date format

|  [163] MONTH Day Hour:Minute:Second

`-

Lines: 163 lines, 0 ignored, 163 matched, 0 missed

Nginx PHP-FPM display blank page for .PHP file on Ubuntu

Setting up new Nginx instance wasn't a funny thing as stated on most blogposts while it display blank page during startup. This is annoying when people set things up from scratches.

First thing first:

Check whether PHP-FPM is running:
$ ps -aux | grep php-fpm --color

$
$ ps -aux | grep php-fpm --color
root      1898  0.0  1.8 209928 18992 ?        Ss   11:48   0:00 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)                      
www-data  1900  0.0  0.6 210060  6660 ?        S    11:48   0:00 php-fpm: pool www                                                            
www-data  1901  0.0  0.5 210060  6088 ?        S    11:48   0:00 php-fpm: pool www   

Also, you may notice that running processes may be owned by someone else, like nginx, apache or whatsoever. Make sure user/group setting in php-fpm config file is referring to the same user/group as set in Nginx config file, like www-data/www-data.

Default location of php-fpm 7.0 config file:

/etc/php/7.0/fpm/pool.d/www.conf

Default location of Nginx config file:
/etc/nginx/sites-available/default

Back to the question about why nginx displays a balnk page instead? Let's take a look at the Nginx config file:

...
...
server {
        ...
        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_cache  microcache;
                fastcgi_cache_key $scheme$host$request_uri$request_method;
                fastcgi_cache_valid 200 301 302 30s;
                fastcgi_cache_use_stale updating error timeout invalid_header http_500;
                fastcgi_pass_header Set-Cookie;
                fastcgi_pass_header Cookie;
                fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
                fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
                # Fix for missing params and blank php page display problems
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;

        }
}

The line "include fastcgi_params" actually refers to the file /etc/nginx/fastcgi_params which has various fastcgi_param variables initialized when calling. Unfortunately, two important variables went missing leading to an unknown blank page when startup.

They are SCRITP_FILENAME and PATH_TRANSLATED. Add them back to Nginx config file and PHP things execute again!

Ref: https://www.narga.net/avoid-nginx-wordpress-blank-page/