apt get life

Life around technology

You are here: Home

Fail2ban does not enable some rules

by

While setting up a webserver, I noticed that

1
fail2ban-client status

 did not list all of the rules that I’d configured in

1
jail.d

. Althought configuration files were added to the directory, the status wasn’t showing them listed, so it hadn’t activated the jails. Running

1
service fail2ban restart

 didn’t add them either.

After spending some time researching, some people suggest changing the backend used in fail2ban from auto to polling in jail.conf. Since you shouldn’t edit jail.conf on a debian based system, I tried creating a new file 

1
nano /etc/fail2ban/jail.local

 and adding the line

1
backend = polling

. This actually prevented the fail2ban service from starting for me. The errors in

1
systemctl status fail2ban.service

didn’t show anything useful as to the cause of the error. In the end I reverted this change.

running

1
fail2ban-client reload

 did present error messages detailing which rule couldn’t be activated:

1
2
ERROR No file(s) found for glob /var/log/apache2/*.log
ERROR Failed during configuration: Have not found any log file for apache-xmlrpc jail

This then meant I was able to investigate the

1
jail.d

 config file with the rule indicated as causing the problem and correct the log file path.

1
fail2ban-client status

 then shows the correct jails running.

mount disk image created with dd using ubuntu

by

If you’ve cloned a whole drive using dd and you need to access one of the partitions on it here are some steps to follow in order to gain access:

Find the partition start sectors using fdisk -b512 -l. Note that you’re explicitly setting the sector size to 512 bytes and you’ll need to change your command to match your own image file.

1
fdisk -b512 -l backup_sata.img

You should get output similar to this (note I’ve truncated it to only show the appropriate output):

Shell
1
2
3
4
5
6
Device         Boot     Start       End   Sectors   Size Id Type
backup_sata.img1 *         2048    206847    204800   100M  7 HPFS/NTFS/exFAT
backup_sata.img2         206848 237185023 236978176   113G  7 HPFS/NTFS/exFAT
backup_sata.img3      237185024 588070911 350885888 167.3G  f W95 Ext'd (LBA)
backup_sata.img4      588070912 625137663  37066752  17.7G 27 Hidden NTFS WinRE
backup_sata.img5      237187072 588070911 350883840 167.3G  7 HPFS/NTFS/exFAT

Normally sector are 512 bytes, so you can calculate the offset you need in the next command with:

start * 512 = offset

So if you want to mount backup_sata.img5 (partition 5 of the backup image) you’d run 237187072×512=121439780864:

1
mount -o ro,loop,offset=121439780864 backup_sata.img /backup_sata

Remember to have created /backup_sata or whatever directory you’re mounting to first!

Fixing Cannot remount block device is write protected on Ubuntu

by

While working on an old hard drive, I came across a problem that it would only mount as read only, even when specifying that it should mount as read write. Here’s an example:

1
2
mount /dev/sdb1 /media/aptgetlife/datadisk -o remount,rw
mount: cannot remount block device /dev/sdb1 read-write, is write-protected

By this point I’d already got the data disk mounted to the local user media folder, so I could read data from /media/aptgetlife/datadisk but not write data to it.

After some investigation I was able to found this post on stack overflow regarding a similar problem and a solution using blockdev:

1
blockdev --setrw /dev/sdb1

After which it was possible to run the mount command again, which didn’t present an error and allowed me to write data to the disk.

Add a policy to ImageMagick in Debian

by

As Arstechnica have recently reported, there is a critical security vulnerability in ImageMagick, an image processing library used by many websites. While official patches are being worked on, this is a reccomended workaround to secure ImageMagick on Debian.

1. Check loaded Imagick policies

From a terminal, check to see if any policies are loaded. There will almost certainly be none returned if you’ve not configured any previously.

Check ImageMagick Policies
1
convert -list policy

2. Open Imagick’s policy.xml file

In Debian, you can find the ImageMagick policy file in /etc/ImageMagick:

Edit Policy.xml
1
nano /etc/ImageMagick/policy.xml

In other operating systems your best bet is to run a find:

Find Policy.xml for Non-Debian based systems
1
find /usr | grep "policy.xml"

3. Edit policy.xml

Now we need to edit policy.xml. The current reccomended settings related to the vulnerability are here: https://gist.github.com/rawdigits/d73312d21c8584590783a5e07e124723 It’s best to check this URL for the latest version. Alternatively here’s the code at time of writing:

policy.xml
1
2
3
4
5
6
7
<policymap>
  <policy domain="coder" rights="none" pattern="EPHEMERAL" />
  <policy domain="coder" rights="none" pattern="URL" />
  <policy domain="coder" rights="none" pattern="HTTPS" />
  <policy domain="coder" rights="none" pattern="MVG" />
  <policy domain="coder" rights="none" pattern="MSL" />
</policymap>

Remember it’s Ctrl + x to exit nano and you do want to save the changes. If you’re told you don’t have write permissions try closing the file and opening it again with sudo.

4. Check the Imagick policy is loaded

Now re-run the first step to make sure the policy has been loaded properly.

Check ImageMagick Policies
1
convert -list policy

You should get the following output:

policy output
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#
Path: [built-in]
  Policy: Undefined
    rights: None
 
Path: /etc/ImageMagick/policy.xml
  Policy: Coder
    rights: None
    pattern: EPHEMERAL
  Policy: Coder
    rights: None
    pattern: URL
  Policy: Coder
    rights: None
    pattern: HTTPS
  Policy: Coder
    rights: None
    pattern: MVG
  Policy: Coder
    rights: None
    pattern: MSL

For more details on the problem, check out the ArsTechnica post here, and the ImageMagick forum announcement on the subject here.

Official patches are due to be distributed over the weekend, but may take longer to enter your distributions package manager.

Laravel 5.2 API Token Authentication

by

At work I’ve been tasked with improving an API recently, and I decided it would be a good opportunity to take Laravel out for a spin. I’ve been keen on learning more about laravel and it’s API capabilities which are supposedly very strong, although I have noted that there’s not much documentation around them. The existing API is flat PHP and uses token based authentication. This allows users to authenticate with a string “api_key” in the request URL, in the header or in the body of the JSON request. I decided that instead of trying to get existing users to upgrade to something like oAuth (for which there are some interesting plugins https://packagist.org/packages/lucadegasperi/oauth2-server-laravel), I’d just implement the same token based authentication model for the revised API in Laravel. There are already advantages to using Laravel for APIs – it highly encourages a restful approach, as for Laravel 5.2 it includes rate limiting out of the box and allows for route prefixing, so it is possible to have multiple endpoints in one Laravel application.

Setting up token based authenticaton in Laravel is so poorly documented that it took me a while to work out how it is achieved.

1. User API Tokens

Users need to have an API token to be associated with them in order to allow the authentication model to work. This is easy enough to add by editing the user migration in your laravel installation.

edit CreateUsersTable
1
2
// Store an API key for this user.
$table->string('api_token', 60)->unique();

This allows you to store a 60 character unique API Token for each user.

2. Setting up API Authentication

There are several ways you can now call API Token authentication for your application. Probably the best is to use middleware in your routes file:

Adding API authentication to your middleware
1
2
3
4
5
6
Route::group([
    'prefix' => 'api',
    'middleware' => 'auth::api'
    ], function() {
    Route::resource('fruit', FruitController);
});

Now any time requests are made to the route group, the API authentication method will be called. This includes token based authentication (now defined in the users table) as well as the API rate limiting.

3. Making API Requests

You can now submit your API requests to see if the Laravel token authentication is working. To do this you can submit “api_token” as either a GET or POST paramiter. There’s also hidden away the option to have it set as a header, however this requires you to use an Authorization header:

Key: ‘Authorization’

Value: ‘Bearer [token]’

Check out the code here:

https://github.com/laravel/framework/blob/c04159dee4a47b0d7cd508ab720932121927b1b3/src/Illuminate/Http/Request.php#L815-L822

and here:

https://github.com/laravel/framework/blob/master/src/Illuminate/Auth/TokenGuard.php#L81-L94