Skip to main content

Posts

PuTTY hack keeps SSH session data out of Windows registry

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

SmartDraw installs adware as part of demo program

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

Paypal Presents Payment to Placate Piqued Purchasers; Persists in Peeking into Pockets of Patrons

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

Microsoft search indexing can be so aggressive that it resembles DoS traffic

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

Bash script to email new S3 bucket files as compressed attachments (UDPATED)

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

Email server using amavisd-new fails with (!)DENIED ACCESS from IP 1.2.3.4, policy bank ''

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_

Setting a hostname for your Amazon AWS EC2 server running RHEL or CentOS 7

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