Detecting SSH Brute Force

It always annoys me when I see the log filling up with ssh attacks. It isn’t really a worry, these are password guessing and since passwords aren’t permitted they will never work.

I’ve been meeting for a long time to investigate the tools available in iptables with the “recent” module to detect them and block them. Today I finally did it.

There is a little script in /root called sshdrop, which contains the iptables rules. It is parameterized, but currently set for reacting to more than 2 syn in 20 seconds, and sends rejects with tcp-reset.

I also downloaded a little python script to inspect the /proc/net/xt-recent/DEFAULT and decode it a bit, which lets me see how many attackers, and how recently. The script is invoked with ipt_recents -txt.

Seems to be working well.

Headless Windows 10

The oldest physical box in the house, a 12 years old Core2 Quad in an old case was my Windows 10 box, nutmeg, which I don’t use very much except to test out various things under Windows. I don’t do much with Windows any more, yet it was attached to one of the three monitors on my desk – using up 1/3 of my total screen real estate; and it was generating heat and fan noise, and its presence offended me. I decided it needed to move to the basement, alongside Cinnamon and Rosemary who are already down there in a rack — banished to the basement because they have a lot of disk drives, and so generate a lot of heat and noise.

I bought another rack mount chassis, and moved nutmeg’s innards to it. This proved annoyingly difficult because various old bits of hardware decided this was a good time to give up the ghost – I lost two old disk drives that decided to stop functioning. But eventually got everything up and running.

The idea was that I would manage the box, on the relatively few occasions I needed to do so, just as I do both Cinnamon and Rosemary, with a VNC connection. So after it was up and running on my work table, I pulled the monitor, keyboard and mouse and rebooted. But attempting to connect with VNC failed. For the record, this was TightVNC.

I eventually found that VNC would work if and only if I had a monitor attached. Furthermore, if I had a monitor attached and established a VNC viewer to nutmeg, if I then unplugged the monitor the VNC viewer would immediately freeze. WTF?

Without making this a long story, I found that the problem could be resolved by changing an option in Settings/Accounts/Sign-in options which is down at the bottom under Privacy, and reads “Use my sign-in info to automatically finish setting up my device after an update or restart.”

So my mental model of what is going on is that if that option is set, windows is attempting to “set up my device” and I suppose the device it is trying to “set up” must be the monitor. What I don’t exactly get is why the VNC viewer should freeze when an existing monitor is removed. I suppose that removal generates some event internally, and processes attached in some way as consumers must be killed or something. Not sure. I don’t need to understand it. I have very few cycles in my advanced age and am not planning to waste any of them trying to figure out Windows.

I was very pleased that after I did this, and was able to connect via VNC, I was able to set the resolution to various values up to 4K. And after rebooting and reattaching it even retained my display resolution setting.

Attaching and backing up the iphone

I have an iPhone 11. From time to time it would be nice to be able to attach it to my network. Always a struggle.

The old Macbook Pro can only run High Sierra, and then only with some special jiggery-pokery. I can sometimes get iTunes on the Macbook to connect to the iPhone, and can usually figure out how to get data into some app using that, or to do a backup, but it is a hassle. The Windows 10 box with iTunes won’t connect to it at all, and (typical of Windows) won’t explain why. I really just want to mount it without all the fuss.

I found a guy on the net who claimed to be able to mount his iPhone on Arch, so I tried following his instructions, which basically involved installing a few libraries usbmuxd, libplist, libimobiledevice and ifuse, the last of which I had to install from AUR. That was easy enough.

Then reboot, plug in the iphone, and voila. It is detected.

I created a directory /ginger, and mounted it with ifuse /ginger, and Bob’s your uncle, I have access to its disk on Arch.

Then I checked on a whim whether I could do a backup. Sure enough libimobiledevice comes with idevicebackup2 which, supposedly, will do a backup of the device. Alas, it doesn’t work, complaining of a protocol mismatch, which according to the net means that the version 1.3.0-3 available on Arch is not the latest, and I need 1.3.1. The option is to download from git and compile from source.

This is low priority for me. I still can do an occasional backup on the Macbook, when I think of it, either locally or to iCloud, via iTunes. The local backup is stored in /Users/dee/Library/Application Support/MobileSync/backup and can be copied elsewhere by root. I don’t actually have much on the iPhone that needs a backup. Many people have their contacts and calendar exclusively on the phone, but I keep both my contacts and calendar in radicale on my server and connect to them from everywhere.

I may eventually do this if there comes a time the backups become important. For now I’ll just wait till a later version shows up in Arch.

Waiting for system online with systemd

I had previously used the NetworkManager utility nm-online in my startup script as described in Waiting for networks, but now that I have moved to systemd-networkd that isn’t available anymore.

There is a fair amount of stuff on the net about the systemd service called systemd-networkd-wait-online.service. And indeed, that is a useful service, if one wants other services to wait for the network to be online. But somehow most of it seems to miss the point somehow, or at least one big point. I found various statements on the net that systemd doesn’t have the equivalent of nm-online. The only way in which that is true is if one means by it that systemd doesn’t have something as primitive. In truth what systemd has is much better, and much more powerful.

Continue reading Waiting for system online with systemd

Switching to systemd-networkd

Since moving to IPv6 I have had two recurrent problem: one with some conflict between systemd and the kernel over the /proc/sys/net/ipv6/conf/*/accept_ra, and the second with losing the static ipv6 address assignments on some boxes. I believe the former problem to have something to do with systemd wanting to have control of the sysctl variables, such as accept_ra.

The latter problem is due to the various bits of software that want to have a say in the control of the network. In part some of this is my own fault, as I do have these various bits installed – and if they weren’t installed they could not be causing trouble.

I installed NetworkManager in some places, even when it hadn’t been installed by default, because I wanted to be able to control things with the network applet in gnome. I installed dhclient even though it wasn’t installed, because I wanted better ability to see and control the dhcpv6 leases, particularly the DUID, and network manager made that difficult (and astonishingly, in some cases simply didn’t work).

Continue reading Switching to systemd-networkd

IPv6 Re-implementation

This is a follow up to the activities in IPv6 implementation, which was published on March 2nd and revised up through March 19th, as new challenges were addressed. Since March 19th a great deal of what I wrote has been revised, as I have learned a lot more.

The main issue was that there remained a number of problems with the implementation of IPv6 in my residence.

  • The biggest was the question how to handle the delegated prefix, particularly in renumbering. Over the course of the last several months I have to note that Comcast has never changed my prefix, except early on, when I forced it to do so by changing my DUID. And I don’t think it likely that my prefix would change unless some great catastrophe befalls which results in my being down for a very extended period – like 30 days; or more likely there is some change in my service (a change in ISP, or perhaps fiber arriving in my area).
  • The first implementation required that I make patches to the code of my router. This meant that I would have to figure out how to carry those patches forward in the event of firmware updates from Ubiquiti, the maker of the Edgerouter-X that I am using.
  • The implementation was pretty fragile, with a lot of unrelated bits in different places. In particular there was a lot of hand-waving in trying to assign and maintain a separate network for the virtual machines on one of the interior boxes.
Continue reading IPv6 Re-implementation

Waiting for networks

I was revising some things in my startup scripts. I have a sort of generalized startup script in all the boxes in my constellation, which is capable of doing 8 or 10 different things that various of the boxes need to do at startup.

For example, the various gateway boxes need to open up (auto)ssh connections to my house with reverse tunnels so I can reach them. On some boxes I want them to open a vncserver so I can get a graphical environment up. On some others they may need to mount some filesystems, with smb or nfs. On some of them I want them to figure out where their router is, in case I want to open up their router in a browser. On some I need them to establish the keychain.

Continue reading Waiting for networks

more spam improvements

Over the last couple of weeks I have made the following improvements in spam checking for mail handling on tarragon. Tarragon handles mail for about 20 domains, although only about a dozen have any mail to speak of.

I used to have entries in the amavis whitelist file, but this is/was a weakness. It is easy to fake sender addresses. Use of the amavis sendermaps feature is preferable as that way one can give a spamassassin bump to a known address or domain, but the value of the bump can be small enough not to overcome other attributes of the message. So egregious spam that claims to come from my own domain will still be caught. Also, I can have sendermaps for each separate email domain, instead of a whitelist applying to everyone. The file /etc/amavis/conf.d/56-sendermaps now has all the sendermaps.

Continue reading more spam improvements

Spamassassin change

I seemed to have more spam getting through. When I look at those messages which I think should have been caught, I observe that many/most/almost all of them contain in the X-Spam-Status the value: RCVD_IN_DNSWL_HI=-5. Spamassassin is giving them a whopping -5 whole points if the dns source of the message appears in the High Reliability list of the site DNSWL.org, which according to what I read, is one of those sites that maintains reputation lists, and says of the High list:

“Recommended Usage: Skip spam filtering for medium and high ranked IPs. These are trusted to send spam rarely enough that they are not worth filtering.”

There is some discussion on the net, others too seem to think they are getting a lot of spam because of this, suggesting that a site on the dnswl high list can be induced to forward spam. I know little of all of this, but I have added a rule to /etc/spamassassin/local.cf:

score RCVD_IN_DNSWL_HI 0 -0.1 0 -0.1

This changes the value from -5 to -0.1. If I set it to 0 (as I originally did) then I can’t tell in X-Spam-Status whether the rule applied or not. Now I see the rule in X-Spam-Status with a small value.

So far this seems to have helped. Encouraged by this, I’ve added another couple of specifications to /etc/spamassassin/local.cf, to wit:

ok_languages en fr
ok_locales en fr

Which should act to increase the “spaminess” score of emails in other languages and character sets. A couple of mail users are French speakers, but AFAIK nobody using tarragon for mail speaks any other language or/and receives mail in another language.

IPv6 implementation

This post describes my first attempt at implementation of IPv6, a process that took place over a span of a couple of months. After this was done, and was working, a “better way” emerged, which will be the subject of an additional post. I leave this in here for the sake of documenting what I did the first time, but in the unlikely event that anyone finds this while looking on the net for information about implementing a similar arrangement, I urge you to find the other post, and read it as well. This implementation was fragile.

A few weeks back (10 Feb) my friend Mr. G and I exchanged an email in which he said of a possible project “…but this would be an opportunity to learn IPv6”, reminding me that I have for a long time wanted to learn more about IPv6. Part of the genesis of that email conversation was a recent switch by my brother-in-law to a new ISP that employed CGN, so called Carrier Grade Nat, which had disrupted arrangements I had in place for reaching my brother-in-law’s home network. Mr G. opined that the move towards CGN, and other things the ISPs were doing, raised the specter that someday, perhaps sooner than we expect, anyone desiring to do more with their network than occasionally use a browser would find ourselves having to move to ipv6.

More, I have actually wanted to use IPv6 for a long while, but had been under the impression (erroneously) that Comcast really wasn’t ready for this, that all they would give me was a 6to4 tunnel, which I barely understood anyway.

Continue reading IPv6 implementation