AliGrant.com
 
Valid XHTML 1.0!

Valid CSS!

Powered by PHP

Get FireFox

1&1 Internet


Archived News

SpamAssassin, Amavis - Missing headersTuesday 13th June 2017
I got a piece of spam the other day - not entirely shocking in itself, but it wasn't filtered and didn't seem to have any scoring information on it. This is strange as I use Amavis and Spamassassin to filter incoming emails.

The difference for this email was the destination - I've been trying out some virtual mail hosting in Postfix by using the /etc/postfix/virtual file and aliasing an entire domain to a mailbox. This works fine, and whilst Amavis was running, it wasn't my rule set.

It turned out the cause is the @local_domain_maps variable in Amavis. I had already added my virtual domain to this but that wasn't triggering it, instead I had to add the final destination domain, which was the hostname of my server. Once added everything started working as expected.

I suspect this only applies when running Amavis as a post-queue filter and not pre-queue filter. Still, it's a gotcha worth remembering.


Remmina & Windows 10 - Unable to connectFriday 9th June 2017
I use a XFCE Linux desktop to remote desktop to various computers, but I've found recently that some don't work.

I'm using Remmina and the target is Windows 10 - maybe something new in Windows 10? I played around for ages looking at routing and firewalls, ticking boxes in Windows 10 before I finally stumbled upon this helpful post.

The target system had been updated to Windows 10, which was a new build - but it seemed that I had already connected to a host with the same name and the host key had been saved locally. Remmina saves host keys into ~/.freerdp/known_hosts. So finding the correct line and deleting it is required for things to spring back into life.

I deleted the whole file as there were several hosts suffering from this problem and I felt it was time for a periodic refresh.


CentOS 7 iptablesThursday 8th June 2017
I've been playing about with CentOS on a dirt-cheap VPS.

One of the first tasks was getting iptables (firewall) up and running - no problem but keeping the rules to be sticky after rebooting doesn't seem to work out-of-the-box.

There are a couple of things you need to do:

1) Update /etc/sysconfig/iptables-config (and ip6tables-config) to set: IPTABLES_SAVE_ON_RESTART="yes" in order to save changes when you reboot (or, if you prefer, do this manually).

2) Run the command "chkconfig iptables on" and the same for ip6tables.

When rebooting rules should load up automatically.


Blocking malware domain names in BIND.Wednesday 7th June 2017
A lot of malware, including ransomware, make extensive use of the domain-name-system. Connecting to servers to report in or get latest scripts etc. This is probably due to the flexibility DNS provides over a direct IP. If an IP address is blocked or changed, then the malware can no longer phone-home. With DNS, an attacker can just update their domain to point towards another server without having to re-distribute anything.

As a result, a number of organisations are publishing lists of "bad" domains, which can be blocked, or "sinkholed" to provide a degree of protection against malware.

Projects like OpenDNS provide some of this functionality baked-in, but if you run your own resolving server then you will need to look elsewhere. I've gone with Malware Domains because for one, they provide a BIND configuration file directly, so no need to script your own.

You do though, need to script automatic updating to keep it effective. These instructions will vary depending on the flavour of Linux you're using. I'm using openSUSE.

First off, you need to create a zone file that will act as the sinkhole, this has to match the location provided in the malware list: "/etc/namedb/blockeddomain.hosts"
$TTL 4w
@ IN SOA myserver.mydomain. root.mydomain. (
2017060700 ; serial
6h ; refresh
1d ; retry
4w ; expiry
1m ) ; minimum

IN NS myserver.mydomain.

By using the @ sign, the zone will be valid for any zone entry BIND loads against, which saves you creating thousands of zone files.

The next step is to create a script to update:
wget -N http://www.malware-domains.com/files/malwaredomains.zones.zip
unzip -u malwaredomains.zones.zip
chown named:named malwaredomains.zones
chmod 664 malwaredomains.zones
cp malwaredomains.zones /etc/named.d/
mv malwaredomains.zones /var/lib/named/etc/named.d/
rndc reload

This will download the zip, decompress it, prep permissions and place it into my configuration directory as well as the chroot directory of named. You need both directories unless you plan to restart the BIND server, which would be overkill as "rndc reload" takes care of changes to zone definitions.

You can then schedule this to run at whatever frequency you desire - I don't believe the list is published more than daily. If you have multiple resolvers, be sure to set them all up - but maybe only download the file once to keep bandwidth costs down.

The final step to piece it all together is to include the output of the script in your named.conf:
include "/etc/named.d/malwaredomains.zones";

Of course, if you find the service useful, then you may wish to consider donating to them.


Previous Next