April 20, 2017

mcblockd automation progress

So far, so good. Nice to see this in the logs while I’m working on updates to mcblockd. This shows lines from my auth.log with the corresponding actions invoked in mcblockd. The key takeaway: nearly instantaneous response to login attempts from countries where I have the policy set to low tolerance, and the expected response for “US” networks where I have the tolerance set a little higher.

The way this works…

A mcblocklog process receives all auth.log entries via a pipe from syslogd. It uses a list of regular expressions (in a plain text file) to match offending lines in the log, then posts matched IP addresses to mcblockd as ‘logHit’ requests. Unlike my previous setup that periodically parsed entire logs, this happens in real time. mcblockd asks dwprdapd for prefix and country information, then applies configured policy. Depending on the policy for the network, mcblockd may instantly add an entry to its database and the pf table, or wait for the policy to be violated (number of hits over a configured time period). For foreign countries, I have the policy set to trigger from a single offending line, hence mcblockd will immediately add an entry to the pf table. For the U.S., I have the policy set to 5 hits in 7 days. These are experimental settings at the moment, it’s likely I’ll change them.

Also part of the configured policy is how long an entry will live in the pf tables, by days. For countries which have no business connecting to my network, the policy is set long versus my own country. This is a common desired feature in an IPS (Intrusion Protection System). Another part of the policy is a ‘widest mask’ setting, to allow me to avoid blocking huge swaths of address space from a given country to whom I want to grant a bit of leniency (say the U.S. and Canada in my case).

Probably worth noting that if an address is already covered in the pf tables, mcblockd does nothing.

Also worth noting that the service is secured with libDwmAuth, using ECDH and 2048-bit RSA keys during authentication, then AES128 in GCM mode after authentication.

While the log entries below are for ssh, I have a similar process for web logs and mail server logs.

Apr 19 05:33:30 ria sshd[7695]: error: maximum authentication attempts exceeded
                    for root from 81.100.183.189 port 43973 ssh2 [preauth]
Apr 19 05:33:30 ria mcblockd[1854]: [I] Added 81.96/12 (GB) to ssh_losers

Apr 19 06:09:50 ria sshd[7752]: error: maximum authentication attempts exceeded
                    for root from 36.36.254.10 port 60635 ssh2 [preauth]
Apr 19 06:09:50 ria mcblockd[1854]: [I] Added 36.36/16 (CN) to ssh_losers

Apr 19 09:22:37 ria sshd[8123]: error: maximum authentication attempts exceeded
                    for root from 123.96.0.151 port 60583 ssh2 [preauth]
Apr 19 09:22:37 ria mcblockd[1854]: [I] Added 123.96/15 (CN) to ssh_losers

Apr 19 09:29:38 ria sshd[8129]: Did not receive identification string from 34.205.143.181
Apr 19 09:29:43 ria sshd[8130]: Invalid user support from 34.205.143.181
Apr 19 09:29:43 ria sshd[8130]: Postponed keyboard-interactive for invalid user
                    support from 34.205.143.181 port 53145 ssh2 [preauth]
Apr 19 09:29:43 ria sshd[8130]: error: PAM: authentication error for illegal user
                    support from 34.205.143.181
Apr 19 09:29:43 ria sshd[8130]: Failed keyboard-interactive/pam for invalid user
                    support from 34.205.143.181 port 53145 ssh2
Apr 19 09:29:44 ria mcblockd[1854]: [I] Added 34.205.143/24 (US) to ssh_losers

Apr 19 14:11:40 ria sshd[8666]: error: maximum authentication attempts exceeded
                    for root from 200.73.205.204 port 45585 ssh2 [preauth]
Apr 19 14:11:40 ria mcblockd[1854]: [I] Added 200.73.200/21 (EC) to ssh_losers

Apr 19 14:51:48 ria sshd[9272]: Invalid user admin from 77.39.72.192
Apr 19 14:51:48 ria mcblockd[1854]: [I] Added 77.39.0/17 (RU) to ssh_losers

Apr 19 15:31:18 ria sshd[17218]: Invalid user admin from 193.105.134.184
Apr 19 15:31:18 ria mcblockd[1854]: [I] Added 193.105.134/24 (SE) to ssh_losers

Apr 19 15:34:02 ria sshd[18020]: error: maximum authentication attempts exceeded
                    for root from 85.90.198.244 port 44202 ssh2 [preauth]
Apr 19 15:34:02 ria mcblockd[31598]: [I] Added 85.90.192/19 (UA) to ssh_losers

Apr 19 15:58:13 ria sshd[23696]: error: maximum authentication attempts exceeded
                    for root from 156.213.133.233 port 58400 ssh2 [preauth]
Apr 19 15:58:13 ria mcblockd[31598]: [I] Added 156.192/11 (EG) to ssh_losers

Apr 19 16:04:49 ria sshd[23785]: error: maximum authentication attempts exceeded
                    for root from 171.50.175.114 port 46884 ssh2 [preauth]
Apr 19 16:04:49 ria mcblockd[31598]: [I] Added 171.48/12 (IN) to ssh_losers

Apr 19 16:39:23 ria sshd[23858]: Invalid user support from 181.211.93.159
Apr 19 16:39:23 ria mcblockd[31598]: [I] Added 181.211/16 (EC) to ssh_losers

Apr 19 16:59:10 ria sshd[23914]: Did not receive identification string from 
                    128.40.46.124
Apr 19 16:59:10 ria mcblockd[31598]: [I] Added 128.40/15 (GB) to ssh_losers

Apr 19 18:19:24 ria sshd[24599]: error: maximum authentication attempts exceeded
                    for root from 178.216.100.130 port 52035 ssh2 [preauth]
Apr 19 18:19:24 ria mcblockd[31598]: [I] Added 178.216.96/21 (UA) to ssh_losers

Apr 19 19:21:43 ria sshd[24873]: Invalid user admin from 200.121.233.88
Apr 19 19:21:43 ria mcblockd[31598]: [I] Added 200.121/16 (PE) to ssh_losers

Apr 19 23:12:25 ria sshd[30989]: error: maximum authentication attempts exceeded
                    for root from 131.161.55.11 port 42822 ssh2 [preauth]
Apr 19 23:12:25 ria mcblockd[31598]: [I] Added 131.161.52/22 (HN) to ssh_losers

Apr 20 00:08:10 ria sshd[31282]: error: maximum authentication attempts exceeded
                    for root from 167.250.75.214 port 4837 ssh2 [preauth]
Apr 20 00:08:10 ria mcblockd[31598]: [I] Added 167.250.72/22 (BR) to ssh_losers

Apr 20 00:22:31 ria sshd[31674]: Did not receive identification string from
                    218.93.17.146
Apr 20 00:22:31 ria mcblockd[31598]: [I] Added 218.64/11 (CN) to ssh_losers

Apr 20 00:25:41 ria sshd[31691]: Invalid user admin from 60.178.126.100
Apr 20 00:25:41 ria mcblockd[31598]: [I] Added 60.160/11 (CN) to ssh_losers

Apr 20 00:38:12 ria sshd[31715]: Invalid user ubnt from 119.191.105.117
Apr 20 00:38:12 ria mcblockd[31598]: [I] Added 119.176/12 (CN) to ssh_losers

Apr 20 00:45:53 ria sshd[31733]: Invalid user admin from 123.170.99.10
Apr 20 00:45:53 ria mcblockd[31598]: [I] Added 123.160/12 (CN) to ssh_losers

Apr 20 01:39:27 ria sshd[31845]: error: maximum authentication attempts exceeded
                    for root from 119.193.140.196 port 60716 ssh2 [preauth]
Apr 20 01:39:27 ria mcblockd[31598]: [I] Added 119.192/11 (KR) to ssh_losers

April 20, 2017

dwmrdapd nearing production-ready: RDAP cache for IDS/IPS applications

I’ve been working on a new IP to country mapping service to be used by my IDS/IPS tools. This post is about the server portion, named dwmrdapd.

dwmrdapd provides a simple service to map an IP address to its registered prefix (in one of the NICs, i.e. ARIN, RIPE, AFRINIC, LACNIC, APNIC) and its registered country. It maintains a small custom database of the mappings in order to provide a quick responses to most queries. When an entry is not found in the database, or the requested entry is more than 30 days old, dwmrdapd will make a new RDAP query to the RDAP server of the corresponding NIC (Network Information Center).

I’ve been using the service to apply policy to the networks automatically blocked by my firewall. As of this week, I can call it near production-ready.

Most of the trickery in implementing this service revolved around dealing with ARIN’s poor RDAP service. The first problem was dealing with the fact that they pad IP octets with leading zeros in startAddress and endAddress, which leads all of the standard string to address functions to interpret the numbers as octal. That was relatively easy to handle with a simple regular expression fix. The second problem is that ARIN doesn’t populate the country value. Why, I don’t know. The workaround is to parse all of the vcardArrays for a card with an adr label and then parse the label looking for a country name, then map that country name to a 2-letter country code. The latest version of dwmrdapd does this, but it’s still a bit hokey. Some ARIN RDAP responses contain many vcard entries, with different countries. There doesn’t seem to be a science to the entries, hence I prioritize non-U.S. cards and fall back to “US” as the country code as a last resort.

The service itself is secured with libDwmAuth using ECDH, RSA 2048-bit keys and AES128 in GCM mode once authentication is complete. Key management is very similar to that used by ssh, which makes it easy for me to use on my local hosts.

Inside the encryption is just simple JSON. Example output from the simple client:

% dwmrdapc 35.1.1.1
[
   {
      "country" : "US",
      "countryName" : "United States of America",
      "ipv4addr" : "35.1.1.1",
      "lastChanged" : "2014-09-23 18:00",
      "lastUpdated" : "2017-04-20 15:26",
      "prefix" : "35.1/16"
   }
]

This isn’t exactly a new kind of service. Going back to the late 1990s, we’ve had IP geolocation services. But I wanted something free, tightly secured, and automatically updated on an on-demand basis. I also wanted something small data-wise; I don’t need latitude/longitude, etc. And I also wanted to take a look at the RDAP services from the NICs.

I did look at some other freely available sources of data, one of them being ipdeny.com. While their data is useful for bootstrapping (and I have a program to bootstrap dwmrdapd’s initial database from their country ‘zone files’), I’ve found it lacking in correctness. Possibly due to no fault of their own: NIC data is messy, especially if you’re fetching it via WHOIS but even the RDAP data can be very sloppy (cough, ARIN, cough), or abysmally slow (LACNIC).

There are also RIR datasets (Routing Information Registry), but they’re not uniform and there’s less participation than some of us would like to see.

April 7, 2017

Refactoring and adding to libDwmAuth

I’ve been working on some changes and additions to libDwmAuth.

I had started a round of changes to the behind-the-scenes parts of the highest-level APIs to make managing authorized users and MitM prevention easier. However, in the end I felt like I was following the wrong course because my first solution involved too many round trips between client and server and some significant key generation overhead since I was using ephemeral 2048-bit RSA keys.

I’m now using ECDH for the first step. I have a working implementation with unit tests, using Crypto++. Unfortunately I’m still waiting for curve25519 to show up in Crypto++, but in the meantime I’m using secp256r1 despite its vulnerabilities.

I also have a rudimentary scheme for MitM prevention that is very similar to that used by OpenSSH, and client and server authentication based on RSA keys (2048 bits at the moment). I have a known_services file that’s similar to OpenSSH’s known_hosts, and an authorized_keys file that’s similar to the same for OpenSSH. This allows fairly easy management on both client and server side for my applications.

Obviously I also have a public/private key generator application.

December 23, 2016

Raspberry Pi garage door opener: part 9 (done)

by dwm — Categories: embedded, FreeBSD, Software DevelopmentLeave a comment

Not much to say here. I’ve been using the garage door opener for many months and it just works and is very stable.

dwm@pi1:/home/dwm% uptime
 3:33AM  up 123 days,  4:25, 1 users, load averages: 0.40, 0.15, 0.10

dwm@pi1:/home/dwm% psg mcpigdod
USER  PID  %CPU %MEM   VSZ   RSS TT  STAT STARTED        TIME COMMAND
dwm   930   0.0  1.2 46452 11372  0- S    22Aug16  1748:10.15 mcpigdod

August 19, 2016

Raspberry Pi garage door opener: part 8

by dwm — Categories: embedded, FreeBSD, Software DevelopmentLeave a comment

On Wednesday night I stuffed the enclosure with the Raspberry Pi, buttons, indicators and POE splitter after making all of the internal connections. I assembled the second Neutrik dataCON on the second rotary encoder. I temporarily taped my enclosure to the garage wall for testing, and connected the rotary encoders, door activation wires and the POE connection. I also attached the second magnetic door switch to the wall above the south door, and attached the magnet to the top of the door. I then did some basic testing. Both doors work correctly via the web app from my iPhone, and the rotary encoder connections work correctly.

On Thursday night I extended the wiring for the magnetic door switches (soldered joints and heat shrink), then sleeved the extensions with gray braided sleeve. Since I’m still waiting for a Neutrik jack for these, I’m temporarily using a dual row barrier strip to connect them to my PCB inside my enclosure.

August 17, 2016

Raspberry Pi garage door opener: part 7

by dwm — Categories: embedded, FreeBSD, Software DevelopmentLeave a comment

I received my HAT PCBs that I designed for the garage door opener. I populated one of them and tested all of the outputs as well as the door closed switch inputs. Everything works. Yay! I will continue assembly tomorrow, and possibly test it wired into the garage doors.

August 13, 2016

Raspberry Pi garage door opener: Part 6

by dwm — Categories: embedded, FreeBSD, Software DevelopmentLeave a comment

Today I connected the wiring for door activation from the garage door openers to the new screw terminal keystone jacks in the new wall plate in the garage. I also connected the cat5e to the yellow keystone jack. I then installed the new wall plate (stainless steel) into the new wall box. It looks clean and tidy, and I tested the door activation wiring.

I fabricated the remaining part of the rotary encoder mounts from electrial grade fiberglass angle. Both of the rotary encoders are now mounted.

I terminated the POE connection in my Leviton structured media enclosure in the basement. The jack is a yellow Leviton QuickPort, to identify it as needing POE. I used my Rhino labeler to put a heat shrink label on the cat5e cable before I punched it down on the jack. The jack is in a new Leviton 12-port jack panel that I bought to keep my POE jacks separate from non-POE jacks.

I installed the new POE switch in my rack in the basement. I then assembled a short cat5e patch cable and connected the POE switch to my main switch. I then connected one of the POE ports of the new switch to the new jack that leads to the wall plate in the garage. I connected my Raspberry Pi in the garage with a POE splitter. It works fine.

I drilled two more holes in the enclosure for the Raspberry Pi, and installed cable glands. One is for the wires to activate the garage doors, the other is for the cat5e cable. I haven’t decided how I’m going to connect the door switches yet. I’m leaning toward using a single Neutrik speakON 4-pole connector.

August 12, 2016

Raspberry Pi garage door opener: Part 5

by dwm — Categories: embedded, FreeBSD, Software DevelopmentLeave a comment

Tonight I finished running cat5e from the new wall plate box in the garage to the basement. This was a difficult, sweaty job climbing around on trusses in the attic with fish tape (it was over 95F during the day today). But it’s done. I will terminate the ends with new jacks tomorrow.

Over this week I did some work on the enclosure for the Raspberry Pi, my HAT, buttons, indicators, POE splitter and jacks. I installed two Neutrik etherCON jacks in the enclosure for the rotary encoders, since those are on the top of the enclosure and I want to keep dust out of the connection. Fortunately the rotary encoder wires are correctly sized to use with a crimped RJ45. The door activation buttons and door status indicator LEDs are installed in the front cover. Everything appears to fit, though I will not receive my custom PCBs until Monday and hence can’t assemble the whole thing until next week.

I am also waiting on some cable glands, keystone inserts for the door activation wiring and the rotary encoder mounting piece I designed (which I ordered from Front Panel Express).

August 1, 2016

Raspberry Pi garage door opener: Part 4

by dwm — Categories: embedded, FreeBSD, Software DevelopmentLeave a comment

I ordered brackets of my design from Front Panel Express to mount the rotary encoders.

I ordered Lovejoy couplings and fasteners from McMaster-Carr to connect the rotary encoders to the garage door shafts.

I ordered a Netgear ProSAFE JGS516PE 16-Port Gigabit Rackmount PoE switch with 8 PoE ports (85w total). I’ve been needing a PoE switch for a while, since I want to install a couple of PoE IP cameras. I also ordered 1000′ of yellow Cat5e cable to use for PoE applications. This will make it easy to identify ethernet cables that have PoE in my home, since my others are blue, grey or white. Finally, I ordered a PoE splitter with 5V microUSB output to power the Raspberry Pi.

July 31, 2016

Raspberry Pi garage door opener: Part 3

I finally submitted my order for prototype PCBs for my Raspberry Pi ‘HAT’ that I’ll be using for my Raspberry Pi garage door opener. In the end I wound up with this:

  • 2 relays, used to activate the doors. These are driven by relay drivers.
  • 2 rotary encoder inputs (A and B for 2 encoders), to allow my FreeBSD rotary encoder driver to determine the position of the doors.
  • 2 closed door switch inputs. I’m using Honeywell magnetic switches here.
  • 2 pushbutton inputs. I want to be able to activate the garage doors when standing in front of my garage door unit (inside the garage near the doors).
  • 4 LED outputs. I’m using a tricolor panel-mount LED indicator for each door, which will show green when the door is closed, flashing yellow when the door is moving, steady yellow when the door is open but not moving, and will flash red whenever the door is activated.

I’m using anti-vandal pushbuttons for the door activation buttons. Not because I need the anti-vandal feature, but because they are flat and not easy to push accidentally. The ones I’m using have blue ring illumination.

I’m using Apem Q-Series indicator LEDs.

The enclosure I’m using at the moment is a Hammond translucent blue polycarbonate box. Probably larger then I need, but it’ll let me house a POE splitter to power the whole thing via power over ethernet.

I still need to finish the mechanical stuff… mainly the mounting and connection of the rotary encoders. I have a drawing for part of it for FrontPanelExpress, but I don’t really need to go that route for myself. The main issue I’m still debating is whether I can come up with something cheaper and lighter than Lovejoy couplings to connect them to the garage doors.

In any event, I believe I have fully functioning backend software and the web interface works fine. Everything is encrypted, and authentication is required to activate the doors.

© 2017 rfdm blog
All rights reserved