]]>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!

]]>https://www.securitygeneration.com/security/cloudflare-and-dome9-blacklister-scripts-bashpython/feed/04958Curated List of Penetration Testing Reportshttps://www.securitygeneration.com/security/curated-list-of-penetration-testing-reports/
https://www.securitygeneration.com/security/curated-list-of-penetration-testing-reports/#respondWed, 17 Aug 2016 09:01:23 +0000http://www.securitygeneration.com/?p=4944
No related posts.
]]>Julio Cesar Fort has started putting together a curated list of penetration testing reports from a variety of security consultancies. While the list is new, and not exhaustive yet, it’s on the right track and I look forward to seeing it grow. It’s always interesting to see how different companies do their reporting, and there is a lot to be learned in these reports. If you’re a professional penetration tester, the layout, structure and formatting choices are probably more interesting than the actual content in this case.

]]>Earlier this month, Google and Firefox both dropped the Root Certificate of Chinese Certificate Authority CNNIC, after it was discovered that it had delegated its authority to an Egyptian intermediary to allow it to fraudulently sign SSL/TLS certificates for the google.com domain (presumably for the purposes of performing man-in-the-middle attacks and snooping on Egyptian internet traffic).

Apple, despite releasing Mac OS X 10.10.3 and iOS 8.3, has yet to remove this rogue CA. I hope that Apple joins in and revokes the CNNIC in an upcoming update, but in the meantime you can remove it from OS X yourself!

Simply run the following command in the Terminal and *poof*, another unnecessary and untrusted CA bites the dust:

It’s worth pointing out that a deleted Root CA cert may re-appear in a subsequent system update (I will check when 10.10.4 comes out). The alternative to this, which can only be achieved using Keychain Access (I believe), is to tell OS X to never trust a given Root CA certificate – a setting that shouldn’t be undone by future updates. To do this:

Open Keychain Access

Click on ‘System Roots’ on the left

Right-click on the Root CA you don’t trust (ie. CNNIC ROOT) and select Get Info

Expand the ‘Trust’ section

Select ‘Never Trust’ from the “When using this certificate” dropdown

Close the panel (OS X will probably ask for your password to authenticate the change)

You should then see a red X icon next to the untrusted cert.

I personally think that our operating systems and browsers already trust far too many Root CAs, many of which are unnecessary, others are potentially malicious. OS X by default trusts around 204 Root CAs. I’m planning on cutting this down to a short list of CAs that are both (a) trusted and (b) necessary for normal day-to-day use of the Internet. I’ll report back on that when I get time.

Unfortunately, there is no mechanism in iOS to remove certificates from the Root CA store. The list of current trusted Root CAs in iOS can be found here.

]]>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.

]]>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!

]]>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.

]]>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.

A honeyport is essentially a simpler version of a honeypot. Whereas honeypots aim to simulate an application or protocol for the attacker to play around with, all the honeyport looks for is a connection from an external party, after which a specific action is performed (usually blacklisting them). Although hosts on the internet are regularly port scanned and connected to by automated attacks, it is usually only targeted attackers who will connect to more unusual ports in order to determine what services are running on them. More often than not, it is these targeted attackers you’ll want to repel.

The script below is a fairly simple Linux Bash honeyport script that uses Ncat to listen on a given port, and then blocks the IP of anyone who connects to it. It can block the attacker using Linux’s internal IPtables firewall, or it can add the IP to your Dome9 Dynamic Firewall Blacklist if you use that service (free for one server). The benefit of the Dome9 solution is that any IP that gets blacklisted on one system is automatically and instantly blacklisted across all of your Dome9-enabled servers. The script also has a whitelist so you can prevent certain IPs from getting blocked. Also, I chose Ncat over Netcat as it’s more extensible and could allow you to do more interesting things with your Honeyport. In this case when someone connects the script will execute ‘response.sh’.

I threw this script together fairly quickly, so it’s still a work in progress, but I’m open to suggestions and improvements!

]]>https://www.securitygeneration.com/security/linux-bash-ncat-honeyport-script-with-iptables-and-dome9-support/feed/24257The pending apocalypse? Maybe more fact than fictionhttps://www.securitygeneration.com/general/the-pending-apocalypse-maybe-more-fact-than-fiction/
https://www.securitygeneration.com/general/the-pending-apocalypse-maybe-more-fact-than-fiction/#respondTue, 20 Aug 2013 19:09:04 +0000http://www.securitygeneration.com/?p=4268
No related posts.
]]>Forget for a moment that the following video is a trailer for an upcoming Tom Clancy game, because it’s beautifully done and highlights a real danger that our world faces as we rely more and more of increasingly fragile systems and infrastructure. I think the things depicted in the video are a far bigger threat than things like terrorism, yet are hardly addressed today.

For those of you actually interested in the game, this gameplay trailer looks pretty cool.

]]>A new version of iOS, a new lockscreen/passcode bypass! Luckily this one was caught early in the first Beta of iOS 7 released to developers at WWDC 2013. Although this lockscreen bypass is simpler than some of the previous ones that required some tricky steps to pull off, it’s probably worth pointing out that it will only allow access to the phone’s photos, and the ability to delete, email, tweet or upload the stored image files. It does not allow access to any other apps.

I should point out that I played with iOS 7 for a day, and it was so buggy that I had to downgrade back to iOS 6. Luckily Apple has plenty of time to fix all these issues come the release date this fall.

To bypass the lockscreen simply follow these easy steps:

Pull up the Control Center

Tap the Calculator icon to open it

Pull up the Control Center again

Tap the Camera icon to open it

Tap the photos icon in the bottom-left corner to get full access to the photos

]]>Those of you who have been diligent in securing your iOS devices with passcodes, wiping and Find My iPhone, just to have a thief restore your device and keep on going – well – your prayers have been answered. Coming in iOS 7 is a great feature called ‘Activation Lock’.

With Activation Lock enabled, even if your iPhone or iPad is restored to its factory settings, the user will need to activate the device using the Apple ID of the previous user. Also, if the device was put into Lost Mode in Find My iPhone, the lock screen will continue to display the fact that it is lost until the device is activated.

This is a hugely useful feature that, if used properly, will make iPhones and iPads a significantly less attractive target to thieves, as the stolen devices would be rendered useless to them. It was nice to see Apple address one of the main concerns that users have been expressing about the bypass-ability of Find My iPhone. Check out Protecting and Recovering Your iPhone and iPad from Loss and Theft (will be updated soon with this new feature).