OpenSSH on Windows 10

PuTTY on the shelf


I prefer using the same toolset across platforms, and as Windows 10 have included OpenSSH for a while, why not put PuTTY on the shelf?

Decommissioning PuTTY will also provide you with the ability to do so much more from the command line, and reuse your scripts from your favorite distro.

It's 3 simple steps (4 if you convert your PuTTY key).

1. Install the OpenSSH Client features

Add-WindowsCapability -Online -Name OpenSSH.Client*

Or from the GUI

  1. Click Start, then choose Settings
  2. Choose Apps from Windows Settings
  3. Click “Manage optional features“
  4. Click “Add a feature“
  5. Choose “OpenSSH Client” and click Install

2. Configure the SSH agent service to start automatically

Get-Service -Name ssh-agent | Set-Service -StartupType Automatic

As the service hasn't really been given the chance to auto-start, go ahead and start it

Start-Service ssh-agent

3. Add the required key(s)

ssh-add C:\Users\<i>username</i>\.ssh\keyname

Example: ssh-add C:\Users\Martin\.ssh\id_ed25519

Optional (if you only have a PuTTY private key)

Use Puttygen to show the actual key and export (force new file format) that

That's all there is to it.


Finally! Internet Explorers obituary (ancient time - June 15th 2022)

Time to celebrate

While a number of services hasn't worked with Internet Explorer for a while, Microsoft finally gave us the EoL date for it.


While the "personalities" that haven't prepared for the inevitable likely still refuse to assess and update or replace old sh1t that require IE (or Flash for that matter), at least we can now give them a deadline they can enjoy watching pass by, then request exceptions filled with bad excuses.

More mature organizations will already have replaced IE and the (few) required exceptions written already.

I wrote about this before:



"The future of IE is Edge": https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-internet-explorer-on-windows-10-is-in-microsoft-edge/ 

IE not supported on Azure (March 31, 2021): https://azure.microsoft.com/en-us/updates/azure-portal-to-end-support-for-internet-explorer-11-on-march-31-2021/


Book Review: Intrusion Detection HoneyPots, Detection through Deception

Intrusion Detection HoneyPots, Detection through Deception

  • Author: Chris Sanders
  • Publisher : Applied Network Defense (30 Aug. 2020)
  • Language : English
  • Paperback : 238 pages
  • ISBN-10 : 1735188301
  • ISBN-13 : 978-1735188300



Let's get the important stuff out of the way first1)

Cookie Recipe: 🍪🍪🍪🍪🍪

These cookies are very very good. Having to convert from obscure measurements to something for the modern ages (metric) was well worth it.

1) Read the book You must :)

Conclusion: Recommended reading for everyone interested in honeypots, novice or expert.

While I've worked on most of the ideas and products discussed in the book, I really liked the structure and content of the book.
Came away from reading it with a more structured approach to how, when, and where to deploy honeypots - Really wish this book was available when I started messing with honeypots, it would certainly have saved me some time.

Noteworthy (to me)
Chapter 1, A brief History of Honeypots: While a brief chapter on the history of honeypots, it's always great to be reminded of The Cuckoos egg and Berferd, however it gets even better in the following chapters.

Chapter 2, Defining and Classifying Honeypots: As Chris state in the book, "All honeypots are deceptive, discoverable, interactive, and monitored", but not just that, he's also providing a good explanation of what that these characteristics mean and what questions to ask regarding your own deployment. This chapter also gave me a better understanding of Whaleys Deception Taxonomy - I'd say that theory and practice converged and I'll be able to utilize that understanding better going forward.
Chapter 3, Planning Honeypot-Based Detection: See - Think - Do! - Not just the words, but used to explain honeypots very clearly and precisely. Combined with the case study, it really sets the stage. I feel kinda verified, as it confirms (most of) the ideas and principles I've used when deploying honeypots :)
Chapter 4, Logging and Monitoring: Even for someone with extensive experience in logging and monitoring there's still a lot of food for thought in this chapter - not just for honeypots, but in general. I'll be using variations of Chris's "Log plumbing reference framework for logging and monitoring infrastructure" to explain to both business and other colleagues why we've implemented e.g. certificates for encryption and mutual authentication in our logging infrastructure.
Chapter 5, Building Your First Honeypot from scratch: Nice and pragmatic intro to what a honeypot could be, using Netcat (Specifically NCAT from Fyodor).
Chapter 6, Honey Services: No problem, let's just build a Windows based RDP honeypot, a SSH honeypot with Cowrie, and a multi-service honeypot using OpenCanary. Again very concise and clear guidance that takes you most of the way to deploying honeypots.

Chapter 7, Honey Tokens: Read the "From the Threnches" sidebar. Like other chapters the Sigma and Suricata rules are great inspiration.
Chapter 8, Honey Credentials: This chapter goes way further and provides several possible ways of deploying honeytokens. amongst those, an example on how to create a "LLMNR Broadcast Honeypot", rounding the chapter off with some cool awesomeness. One caution, though, I think it is a violation of GDPR to use previous employers accounts as honeytokens as discussed - I might well be wrong (IANAL), but better safe than sorry.
Chapter 9, Unconventional Honeypots: The idea of a DHCP honeypot is cool, not least because it is likely to delay the adversary, however with a lot of potential pitfalls (YOLO). This chapter also covers "cloned website honeytokens", Honey-tables, and more, rounding the chapter off with honey commands using aliases on Linux.
[1] Applied Network Defense: https://www.networkdefense.co/


Building Your own Greenbone Vulnerability Manager Source Edition (GSE)

Building the GSE Vulnerability Scanner

Want to deploy Greenbone Vulnerability Manager Source Edition instead of  the Trial version graciously provided by Greenbone Networks GmbH to the community?
Latest news
  • Updated to August 2021 updates from Greenbone (current releases) 2021-09-24
  • Changed to work with Debian 10 (Buster) and Debian 11 (Bullseye) on 2021-09-14.
  • Updated to GSE 21.4.0 on 2021-05-08.
The GVM framework is released under Open Source licenses as the Greenbone Source Edition (GSE).
The script on my Github [3] installs GSE, including the following components:
  • gvm-libs - required libraries for GVMD
  • gvm-tools -Remote control your Greenbone Vulnerability Manager (GVM) 
  • GVMD - Greenbone Vulnerability Manager 
  • GSA - Greenbone Security Assistant
  • ospd-openvas - OSP server implementation to allow GVM to remotely control an OpenVAS Scanner 
  • gvm-pyhon - Greenbone Vulnerability Management Python Library
  • openvas - Open Vulnerability Assessment Scanner, a scanner for Greenbone Vulnerability Management (GVM)
  • openvas-smb - SMB module for the OpenVAS Scanner

The installation script is based on the hard work of "sadsloth" [4] and [5], without whom I'd probably never finished the install.

Also a BIG Thank You to Greenbone Networks GmbH for supporting the security community, not least Björn Ricks (https://twitter.com/BjoernRicks) who is Team lead at Greenbone Networks GmbH and responsible for openvas.

Requirements: Debian 10 Buster with 8 GB RAM or more (I've tested with 5 GB, and it works). It should work on Ubuntu too, but that is not tested - yet.

I'm striving to find the time to maintain (and improve) this installation script as well as add additional scanners, not least the ospd-nmap implementation. However any help is appreciated, so go ahead and create issues on github.

[1] Greenbone Security Manager Trial: https://www.greenbone.net/en/testnow/
[2] Greenbone Source: https://github.com/greenbone/
[3] Bash installation script: https://github.com/martinboller/gse.git


Stratum-1 NTP Server & ntppool.org

It's about time

What is ntppool.org? From the website.
"The pool.ntp.org project is a big virtual cluster of timeservers providing reliable easy to use NTP service for millions of clients.
The pool is being used by hundreds of millions of systems around the world. It's the default "time server" for most of the major Linux distributions and many networked appliances (see information for vendors).
Because of the large number of users we are in need of more servers. If you have a server with a static IP address always available on the internet, please consider adding it to the system."
While not good OpSec*, I wanted to support the ntppool by adding a stratum-1 server to it.
* While the GPS coordinates of my server give my location away, this is public information already. Also note that the rounding actually results in Google Maps not pinpointing my home exactly :). My IP address is easily found too, however I'll have to live with it being as easily found as it is now.

In order not to publish any internal stratum-1 servers to the internet the firewall itself was "upgraded" with a GPS configured to provide NMEA time info and PPS over serial - more on that later. While this is something you should never do on your corporate firewall, I've accepted the risk associated with this - most importantly NTP is not running as root.

After configuring and tuning NTP on the firewall [4], it was time to add it to the pool [1]. According to the firewall logs the monitoring station in Newark, NJ, USA connected shortly thereafter racking up the score of the system over the hours of March 6th 2020, as seen in figure 1.

Figure 1 - Initial Monitoring 

Note: It is noticeable from the monitoring that the server was added to hastily - It was still being tuned.

Update: After the first day the score has been consistently at 20 as shown in figure 2.

Figure 2 - March 9th and 10th Monitoring

After achieving a score of 10+ clients started connecting (as expected). Connected peers can be shown using $ sudo ntpq -n -cmru. However I'm also logging all requests on the WAN interface to a separate log file. To ensure that it doesn't outgrow the disk, logrotate is configured to rotate that logfile daily with only 1 backup. The logs are ingested into elasticsearch, so there's no reason to keep those logs on the firewall itself for longer periods of time.
The logging performed for NTP may seem excessive and puts an extra load on the system, however is justified by the need for visibility into this traffic.
The ntp logging is used to monitor NTP activity, including vizualizations in Kibana. A few examples are shown in the figures below. The numbers are relatively low, as I had a power outage just before capturing these images, thus the 24 hour view lacks a few hours of activity.

 Figure 3 - Count of requests and peers

 Figure 4 - World Map of NTP peers 

 Figure 5 - Autonomous System and Country

In an effort to provide a dashboard for everything NTP monitoring, local dashboards for NTPPOOL monitoring were also created. The data from ntppool.org is pulled daily at noon (RandomizedDelaySec=7200) and ingested into elasticsearch. The specific visualizations are shown below.

Figure 6 - Offset Monitoring based on NTPPOOL monitoring data

Figure 7 - Score Monitoring based on NTPPOOL monitoring data

When the NTP server was added to the pool, the NTPPOOL monitoring was giving it a low score which slowly, but steadily, increased the following hours. The score then saw a slight decrease, correlating with the (planned) change to an outdoor GPS antenna. Late on the 7th the score was at 20, and stayed there until a power outage on the 12th (local incident in the household), which caused it to drop below 10 (5.7 to be precise). The development in score from Day 0 until March 15th is shown in Figure 8, below.

Figure 8 - Score Monitoring from Day 0 - March 15th

An observation about ISP's and Cloud Providers use of servers in the pool
NTP clients from several major ISP's as well as Cloud Providers connect to timeservers in the pool including mine. While that is fine, it seems wrong - at least to me - that these providers (often) do not themselves support the pool with NTP servers and/or help their customers use the providers own servers. The cost of doing that would be negligible and they (supposedly) have the required infrastructure.
So if you're working for an ISP or Cloud Provider, please push this agenda to the right people, you're all running on open source software anyway.

The actual configuration

The original firewall, discussed in a previous blog post was (re)configured as discussed briefly below.

The GPS receiver used is based on the U-blox NEO-7M. Chinese factories are cranking these boards out in high numbers and they can be found on e-bay at around the $7 price tag. I've bought quite a few of these exact boards, and have 5 stratum-1 servers deployed so far using these.

Please note that they do not have any holdover, so will stop disciplining NTP when there's no GPS-fix. When that happens, the quality of the other peers configured in ntp.conf and the internal real time clock (RTC) decides how badly the server will drift until there's a GPS-fix again. Buying a device with an oven controlled crystal (OCXO) would help mitigate this, however the price tag is much higher. (Still considering it, as sometimes used ones come up at decent prices). Be aware that devices such as BG7TBL's GPSDO (GNSSDO) does not deliver pps without a GPS-fix either, so don't buy them for that purpose, however there's some refurbished Symmetricom and Samsung devices available that would do the job.

alt text
Picture 1 - U-Blox NEO7M board

Opening the APU and connecting the GPS

For the APU4C4 case I drilled a 6.5 mm hole in the front of the lid and mounted the GPS board internally. Had to mount it there, as there's no room left at the back with 4 NIC's and wireless. The board is connected to J18 on the APU board itself as discussed below.

alt text
Picture 2 - APU 4C4 with mounted GPS board

Connect the GPS to J18 as described in Table 1 using serial #3 of the LPC UART (schematics for for the APU4C4 board can be found here: https://www.pcengines.ch/schema/apu4c.pdf), specifically the LPC UART is shown on page 12 of 18.

Connecting to serial #3 translates to the serial device becoming /dev/ttyS2. It was used for the following main reasons:
  1. Serial #1 (COM1 on the schematic) is used for console access and should be reserved for that purpose.
  2. The GPS board is 3v so doesn't support the RS232 levels on Serial #1 or Serial #2 (COM2 on the schematic).
  3. Serial #2 Also does not have DCD (or RI) required for PPS.
  4. Serial #3, thus is the first feasible port for communicating with the GPS.

GPS to LPC UART connections
GPS   J18     J18 Pin     Comment
GND         Ground    1    Ground
VCC  V3    2    3 Volt
TXD         RXD3#    7    TX (GPS) -> RX (J18)
RXD        TXD3#    8    RX (GPS) -> TX (J18)
PPS        DCD3#    9    Kernel PPS uses DCD
Table 1 - GPS to APU4C4 connection


CPU Throttling

The impact on PPS timing from the CPU changing clock frequency dynamically is very noticeable on the accuracy of NTP. Thus the system is configured with the performance governor set to performance using sysfsutils. The performance governor ensures that all CPU cores will run at 1 Ghz all the time. This was added to the main script, as that doesn't hurt netfilter's performance either.

[1] How do I join pool.ntp.org? https://www.ntppool.org/en/join.html
[2] My NTP server: https://www.ntppool.org/a/aika &
[3] http://support.ntp.org/bin/view/Servers/PublicTimeServer001660
[4] Debian Firewall: https://github.com/martinboller/DebFirewall
[5] PC Engines APU4C4 Schematics: https://www.pcengines.ch/schema/apu4c.pdf

Added server to Beta monitoring and changed the graphs accordingly.

Figure 9 - Beta Offset Monitoring

 Figure 10 - Beta Score Monitoring