It’s a good idea if you have a domain – and you have access to your DNS server, that you setup and use (properly) SPF records. SPF = Sender Policy Framework. This is an an e-mail validation system designed to prevent e-mail spam by addressing a common vulnerability, source address spoofing. Here at Amixa, we use SPF records on all of our domains that send email, just to add another layer of anti-spam protection for our clients.
In recent weeks we’ve noticed a sharp increase in spoofed “from” email addresses attached to bulk email sent by spammers. The “Amixa Sales” email address has been spoofed by some senders and any receipient’s ISP that uses SPF lookups, are properly rejecting the spam messages because the email messages do not originate from our email server. I am sure other people are getting spam emails using our forged email address, but that is just the way things happen on the internet. Some people are good, and others aren’t!
For more reading, learn about SPF here
To check your SPF records after you have them in place, click here
Chances are if you are reading this you’ve failed a “Trustkeeper Scan” – with “Low severity” – due to having weak SSL encryption algorithms enabled on IIS.
It’s pretty easy to solve this, but if you read the microsoft KB article it looks pretty complicated.
Launch regedit and go to this key:
You basically want to disable everything that has less than 128 bit encryption. On one of my servers, the ones with red arrows below need to be disabled:
CLICK FOR LARGER IMAGE
So on each one of these, you want to “Right click”, add a DWORD, name it “Enabled” and set the Hex value to 00000000 (eight zeros).
Repeat for each one that has less than 128 bit length, and then restart your server.
You probably also need to reschedule a security scan so that your changes can be verified, and as always, please double check your SSL protected site with at least two different web browsers and make sure you can get into SSL mode with them both on your site.
If you have undergone a “Trustkeeper Scan” and failed due to your Microsoft web server using SSLv2, then read on.
NOTE: PLEASE READ THIS POST IN OUR BLOG HERE. It is TWO YEARS NEWER and simplifies most of the tasks regarding SSL settings.
SSLv2 is considered a “medium” security risk and will cause your scan to FAIL, so therefore to be PCI-DSS compliant (for credit card companies), you need to disable it via the registry on your Windows server running IIS 3 or later.
The easiest way to do this is to read this KB article from Microsoft.
In a nutshell, you need to go to this registry key
Then locate the SSL 2.0 key
- Click on the “Server” node.
- On the Edit menu, click Add Value.
- In the Data Type list, click DWORD.
- In the Value Name box, type Enabled, and then click OK. Note: If this value is present, just double-click the value to edit its current value.
- Type 00000000 in Binary Editor to set the value of the new key equal to “0”.
- Click OK. Restart the computer
- if applicable, reschedule the security scan
If you are trying to process a transaction against the “live” Chase Paymentech payment gateway and get the following response code back:
9717 Security Information – agent/chain/merchant is missing
the problem is that the IP address being used by your server, is not in the merchant approved IP address list with Chase Paymentech.
You, or the approved merchant contact will need to call Chase Paymentech Gateway support at 1-866-645-1314 and have them update their firewall. Once you have done this, wait 60-70 minutes then re-test your transaction. Should work like a charm.
Welcome to the Amixa blog – our new way of keeping you in the loop with what we are doing, things we discover and other geeky cool things.