I was listening to a recent Packet Pushers Priority Queue podcast called Meet ZeroTier – Open Source Networking and decided to give ZeroTier a go, to see if it really worked as described. TL;DR: Yes it really does work as described! If you’re unfamiliar with ZeroTier I highly recommend listening to this podcast to understand why, what and how. If you’re unsure on the why, what and how, this blog post
HonSSH is essentially an SSH proxy, acting like a Man-in-The-Middle attack. It sits between the attacker and a honeypot and proxies the SSH connections. By doing this it can log all interactions, spoof (rewrite) login passwords and even capture files downloaded by the attacker on to the honeypot for later analysis. Below is my topology: Configuring the Honeypot Server For the honeypot server (the server attackers will login to), I’m using Ubuntu 14.04
Up until a few moments ago, I was using CAcert for all my certificate needs. A free service offering SSL/TLS certificates. The only issue with CAcert is that their Root Certificate is not included in all mainstream Operating Systems or browsers, meaning users will get a certificate error unless they choose to install the Root Certificate. But now Let’s Encrypt is on the scene. A free, open and automated certificate authority that is
I was given an Acer Aspire One ZG5 (A110) and asked to try to update it. There were a few problems with it. Firstly, it was running Ubuntu 12.04 but the upgrade to Precise Pangolin had broken and wasn’t easily recoverable. Secondly, the battery appeared to be dead and wouldn’t charge. In addition I also found that a BIOS password (“user” and “supervisor”) had been set but the password wasn’t
This isn’t something new. SANS ISC reported on this 2 years ago. The bad guys love anything that can be used in a reflection DoS and the WordPress XML-RPC functionality is a prime candidate. There are various ways to disable it, through WordPress plugins for example, or by hacking away at code. All of these are fine if you’re in control over what gets installed on the web server. In a shared
Take the following scenario: You have a hub site. Branch (spoke) sites connect to the hub with a L2L IPsec tunnel. All traffic must traverse the tunnel (no local breakout to the Internet). At the hub, your VPN concentrator is separate from your firewall and runs in two armed mode. Where one interface is outside the firewall (public) to terminate the incoming tunnels and another interface is within a DMZ. As such
More and more I see fail2ban banning the same hosts repeatedly. One way to tackle this could be to increase the ban time but you could also have fail2ban monitor itself to find “repeat offenders” and then ban them for an extended period of time. Firstly, create a filter definition: [Definition] failregex = fail2ban\.actions\[\d+\]: WARNING \[.*\] Unban <HOST>$ ignoreregex = fail2ban\.actions\[\d+\]: WARNING \[repeat-offender\].*$ This will be used against the fail2ban log and
I got lazy after having to create a load of DHCP scopes for Cisco Lightweight Access Points, each requiring Option 43 in TLV format. And now you can be lazy too. Save the following as a HTML file and open in your favorite browser. In the text area enter your WLC IP addresses one per line and hit submit. This will generate the hex string to use in DHCP Option 43.
I’ve been working with some loadbalancer.org appliances recently, load balancing traffic over MySQL and Apache servers running Linux. The load balancer supports a feedback agent where it can query the real server to gauge how utilised it is based on, for example, CPU load and then distribute the request to the real server that should perform the best. Over on the loadbalancer.org blog is an article about the feedback agent and how to implement it
The other weekend I connected a L2 circuit between two sites. At both ends were Cisco 6500 Catalyst switches running VSS. The interfaces they connected to were configured as L3 and EIGRP was run between the two sites to share routes. But as soon as they were connected the neighbors started flapping. Troubleshooting started and as always you start at the lowest OSI layer and work up. Bingo! The issue