Tag Archives: Debian

more mailserver fun

I’m still working through my quarantine folders. There are about 300 emails in each folder, and there are 62 folders. The folders are named 0-9, a-z, and A-Z. I don’t know why SpamAssassin / Amavisd on Debian does it that way, but it does.

Anyway going through them one at time with zless, and then rm was a bit of a pain. So I wrote a quick little one-liner to help:

The problem is, not all of the files are in gzip format, so it didn’t display those. And going in and out of the page system for Less was an annoying flash between the pager system and the normal terminal output.

So I improved it, using zcat, because I had some issues with zgrep not supporting some grep switches, like recursive.

Now it didn’t launch the pager, so no flashing. The second thing it did was give me just the To, From, Subject, and Date fields, and I could decide to delete or not based on block of info provided. Downside was it still didn’t handle the non-gzip files.

So when I got up today, I thought why not create a shell script to do this. And I can add in the feature to release false positives that SpamAssassin put in the folders.

So I now have a Mail Administration script in my DFIR repository on GitHub, that will check if it is gzip or not. Use the right form of grep, show info, and ask what to do with the file, release or delete (or nothing if you don’t use r or d as the answer).

Still some minor issues with the script:

  1. Must be ran as root, or someone else that has access to the virusmail sub-directories. in my case that means root since the mail accounts have /bin/false set up for shells.
  2. To be more portable it has to be called from spam sub-directory. In my case spam is in /var/lib/amavis/virusmails/. Which means I have to go there, and then in to one of the 0-9, a-z, or A-Z directories first. Like so:

  3. I still have 300 or so emails in each folder so I’d rather work 1 folder at a time right now to clear them.

Future plans for the script:
Ask the user where their spam folder is, so the script can be called outside of those folders, and enumerate all the sub-folders.

I also have to find out if the 0-9a-zA-Z is the same for all versions of software or if that is just a Debian thing.


For a while now, I’ve been having problems with DKIM. It wasn’t working. My logs always had the same error:

And I’d look for a fix but never find anything useful.

Today I decided to go through my mail quarantine folders. In them I found several emails from a friend who is having problems with spammers using his email address. None of them are going through his mail server, they’re all spoofed. We’ve compared our SPF records and they look right. So I went and looked up why I’m seeing all these mails.

Turns out that not all mail admins have set up their servers right to look at SPF and block. That was my problem.

So I went and found a howto for my operating system to fix SPF with my Mail Transfer Agent (MTA). The document, provided by my VPS hosting provider, had how to set up SPF, how to configure my MTA to quarntine emails that fail SPF, a DKIM walk through, a ADSP howto, and a DMARC howto, all on the same page.

First things first. I fixed the SPF inbound. Now it should do the stuff it needs to. Then I figured since I still had time, I’d go after the DKIM problem.

So I backed up my existing files and followed along. AND NOTHING WORKED!. Still the same problem. Heck even the same error message.

So an

later and I started completely fresh. Nothing old, not even the old backup files.

And it still didn’t work. sysctrl status -l opendkim.service and journalctrl -xe were not much help either. Neither one gave enough information on what was wrong.

I did some searching through the logs, and found that even after changing the port to a local socet for Milter it still couldn’t work. But this time I found that it couldn’t see the files, and searching the directory that local socket should be in, it wasn’t there. After much googling I found an old bug report for Debian (my OS of choice). If the socket and pid files were missing, do this:

And suddenly everything was working. I sent test emails to test services, and they seem to be working. At least they told me that everything works.

Then I went why not and set up the ADSP and DMARC stuff in DNS.

Really just happy to get past the problem where dkim isn’t working. Now to go finish clearing out the quarantine files.

Raspberry Pi WPA_Supplicant setup taking way longer than it should

—- TL/DR —-
If you want to connect a raspberry pi to a hidden access point your wpa_supplicant.conf needs to have the following in the network statement.

Don’t put a ” or a ) in your ASCII PSK it causes problems. I couldn’t get it to work with the hex psk using wpa_passphrase but I broke the rules of troubleshooting making multiple changes at a time instead of one and resetting it.

—– End TL/DR —-

I got a new phone. Nexus 5x.  But this isn’t what this post is about. My SO got a new phone last August. It was an unplanned by after the last one went for a porta-john swim. Again. not what this is about.

A co-worker suggested setting up a NAS to back up the pictures to. Being a poor college student, yes still grad school isn’t cheap, that really isn’t an option. Then he said well if it’s just the phones, why not use one of your Raspberry Pis?

The problem is getting the wpa_suplicant.conf file talking. It has taken me 2 days. Mainly because I don’t mess with that file much.

it hated my passphrase because of the ” and the ) in the middle example:

I tried wpa_passphrase with the file, but it didn’t like that either. (although I kind of want to go back and test it again, in case I missed something.

Which I couldn’t find out until after I set the AP to broadcast. So after more digging I found that

scan_ssid=1 has to be in the config.

Sigh. This is taking way longer than need be, and I’d just wire it, but it’s going to not be near the cables, because of power.

Oh look HTTPS

Testing out Let’s Encrypt public beta. My thoughts so far:

90 days for the SSL certificate. Does that mean we’ll be seeing spammers setting these up to make their sites look more legit?

Mainly made for HTTPS on web servers. There is a walk through on making it work with email, using links, and some other dark Unix magic (what not everyone is running a linux mail server?). I saw a file for exchange but that’s not my cup of tea. It also brings up that whole 90 days thing again. So for now my mail server has something else.

So while the SSL Cert is good for 90 days, they tell you to update it every 60. Can’t wait to try that in 2 months. (that was sarcasm).

To be honest though, I do like the idea of Let’s Encrypt. I like that it has Debian love and script to make magic happen in the background. Less fiddling under the hood. I like that you can set up either Secure only (all HTTPS all the time) or HTTP and HTTPS. This site used to use a self signed cert for Administration, but now it’s all SSL.

Hopefully in the future we can get at least 365 day certs, more services covered, and most importantly MORE PEOPLE ENCRYPTING their web traffic.

New and Improved WiFi Intrusion Detection System. Pi 2.

So my last post I was fighting the Raspberry Pi 2, with Kali Linux 2.0.1, when it came to starting kistmet_drone on boot. Ian had a work around, but it wasn’t what I wanted. I wanted the built in tools to do their job. Well it turns out it’s a SystemD problem. I spent probably about 12 hours bashing my head against it, making changes and trying things.

Finally, I got smart with my Google searching, and found a slightly better way, but still didn’t want to call an external shell script. Then I spent time smacking my head on the desk. SSHD works, and starts by systemd, why not look at it’s config. Seriously the better you are at something, the less you think of the simple answers that made you good to start with.

2 new lines. One made SystemD wait until after networking was up. The second was a strange sshd -D option. man ssh. Oh doesn’t run ssh as a daemon…

remove –daemonize from Kismet… It worked.



Now to get everything ready before I leave for GrrCon in 17 hours, I’ll be presenting Saturday last I heard.

More on moving WIDS to the Raspberry Pi 2.

So I’m using the Raspberry Pi 2 and Kali 2 for this project so far. As I said last time, I had to expand the image to use the full disk. I have a script for that now. I was actually trying to script the whole deployment. These scrips can be found on my WIDS github repository. But fair warning they are still a work in process.

Continue reading

Moving WIDs to Raspi2.

So I tried to do this back in July but got sick. My next talk is at A2Y.asm on Sept 12, and rebuilding all the Pi2 again with Kali 2.0.1. I have litteraly spent most of the day trying to expand the root directory.

There is a tool called rpi-wiggle, that sounded really cool, but it hasn’t been updated in 3 years. It also didn’t work for the pi2 running Kali 2.0.1. After lots of searching, I found a forum post saying talking about it.

After running apt-get install triggerhappy lau5.1 (from Kali repos) and getting the Debian raspi-config file from Debian. It says it worked. I’m waiting for the reboot to know for sure.

And it worked. from console it says it has full space.

Now if I was making anything other than a drone, I’d run apt-get install kali-linux-full to get the whole Kali experience instead of the light version. But I’m making a drone. So here is what needs to be worked on before I start making images:

  • install: Kismet, NTP.
  • boot to cli instead of gui
  • change the root password
  • configure kismet
  • Clone
  • configure static ip, and daemon mode.

normally I’d disable ipv6, still might. but the ipv4 and ipv6 stacks are working well together right now. In the past they haven’t.

Yet more with Fail2Ban

So yesterday, I thought I was all good on Fail2Ban today’s logcheck emails show there were still problems with Dovecot.

Continue reading

More Fail2Ban fun with Debian Stretch

Yesterday, going through email yesterday, mostly logcheck emails, I found that Apache wasn’t blocking the attackers. It was seeing them, but not adding the ip address to iptables block list.

The fix was setting up the maxretry it was set rather high, I moved it down to 1 like I had it in the past. I also adjusted the search time to 1 hour and the ban time to 7 days. I thought I was good, and didn’t give it a second thought.

Today, looking at the logcheck emails (really it’s a great IDS for system admins to get a view into their box), there are a lot of automated attacks on the mail server NOT BEING BLOCKED!!! It worked yesterday, there were even banned ip addresses in the chain.

After lots of digging, and several changes that didn’t work, I decided to go for the bad option.

Really the real reason was that Fail2Ban had been around for a while. Things changed, and I had a weird mishmash of configuration files. After the install I removed the files in the package that were not debian related, not sure why bsd; osx; or fedora are in the Debian package to start with.

Followed the local customization file directions creating jail.d/server-defaults.conf with apache-auth and dovecot in them. ssh is handled by defaults-debian.conf. Why the new file, in case the Debian one gets over-written by new stuff later.

Restart the service and…

Still not working for dovecot.!? (tailing the log and watching iptables).

Turns out, it’s where Fail2Ban was set for default to watch for login errors for Dovecot (also noted through the logs). It’s looking in /var/log/mail.warn. I don’t know if I changed it, or it’s legacy left over, or what, but my box it’s /var/log/auth.log where Dovecot login failures go. So I added the logpath to jail.d/server-defaults.conf, restarted Fail2Ban and it worked.