Category: Sysadmin

Apache goodies for WordPress security

The list of things to do to harden a WordPress site with Apache is long, but some things that could be done include:

FileETag None                                                                                                                       
                                                                                                                                    
<Files wp-config.php>                                                                                                               
    Require all denied                                                                                                              
</Files>                                                                                                                            
                                                                                                                                    
<Files xmlrpc.php>                                                                                                                  
    Require all denied                                                                                                              
</Files>                                                                                                                            
                                                                                                                                    
<LocationMatch "/wp-content/uploads/.*(?i)\.php$">                                                                                  
    Require all denied                                                                                                              
</LocationMatch>

SSH tunnel to use other mailserver than localhost

Because I have a lot of virtual machines, laptops, work environments, and so on, I never seem to find the time to setup SMTP authentication everywhere. I typically use Linux for everything except hardcore gaming, so it’s only natural that I have some sort of mail server installed like Postfix. The problem in using that mail server to send e-mail is that I also quite often have dynamic IP addresses on these machines, which doesn’t work well with “e-mail protection” (well..) like SPF.

So instead of making my life very complicated, I have a trusted server on the Internet through which I send e-mail.

If you were looking for something fancy in this article, you can move along now, there’s nothing to see 🙂

To make all my Linux work instances believe they’re talking to an SMTP server locally, I simply setup a tunnel from the given Linux instance to this trusted server on the Internet using the ever so versatile OpenSSH / SSH. I know there are a lot of ways to do this, but this is what works for me:

Local machine or “where I work”

I have a private/public key keypair on all of these machines. The public key is placed in the /root/.ssh/authorized_keys file on the trusted server that is running the mail server.

On this machine, as root, I setup a tunnel that looks like this:

ssh -N -L 25:localhost:25 root@mail.example.org -p 2222

This will create a tunnel from “localhost” port 25 (where I work) to “localhost” port 25 on mail.example.org. It will connect the end point of the tunnel to mail.example.org on port 2222. If the mail.example.org server is running an SSH server on its standard port (22), you can remove the “-p 2222” part.

Mail server

On this server, I only need to put the public key from the local machine “where I work” into /root/.ssh/authorized_keys to allow the tunnel to come up.

When I access port 25 on my local machine “where I work”, it will be sent through the tunnel and then attempt to access “localhost” port 25 on the mail server. The mail server software, Postfix in my case, will never know this connection did not actually originate from “inside” the machine, but rather through the tunnel.

Closing thoughts

You can (obviously) make this somewhat more automated with tools like AutoSSH, init scripts, and what not. The above only intends to show how uncomplicated it is to create useful SSH/SMTP tunnels 🙂

 

Var är den oberoende och kompetenta myndigheten för IT?

Man kanske skall vara öppen med faktum att 2017 förmodligen INTE är det år som går till historien då flest snedtramp gjorts vad gäller IT och IT-driften hos myndigheter, riksdagen, osv. Snarare råkar vi, av “ren tur”, ha kommit på att detta skett och fortsätter att ske, med makthavarnas vetskap. Fortsätter det så här, så kanske vi skulle lägga upp samhällskritisk och i många fall hemlig information på en öppen server så att Google kan indexera det (göra det sökbart). Då riskerar vi i alla fall inte att tappa bort informationen och samtidigt sparar vi enorma mängder pengar. Win Win!

Men en större fråga tycker jag är: Varför har vi inte en oberoende myndighet som ansvarar för drift av och beslut gällande driften av IT-system inom offentlig förvaltning? Hur kommer det sig att vi 2017 får reda på att till och med regeringskansliet inte har någon som helst aning om vad de sysslar med och vilka risker man tar när man väljer att “lägga ut driften” eller “ta in kompetens”?

Även om jag principiellt inte är för att ytterligare komplicera och försvåra den redan ganska röriga byråkratin vi har, så känns det som att detta faktiskt skulle kunna vara motiverat. Det är för många dinosaurier, det är för många politiska tillsättningar och det saknas definitivt kunskaper.

Det kanske är dags att tillsätta en grupp människor och bilda en ny myndighet, där de tre yttersta kraven är IT-kunskap, sekretess och oberoende. När vi i de flesta andra situationer strävar efter att ha bäst kompetens på rätt plats, varför är det inte så när det gäller IT inom offentlig förvaltning?

Godtrohet är inte en giltig ursäkt för inkompetens.

Kanske skulle detta falla under MSBs ansvar, kanske inte.

Jag har sagt det tidigare och säger det igen: Vi har bara sett toppen på ett enormt isberg.

#svpol #fail #it #sakerhet

Forcing OutOfOffice response to always fire in Zimbra

We had a need to create an e-mail account in Zimbra that would always generate an automated response to incoming e-mails. So we activated the OutOfOffice functionality (or “Vacation Mode” as some people prefer to call it). This is great, and you do have some control from the ZWC (Zimbra Web Client) user interface.

The “problem” with the OOO functionality is that it is designed for human interaction. So, in an attempt to be somewhat “intelligent”, Zimbra will remember to whom it has sent an automated response message, and if a second message is received within nn time, it will not send another one. This makes sense, if I have sent an e-mail to John Doe, and Mr Doe is on vacation, I probably know this to be true even if I send him another message within a few hours or days. So I don’t want a second automated response.

We wanted it to send an automated response every time it received a message, zmprov to the rescue!

As the ‘zimbra’ user, from the CLI prompt, enter:

zmprov ma acct@tobemod.com zimbraPrefOutOfOfficeCacheDuration <value>

 

The default <value> in our installation was 7d, presumably that means seven days. So I set it to ‘1s’ and anyone sending e-mail to acct@tobemod.com now gets an automated response, even if they send several messages within a short period of time.

Troubles doing factory reset on a Ubiquiti EdgeRouter

If you’re having problems doing a factory reset on a Ubiquiti EdgeRouter, and can’t ping the router on 192.168.1.1 or connect to the admin web interface, you may want to check that you are connecting your computer to the eth0 port on the router. It’s not immediately obvious that this is where the admin interface is residing at https://192.168.1.1. Oh, and don’t forget to hardwire your own computer to the 192.168.1.0-network. This is really a no-brainer, but still not entirely obvious.

Slow SMTP sessions and SSH logins on your Zimbra server?

When upgrading a Zimbra server to a somewhat recent version (8.7.3 for example), it may attempt to install its own DNS Cache (zimbra-dnscache). It’s obvious that this may cause issues if you are running some other DNS caching service, or your own BIND, on the server. But these are rather obvious issues and not unique to Zimbra.

What is not, however, equally obvious is that you may think that zimbra-dnscache is actually running, and that it is actually doing what it is supposed to be doing.

My first hint that things weren’t as they appeared to be was extremely slow external SMTP sessions when clients like Thunderbird and other “client mailers”, as well as some web based Helpdesk applications were attempting to send e-mail via Zimbra.

The upgrade to Zimbra 8.7.3 had gone quite well, so it wasn’t an obvious place to start looking.

Until I noticed that SSH logins were also quite slow to this server. They had never been slow before. Checking the SSH configuration on the server did not reveal much other than the fact that it was indeed using reverse DNS lookups.

Checking /etc/resolv.conf made everything clear. Zimbra had, in attempt to use its own zimbra-dnscache, added “nameserver 127.0.0.1” to /etc/resolv.conf. In a perfect world, that may have been what I wanted …

After removing 127.0.0.1 from /etc/resolv.conf, inbound SMTP sessions from “client mailers” and web applications went from 7-10 seconds down to 0.5-0.1 seconds. Case closed.

I’m thinking Zimbra should add a post-installation sanity check. When all services are up and running, a DNS lookup to a known host (www.zimbra.com for example) should return within less than a second or two, anything else is an indication that the system may not function as intended.

#zimbra-dnscache

The DrayTek Vigor 3900 isn’t bad, just very confusing

3900-other-01The DrayTek Vigor 3900 has been around for some time now. Sadly, this isn’t exactly mirrored on the world wide web. The amount of documentation, samples, and FAQs is sparse; guides, and discussions are few. For a product in this class. And that’s not very good at all.

DrayTek has always gone their own way, and it’s usually a good way. The biggest problem, IMHO, is that you need to wrap your head around how the DrayTek engineers think. To add insult to injury, several of the “DrayTek websites” require you to have an account on their sites to download technical guides. I have no idea how this came to be, but it’s not good. And, it’s not like the good people at Clavister or ZyXEL is going to steal “ideas” from a DrayTek guide. #lol

I’ve toyed with quite a few firewalls. They all have their pros and cons. Well, almost all of them. Some only have cons, really. But I cannot for the life of me understand why DrayTek has such crap documentation, crap support information archives, and have to go their own way on every single administration user interface design. Because they really do make great products. Maybe they are a little bit too aware of that fact.

#draytek #network #security #firewall #vigor

IP-Only, NOC, customer service, support, and network loops

IP-Only often boasts about being “the man” when it comes to Swedish Internet infrastructure and their competence in networks. Customer service and fast response to serious network issues such as routing loops seems to be of … less importance to IP-Only. It’s fascinating how “big players” so often seem to ignore “small customers”. We reported this network issue to IP-Only on 13-Jun-2016 (Monday). On 17-Jun-2016 (Friday), they still don’t know what the problem is. But they are “investigating it”. In the meantime, there is zero response from them until you start screaming.

It’s so comforting to know we’re in safe hands with them, being “the man” when it comes to the Internet infrastructure in Sweden.

What’s less comforting is that they don’t seem to monitor their network equipment nor know how it works.

  3  62.109.44.150 (62.109.44.150)  1 ms  1 ms  1 ms
  4  62.109.44.154 (62.109.44.154)  1 ms  1 ms  2 ms
  5  sesto1024-rc1.ip-only.net (62.109.44.153)  1 ms  2 ms  4 ms
  6  62.109.44.154 (62.109.44.154)  1 ms  1 ms  1 ms
  7  sesto1024-rc1.ip-only.net (62.109.44.153)  1 ms  3 ms  1 ms
  8  62.109.44.154 (62.109.44.154)  1 ms  1 ms  1 ms
  9  sesto1024-rc1.ip-only.net (62.109.44.153)  1 ms  2 ms  1 ms
 10  62.109.44.154 (62.109.44.154)  2 ms  1 ms  1 ms
 11  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  1 ms  3 ms
 12  62.109.44.154 (62.109.44.154)  3 ms  3 ms  2 ms
 13  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  4 ms
 14  62.109.44.154 (62.109.44.154)  4 ms  1 ms  1 ms
 15  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  1 ms  2 ms
 16  62.109.44.154 (62.109.44.154)  24 ms  5 ms  2 ms
 17  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  2 ms
 18  62.109.44.154 (62.109.44.154)  2 ms  2 ms  2 ms
 19  sesto1024-rc1.ip-only.net (62.109.44.153)  3 ms  3 ms  3 ms
 20  62.109.44.154 (62.109.44.154)  2 ms  2 ms  2 ms
 21  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  2 ms
 22  62.109.44.154 (62.109.44.154)  3 ms  2 ms  2 ms
 23  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  2 ms
 24  62.109.44.154 (62.109.44.154)  2 ms  2 ms  2 ms
 25  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  3 ms
 26  62.109.44.154 (62.109.44.154)  3 ms  3 ms  4 ms
 27  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  3 ms  2 ms
 28  62.109.44.154 (62.109.44.154)  2 ms  6 ms  2 ms
 29  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  2 ms
 30  62.109.44.154 (62.109.44.154)  2 ms  4 ms  4 ms

SSH keys are no longer working after upgrading to Ubuntu 16.04.LTS – Help!

I recently upgraded one of my laptops to Ubuntu 16.04.LTS (going from 14.04.LTS). The upgrade went very smooth and I have no issues with the resulting operating environment 🙂 Having said that, I quickly discovered a quite serious issue for me when I attempted connecting to one of many servers I need to get into. All of a sudden, my SSH key was no longer accepted by the server, and I was prompted for a password! WTF!?

I immediately feared the worst and started looking at the server(s), tailing log files, enabling debugging, etc. No trace was to be found other than that no key was presented by the client. The servers were intact, the authorized_keys had not been compromised, and vanilla ice cream was still the number one flavor. The problem is not with Ubuntu 16.04.LTS. The problem is with my SSH key, as well as a recent change in “acceptable keys” by OpenSSH, version 7.

Doing “ssh -vvv user@server.com” told me that the SSH client couldn’t find an acceptable key to present to the server. After having figured that out, and facepalming for a few seconds, I added this to my /etc/ssh/ssh_config file:

PubkeyAcceptedKeyTypes=+ssh-dss

Saved the file and tried again. Voila! One could say many things about using this type of SSH key, but rest assured I will change mine. You should too if you run into this problem. This is a workaround, not a fix or a solution. So sit down with some vanilla ice cream (with actual vanilla) and something nice to drink and go through the process of replacing your public SSH keys everywhere.