Category Archives: security

cloud, networking, postfix, security

Switching Mail Sending to Amazon

This is another aide-memoire about changes in mail on Tarragon.

Some weeks back a change in one of the website contact pages was done and the captcha code was inadvertantly omitted. There followed a period of massive junk email directed at the owner of the site, on her google gmail account. Google decided to cut off tarragon’s ip address.

Although the problem is fixed, google has not relented. And this is the same kind of issue I have had in the past with microsoft. Although I have never been a source of spam, the big mail outfits are quick to ban the ip address of any small personal smtp server, and it takes a lot of effort to convince them to release the ban. I am tired of it. Despite my quixotic desire to run my own mail server as a symbolic cry against the erosion of personal services on the internet, I am tired of fighting, and I think it is time to stop.

Continue reading Switching Mail Sending to Amazon →
backup, gateways, linux, networking, openssh, raspberry pi, security, virtualization

Protecting ssh

I have a dozen or so boxes, mostly little raspberry pis, out in people’s houses which let me do backups for them, and attach to their networks. I’ve documented this before in “Gateway pi”, “Memory on the Gateway Pi”, and “Timemachine on Gateway pi” for example.

Connection between these boxes and my house is with SSH, and I use openssh certificates as described in “Using openssh certificates” and “Re-signing Openssh Certificates”. However, there has always been a little nagging problem, which is that these boxes must (re-)establish their connection to me automatically upon reboot, without user intervention. This means that the private keys that accompany the certificates cannot be encrypted, for that would require human intervention.

So there is a risk. Those raspberry pis have upon them a certificate and a private key which would enable access to boxes in my house. Not completely unrestricted access, and not root access, but nevertheless.

Continue reading Protecting ssh →
linux, networking, openssh, security

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 meaning 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.

arch linux, gateways, ipv6, linux, mac, networking, openssh, postfix, raspberry pi, raspbian, security, ubuntu, vpn

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 →
fedora, gateways, linux, mail, postfix, raspberry pi, raspbian, saslauthd, security

No Worthy mechs

I just built another little gateway pi, on Raspbian. It is a newer Raspbian than I used for the others. And newer is better, right? But when the little fellow came up, postfix claimed it couldn’t relay through tarragon, because it couldn’t accomplish login. Sasl authentication failed, no worthy mechs.

I remember good old “no worthy mechs” from way back when, always thought it a very cool error message. But why in the heck am I getting this? I’m not doing anything fancy.

I had a vague nagging feeling from some old Fedora problems, long ago. Could it be that I have to install some kind of sasl library, even to do plain authentication? Poked around a little. Eventually did an apt install libsasl2-modules and sasl2-bin. Sure enough, they actually installed.

And afterwords postfix came up and send the mail out of the queue. I’ll be dipped in … I am surprised. This was not something I had to do before. Is this an improvement in Raspbian. Don’t package any sasl mechs, make the poor sod figure out why sasl authentication won’t work.

This is to help me remember the next time this happens.

arch linux, encryption, fedora, gateways, linux, openssh, security, ubuntu

Re-signing Openssh Certificates

Seldom do I get to write a post where I am offering information which might not actually be out there in a lot of places. I could not find this information on the web, and had to figure it out myself, by reading the code, and doing experiments.

I talked in the last post about the need to re-issue all the openssh certificates, in order to update the hash algorithm used for the signatures. My way of maintaining the certificates, in my repository, would make it easy for the signing box to get all the existing certificates, but not (directly) the public keys that are inside those certificates.

Continue reading Re-signing Openssh Certificates →
arch linux, encryption, fedora, gateways, linux, networking, security

SSH Certificate signing

I’ve encountered a problem migrating from Fedora to Arch which ends up being about ssh and openssh certificates. I look back and discover that I never posted anything about my movement toward openssh certificates. Curious because I wrote a lengthy document about it (because of my leaky brain – not because I am any kind of authority on it).

I will probably go back and write a post about it, and back date it. But now a problem has arisen. Rather than explain, let the boys at openssh speak for themselves, in the release notes for openssh 8.2:

Continue reading SSH Certificate signing →
apache, centos, cloud, encryption, linux, networking, security, website building

Apache certificate chains

When I switched my main server to CentOS, described in an earlier post, one of the big pains was that I had to use CentOS 7, and there was a lot of software which had come a long way since CentOS 7, and I had to upgrade a log of things from upstream to get functionality that I had grown reliant upon.

I didn’t realize that Apache itself was one of those things that was sufficiently backwards in CentOS 7 that I would have trouble.

Ever since I move the server to CentOSdid that “upgrade”, I’ve been struggling with problems with the certificates not being honored. For the last few days I have been working pretty diligently to try to figure out this nagging problem, and today I finally figured it out. It is owing to an old Apache.

Continue reading Apache certificate chains →
ipv6, linux, networking, security, vpn

Odd VPN Problem

I have had trouble twice now with modifying a working vpn configuration, and then being unable to get it to start. Both times I never actually solved it, so much as eliminating the problem by switching to a different nordvpn config file.

There was a penetration at nordvpn in which some passwords and userinfo were leaked. I wanted to change my password, and did, and had to get into the vpn router and change it there. And after I did the vpn just would not start. Eventually, I switched to another vpn endpoint, put in a new .conf file in /etc/openvpn/client and it came right up.

I don’t know what this is about.

March 26, 2021: I spent all morning on this again. I was changing scripts on Rosemary and also, double and triple checking that I did not allow IPv6 on obelisk/rosemary (if routable IPv6 addresses are available they will be used in preference to the IPv4 vpn, which is the whole point of obelisk). After a reboot of obelisk, it lost dns. I spent several hours trying to solve this, most of the time spent on obelisk. The vpn would come up, and I could ping raw addresses, but the dns wouldn’t work. I don’t even see what this has to do with the vpn tunnel.

Yet in the end, out of desperation, I tried bringing in a new nordvpn conf file (actually it comes in as an ovpn file, and once I put a password link in it it is saved as a conf file). A link in /etc/openvpn points to whichever of these is active. So I installed a new one, rebooted the router (again), and like magic it began to work.

apache, backup, centos, cloud, fedora, linux, mail, postfix, security, website building

Clamd signatures and Apache memory

After implementing the new tarragon the biggest problem I had involved the clamav package, and its loading of signatures. If clamd doesn’t come up and open its socket, then amavisd (the daemon who is consulted by postfix to handle all the checking of each piece of mail on input and output) will fail (assuming he is configured to do virus checking), This results in various problems. Amavis will mark the mail as “unchecked”, but worse, it will report failure back to postfix who gets confused and very often the message is delivered two or three times.

Clamd, the clamav daemon, now has over 6 million signatures. There are a lot of bad boys out there. The signatures are loaded by clamd from its database (in /var/lib/clamav) on startup, into memory. As a result, clamd has a large memory footprint, almost 800Mb on my system. The first issue, discovered before going live, was that systemd’s default parameters expect any daemon he starts to load within 90 seconds. If it fails to check in within that time, systemd considers it broken and terminates it. Clamd takes at least 3 minutes to load. I had to set a special TimeoutStartSec value in the systemd service script for clamd@.service.

Whew! I thought, boy I’m glad I figured that out. Hah!

Continue reading Clamd signatures and Apache memory →