Dissecting a build.gradle file

As a reference, the following parts form a build.gradle file for a simple Java project:

group 'org.asysob'
version '1.0'

The organisational identifier for the project and the current version.

buildscript {
    repositories {
        mavenCentral()
        jcenter()
    }
    dependencies {
        classpath 'org.junit.platform:junit-platform-gradle-plugin:1.0.0-M3'
        classpath 'com.github.jengelman.gradle.plugins:shadow:2.0.0'
    }
}

Continue reading “Dissecting a build.gradle file”

Java example using GSON, 0MQ and built with Gradle

Just implemented a little Java program where a publisher sends JSON encoded messages that are received by a subscriber. The messages contain simple integers and are tagged as even or odd. PUB/SUB is done with the pure Java 0MQ implementation jeromq while the GSON library makes JSON encoding easy. Gradle is my favourite build tool, so this version of the file may serve as a starting point for future projects. JUnit5 and the shadow plugin for Uberjars are already configured; although the first is not used in this project.

Moving my wordpress blog to https

I received a SSL certificate for this blog. Switching from http to https is more work than expected, but fortunately, with the help of some tools, it is just a matter of minutes.

The easiest part: Change the URL scheme of the blog address in Settings -> General tab to HTTPS.

The next step is, to enforce HTTPS by advising the www server to redirect every query. On the blog www.bjornjohansen.no, i found the required nginx configuration:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

Thanks to a blog entry (dhue.de), i became aware of the problem that any entries with HTTP already stored in the database must be changed as well. Fortunately, with the help of the wordpress plugin Better Search Replace this is a matter of a few minutes. Since we make detailed changes in the database itself, a backup if it is definitely a good idea. After installing and activating, the plugin is accessible via Tools. It seems to be important, to replace GUIDs as well, so this checkbox should be selected. The job is done by entering the old address and the new address, by selecting all relations in the database, and finally by starting the task. A dry run can be selected first.

Creating a firewall (iptables)

Make sure that iptables are installed (otherwise call apt-get install iptables). A very basic rule set that allows http, https, and ssh (via default port 22) access:

*filter

# Define default policies
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

# Accepts all established inbound connections
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Drop invalid packets
-A INPUT -m conntrack --ctstate INVALID -j DROP

# Allows HTTP and HTTPS connections from anywhere
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allows SSH connections 
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow DNS lookups
-A INPUT -p udp --sport 53 -j ACCEPT
-A INPUT -p tcp --sport 53 -j ACCEPT

# Allow NTP
-A INPUT -p udp --sport 123 -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls (access via 'dmesg' command)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

COMMIT

Installing these rules – according to wiki.debian.org:

iptables-restore < /etc/iptables.test.rules
iptables -L # Are these my rules?
iptables-save > /etc/iptables.up.rules

Activating iptable rules at boot time requires a file /etc/network/if-pre-up.d/iptables (as a shell script, it requires x permissions):

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.up.rules

Nowadays, the same is needed for IPv6 with some minor changes because ICMP plays a far more important role in this version:

 *filter

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT

# -A INPUT -m rt --rt-type 0 --rt-segsleft 0 -j DROP
# -A FORWARD -m rt --rt-type 0 --rt-segsleft 0 -j DROP
# -A OUTPUT -m rt --rt-type 0 --rt-segsleft 0 -j DROP

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -p ipv6-icmp -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -m state --state NEW -m udp -p udp --dport 546 -d fe80::/64 -j ACCEPT

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

# -A INPUT -j REJECT --reject-with icmp6-port-unreachable
# -A FORWARD -j REJECT --reject-with icmp6-port-unreachable

COMMIT

Enabling these rules goes the same way as with IPv4 with the sole exception that ip6tables, iptables-restore and ip6tables-save must be called.

A pair of keys for ssh

ssh-keygengenerates the key pair (private key keyname and public key keyname.pub). The easiest but somewhat more dangerous way is to use passphrase-less keys. Keys may be hardened against brute force attacks by increasing the number of rounds (-a 128) and by making the keys longer (-t rsa -b 4096). Don’t forget to add a comment -C "comment" to the public key which makes it easier to be recognized:

ssh-keygen -a 128 -t rsa -b 4096 -C "comment" -f "keyname"

The private key is needed on any host used as a source for logging in. Any target system needs a .ssh subdirectory in the home of the user allowed to login remotely with rwx permissions for the owner (chmod 700). A file called authorized_keys is needed which holds the public keys of all remote hosts from where a login happens (rw permissions for owner (chmod 600) and make sure that the owner actually owns this file). The public key can be appended by using cator it can be copied from a remote machine using ssh-copy-id -i @. ssh-copy-id works with localhost in case the keys are generated on the target machine.