Josh Wieder

Did you have a PayPal account between April 2006 and November 2015? During that time, did PayPal ever place a hold or reserve on your account? Did PayPal suspend or cancel your account? Than this post is good news for you. Zepeda v. PayPal (Case No. 10-CV-02500), a class action lawsuit that has been working its way through the United States District Court for the Northern District of California, appears to have been resolved with PayPal offering to pay a cash settlement to PayPal account holders whose assets were essentially seized by PayPal. PayPal is an enormous company with millions of customers and a lengthy track record of having sticky fingers when it comes to transactions that violate PayPal's nebulous and ever-changing terms of service - this settlement will almost certainly be enormous, as well. In addition to essentially stealing from their own customers, the Zepeda suit brought to light evidence that PayPal has violated several rules of the Electronic Fund Transfer Act...

As part of my consulting business I have a number of web servers I take care of. This morning, I woke up to receive a particularly crappy message related to one of those servers: possible DoS attack Awesome, right? Ever notice how you never get these sorts of messages between the hours of 9 AM and 5 PM, Monday through Friday? So I tried to SSH into the target server, and was pleased to find I was able to connect. Relieved that this was likely a false alarm, I found this in the Apache logs: 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 200 146 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 200 146 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 200 146 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 403 5 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500] "GET /robots.txt HTTP/1.1" 403 5 40.77.167.20 - - [19/Jan/2016:19:43:15 -0500...

I've written a simple bash script that checks for new files in an AWS S3 bucket and emails any that it finds as a compress (tar.gz) attachment  - you can find it at my Github account under the name "S3-Filer-Mailer". I built it as a supplement for a contact form that relies on S3 as a back-end, rather than a php mailer or database. Using S3 for contact forms is attractive because it is so unattractive to spammers. There is no way to corrupt this sort of setup for spamming or to get hands on a database through the form, because it isn't connected to one. Why not use Amazon's Simple Notification Service (SNS) ? For one, AWS charges more for SNS than it does for S3 queries and downloads. For another, if this sort of functionality is available through SNS it is not clearly documented. Getting back to the topic of security, the script establishes two network connections - one a connection to S3 to retrieve the files, the other sending the email. The S3 connection ...

I have used ClamAV and Spamassassin for many years. I've had a less experience with Amavis (now amavisd-new), but I've decided to give it a try with a new mail server deployment I've been working on. As a reference for my install, I relied on the documentation provided by Amavis for integration with Postfix  as well as a somewhat-outdated but still-relevant walkthrough published by CentOS . Prior to integration with amavisd, Postfix worked fine. Similarly, I had no issues with Spamassassin on its own. But once I finished my install of amavisd-new, things quickly went wrong. Attempting to send messages to accounts hosted on my email server resulted in the following chaing of errors in my maillog: Jan 13 18:17:34 hostname amavis[31578]: Net::Server: 2016/01/13-18:17:34 CONNECT TCP Peer: "[192.168.1.1]:40209" Local: "[127.0.0.1]:10024" Jan 13 18:17:34 hostname amavis[31578]: loaded base policy bank Jan 13 18:17:34 hostname amavis[31578]: lookup_ip_...

So it turns out that setting your AWS EC2 server's hostname to be persistent across reboots is a surprising pain in the ass, at least with my usual OS of choice - RedHat/CentOS Linux. If you're like me, setting a hostname is the sort of trivial non-task that at this point you really feel like you dont need to RTFM  to figure out. You know about `hostnamectl set-hostname`. You've tried `nmcli general hostname`. You've manually set /etc/hostname. None of its persists past a reboot. Which can make life very difficult for those planning to use EC2 for email or dozens of other tasks. Here's how to do it the right way, the first time. I'll also describe some circumstances that setting your own hostname will break things, and why its such a hassle to get this done in AWS in the first place. Amazon relies on cloud-init to manage a variety of initialization tasks for its cloud servers; cloud-init was originally built to support Ubuntu images , but it is now used fo...