Neighborhood Techie: February 2017

Thursday, February 16, 2017

Fail2Ban notifications via Pushbullet (using nfty)

Following was built on a CentOS 7 VPS, configured to protect the ssh login from brute force authentication attempts. This assumes that you already have a Pushbullet account and have your Pushbullet clients set up properly.

Installation

Unless otherwise noted, following is performed as root.

1) Install ntfy (better instructions at http://ntfy.readthedocs.io/en/latest/)

pip install ntfy

2) Create the config file for ntfy

cd
mkdir .config
cd .config
mkdir ntfy
cd ntfy
echo -e 'backends: ["pushbullet"]\npushbullet: {"access_token": "t0k3n"}' > ntfy.yml
chmod 600 ntfy.yml

3) Acquire your access token. On the Pushbullet site, click on "Settings in the gray menu". If "Account" isn't already selected, click on that. Under "Access Tokens" click on "Create Access Token" and copy & paste the resulting token to somewhere safe. Also edit the above ntfy.yml file and change "t0k3n" to whatever actually is your access token.

4) Install fail2ban

yum -y update
yum -y install epel-release
yum -y update
yum clean all
yum -y install fail2ban
systemctl start fail2ban
systemctl enable fail2ban
systemctl status fail2ban

In the above, "systemctl enable fail2ban" configures systemd to automatically start fail2ban at boot time. "systemctl status fail2ban" will tell you whether or not fail2ban is running.

5) Create a new jail configuration. (Note: this adds "jail.local" which will override the existing "jail.conf".)

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

6) Using your favorite text editor, edit jail.local and add "enabled = true" in the (un-commented) sshd section. It should look something like:

[sshd]
enabled = true

You may also want to change the entry for bantime (in the "DEFAULT" section) to something longer than 600 (which is only 10 minutes). It's also recommended that you edit the entries for the following controls: ignoreip, findtime, and maxretry. The "ignoreip" entry will exclude the given IP address from being banned by fail2ban (i.e., keeps you from banning yourself). The "findtime" entry is the timespan in the logs where fail2ban will search for failures. The "maxretry" entry is the number of failures in the timespan that will trigger a ban.

7) Restart fail2ban using:

sytemctl restart fail2ban

8) Check the status of fail2ban by running one, some, or all of the following:

systemctl status fail2ban
fail2ban-client status
fail2ban-client status sshd
iptables -L -n

9) Make a copy of fail2ban's iptables-multiport.conf file by running:

cd /etc/fail2ban/action.d
cp iptables-multiport.conf iptables-multiport-letmeknow.conf

10) Using your favorite text editor, find the action ban line and edit it so that it looks like:

actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>
/usr/local/etc/pb-f2b-notify <name> <ip>

11) Edit /etc/fail2ban/jail.local and change the following line:

banaction = iptables-multiport

so that it looks like:

banaction = iptables-multiport-letmeknow

12) Create the notify script "pb-f2b-notify" in the /usr/local/etc folder, so that it contains the following:

#!/bin/bash
ntfy -b pushbullet -t "fail2ban alert!" send "fail2ban for $1: blocked $2 for ten minutes"

13) Restart fail2ban via:

systemctl restart fail2ban

14) It's up to you to figure out how to test it. I used a separate machine (at another IP) and attempted multiple logins with incorrect passwords.

Above was adapted from the following sources:

Monday, February 13, 2017

Sote - speeding up command line navigation

Sote is described by its author as "shell favorites paths, for faster cd". In short, it allows the user to "name" a much-used path, allowing for faster navigation to/from multiple directories with fewer keystrokes.

Sote is similar to pushd [1] in that they both use similar means to facilitate navigation. Sote is different from pushd in that it avoids use of the stack model and allows for a separate (and persistent) saved name for the target directory (e.g., "html" or "h" for "/var/www/html/", "b" for "/usr/local/etc/bitlbee/").

Sote is written in Bash. In short, it self installs as a hidden file and appends itself to the users .bashrc file.

Installation

Installation is simple.

1) Run

git clone https://github.com/krkn/sote ~/.sote

2) If needed, exampine the code in the ~/.sote folder. The executable scripting is in ~/.sote/bin/sote.

3) Run

~/.sote/bin/sote

4) (OPTIONAL) I took sote's idea a bit further, by aliasing sote to a single keystroke ("z"), so that navigation involves even fewer keystrokes (example: "z h" for "cd /var/www/html/"). It may not seem like much but, for command line users, use of the tool can become habitual very quickly.

Note: in Ubuntu, you can alias "sote" to "z" by adding the following to ~/.bash_aliases

alias z = "sote"

5) Close and reopen the terminal window (or run "bash"). The reason for doing this is to load the new .bashrc (you'll see "source ~/.sote/bin/sote" or something similar attached to the end of .bashrc).

Using sote

You can now add your favorite paths into the tool. Example (with my z alias for sote):

z -a h /var/www/html
z -a html /var/www/html
z -a b /etc/bitlbee
z -a sys /lib/systemd/system

The above are saved in a file named "~/.sote-store". This is how the aliases are persistent across session. You can also show or delete individual (or all) aliases using similar syntax.

You can then use the above to quickly jump between directories. "z h" jumps to /var/www/html. From there "z b" switches to /etc/bitiblee and "z sys" switches to the /lib/systemd/system directory. Note that you can save/use more than one path alias for the same path.

To see all of the available switches for sote, run "sote" or "sote -h".

Source

https://github.com/krkn/sote

Saturday, February 11, 2017

CoVim as a service

Following are my notes for creating a CoVim service, in Docker, on Ubuntu 16.04. It should be quite easy to port this to other Linux distros (probably even Windows with the proper libs):

Note: this assumes that each student also has a current Vim instance, as well as the CoVim plugin, installed on their system. If they don't, the Docker file can also be used as a recipe for building and installing Vim and CoVim on each student's workstation.

Steps:

1) (as root) Create a working folder and cd into it.

mkdir work && cd work

2) Inside of the work folder, create a Dockerfile containing the following:

FROM ubuntu:16.04
MAINTAINER Tim Kramer <joatblog@gmail.com>
# Date: 04 Feb 2017

# This Dockerfile will install build the current
# version of Vim, and then install the covim plugin

# make sure source image is up-to-date
RUN touch /deleteme
RUN apt-get update && apt-get upgrade -y

# build and install the current version of Vim
RUN apt-get install -y bash python-pip git libssl-dev libncurses5-dev supervisor
RUN pip install twisted argparse service_identity
RUN git clone git://github.com/vim/vim
RUN cd /vim && ./configure --enable-pythoninterp=dynamic
RUN cd /vim && make && make install

# build and install the covim plugin
RUN mkdir ~/.vim && mkdir ~/.vim/bundle
RUN cd ~/.vim/bundle && git clone git://github.com/FredKSchott/CoVim.git
RUN mv ~/.vim/bundle/CoVim/plugin ~/.vim/
RUN cp ~/.vim/plugin/CoVimServer.py /bin/

# add the supervisor config file
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf

EXPOSE 8555
CMD ["/usr/bin/supervisord"]

3) Inside of the work folder, create a file called "supervisord.conf", containing the following:

[supervisord]
nodaemon=true

[program:covim]
command=/bin/bash -c "exec /bin/CoVimServer.py -p"
autorestart=true

4) Create the Docker image by running the following (inside of the working folder):

docker build -t pg/covim .

5) Create a container from the image by running:

docker run --name covim -itd -p 8555:8555 pg/covim

6) (As a user) Connect to the service by running Vim and running the following command:

:CoVim connect IPADDR 8555 USERNAME

In the above, edit "IPADDR" and "USERNAME" to fit. Note: If vim is being run on the same machine as the CoVim service then IPADDR must be "localhost". It's also assumed that each student has a different username.

IMPORTANT: All editing is done in memory. If each user wants a copy of the edited file, each must issue a save command (e.g., ":w myfilename") before exiting. By default, the saved file will show up in whatever directory the user was in when they executed Vim.

Other ideas:

Install the client end on a machine reachable via ShellInABox (or similar SSH client). This removes the need to install CoVim on each student's workstation. All they'll need is a browser. Possible drawback: when the student saves a file, it is stored on the machine running ShellInABox, not the student's machine.
In the student's .bashrc file, add the following line:
alias covim="vim -c 'CoVim connect IPADDR 8555 $(whoami)'"

Oddities:

The user must exit twice when leaving the program. The first ":q" or ":q!" disconnects from the service. The second exits the Vim program.

Sunday, February 5, 2017

Ubertooth, ESP32, and a Jinou BLE beacon

Put a slight dent in my hardware backlog today. Managed to get the Ubertooth to "see" the Jinou BLE beacon. Had to install an app on my tablet to discover the correct address though.

The Jinou beacon is supposed to have a range of 50ft and is supposed to run off a couple AA batteries for about a year (depending on config settings). I'm thinking that the reason the beacon was so cheap is that it comes with no docs or software. It's main attraction (for me) is that it has a power switch on the side.

Intent is to use an ESP32 instead of the Ubertooth (motivation: cost) and carry the Jinou beacon with me. Idea is to have the ESP32 send a WOL packet when it senses the beacon.

The docs for the ESP32 indicate that the device should be able to act as a BLE gateway while simultaneously being connected to Wi-Fi. If that's actually possible, it makes for a very cheap (~$5) solution that only requires 5v power. Given the crashes on the Ubertooth (during mode switches), I'm hoping the ESP32 is a bit more reliable.