Tag: network

vysolator: vyos virtual network isolation

Sometimes projects are just born out of pure frustration, this is one of those projects. I’ve probably build like a dozen VyOS configurations to virtually isolate networks and virtual machines on my host. I  briefly touched upon this subject a couple of years ago when I wrote about stashing ESXi inside VMware workstation to achive a portable lab. Since then I’ve build multiple versions, to either ensure that Red Team operations and regular penetration tests are able to contain the breach to a single virtual machine or to enable training networks with multiple networks and clients. If we visualize a simple setup it looks like this:

This compartmentalizes potential breaches to their own segment. In this case each segment has a single VM, but it could contain multiple VMs. Yes, the virtualization layer becomes a single point of failure. I still think it adds value from most attacks that you could suffer. Including the usual surfing the internet and getting pwned one.

So here is a repo which contains the instructions and example config file to get you (read: most probably future me) started. The current setup ensures that you have one mgmt segment and one internet only segment. That means, you can manage your VyOS from the mgmt segment if you place a VM in it. You can browse the internet and nothing else if you place a VM in the internet only segment.

Whenever I build more segments that lend themselves to be of generic use I’ll update the repo. Feel free to send pull requests with either alternative configurations or improvements and segment expansion on the current one. @donnymaasland, already had a sneak preview and submitted some improvements. You can view the historical commits to review the improvements as well as some personal preferences on rules.

On and yes, I do agree that Qubes OS is a superior solution, however this is more versatile. Also this does not have the same threat model that Qubes OS has. For those wondering about the threat model for this, here is a quick summary of it / the intended features:

      • Contain regular breaches to a single segment
      • Protect against regular attacks
      • Not intended to withstand targeted or advanced attacks
      • Avoid user mistakes by enforcing network ACLs from a central system
        • Improve ease of use by just requiring users to place VMs in the right segment
      • Aid Red Team / Pentest to not fuckup when they have to use specific exit IP addresses

Identify a whitelisted IP address

An IP whitelist is one of the many measures applied to protect services, hosts and networks from attackers. It only allows those that are on the IP whitelist to access the protected resources and all others are denied by default. As attackers we have multiple obstacles to overcome if we want to bypass this and not always will it be possible. In my personal opinion there are two situation in which you will end up as an attacker:

  1. You are NOT on the same network as your target
  2. You are on the same network as your target

In the first situation you will (generally speaking) not be able to access or influence the network traffic of your target. This in turn enables the TCP/IP mechanisms to be useful and prevent you from accessing the resources, although maybe not prevent you from discovering who is on the whitelist.

In the second situation you will (generally speaking) be able to access or influence the network traffic of your target. This enables us as attacker to identify as well as bypass IP restrictions, by manipulating the TCP/IP protection mechanisms, to gain access to the protected resources.

For both situations there is an often overlooked detail which is: how do you know which IPs are on the whitelist? Mostly it is just assumed that either you know that upfront or discover that due to a connection being active while you initiate your attack. In this blog posts we’ll discuss the two situations and describe the techniques available to identify IPs on whitelist which have no active connection. A small helper script can be found here.

Continue reading “Identify a whitelisted IP address”

Everything can be hacked…or can it?

Everything can be hacked!

That’s a quote I love, you hear it all over the net. Most people reversing software/hardware or people penetrating highly secure (or at least claimed) networks, state that most of today’s applications/hardware/networks can be compromised. Normally you see the vicious circle of stuff being released….hackers attempting to pwn it, vendors claiming it can’t be hacked, hackers publishing the hack. I might be exaggerating a little bit, but usually that’s the general consensus. Of course there are exceptions to the rule and there is hardware/software out there that hasn’t be hacked yet and maybe it really is NOT hackable. Today I wanted to write about one of those exceptions: Unidirectional networks. This post will cover the devices and answer the question if I believe their 100% claim, it will also cover some of my midnight thoughts on how to use alternative ways to maybe get data back even when such a device is in place. These ideas DO NOT BYPASS the device, so don’t get your hopes up, it are just possible ideas to use other vectors instead of routing your traffic through the secure device.

Continue reading “Everything can be hacked…or can it?”