Cloudflare and Dome9 Blacklister Scripts (Bash/Python)
One of my servers was under attack from an IP in China recently (some lame automated SQLi), but I figured I’d blackhole the source IP anyway.
My first step was to blacklist in Dome9, which I use to manage that server’s firewall, but after noticing that the attacks were still hitting my server I remembered that because I also use Cloudflare and those attacks were getting tunnelled through their network. So the solution (for that particular attack) was to also blacklist the source IP in Cloudflare. When another stupid attack came in a day or so later, I did the same and realised that it would be much easier if I automated the whole process.
So I threw together a Bash script (and then a Python script) that leverages the Cloudflare and Dome9 APIs to submit a given IP address to one or both services.
I’ve put these into my scripts repo on GitHub. Simply insert your Cloudflare and/or Dome9 API keys into the configuration portion of the script and go. Using this you could conceivably fully automate it by auto-detecting brute-force type attacks using a script on the server and calling this script to make the blacklist updates.
Bearing in mind these were very hastily put together, any feedback/improvements are welcome!
Dome9 Package for Synology NAS
I own a Synology DS413j NAS, and without wanting to write a whole review about it, these things are awesome, the management UI is great, and you can run all kinds of packages on them. One thing I like to do with mine is run an OpenVPN server so that I can VPN into home and do cool stuff.
But I was a bit concerned about the notion of having my NAS internet-facing, even if it was only OpenVPN’s UDP port. So, powering through with my love for all things Dome9 (I swear they don’t pay me), I wrote my own little package that installs the Dome9 Agent onto a Synology NAS and allows you to control its firewall (and make dynamic access requests) through the Dome9 service. Now I can make pretty much any of my NAS’ services available to the internet, and not have to worry about random attackers discovering those services. Similar to Single Packet Authorization (although easier to set up and use), Dome9 allows you to dynamically open one or more ports to a given IP for a period of time, and so while the port is available to you, the services remain completely invisible to everyone else.
This is the first release of the Dome9 package, and while it may need more work to support other VPN protocols, it’s ready for testing. If you do use this package, I’d be keen to hear from you, as I’ve yet to find another Synology-owning Dome9 user!
To install this package, simply download the dome9.spk file (below) and use the Manual Install option in the Package Center in DSM. You will need to have a Dome9 account and enter your pairing key to allow the agent to pair with the Dome9 service.
Honeyport Python Script with Local Firewall and Dome9 Support
Following on from my linux bash honeyport script (read this first if you don’t know what a Honeyport is), I wanted to write a script that works across platforms to accept connections on a given port and block that IP using the local firewall – IPFW on Mac OS X, iptables on Linux, or Windows Firewall – or using the Dome9 service (I’m hoping to add Unix support soon).
I chose to write this one in Python as the cross-platform language of choice, and it’s compatible with Python 2.7 to 3.4. One feature of this script is that you can optionally configure it to run another Python script whenever a client connects to the honeyport. The client’s IP will be passed to the called script as an argument, allowing you to do whatever you want with it. The script’s output is then sent back to the connected client before they are blacklisted.
Check it out on GitHub, improvements and additional ideas are welcome!
Honeyport Script Dome9 Blacklist TTL Update
Dome9 just introduced the ability to set a time-to-live (TTL) option for blacklisted IPs, something I may have bugged them for about once or twice! This is nice as it allows items on your blacklist to expire after a pre-determined amount of time instead of living on in perpetuity. It’s particularly beneficial when you run something like my Honeyport that can end up blacklisting over 400 unique IPs in about two months — it saves having to go in and manually remove blacklisted IPs periodically.
I’ve updated my Honeyport script to include the option to set a TTL on blacklisted IPs when using Dome9. Note this doesn’t yet work when using IPtables as it doesn’t have an easy TTL-style option for rules. This functionality for IPtables is on my TODO list.
Check out honeyport-0.2.sh here!
Linux Bash Ncat Honeyport Script with IPTables and Dome9 Support
After securing systems by hiding them completely from the network/internet using Single Packet Authorization, I’ve recently been interested in doing more so-called ‘active’ defense, by implementing solutions to delay, confuse, or thwart attackers. Completely hiding one’s system is not always feasible (ie. in the case of an internet-facing server), and monitoring, apart from being purely reactive, is not always easy and requires the involvement of a human. An alternative to these is to do some automated active defense. One simple tool in the bag of active defense tricks is the honeyport. Read more
Pwn Plug Command Execution Using USB Sticks
This is something I’ve been meaning to do for a while, and whilst the title may not sound all that intuitive, it’s actually referring to something pretty simple. When I got my Pwnie Express Pwn Plugs, there were several times when I wished I could run commands on them when I couldn’t connect to them over SSH, for example when I couldn’t remember the last static IP I’d set. Yes, I could use the serial connection, but somehow that didn’t fully appeal to me.
So I came up with the idea of being able to use a USB stick to carry a command ‘payload’ that would get automatically executed upon being plugged into the Pwn Plug. Now I can run commands such as ifconfig, kick off an nmap scan, whatever I need; and all the results are output back onto the USB stick.
Note that I chose to do this on my Pwn Plug, but it should work equally well on other embedded devices such as the MiniPwner with a bit of tweaking.
Reverse SSH over Tor on the Pwnie Express
The Pwnie Express (PwnPlug) is a great little tool for hackers, pentesters and social engineers alike. While I don’t advocate the use of a Pwnie for illicit purposes, I was intrigued about using it as an untraceable tap into a network. Out of the box the Pwnie allows you to configure reverse SSH connections, exfiltrated over a number of different protocols including HTTP, SSL, ICMP and DNS.
While these are great for getting out of controlled networks, they all require the Pwnie to be configured with the IP address of your SSH server, which could potentially be traced back to you. It also requires your SSH server to be able to directly receive connections at the IP/hostname configured on the Pwnie. While one could run an SSH server on a proxy box somewhere, I felt that was too primitive, so I installed Tor on my Pwnie and configured a Tor Hidden Service on my SSH server.
Note: For the purposes of this tutorial, the SSH server will be running on BackTrack 5. I’m assuming you’ve already performed the initial Pwnie Express setup steps on the server! Check out my PwnieScripts to help speed up and automate the Pwnie setup.
These instructions do not yet work on Pwn Plug software >= 1.1 as they’ve changed the layout of things! Will update this post when I get the time.
PwnieScripts for Pwnie Express
The Pwnie Express (PwnPlug) is a purpose-built penetration testing device in a plug form factor. A key feature is its ability to exfiltrate from a network and connect back to your SSH server using HTTP, SSL, ICMP or DNS tunnels. Check out my tutorial on how to hack your Pwnie to make untraceable reverse SSH connections over Tor.
There are a number of steps required to set up the computer on which the Pwnie’s reverse SSH connections will be received (setting up the listeners). To simplify and automate this process, I’ve put them together into a set of very simple bash scripts. I’m hoping to turn two of these into a proper init.d script, but haven’t yet had the time. The PwnieScripts set contains the following five bash scripts, and are designed to be used on BackTrack 5 (although they can easily be adapted to work on any other distro):
- pwnsetup.sh: Automates the Pwnie Express setup process by enabling SSHD, generating SSH keys, creating a ‘pwnplug’ user, installing HTTPTunnel, generating an SSL certificate, configuring stunnel, and configuring DNS2TCP.
- pwnstart.sh: Kills any existing listeners, and then starts SSHD as well as new HTTPTunnel, stunnel (SSL tunnel), DNS2TCP (DNS tunnel) and ptunnel (ICMP tunnel) listeners.
- pwnwatch.sh: One-line script to monitor netstat for incoming connections from Pwnie Express.
- pwnconnect.sh: aka. the Lazy Script – initiates an SSH connection to the first available established connection from Pwnie Express, so you don’t have to check which ones are active. It’ll use the more secure/relible ones first (SSL, HTTP) where available. Use the -t flag to only connect over Tor.
- pwnstop.sh: Kills all existing HTTPTunnel, stunnel, DNS2TCP and ptunnel listener processses.
Download PwnieScripts (tgz 4kb)
Any feedback or tweaks are welcome. Leave a comment below, send me an email, or message me on Twitter.
[Changelog]
v0.1: Initial release.
Kernel.org Compromised, OpenSSH Source Not Backdoored
Kernel.org, the primary site for the Linux kernel source, was compromised sometime in August. It is believed that the attackers gained access using compromised user credentials, and then escalated their privileges to root. Early pieces of information implied that some OpenSSH source code was stored on the compromised Kernel.org server(s), apparently this may not be the case. So far the investigation has found that several modifications were made to the compiled OpenSSH client and server binaries running on the system to log user activity. The full extent of the changes is not yet known, and nobody has yet come forward to claim this hack.
If you’ve installed or updated your kernel or OpenSSH recently, you may want to reinstall from a known good version, although it is not yet known if any kernel sources were modified. Although in this case OpenSSH wasn’t compromised, admins can consider running some form of Single Packet Authorization, such as fwknop, as an additional layer of protection for your SSH server against these kinds of issues (backdoors) and other potential future 0days.
Hopefully more info will come to light as the investigation progresses. Hit the jump for more details.
Fwknop in BackTrack 5 Repository
Just a quick update to say that fwknop (Single Packet Authorization tool) has made it into the BackTrack 5 repository. Although it’s not installed by default, it’s a few keystrokes away, and can be installed by typing the following into the terminal:
apt-get install fwknop-client
apt-get install fwknop-server (if you want to use the server on your BackTrack install)
Note that it’s still version 1.9.12 of the Perl implementation, as the the C++ port (v 2.0) is still in the Release Candidate stage. Those of you who have been meaning to experiment with Single Packet Authorization and have already downloaded BT5, now’s a good time to install fwknop and give it a try! When installing fwknop-server it brings up an ultra-simple config screen that allows you to set up your initial passphrase.
Read more
Loading ...
