For the past few months, I’ve been running a handful of SSH Honeypots on some cloud providers, including Google Cloud, DigitalOcean, and NameCheap. As opposed to more complicated honeypots looking at attacker behavior, I decided to do something simple and was only interested in where they were coming from, what tools might be in use, and what credentials they are attempting to use to authenticate. My dataset includes 929,554 attempted logins over a period of a little more than 3 months.

If you’re looking for a big surprise, I’ll go ahead and let you down easy: my analysis hasn’t located any new botnets or clusters of attackers. But it’s been a fascinating project nonetheless.

The first thing you'll notice about the Wio Terminal is it's 2.4" LCD screen, but under the hood, it's powered by an Atmel SAMD51 Microcontoller (120 MHz ARM Cortex M4F) paired with a Realtek RTL8720DN for WiFi and BLE. It has a 5 way switch, multiple buttons, and a Micro-SD card slot. Embedded peripherals include an accelerometer, microphone, speaker, and light sensor. I/O is available via a Raspberry Pi compatible 40 pin header, 2 Grove interfaces, and USB type C.

I can already hear some readers saying that backups are an IT problem, and not a security problem. The reality, of course, is that they’re both. Information security is commonly thought of in terms of the CIA Triad – that is, Confidentiality, Integrity, and Availability, and it’s important to remember those concepts when dealing with backups.

We need look no farther than the troubles Garmin is having in dealing with a ransomware attack to find evidence that backups are critical. It’s unclear whether Garmin lacked adequate backups, had their backups ransomware’d, or is struggling to restore from backups. (It’s possible that they never considered an issue of this scale and simply aren’t resourced to restore this quickly, but given that the outage remains a complete outage after 4 days, I’d bet on one of those 3 conditions.)

Sometimes, especially in the time of COVID-19, you can’t go onsite for a penetration test. Or maybe you can only get in briefly on a physical test, and want to leave behind a dropbox (literally, a box that can be “dropped” in place and let the tester leave, no relation to the file-sharing company by the same name) that you can remotely connect to. Of course, it could also be part of the desired test itself if incident response testing is in-scope – can they find your malicious device?

In all of these cases, one great option is a small single-board computer, the best known of which is the Raspberry Pi. It’s inexpensive, compact, easy to come by, and very flexible. It may not be perfect in every case, but it gets the job done in a lot of cases.

I’ll use this opportunity to discuss the setups I’ve done in the past and the things I would change when doing it again or alternatives I considered. I hope some will find this useful. Some familiarity with the Linux command line is assumed.

I thought about using a clickbait title like “Is this the best web security book?”, but I just couldn’t do that to you all. Instead, I want to compare and contrast 3 books, all of which I consider great books about web security. I won’t declare any single book “the best” because that’s too subjective. Best depends on where you’re coming from and what you’re trying to achieve.

The 3 books I’m taking a look at are:

• Real-World Bug Hunting: A Field Guide to Web Hacking
• The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws
• The Tangled Web: A Guide to Securing Modern Web Applications