2022-07-15.01
A bit of a change-up in plans for today's edition. Rather than three distinct+diverse topics with the usual extended blathering, there are three topics that build up on each other in an effort to truly make this a "weekend edition". I won't spoil the surprise, and I've named topic number three "The Drop" to not spoil where the topics are leading to.
Netplan
Once upon a time, we had simple, single plaintext configuration files for network configuration on UNIX-alikes; and we liked it. Now, the crazy kids have all sorts of fancy filesystem layouts and os-level daemons/kernel elements for configuration and management of all things networking. The old-school KISS part of me does miss the simplicity of the well-before-times. However, I am a big fan of this modern concept of network infrastructure as code, since we are in far more complex times, and the concepts and tooling behind net-infra-as-code do, indeed, make quick KISS-work out of said complexity.
Netplan [GH] — a tool built by Canonical — is "the network configuration abstraction renderer". It enables network configuration abstraction over any supported back-end system. For now, said back-ends include networkd and NetworkManager. With Netplan, one can manage both physical and virtual network interfaces via YAML (ugh, tho) configuration files. These configurations then get rendered to your back-end of choice. Here's a portion of a sample YAML:
network:
version: 2
ethernets:
enp4s0f0:
addresses:
- 198.51.100.42/24 # Gateway server external IP address
- 198.51.100.4/24 # SEEKRIT service (reveal in the third section)
- 198.51.100.12/24 # Another SEEKRIT Service
gateway4: 198.51.100.1
dhcp4: false
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
enp7s0f0:
dhcp4: false
addresses: [192.168.1.1/30]
vlans:
vlan.2:
id: 2
dhcp4: false
link: enp7s0f0
addresses: [192.168.2.1/30]
vlan.3:
id: 3
dhcp4: false
link: enp7s0f0
addresses: [192.168.3.1/30]
...
You can run netplan [generate | apply | try] to generate the required configuration for the renderers, apply all configuration for the renderers, restarting them as necessary, or apply configuration and wait for user confirmation; will roll back if network is broken or no confirmation is given.
You can read more about the design of netplan and review many other examples to help get you comfortable.
I highly suggest setting up a solid YAML editing system before venturing forth into Netplanning to avoid many frustrations and errors that can occur with such a terrible format.
Consider playing with Netplan in a Linux VM before migrating any existing cloud, VPS, or local Linux systems to this net-infra-as-code paradigm, since mistakes in VMs are way less painful than ones IRL.
PolarProxy
Most examples of a client making an HTTP[S] request revert to a simplistic setup where the client directly connects to the target system. It is often advantageous to toss a proxy server into the mix for access control, security, debugging, inspection, research, or other purposes. If you are in a major enterprise/organization, you likely use a proxy server without even knowing it (ref "transparent in-line proxy" below), but there may be deliberate configurations you need to apply to have your clients use one to make internet requests.
There are many flavors of HTTP[S] proxies out there. Today, we're looking at one by NETRESEC (@netresec), an independent software vendor with focus on network security monitoring and network forensics. They make many fun things, release many of said things in a freemimum context, and generously donate free licenses to qualified researchers/organizations.
The proxy NETRESEC makes is dubbed "PolarProxy", which is a transparent SSL/TLS proxy created for incident responders and malware researchers (though those two use-cases are far from exhaustive). PolarProxy is primarily designed to intercept and decrypt TLS encrypted traffic from malware. PolarProxy decrypts and re-encrypts TLS traffic, while also saving the decrypted traffic in a PCAP file that can be loaded into Wireshark or an intrusion detection system (IDS). It has many operational modes:
Transparent Forward Proxy : connects to external TLS servers on behalf of clients on a network. This mode is typically used to intercept and monitor otherwise encrypted HTTPS traffic from clients. (As an aside, I'm
#notAFanof doing this in an enterprise context with employee web sessions, which is a topic best suited for another edition.)Reverse Proxy : connects to one or several local TLS servers on behalf of external clients. This mode is used to monitor of the incoming TLS traffic as if it were unencrypted.
TLS Termination Proxy : terminates the TLS encryption for incoming connections and forwards the application layer traffic in decrypted form to a local server.
Transparent In-Line Proxy : decrypts, re-encrypts and forwards all TLS connections to a specific proxy, security gateway or some other form of "next-generation firewall".
SOCKS Proxy : runs as a local SOCKS proxy server, which clients can use to access the Internet. All TLS traffic passing through PolarProxy's SOCKS server will be decrypted and re-encrypted regardless of port.
HTTP CONNECT Proxy : runs as a local HTTP proxy server, which only supports the CONNECT request method. TLS traffic passing through PolarProxy's HTTP CONNECT proxy will be decrypted and re-encrypted regardless of port.
This proxy can work right at the OS-level, in containers (e.g. Docker), and in Windows Sandbox.
NETRESEC provides many links to examples that should help you get PolarProxy up and running (it has a fairly generous freemium model), providing many hours of fun in an air-conditioned room over the heatwave that's coming.
The Drop: Building a TLS-compatible Honeypot
Nils Hanke is working on a Master's degree and has opened source his how-to on setting up a pretty clever HTTPS honeypot system using the above resources plus ELK.
The repo is a giant README with example configurations, all reproduced post-MS-degree-project to help others learn how to work with a fairly complex honeypot system. Nils uses Netplan + iptables to define secure network paths from a gateway system to honeypot backends manage by PolarProxy.
While this setup isn't precisely how we do things at the $DAYJOB, Nils provided a solid foundation for anyone who wants to see what opportunistic folks are up to in HTTPS-land.
The README is long and fairly thorough, so I'll leave you in Nils' capable hands vs blather more.
FIN
Def drop a note in the comments on your thoughts on this "The Drop" format. If so, also def drop requests in said comments for future Drops. ☮