Category Archives: networking

Normally when a Linux Virtual Machine is created on Azure, we’re given just the core installation. That is, the VM is accessed through a command line over an SSH session. Here I’m going to try setting up an environment on a Linux VM that’s accessible through the Remote Desktop client.
The general principle here is that we create a standard Linux virtual machine in Azure, and on that we install the desktop manager, interface and a Remote Desktop server. Hopefully we’ll be able to connect the Remote Desktop client to this the same way we would a Windows VM.

First thing’s first: Most the configuration is done in the VM’s command line, so the local machine must have either BASH or PuTTY, or a program that enables an SSH session. Also, it helps to understand something about the architecture, dependencies and configuration files of a Linux system, but that’s not essential here.
The remote system here is an Ubuntu 16.04 Virtual Machine, and I’ve selected the cheapest and most basic pricing option.

An SSH Session
After the VM has been ceated, deployed and started, clicking the ‘Connect‘ link in the Azure Portal will show which IP address to point the SSH client to.

So, let’s try this by running PuTTY and initiating an SSH session to the VM’s IP address. After entering my username and password, and switching to the root account, I get the following:

Now we’re in business, and I can check for a package manager (ideally APT), and whether the X11, desktop manager, desktop interface and XRDP packages are available. This should be the case for any Debian-based installation. Before proceeding, run ‘#apt-get update‘ to avoid broken header problems.

Desktop Manager and Environment
Initially I was going to install the MATE desktop, but running ‘#apt-get install mate‘ indicated the components and dependencies amounted to over 1GB. I wanted something much smaller for demonstration purposes, so I chose XFCE instead, running ‘#apt-get install xfce4‘. It’s always possible to install and switch between desktop managers later, if needed.
Despite the warning messages shown during installation, the desktop components will be installed.

Setting Up the XRDP Server
The next component required is a remote desktop server. This will be provided by XRDP, which is installed with:#apt-get install xrdp

After installation, we can use ‘#service xrdp status‘ to check whether the XRDP server is running. This is a useful command, as it enables us to stop and restart services at any point. The output should look something like this:

Every user on the system will need a .xsession configuration file in their home directories, to specify the default environmment to load when initiating an X11 session. Currently I’m logged in as root, so I need to navigate to my non-root home directory, and create this file containing the line ‘xfce4-session‘ in it. The commands are:
#cd /home/michael
#nano .xsession

And add a single line to the file:xfce4-session

A quicker way to do this as root from the current path would be:#echo xfce4-session >/home/michael/.xsession

Now restart the XRDP server to load the changes.#service xrdp restart

UPDATE: 300MB of the desktop manager and interface packages consist of dependencies common to MATE and XFCE. If you want to install the MATE desktop, run #'apt-get install mate‘ and change the line in .xsession to ‘mate-session‘.

Configuring the Azure Inbound Rule for RDP
At this point the VM should have a desktop manager and an RDP server running. Now we need to find the Remote Desktop server port, so Azure can be configured to allow connections to it.#netstat --listen

It looks like the port we’re interested in here is 3389. In the Azure Portal, under the Network tab, add an Inbound Port Rule for ‘RDP’ – this will indeed be port 3389.

Now, the moment of truth. We’ll connect the Windows Remote Desktop client to the VM. And presto, the XFCE desktop.

Like this:

This works best when the browser has AdBlock and Ghostery installed, and geolocation is disabled, if you’re installing this as a privacy tool.

Installation
You’ll find the OpenVPN client installer under the Community Downloads section. Setup is straightforward, but make sure the option for installing the OpenSSL Utilities is checked.

After it’s installed, there’ll be an OpenVPN folder with several sample configuration files, each representing a service the client might connect to. This is where we can drop other configuration files for whatever services we might use.
Running OpenVPN won’t bring up a GUI, but instead a small icon in the system tray, and it’s activated/decativated by right-clicking that icon and selecting options from its context menu.

Adding the VPN Service Provider
The VPN client creates the virtual tunnel interfaces on the local system, but they wouldn’t be of any use without a VPN service.
The service provider I’ve chosen here is VPNBook. The ‘bundles’ posted on VPNBook’s site are .zip archives of configuration files – download whichever one, and extract it to the OpenVPN config directory.

With these files in place, the connections should appear in the context menu for the OpenVPN icon.

Be aware that whichever port you select, it will only tunnel traffic for that port. Everything else will bypass the virtual tunnel interfaces and get routed as normal.
Now enter the login and password provided on the VPNBook site.

Checking the Connection
How can we be certain our browser traffic is going through the VPN service? We can check by finding the IP address we’re using at http://www.whatismyip.com or whatismyipaddress.com. A reverse whois query using domaintools should reveal the IP address is assigned to the VPN service. Also, the browser shouldn’t throw SSL/TLS certificate errors if the traffic is being tunnelled correctly.

As it turned out, The Telegraph must have jumped to this conclusion after the BBC closed a legal loophole that allowed the watching of iPlayer without a TV licence, and after seeing the following statement within the Audit Office report: ‘TVL detection vans can identify viewing on a non-TV device in the same way that they can detect viewing in a television set‘.
The only way that could be true is if the detection equipment was comparing light radiation from a TV/monitor with a live broadcast. There’s nothing in the report about WiFi signals. In fact, the report itself implies that, whatever ‘evidence’ they’re gathering inside the ‘TVL detection vans’, it’s actually less reliable than the contemporaneous notes made during a physical inspection of suspected license evaders’ properties.

Let’s suppose, hypothetically, the BBC did comission a TV Licensing authority to go around monitoring peoples’ WiFi traffic. From a technical perspective, the people manning the BBC detection vans would be no different from the criminal parked outside with a laptop running a packet sniffing tool. This is true regardless of what the law says, simply because the technology cannot distinguish between adversaries.

Thankfully the basic security on the typical WiFi router provides a good level of protection against such an adversary. Anyone could operate their network interface in ‘monitor mode’ and passively capture encrypted packets/frames from multiple nearby networks, but that wouldn’t reveal much about what’s being communicated on the networks unless they were later decrypted somehow.
Technically it’s possible for the iPlayer server to send beacon or signature packets, maybe of a specific size at a specific frequency, then listen for that signature in WiFi traffic (edited to add: Dr. Miguel Rio also suggested something like this in the Telegraph article)- you could get that running a capture in monitor mode, just about, assuming the owner hasn’t changed the MTU trying to fix router/ISP synching problems. The problem is that alone is nowhere near enough evidence to prosecute someone.

I didn’t want to pick on VeriSign/Symantec specifically, but there was a story that broke earlier this week that got me thinking what would happen if an SSL Certificate Authority was compromised.

VeriSign is a trusted CA, and was bought out by Symantec back in 2010. Blue Coat is an interception hardware vendor that by its own admission sells to regimes with questionable human rights histories. The problem is that Symantec appears to have granted Blue Coat intermediate CA status, with the ability to verify SSL connections as secure on behalf of Symantec.
Take a look at the crt.sh entry and judge for yourself. The commonName is ‘Blue Coat Public Services Intermediate CA’, and the cert doesn’t expire until September 2025.

On a corporate network, the admins might install their own root certificates on the client machines, which enables them to decrypt SSL traffic for the purpose of detecting malicious activity. This is entirely legitimate if it’s done by whoever owns the network and all the client machines. I’m a little skeptical about the claim Blue Coat was limited to being an intermediate CA for testing purposes within a corporate network only.
The ‘trusted’ CA model would be fundamentally broken if this became common practice, since it would allow anyone operating Blue Coat’s MITM kit to tamper with HTTPS sessions undetected. The browser wouldn’t flag that connection as compromised, and we’d be none the wiser without a deliberate inspection of the certificate.

Looking at one certificate where Symantec is the CA, it transpired that the root CA is actually ‘VeriSign Class 3 Public Primary Certification Authority – G5’.

Symantec bought out VeriSign a while ago, so life could get pretty awkward for anyone who revokes or removes Symantec from their certificate lists without making a backup.

Scrapping the Intermediate CA
Ideally you’d do the following procedure for a cert where the subject or common name is ‘Blue Coat’, but since I haven’t encountered that yet, I’ve done this with a cert signed by Symantec. If you’re going through with this, make sure you keep a backup of the file.

If we try to open that file in Windows Explorer, Windows will recognise it as a certificate, and we get the option to install it using the Certificate Import Wizard. However, we get the option of importing it into the Untrusted Certificates store.

How to Remove SSL Certificate in Windows
In Windows 8.1, search in the start screen for ‘Manage computer certifications‘. The entries you’d want for this are under the Third-Party Root Certification Authorities and Trusted Root Certification Authorities, and they can be deleted or the permissions modified in their Properties.

In Windows 7, run certmgr.msc and do the same as above.

Certificates can also be revoked or deleted in the Advanced options in Firefox.

How to Remove SSL Certificate in Linux
In the Advanced settings of Firefox, certificates can be deleted/revoked certificates and their trust settings modified.

Alternatively, download the certificate from cert.sh and try to import it into Firefox’s Certificate Manager – note that the trust settings are blank by default. You’ll then see it listed under VeriSign as ‘Blue Coat Public Services Intermediate CA’. Click the ‘Delete or Disrust’ button in the Certificate Manager – the certificate would still be installed, but marked as untrusted.

In Linux Mint, there are also certificates in /etc/ssl/certs/ca-certificates.cert, and CA lists are in /etc/ca-certificates.conf. Entries in the ca-certificates.conf file can be invalidated by prefixing their entries with ‘!’. Plus you’ll find public keys for the CAs in /usr/share/ca-certificates/mozilla.

Like this:

Elsewhere on this blog I’ve probably mentioned that patching, a properrly configured firewall and updated anti-malware protection will prevent 99% of security threats. Fortunately all three can be readily added to a FreeBSD installation, and there are some other native features in this operating system that can provide pretty solid security.
The most important things, in my opinion, are exploit prevention and mitigation – that is, making it hard as possible for something to exploit software vulnerabilities, and restricting what an exploit could do if executed.

BSD Configuration Options
Already present in a FreeBSD installation is the ‘bsdconfig’ utility, which enables low-level configuration changes. The Security and Startup options are the ones we might want to configure, after everything’s set up.

The Securelevel options are used for limiting the actions that could be performed with root privileges, assuming no malicious program is capable of undoing these configuration changes. In Highly secure mode, the loading/unloading of kernel modules, the mounting of additional filesystems and certain configuration changes are disabled. This could provide an additional safeguard against the installation of kenel-mode rootkits. There is a help page describing what each Securelevel option does.

Patching
If an anti-malware system has reacted to a malware infection attempt, it typically means a vulnerability has already been exploited and shellcode was executed. Patching known vulnerabilities and removing software we don’t need really is the first line of defence, if the operating system doesn’t have native exploit prevention measures such as ASLR.
The following commands are used to fetch available updates to the base system, and install whatever has been fetched:#freebsd-update fetch#freebsd-update install

This sorts the updates for the core operating system, but there are also a load of other packages that were added later. The following looks for vulnerability notices associated with installed applications:#pkg audit -F

Vulnerability disclosures are posted quite regularly, so it makes sense to make periodic checks.

To check for packages that could be upgraded to a more recent version:#pkg version

Another tool we could use for checking for outdated pakages is portmaster.#portmaster -a

Exploit Mitigation
PolicyKit/PolKit is something I’d need to look into further, but it seems the rough equivalent of SELinux here. Essentially it checks a request to a privileged process from an unpriviliged process, according to specific policies. The idea is that an exploited or compromised program remains limited by whatever policies are set.
A configured PolKit is included as part of the base system, and a GUI for it’s included with KDE by default.

Jails
There is a ‘jail’ utility native to the system, which is based on the chroot concept. Essentially this changes the root directory location for a given process, so that it cannot refer to anything beyond it. The FreeBSD jail adds further mechanisms to restrict access to hardware resources from a process in the chroot, so it almost provides a fake environment with predefined resources. For this to work, the FreeBSD jail requires its own jail name, host name and IP address attributes. A jail could be made to resemble a complete FreeBSD system, or a ‘service’ jail dedicated to one or two processes.
We might use this for compiling a new Linux/UNIX system within a pre-existing host installation, and the FreeBSD handbook makes reference to extracting the contents of an ISO file into the /mnt directory.

Anti-Malware
With UNIX-based systems, the anti-malware solutions have the advantage of performing more thorough checks for anything suspicious in the operating system components.
With FreeBSD’s package repositories, we have a choice of rkhunter, chkrootkit and clamAV. Each has a different method of looking for activity associated with malicious programs, but generally they check for signs of privilege escalation, replaced binaries and processes being hidden from user space.

It might take a little knowledge and experience to understand the command line output from these programs. Of course, the full output of these programs can be dumped to a text file using a command like:#rkhunter -c >> scanlog.txt

Since all three employ slightly different methods for uncovering rootkits, best results are gained by running all three separately periodically.

Firewall and Packet Filtering
Packet filtering in FreeBSD (and Linux) happens at the kernel level, with the packets passing through the network interface and then the packet filtering module. I think this is more for FreeBSD boxes on the network perimeter, or even to use a FreeBSD box as a firewall, but it’s not a bad idea to have a host-based setup as threats are stopped at the kernel level.

FreeBSD includes three firewalls: PF, IPFW and IPF. IPFW seems the default choice here, as there’s already a ruleset file in /etc/rc.firewall, and it might be easier for most users to simply modify this as needed. There seems to be a disadvantage that IPFW only works with IP addresses, port numbers and transport layers, whereas PF looks at the session layer as well and includes a few other proxying and NAT features.

To enable the IPFW as a service at startup, add the following lines to /etc/rc.conf:

The firewall profiles are listed in rc.firewall. The alternative for a desktop system is ‘client’. For an offline machine it might be ‘closed’. Or we could set this variable to ‘filename’ if we wanted to load all the rules from elsewhere. To list the currently applied firewall rules:#ipfw list

Then, if any changes were made and the ruleset needs reloading:#service ipfw restart

inetd
Slightly related to the packet filtering and firewall features, FreeBSD’s repositories include xinetd, which can replace the pre-installed inetd. These programs listen for incoming network traffic, and starts a predefined server process to handle requests for whichever port, while applying any relevant policies. This ensures the right programs respond to incoming requests, and to prevent servers being misused. For example, we might want Apache to handle incoming traffic on ports 80 and 443 only, and to limit the number of session attempts for each IP address.

The rules are defined in /etc/inetd.conf, and the port-service mappings in /etc/services.

Categories

Profile

My name is Michael, and I’m a software developer specialising in clinical systems integration and messaging (API creation, SQL Server, Windows Server, secure comms, HL7/DICOM messaging, Service Broker, etc.), using a toolkit based primarily around .NET and SQL Server, though my natural habitat is the Linux/UNIX command line interface.
Before that, I studied computer security (a lot of networking, operating system internals and reverse engineering) at the University of South Wales, and somehow managed to earn a Masters’ degree. My rackmount kit includes an old Dell Proliant, an HP ProCurve Layer 3 switch, two Cisco 2600s and a couple of UNIX systems.
Apart from all that, I’m a martial artist (Aikido and Aiki-jutsu), a practising Catholic, a prolific author of half-completed software, and a volunteer social worker.