Archive

Archive for the ‘My tips and tricks’ Category

Being a good net citizen: SPF, DKIM and DMARC records

Spam and Phishing emails are some of the more visible scourges of the modern internet. No one enjoys opening up their mailbox and seeing junk clutter up the place, or seeing a mail that tempts you to enter credentials somewhere because it looks legitimate. The war against Spam and Phishing is an on-going battle, with many tools deployed to try and keep a user’s inbox clean.

If you own or manage a domain on the internet and that domain makes use of email, it’s only right to be a good net citizen and set up SPF, DKIM and DMARC records. Together those 3 make a 3 pronged fork that can be stabbed into the heart of junk mail, but they each do a slightly different thing. Let’s take a look at them:

SPF essentially denotes who is allowed to send mail for your domain. Anything that doesn’t match the details in the record is to be considered an attempt to spoof your domain and should ideally be rejected, provided the record is set up as such. If you have a small domain with simple records, SPF is incredibly easy to set up. It becomes harder if you are a giant corporation or have lots of mail being sent from third party bulk mailers, but even those use case scenarios can be brought into line so that you have a valid SPF record. If Microsoft, Google and others can do it, why can’t we?

DKIM is a little trickier. DKIM enabled servers sign outgoing mail with a digital signature and lets receiving servers validate the signature using the published key in the DKIM DNS record. This way, mail can be verified as having been sent from domain abcdefg.com because the signature can be verified by consulting the DKIM record in abcdefg.com’s domain. If the validation fails it’s either because the mail was forged or the message modified on route. Since spammers aren’t running your mail server, they can’t validly sign outgoing messages with your private key, so when a destination server checks the signature, the check will fail.

DMARC sits on top of SPF and DKIM. While SPF contains syntax for what to do when mail fails a check, DKIM does not. DMARC essentially tells a recipient mail server what do with those mail if they fail the SPF/DKIM checks. Mail can either be allowed through to be processed as the destination sees fit, sent to the Spam/Junk folder or rejected outright. Set to reject mode and along with an –all syntax in SPF, this will ensure that spammers cannot spoof mail from your domain (in theory)

It’s not perfect though. In order for the 3 records to be effective, the destination mail server needs to check the records. If the server doesn’t and simply accepts mail as is, junk mail will make it into the inbox from forged senders. The records also don’t help if a spammer compromises a legitimate account in a domain with all 3 records, as when the mail is sent out via that domain, it will pass all checks on the destination end, as it was sent from a domain with valid records. To prevent this, you’ll need to set up rules to detect outgoing spam and block it from being sent. Each mail server will have different instructions on how to do this.

Office 365 and G-Suite all include records for SPF, while DKIM takes a few more steps to set up in Office 365. G-Suite also supports DKIM as far as I know, but since I don’t use the product, I don’t know how hard or easy it is to set up.

While nothing is ever perfect in the war against spammers, a huge amount of junk mail could be stopped cold if more domains published valid SPF, DKIM and DMARC records. Banks and financial institutes that are a favourite target of fraudsters could save themselves a lot of grief by having destination domains reject all mail that isn’t legit. IP block lists and content filtering will remain an important part of the game, but if more junk mail could be stopped at the edge before being accepted and processed, the better off the entire internet will become.

Advertisements
Categories: Internet, My tips and tricks Tags: , ,

Sage Pastel Xpress/Partner V12 and 64 bit Outlook

The Sage Pastel Xpress and Partner products pretty much rule the South African landscape for accounting packages. Almost everywhere you go, you’ll find some Pastel product keeping the books up to date. Our school is no exception, running Partner for the 3 ladies in our accounts department.

With my recent move to Office 365 for mail, I installed Office 2016 64 bit edition on the PC of the debtors clerk to access her mail in Outlook. No problem there, everything worked as it should. However, a few days later she called me back as she was unable to send statements out of Pastel Partner, as the PC now through up an error message when Partner tried to invoke Outlook. This wasn’t a problem in the past, as we’ve only ever used the 32 bit editions of Office. Office 2016 is the first time we’ve installed the 64 bit edition of Office.

It turns out that out of the box, Partner V12 can’t interface with Outlook 64 bit. I don’t have a 32 bit edition of Office 2016 at work, so I needed to get the functionality restored. Luckily, a bit of internet searching revealed the answer: use a replacement DLL file on the Partner installation disk. The process is as follows:

  • Close Partner and Outlook.
  • Copy the NewMail.dll file from the Pastel disk\Utils\Outlook 64-bit folder to C:\Program Files (x86)\Common Files\Softline Pastel. Overwrite the existing file.
  • Run the Component Setup utility in the Pastel folder in the Start menu. This will briefly re-register files, including the replaced DLL file.
  • Try to mail any statement from inside Partner, it should now invoke Outlook correctly.

I checked a Partner V11 disk and this didn’t contain the DLL file, so I assume it only started being introduced with V12. It’s possible that using the DLL file from the V12 disk would work with previous Partner versions going back a while, but I don’t know how compatible or reliable it will be. I have yet to test Partner V14 or V17 to see if they are compatible out the box or will also need the DLL file replaced. Since V14 and V17 were digital downloads with no extra folders, it’s going to prove interesting when I migrate the accounts department.

Ddrescue to the rescue

September 20, 2014 Leave a comment

A few weeks back, thanks to the blue screen caused by Microsoft’s batch of faulty updates, I formatted a teacher’s class computer and redid it from scratch – this was before I managed to find the work around to fix the blue screen issues. The computer was running fine since then, until this past week. The teacher started complaining bitterly about how slow the PC had become. I checked for malware, as well as for any other crappy software that may have been causing the slow down. I found nothing. I asked the teacher to monitor the PC, while I investigated further.

A few days later, the teacher was even more frustrated with the machine. Now it was taking forever to start up, shut down and was hanging on applications. I looked through Event Viewer, only to discover ATAPI errors were being logged. Not just one either, there were dozens of errors. The moment I saw this, I knew that the hard drive was on the way out. While the SATA port could be faulty or even the cable, the odds of those being the culprits were rather low. Too many bad experiences in the past have taught me that it is almost always the drive at fault.

I procured a spare drive and decided the quickest fix was to simply clone one drive to the other. Using Clonezilla I tried to do the clone. On my first pass, about 75% of the way through the PC looked like it went to sleep and I couldn’t see any output on the monitor. I couldn’t revive the PC, so I rebooted and tried the procedure again. This time, it got up to about 97.5% before it crashed out. Based on what I saw, Clonezilla was hitting bad sectors, corrupt files or the mechanical weakness in the drive. Now I was getting worried, because any more cloning attempts could hasten the end of the faulty drive. Not only that, it was wasting time. Setting up the PC from scratch again was my last resort, since it would take hours. Before I gave up and did that, I remembered Ddrescue.

I had tried to use Ddrescue on my home computer more than a year ago when the hard drive holding my Windows 8 install died. Sadly, that drive was too damaged even for Ddrescue to be able to save. I was hoping that this hard drive of the teacher hadn’t yet hit that stage.

I ran Ddrescue and then waited as the drive literally copied itself sector by sector over to the new drive. What I wasn’t aware of is that Ddrescue doesn’t understand file systems – it just copies raw data from one drive to another. This means it will copy any file system, but in order to do so, it must copy every block on the disk. A tool like Clonezilla will understand a file system and only copy used data blocks, therefore saving lots of time by not copying essentially blank space.

Ddrescue did hit one patch of bad data, but was able to continue going, then came back at the end to try and pull out what it could. Thankfully, whatever bad data there was wasn’t too major, and Ddrescue completed successfully. Booting from the new drive was a success, and best of all, the speed was back again. I did run a sfc /scannow at the command prompt to check for any potential corrupt system files. SFC did say it fixed some errors, and I rebooted. Apart from that, it looks like I managed to save this system in the nick of time. The old hard drive was still under warranty, and has been returned to the supplier. He can return that drive and get a replacement for us, which will become a new hot spare for some other classroom.

When Windows Update goes wrong

Windows Update is usually a very reliable method of keeping Windows based computers up to date. Rough in the early days, it’s come a long way since then. Smooth and mostly transparent in the background, it isn’t often that bad updates slip through.

Unfortunately, during after August’s Patch Tuesday, such an event occurred. After a number of updates were either automatically approved or approved by myself, we had some computers blue screen and go into a reboot loop. Thankfully, out of almost 180 computers, only 5 have suffered the problem seen below:

WP_20140814_001

All of the affected computers were running Windows 7 x64 SP1 with all updates applied. The first 3 times this happened, I couldn’t find a cure for the problem and ended up wiping and redoing the computer from scratch. Later in the week, I found some instructions online on how to get out of the loop and get back into working order.

  1. Get into the Recovery Console either from install media or by letting the Repair your Computer wizard run after a number of crashes.
  2. Open up a Command Prompt and delete the FNTCACHE.DAT file located in C:\Windows\System32
  3. Reboot the computer, and you should now be able to get back into Windows.
  4. Delete the FNTCACHE.DAT file again, as it will have been recreated by Windows.
  5. Lastly, go to Windows Update in the Control Panel, then view Installed Updates. Remove KB2982791 and optionally KB2970228. The other 2 updates mentioned out there on the web only apply to Windows 8.1/Server 2012 and so are irrelevant to Windows 7 computers.
  6. Reboot after the patches are removed.
  7. As I said, it’s not often anymore that bad updates slip through all of Microsoft’s testing, but it does happen. Although it’s frustrating, I don’t intend to modify how I approve patches. I’d rather take the risk of something like this happening than get hammered by Alureon or Conficker or some other nasty because I ignored security patches.

Fixing Windows Update issues

August 3, 2014 1 comment

About three weeks ago, I approved a number of updates to be downloaded into WSUS for distribution on the school network. Among those updates was an update for the Windows Update client itself. I watched the WSUS console as the computers started reporting back and after a while I began to notice an odd pattern. 36 out of 39 computers in our main computer lab were not reporting in.

Taking a look at one of the affected computers in the lab, the cause of the computer not reporting in became clear: Windows Update Agent 7.6.7600.320 was failing to install repeatedly. Since this new version was required to download and install updated from WSUS, the computers would not be able to patch themselves until this Agent issue was fixed.

I tried numerous approaches to get the issue fixed: Uninstall anti-virus software, try installing updates at shutdown instead of through Windows Update in the Control Panel, run the System Update Readiness checker tool, run System File Check from the command prompt. Nothing worked. I was on the verge of preparing to wipe the lab and reimage the computers when I came across the answer.

Thanks to some vigorous internet scouring, I came across this Knowledge Base article on Microsoft’s website: http://support.microsoft.com/kb/2887535. Thankfully, the latest update agent was available to download right there from the article. I downloaded the 64 bit version and attempted to install the update manually on my affected lab computer. After a required reboot, I had success. Windows Update connected again and proceeded to download the now missing 17 updates and installed them. With this proving to be the solution, I went to each computer and installed the new update agent by hand. One by one, these computers were cured of the issue.

One computer however refused to install the updated agent. Checking the CBS Log file found in C:\Windows\Logs\CBS revealed that it thought it needed to be rebooted before updates could be installed. However, rebooting did not solve the problem. I’ve had issues in the past with Server 2008 where it got stuck on updates and needed a certain XML file to be deleted before it would boot again. Going to the location of the XML file, I couldn’t find the usual XML file. I did however find a reboot.xml file, which I viewed. This file pointed to a registry key that I assume was supposed to be deleted after the last round of updates. Since the key wasn’t deleted, the computer still thought it needed to be restarted. Deleting this key and rebooting solved the issue – I could now install the updated agent and install updates again.

At this point in time, I’m still not exactly sure why this lab of computers failed to install the update agent while the rest of the school did so without much fuss. About the only thing I can think of is that it’s somehow related to how the lab was cloned which was somehow causing an issue. Reading through the CBS logs doesn’t shed much light on the issue, since I don’t fully understand everything that’s captured in those log files.

I suppose this serves as a good reminder that while WSUS and Windows Updates in general normally just work, sometimes things can go wrong.

Fixing Windows Update on Windows 7

Generally speaking, the Windows Update mechanism usually just works. Updates are downloaded and installed usually without much fuss. In the home environment, it’s pretty rare that things will go wrong, since computers at home are less likely to come under heavy use and abuse. Most of the time at work I have no issues with Windows Update, despite the pounding the computers take in the school environment.

Sometimes however Windows Update gets broken. Malware infection, powering a computer off during the update process and hard disk corruption are some of the most likely culprits. I’ve found myself fixing a few computers in the last week at work that have developed faulty update mechanisms.

To fix the problem, there’s two tools I’ve used. System File Check is built into Windows, while the System Update Readiness (SUR) tool can be downloaded from Microsoft’s website. The first port of call is to simply run sfc /scannow from an elevated command prompt and let it scan the system. I’ve found this to fix some problems, and it serves as a good stepping stone for step 2.

Step 2 involves running the SUR tool. The SUR tool looks like a stand alone Windows Update, though it is actually scanning your computer’s Component Base Store for corruption and either fixing the issues, or logging the issues it can’t fix into a very useful log file. Depending on the speed of your computer and the number of faults, the process could take up to 20 minutes to complete.

If the computer still refuses to install updates after step 2, it’s time to check the SUR log to find out exactly what is wrong. Navigate to C:\Windows\Logs\CBS\CheckSUR.log and find out exactly what files or packages are causing the problem.

In the case of the computers at work, all of them were missing certain manifest files out of the C:\Windows\WinSxS directory. To fix the issue, I copied the same manifest files from a working PC and placed them into the C:\Windows\Temp\CheckSur\WinSxS\Manifests folder and reran the SUR tool. Checking the log file after the tool had run indicated that all the remaining problems had been fixed. After that, the problematic updates installed without issue.

Research on the internet indicates that things can be a whole lot more corrupt that what I experienced, but thankfully I had it easy. There’s a nice long article on the SUR tool as well as how to analyse the logs on here.

Although it is frustrating to deal with Windows Update issues, the mechanism is largely robust enough that with a little time and effort, you can fix just about any problem. Certainly a far cry from Windows Update errors and troubleshooting in Windows XP!

Creating bootable USB drives using Rufus

With the seemingly slow decline of optical drives in computers, it’s becoming more and more common to install the OS via a bootable USB flash drive. I outlined a method of doing so using built in Windows tools way back in 2010. However, that method is little tedious and doesn’t make the flash drive capable of an UEFI based install, only legacy BIOS.

Enter a better way of doing things: Rufus.

Rufus

With an easy to use graphical interface, you can select all the options you’ll need to make a bootable flash drive. In particular, under “Partition scheme and target system type” you can select GPT as the partition type for an UEFI based install. At work, our brand new server doesn’t have a DVD drive, so this was the only way to install Windows Server onto the server in UEFI mode. No other tool could do that.

Make sure you have an ISO image of the disk you want to put onto the flash drive – Rufus doesn’t do a live capture from a physical disk unfortunately. You can even make a bootable MS-DOS based flash drive if you have the MS-DOS files, useful if you need to be able to flash an older computer’s BIOS or RAID card for example.

Add Rufus to the list of essential tools any administrator or technician should have in their toolkit.