LYFR

Use KeePass to automatically open authenticated nsupdate

Sat, 01 May 2021 00:00:00 +0000

This is a quick guide on how to configure to open nsupdate with a configured tsigkey stored in KeePass. nsupdate is used to submit Dynamic DNS Update requests as defined in RFC2136 to a name server. This is useful when administrating a dynamically managed DNS zones. To secure the process i.e. allow it to be done from an administrators computer the transaction is a authenticated with the use of TSIG, however specifics about TSIG, nsupdate and DNS in general are not the goal of this post.

As I didn’t want my personalized TSIG key lying around in a directory somewhere on my computer I instead put it in KeePass. And as I also didn’t want to copy it into the nsupdate interactive shell each time a created a quick URL Override for KeePass to do it for me.

Prerequisites

First of you need a locally installed instance of nsupdate. On my Windows 10 I used Windows Subsystem for Linux (WSL) to install ns update via APT apt update; apt install -y dnsutils. Alternatively you can download the Bind9 package for Windows from ISC and extract nsupdate.exe from there.

KeePass configuration

To change the default URL action for a URL scheme (e.g. https:// or ftp://), got to Tools -> Options -> tab Integration -> URL Overrides and define a new URL scheme override.

Scheme: nsupdate
URL override: cmd://C:\Windows\System32\wsl.exe -- nsupdate -v -y {S:hmac}{USERNAME}:{PASSWORD}
Or if you downloaded nsupdate.exe:
URL override: cmd://C:\<path>\<to>\nsupdate.exe -v -y {S:hmac}{USERNAME}:{PASSWORD}

After creating the URL override you can trigger the shell from a entry with a nsupdate:/// url entry. The entry uses the usernames as key name and the password as the base64 encoded secret key as found in the .private file.

If you use a key algorithm other than HMAC-MD5 (and you should), then you need to also define the custom string field hmac for the entry. This field is used to tell nsupdate what key algorithm is in use for the key.
Important this value has to end in : es it is seen as part of the key name.

Possible key algorithms:

hmac-md5
hmac-sha1
hmac-sha256
hmac-sha512

Dotnet project layout with MSBuild 15+

Mon, 09 Dec 2019 00:00:00 +0000

Recently I stumbled upon an article by Filip W. in which he wrote about Solution-wide Nuget package version handling with MsBuild 15+. That inspired me to give it a try but with a bit more fine grained control, by using multiple Directory.Build.targets and Directory.Build.props files. Here is the result of that experiment; I omitted other files such as README.md because they are not really relevant to the build process.

/
├─ src/
│  ├─ Directory.Build.props
│  ├─ Directory.Build.targets
│  ├─ Project.Common/
│  │  └─ Project.Common.csproj
│  └─ Project/
│     └─ Project.csproj
│
├─ test/
│  ├─ Directory.Build.props
│  ├─ Directory.Build.targets
│  ├─ Project.Common.Tests/
│  │  └─ Project.Common.Tests.csproj
│  └─ Project.Tests/
│     └─ Project.Tests.csproj
│
├─ Directory.Build.props
├─ Directory.Build.targets
└─ Project.sln

`Directory.Build.props` and `Directory.Build.targets` files.

The root Build.props only sets properties required for source link. Whereas the root Build.targets specifies the package versions for the entire solution. It also adds source link to all projects as all projects need to reference it for the build process. Additionally target framework dependent package version can be made in the global location.

/Directory.Build.props:

<Project>
	<PropertyGroup>
		<PublishRepositoryUrl>true</PublishRepositoryUrl>
		<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
	</PropertyGroup>
</Project>

/Directory.Build.targets:

<Project>
	<ItemGroup>
		<PackageReference Include="Microsoft.SourceLink.GitLab" Version="1.0.0-*">
			<PrivateAssets>all</PrivateAssets>
			<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
		</PackageReference>
	</ItemGroup>
	<ItemGroup>
		<PackageReference Update="System.Buffers" Version="4.5.*" />
		<PackageReference Update="System.Memory" Version="4.5.*" />
		<PackageReference Update="System.ValueTuple" Version="4.5.*" />
	</ItemGroup>
	<ItemGroup Condition="('$(TargetFramework)' == 'netstandard1.6') Or ('$(TargetFramework)' == 'netstandard1.3')">
		<PackageReference Update="System.Threading.ThreadPool" Version="4.3.*" />
		<PackageReference Update="Microsoft.Extensions.Logging.Abstractions" Version="[1.1.*,2)" />
	</ItemGroup>
	<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
		<PackageReference Update="Microsoft.Extensions.Logging.Abstractions" Version="2.2.*" />
	</ItemGroup>
</Project>

/src/Directory.Build.props:

<Project>
	<Import Project="../Directory.Build.props" />
	<PropertyGroup>
		<VersionPrefix>1.0.0</VersionPrefix>
		<PackageLicenseFile>LICENSE.txt</PackageLicenseFile>
		<PackageProjectUrl>https://example.com/Project</PackageProjectUrl>
		<RepositoryUrl>https://example.com/Project.git</RepositoryUrl>
		<RepositoryType>git</RepositoryType>
		<PackageReleaseNotes>https://example.com/Project/blob/master/CHANGELOG.md</PackageReleaseNotes>
		<GenerateDocumentationFile>true</GenerateDocumentationFile>
		<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
	</PropertyGroup>
</Project>

/src/Directory.Build.targets:

<Project>
	<Import Project="../Directory.Build.targets" />
	<ItemGroup>
		<None Include="../../LICENSE.txt" Visible="false" Pack="true" PackagePath="$(PackageLicenseFile)" />
		<None Include="../../THIRD-PARTY-NOTICES.txt" Visible="false" Pack="true" PackagePath="THIRD-PARTY-NOTICES.txt" />
		<None Include="../../CHANGELOG.md" Visible="false" Pack="true" PackagePath="CHANGELOG.md" />
	</ItemGroup>
	<ItemGroup>
		<AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
			<_Parameter1>$(MSBuildProjectName).Tests</_Parameter1>
		</AssemblyAttribute>
	</ItemGroup>
</Project>

I haven’t really done anything with the Build.props in the test directory and only listed it for completeness. In the Build.targets however I specified the versions for the test-framework packages. As they are specific to the test projects, so that they do not clutter up the root Build.targets.

/test/Directory.Build.props:

<Project>
	<Import Project="../Directory.Build.props" />
</Project>

/test/Directory.Build.targets:

<Project>
	<Import Project="../Directory.Build.targets" />
	<ItemGroup>
		<PackageReference Update="Microsoft.NET.Test.Sdk" Version="16.0.*" />
		<PackageReference Update="NUnit" Version="3.11.*" />
		<PackageReference Update="NUnit3TestAdapter" Version="3.13.*" />
	</ItemGroup>
</Project>

Project files

Because post of the includes and package config are defined in the .builds and the .targets files the .csproj files are rather slim, only including the name of the NuGet package to include.

Project.csproj:

<Project Sdk="Microsoft.NET.Sdk">
	<PropertyGroup>
		<TargetFrameworks>netstandard1.3;netstandard1.6;netstandard2.0</TargetFrameworks>
		<LangVersion>latest</LangVersion>
	</PropertyGroup>
	<PropertyGroup>
		<Description></Description>
		<PackageId>Project</PackageId>
	</PropertyGroup>
	<ItemGroup>
		<PackageReference Include="System.Memory"/>
	</ItemGroup>
	<ItemGroup Condition="('$(TargetFramework)' == 'netstandard1.6') Or ('$(TargetFramework)' == 'netstandard1.3')">
		<PackageReference Include="System.ValueTuple"/>
	</ItemGroup>
</Project>

Project.Common.csproj:

<Project Sdk="Microsoft.NET.Sdk">
	<PropertyGroup>
		<TargetFrameworks>netstandard1.3;netstandard1.6;netstandard2.0</TargetFrameworks>
		<LangVersion>latest</LangVersion>
	</PropertyGroup>
	<PropertyGroup>
		<Description></Description>
		<PackageId>Project.Common</PackageId>
	</PropertyGroup>
	<ItemGroup>
		<PackageReference Include="System.Buffers"/>
		<PackageReference Include="Microsoft.Extensions.Logging.Abstractions"/>
	</ItemGroup>
	<ItemGroup Condition="('$(TargetFramework)' == 'netstandard1.6') Or ('$(TargetFramework)' == 'netstandard1.3')">
		<PackageReference Include="System.Threading.ThreadPool"/>
	</ItemGroup>
</Project>

Conclusion

Alternatively to specifically importing the targets/props in the parent directory I could have also used the approach described in the Microsoft documentation. But in this case I think <Import Project="../Directory.Build.props" /> reads a bit better than: <Import Project="$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)../'))" />.

Of course this layout will not fit all cases of the get go. But all in all I personally really like the way that the version of a package is specified in a central place. Combined with the Directory.Build.props I can save on some repettetive work.

Configuring Debian 10 (Buster) as a Tor router

Mon, 09 Dec 2019 00:00:00 +0000

Recently I needed to route the traffic of a application through Tor, but said did not support any kind of proxy. So I decided to simply rout all traffic coming from the machine running the app through Tor. To accomplish this I used redsocks a tool to redirect TCP connections to a SOCKS/HTTPS proxy using iptables.

Setup

The setup consists of 2 VMs one acting as the Tor router and the other running the application to be tunnled through Tor.

VM0

The router vm named rtr01, has 2 network interfaces eth0 and eth1. eth0 is connected to the Hypervisor via NAT or Bridge, this interface must be able reach the internet to connect a Tor circuit. eth1 is connected to a virtual switch without internet access.

The router will be configured to act as default gateway for any connected machine and relay the connection through a Tor circuit.

VM1

The application host vm named app01, has only 1 network interface eth0. eth0 is connected to the same virtual switch as eth1 of vm0.

The application host will be connected to the router and use it as default gateway for connection to the internet, that will be relayed through a Tor circuit.

UDP/DNS

Whilst redsocks can be configured to relay UDP traffic for specific destination addresses and ports this is as of writing not supported by tor. This poses a problem for DNS as it is typically UDP:53. The traditional approach of getting DNS to work with redsocks is to use the redsocks internal UDP DNS server that only returns TURNCANATED which should trigger the resolution through TCP. However I found this to be rather unreliable, therefore I opted to use simply use the Tor built-in resolution of DNS.

Configuration

rtr01

The router should be a default fresh install of Debian 10. First off update and install the required packages on the machine.

# apt-get update
# apt-get dist-upgrade -y
# apt-get install -y iptables redsocks tor iptables-persist

The installer should already have configured eth0 as the default interface using DHCP. Next of eth1 will be configured so that the machine can be reached on the virtual switch.

Network

Network range: 192.0.2.0/24 TEST-NET-1

/etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

# The WAN network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The LAN network interface
allow-hotplug eth1
iface eth1 inet static
        address 192.0.2.1
        netmask 255.255.255.0
        network 192.0.2.0
        broadcast 192.0.2.255

Tor

The tor configuration is strait forward as only 2 settings are needed.

# Bind socks proxy on port 9050 of the LAN interface.
SocksPort 127.0.0.1:9050
# Bind dns on port 53 of the LAN interface.
DNSPort 192.0.2.1:53

Tor needs to bind the DNS port to the LAN interface as iptables only redirects the port.

Redsocks

In the redsocks config only the base and a single redsocks section are required. The base section is the Debian default config. And the redsocks section simply redirects all traffic from port 12345 to the Tor socks proxy on port 9059.

base {
        log_debug = off;
        log_info = on;
        log = "syslog:daemon";
        daemon = on;
        user = redsocks;
        group = redsocks;
        redirector = iptables;
}

redsocks {
        // Must bind on the LAN interface as iptables only redirects the ports.
        local_ip = 10.8.42.1;
        local_port = 12345;
        ip = 127.0.0.1;
        port = 9050;
        type = socks5;
}

iptables

First of create a new chain for redsocks, dropping reserved addresses and redirecting everything else to redsocks/tor. Unfortunately redoscks currently does not support IPv6.

# iptables -t nat -N REDSOCKS
# iptables -A REDSOCKS -d 0.0.0.0/8 -j RETURN
# iptables -A REDSOCKS -d 10.0.0.0/8 -j RETURN
# iptables -A REDSOCKS -d 127.0.0.0/8 -j RETURN
# iptables -A REDSOCKS -d 169.254.0.0/16 -j RETURN
# iptables -A REDSOCKS -d 172.16.0.0/12 -j RETURN
# iptables -A REDSOCKS -d 192.168.0.0/16 -j RETURN
# iptables -A REDSOCKS -d 224.0.0.0/4 -j RETURN
# iptables -A REDSOCKS -d 240.0.0.0/4 -j RETURN
# iptables -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345

To redirect all TCP connection coming in on eth1 to Tor the following PREROUTING rule is applied.

# iptables -A PREROUTING -s 192.0.2.0/24 -p tcp -j REDSOCKS

Redirect DNS requests to TOR.

# iptables -A PREROUTING -s 192.0.2.0/24 -p udp --dport 53 -j REDIRECT --to-ports 53

Finally safe the ruleset.

# iptables-save > /etc/iptables/rules.v4

Afterword

One disadvantage of this approach is that there is no way for a client to instruct Tor to establish a new circuit in case the current one is compromised, this could however be remedied by periodically switching the circuit.

Analyse des Netzwerkverkehrs der RWE Smarthome Zentraleinheit V1

Tue, 07 May 2019 00:00:00 +0000

Bei der RWE Smarthome Zentraleinheit V1 handelt es sich uim eine von RWE vertriebene Hausautomatisierungs Lösung. Die Zentraleinheit kommuniziert mit den verschiedenen Geräten über 868.3 MHz. Die Steuerung von verschiedenen Ereignissen findet intern statt. Die Zentraleinheit kann auf intern, von Geräten oder per Zeitsteuerung, extern, über eine Weboberfläche https://home.innogy-smarthome.de angestoßene, ausgelöste Ereignisse reagieren. Die Zentraleinheit kann eigenständig ohne Internet agieren, dabei allerdings nicht länger auf externe Ereignisse reagieren. Die Einheit besitzt ebenso einen physikalischen Schalter zum Deaktivieren der Internetverbindung, allerdings unterbindet dieser lediglich auf Softwareebene die Verbindung zu den RWE Kontrollservern.

Frontalansicht der Zentraleinheit:

Seitenansicht der Zentraleinheit mit Anschlüssen:

Kommunikations Endpunkte

189.146.13	0.rwesmarthome.pool.ntp.org
81.173.155	0.rwesmarthome.pool.ntp.org
121.7.182	0.rwesmarthome.pool.ntp.org
60.22.240	0.rwesmarthome.pool.ntp.org
239.212.164	blob.ams20prdstr08a.store.core.windows.net
25.80.70	services.rwe-smarthome.de
25.80.73	relay.rwe-smarthome.de

Bei dem Endpunkt blob.ams20prdstr08a.store.core.windows.net handelt es sich um einen Microsoft Azure data-store, dieser wurde zm Download des Firmwareupdates verwendet. Im normalen Betriebsmodus is der Verwendungszweck nicht eindeutig identifizierbar.

Die Endpunkte 0.rwesmarthome.pool.ntp.org werden wie aus dem aufgelösten Namen bereits hervorgeht für NTP Auflösung verwendet.

Die Endpunkte services.rwe-smarthome.de und relay.rwe-smarthome.de dienen vermutlich zur Kontrolle der Zentraleinheit über die Kontrollserver von RWE.

Verwendete Protokolle

Bei einem mitschnitt des Netzwerkverkehrs der Zentraleinheit während eines Firmwareupdates und anschließendem normalen Betriebs tauchten folgende Protokolle auf:

NTP
MDNS
DNS
Bootstrap Protocol
SSL

Für den zur Verfügung gestellten Dienst werden Primär die Endpunkte services.rwe-smarthome.de, relay.rwe-smarthome.de und blob.ams20prdstr08a.store.core.windows.net verwendet. Alle Verbindungen zu diesen Endpunkten sind mit einer Form von SSL gesichert. Allerdings verwenden alle Verbindungen lediglich 3DES. Da auch Verbindungen zu Microsoft Servern keine bessere Cipher Suite verwenden ist davon auszugehen das die Firmware selbst entweder keine besseren Cipher Suites auswählt oder gar Unterstützt.

`blob.ams20prdstr08a.store.core.windows.net`

Zertifizierungsstelle: Microsoft IT TLS CA 2 und Baltimore CyberTrust Root
Zertifikat ausgestellt an: *.blob.core.windows.net
Verwendete Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA
Verwendung vom 3DES macht die Chipher anfällig gegen einen Angriff mit Sweet32. Ebenso ist die eigentliche Schlüssellänge aufgrund von Parity Bits reduziert.
Verwendete SSL-Version: TLS 1.0
Die Verwendete SSL-Version ist veraltet und es existieren bekannte Angriffe, und sollte nicht länger verwendet werden.

`services.rwe-smarthome.de`

Zertifizierungsstellen: SHMPROD-CA-E
Zertifikat ausgestellt an: services.rwe-smarthome.de
Verwendete Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA
Verwendung vom 3DES macht die Chipher anfällig gegen einen Angriff mit Sweet32. Ebenso ist die eigentliche Schlüssellänge aufgrund von Parity Bits reduziert.
Verwendete SSL-Version: TLS 1.0
Bewertung: Die Verwendete SSL-Version ist veraltet und es existieren bekannte Angriffe, und sollte nicht länger verwendet werden.

`relay.rwe-smarthome.de`

Zertifizierungsstellen: SHMPROD-CA-E
Zertifikat ausgestellt an: relay.rwe-smarthome.de
Verwendete Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA
Verwendung vom 3DES macht die Chipher anfällig gegen einen Angriff mit Sweet32. Ebenso ist die eigentliche Schlüssellänge aufgrund von Parity Bits reduziert.
Verwendete SSL-Version: TLS 1.0
Die Verwendete SSL-Version ist veraltet und es existieren bekannte Angriffe, und sollte nicht länger verwendet werden.

Durchgeführt im Rahmen der Veranstaltung Praktikum IT-Sicherheit der Hochschule Trier.

Continuous deployment of a ASP.NET core website

Tue, 08 Aug 2017 00:00:00 +0000

This guide will elaborate on how to automatically deploy a ASP.NET core website to a Linux host using GitLab and gitlab-ci-multirunner.
Dotnet website files located in /var/www may be different for your deployment, adjust accordingly. This guide assumes your website is already ready to be deployed, that you have a basic understanding of Linux and are comfortable with the console. You will need to substitute some variables in the templates and file names marked by <name-of-variable>.

Dependencies

A Linux host with root access
Dotnet version required to run the website installed on the host. (Assumes an existing symlink to dotnet in /usr/local/bin/dotnet, adjust accordingly)
A GitLab repository
The gitlab-ci-multi-runner package installed on the host. (With Debian stretch the runner package is part of the regular repository in systemd unit)
The GitLab runner configured to the GitLab instance with the shell runner. It is adviced to make the runner specific to the website repository and give it a unique tag. A good unique tag would be the domain that the website will be reachable from.
Nginx or other web server. If you wish to use another web server besides Nginx adjust the permissions in /etc/sudoers and commands in .gitlab-ci.yml accordingly.
Sudo installed on the host.

Configuration

Preparing the host

First create a systemd unit to control your website on the Linux host from the template below.
If you have dotnet installed through a package manager remember to adjust the dotnet path in ExecStart

[Unit]
Description=example website

[Service]
WorkingDirectory=/var/www

# Make sure the web server user owns the files for the website
ExecStartPre=/bin/chown www-data:www-data -R /var/www/
ExecStart=/usr/local/bin/dotnet /var/www/<name.of.website>.dll

# Automatically restart the website if it crashes
Restart=always
RestartSec=10
SyslogIdentifier=dotnet-website
User=www-data
# Only run the start command as www-data
PermissionsStartOnly=true

# We want asp.net to run with the production settings
Environment=ASPNETCORE_ENVIRONMENT=Production

[Install]
WantedBy=multi-user.target

Now we need to adjust the permissions of the gitlab-runner user to allow him to control the files needed by the website and hand permission back to the web server user after the deployment. The handing back of the permissions is done in the systemd unit. For that we need to adjust /etc/sudoers to allow for no password execution of specific commands, simply add the line below to the sudoers file. With that the basic setup of the host is complete, below is an example Nginx config.

gitlab-runner ALL=NOPASSWD: /bin/systemctl stop <name-of-service>, /bin/systemctl start <name-of-service>, /bin/systemctl stop nginx, /bin/systemctl start nginx, /bin/chown gitlab-runner\\:gitlab-runner -R /var/www

An example Nginx config to proxy requests to the running dotnet instance.

location /
{
    proxy_redirect      off;
    proxy_set_header    Host                    $host;
    proxy_set_header    X-Real-IP               $remote_addr;
    proxy_set_header    X-Forwarded-For         $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Protocol    $scheme;
    proxy_set_header    X-Url-Scheme            $scheme;
    proxy_set_header    X-Forwarded-Port        $server_port;
    proxy_pass          http://[::1]:5000;
}

The GitLab CI script

After the host is configured all that is left to do is to tell the GitLab server to execute the CI build on any build server and the on the deployment server. For that we can use .gitlab-ci.yml. The script below assumes the usage of Nginx and the dotnet standard repository layout. The script will build the website on any runner (shared included) with the dotnet tag. After that the build files will be uploaded to the GitLab server, then the specific runner, our host, will pick up the next stage. But only on the master branch as we don’t want to publish the website on every commit. The runner will then stop the web server, dotnet and update the permissions of the old files, delete the old files and move the new files in place and restart all stopped services. The script need to be located at the root of the repository.

stages:
  - build
  - release

build:
  stage: build
  script:
  - 'dotnet publish --output $(pwd)/src/<Name-of-Project>/bin/Release/Publish/ -c Release'
  tags:
  - dotnet
  artifacts:
    name: "${CI_PROJECT_NAME}_${CI_BUILD_REF_NAME}"
    expire_in: 7d
    paths:
    - "./src/<Name-of-Project>/bin/*"

release:
  stage: release
  script:
  - 'sudo /bin/systemctl stop nginx'
  - 'sudo /bin/systemctl stop <name-of-service>'
  - 'sudo /bin/chown gitlab-runner:gitlab-runner -R /var/www'
  - 'rm -rf /var/www/*'
  - 'mv ./src/<Name-of-Project>/bin/Release/Publish/* /var/www/'
  - 'sudo /bin/systemctl start <name-of-service>'
  - 'sudo /bin/systemctl start nginx'
  tags:
  - <unique-tag-of-build-server>
  only:
  - master
  dependencies:
  - build

Afterword

The great thing about using the GitLab runner is that if for whatever reason one of your changes to the website breaks it, you can simply roll back to any older version by executing that pipeline again. Another thing that can be done is to make the server host multiple websites at once, which can a bit of a security risk because the build server need to be allow to control all website files. Which could be misused to disable other websites hosted on the server, which is only a concern if users are allowed to freely edit the CI script in gitlab.

Shared hosting

If you want to make the host a shared host, than you need to tell dotnet to listen on a different port per installation. That can be achieved multiple ways, in this guide we will use command line arguments. For that we need to firstly tell dotnet to use command line arguments by telling WebHost to use a IConfigurationRoot created by the command line arguments. After that the website can be configured from the command line, mainly the listen address can be specified in the service file. It is important where the argument is added, in case of dotnet it need to be after the path to the website dll. Now to change the listen address append --urls "http://[::1]:5001" to ExecStart. This causes dotnet to only listen on IPv6 localhost and port 5001, multiple listen addresses an be specified by separating them with ;. It is also required to adapt the proxy address accordingly, that is left for the reader to do as an exercise. Another thing that need to be adapted is /etc/sudoers to allow for the new commands needed to start/stop multiple services.

Adding IConfigurationRoot

public static IWebHost BuildWebHost(string[] args)
{
  IConfigurationRoot config = new ConfigurationBuilder()
    .AddCommandLine(args)
    .Build();
  return WebHost.CreateDefaultBuilder(args)
    .UseConfiguration(config)
    .UseStartup<Startup>;()
    .Build();
}

Flatcar Nomad Cluster Virtual Environment

Thu, 01 Jan 1970 00:33:45 +0000

Flatcar Nomad Cluster Virtual Environment

GIP SARL - Cyber Defense as a Service

Thu, 01 Jan 1970 00:33:42 +0000

GIP SARL - Cyber Defense as a Service

A TSIG DNS record manager daemon

Thu, 01 Jan 1970 00:33:39 +0000

A TSIG DNS record manager daemon

ESignboard - An E-Ink display manager

Thu, 01 Jan 1970 00:33:38 +0000

ESignboard - An E-Ink display manager

XMPP - TeamSpeak bidirectional bridge

Thu, 01 Jan 1970 00:33:37 +0000

XMPP - TeamSpeak bidirectional bridge

Manga Lector - A Manga reader with integrated downloader

Thu, 01 Jan 1970 00:33:35 +0000

Manga Lector - A Manga reader with integrated downloader

LYFR

Use KeePass to automatically open authenticated nsupdate

Prerequisites

KeePass configuration

Dotnet project layout with MSBuild 15+

Directory.Build.props and Directory.Build.targets files.

Project files

Conclusion

Configuring Debian 10 (Buster) as a Tor router

Setup

VM0

VM1

UDP/DNS

Configuration

rtr01

Network

Tor

Redsocks

iptables

Afterword

Analyse des Netzwerkverkehrs der RWE Smarthome Zentraleinheit V1

Kommunikations Endpunkte

Verwendete Protokolle

blob.ams20prdstr08a.store.core.windows.net

services.rwe-smarthome.de

relay.rwe-smarthome.de

Continuous deployment of a ASP.NET core website

Dependencies

Configuration

Preparing the host

The GitLab CI script

Afterword

Shared hosting

Flatcar Nomad Cluster Virtual Environment

GIP SARL - Cyber Defense as a Service

A TSIG DNS record manager daemon

ESignboard - An E-Ink display manager

XMPP - TeamSpeak bidirectional bridge

Manga Lector - A Manga reader with integrated downloader

`Directory.Build.props` and `Directory.Build.targets` files.

`blob.ams20prdstr08a.store.core.windows.net`

`services.rwe-smarthome.de`

`relay.rwe-smarthome.de`