Josh Wieder

So you've screwed something up. You made a typo in your sshd_config file. You added a firewall rule, or a route, or some other thing, and lost your network access to your EC2 instance. And of course whatever you broke, you broke permanently - you wrote your firewall rules directly to /etc/sysconfig/iptables, you made your goofy change to /etc/sysconfig/network-scripts/whatever-interface; so rebooting won't make a damn bit of difference. You read the warnings, you know you shouldn't have. But you did anyway. Oh, and you don't have any backups. Or you have backups from three months ago. Restoring from your crappy backups would mean hours to days of non-stop work and consistent downtime. Or Amazon or whatever other company you're using for backups actually broke your backups/lost your backups/never actually provided you with the backups you paid for. Don't panic. You've got this . You remember that Amazon has some sort of Java-based something or other. Its

A lot of people connect to Linux machines from a Windows desktop computer. Despite the number of people that have to do this for one reason or another, there are hardly any SSH clients for Windows. Basically there's three - Bitvise , Dameware and PuTTY . I've almost always used PuTTY. There are problems with all of these clients, including PuTTY. One of the smaller issues with PuTTY that I've nonetheless always found annoying is that it is not quite as portable as it appears to be. Installing the client is usually as simple as downloading and running the EXE file, but vital information about saved sessions as well as seed data gets stored in the Windows registry, where it can be forgotten about. Or where someone else can grab it. That's not really the fault of the developer; if I was making PuTTY today I doubt I would do anything differently. Its a garbage collection thing. The problem is that PuTTY information can be valuable to attackers. Just about everyone who

When I'm not writing about computers for free on the internet, I actually work with computers (for money). Most of what I do involves doing stuff with computers directly, but sometimes I have to talk to people before I can start with the computer-stuff. That can involve convincing people that my colleagues and I actually know what we are doing or planning projects with other people. With both of these tasks I've found that drawing pictures can be very helpful. These are special types of pictures - called work flows or network typologies. Here's a really basic example: Tree Topology, by  Tsingha02 The idea is taking some very complicated ideas about the relationships between computers and applications and putting them into very basic visual representations. Particularly for projects involving large numbers of servers, this sort of visualization is critical to understand what is going on. Despite how critical this sort of thing is to working with computers, there is

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_