Artikel mit Tag konfiguration

NGINX - Webserver, Load Balancer und Proxy

NGINX ist neben Apache einer der bekanntesten Webserver. Allerdings kann das Tool mehr als nur ein schlichter Webserver sein. Reverse Proxy, Load Balancer, Mail Proxy oder HTTP cache Server sind ein paar wenige Funktionen die Nginx beherrscht.

Ich möchte euch heute ein paar Beispiele zu einzelnen Funktionen zeigen. Den Anfang macht logischerweise die Installation. Als System verwende ich einen Ubuntu 20.04 LTS Server.

 

Nginx

 

Installation Nginx unter Ubuntu/Debian

Die Installation der frei verfügbaren Version (Die kommerzielle Variante nennt sich Nginx Plus) erfolgt über das Nginx Repository.

sudo wget https://nginx.org/keys/nginx_signing.key

sudo apt-key add nginx_signing.key

sudo nano /etc/apt/sources.list.d/nginx.list

  deb https://nginx.org/packages/mainline/ubuntu/ focal nginx
  deb-src https://nginx.org/packages/mainline/ubuntu/ focal nginx
              
sudo apt install nginx

sudo systemctl is-enabled nginx.service

sudo systemctl enable nginx

Nach der Installation erfolgt eine schnelle Kontrolle.

ss -ltn
ubuntu:~$ curl -I http://127.0.0.2

HTTP/1.1 200 OK
Server: nginx/1.19.6
Date: Thu, 17 Dec 2020 22:20:49 GMT
Content-Type: text/html
Content-Length: 612

Nginx selbst kompilieren

Es besteht auch die Möglichkeit, das Nginx Paket selbst zu kompilieren. Dies wird dann nötig, wenn Pakete benötigt werden, die in der Standardvariante nicht enthalten sind. Die war zum Beispiel bei der Verwendung von GeoIP oder LibreSSL mal bzw. ist noch so.

Mit dem folgenden Befehl können die installierten Module eingesehen werden.

Nginx –V

In der Standardinstallation sollte hier das Modul --add-dynamic-module=/build/nginx-5J5hor/nginx-1.18.0/debian/modules/http-geoip2 angezeigt werden. D.h. das eingangs erwähnte Geo IP Modul wird hier bereits geladen.

Einen eigenen Nginx Server unter Debian/Ubuntu einrichten

Nach einer erfolgreichen Installation zeigt Nginx eine Standardseite an. Diese kann gelöscht oder zusätzlich eine eigene virtuelle Seite angelegt werden. Auf einer IP können so mehrere Webseiten gehostet werden.

Folgende Struktur bietet sich unter Ubuntu an:

Konfiguration der einzelnen virtuellen Server.

/etc/nginx/sites-available/xyz

Momentan aktive Server wobei es sich hier um einen Symlink handelt.

/etc/nginx/sites-enabled/xyz

Schritt für Schritt heißt dies für einen Server welche auf Port 80 lauscht:

#config anlegen
touch /etc/nginx/sites-available/itrig

#config schreiben
nano /etc/nginx/sites-available/itrig

server {

        listen 80 default_server;    

        # Make site accessible from http://localhost/

        server_name localhost;
        location / {
            root /usr/share/nginx/html;
            index index.html index.htm;
        }
}

#aktiv setzen
ln -s /etc/nginx/sites-available/itrig /etc/nginx/sites-enabled/itrig

Konfiguration überprüfen

nginx –t

Neustart der Konfiguration mit

#lädt nur die neue Konfiguration
nginx –s reload

oder

sudo systemctl reload nginx


Nginx als Loadbalancer verwenden

Neben der reinen Webserverfunktion bietet NGINX die Möglichkeit den Server, als Loadbalancer zu betreiben. Da heißt der Server sorgt für Ausfallsicherheit bzw. Leistung von Webanwendungen, in dem er die Last verteilt. Vorstellen kann man sich dies wie einen Haupthändler, welcher Daten unter verteilt.

LoadbalancerNginx bietet mehrere Varianten an, wie diese Verteilung geschehen kann.

Round Robin

Das bekannteste dürfte das Round Robin Verfahren sein. Es wird eine Liste von Servern durchgearbeitet und die Last nach und nach verteilt. Ist die Liste zu Ende, fängt der Server wieder am Anfang an.

Im unteren Beispiel werden 3 Server in der Gruppe "itrigloadbalancer" zusammengefasst und der Webserver geht diese Liste nach und nach durch. Unterstützt werden die Protokolle HTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached, und gRPC.

http {
    upstream itrigloadbalancer {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://itrig.de;
        }
    }
}

Least Connected

Eine weitere Lastverteilung ist das Least-Connected-Verfahren. Hier wird auf die aktiven Verbindungen der einzelnen Server geschaut. Der Server, welcher die geringste Anzahl an aktiven Verbindungen hat, bekommt die Anfrage zugeschanzt.

upstream intrigleastload {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

Session-Persistenz - IP Hash

Die dritte Möglichkeit Last zu verteilen, stellt das IP-Hash-Verfahren dar. Hier werden von den zugreifenden Client IPs Hash Werte erstellt. Anhand dieser Werte wird einem Client immer ein bestimmter Server zugewiesen. Damit erhält der Nutzer eine Session Persistenz, da Anfragen immer vom gleichen Server beantwortet werden.

Beim Round-Robin- oder Least-Connected-Load-Balancing kann jede nachfolgende Anfrage eines Clients potenziell auf einem anderen Servern ankommen.

upstream itrighash {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Weighted load balancing

Alle Varianten lassen sich zusätzlich gewichten. So kann es vorkommen, dass ein Server eine bessere Hardware verbaut hat, als ein anderer. Mit Weighted load balancing lässt sich einzelnen Geräten mehr Last zuschieben.

upstream itrigmitgewicht {
        server srv1.example.com;
        server srv2.example.com weight=3;
        server srv3.example.com;
    }
upstream itrig {
    ip_hash;
    server srv1.example.com weight=2;
    server srv2.example.com;
    server srv3.example.com;
}

Mehr zu der Thematik unter load_balancing.


Nginx als Reverse Proxy verwenden

Den aufmerksamen Lesern dürfte aufgefallen sein, dass in einem Code Beispiel weiter oben eine Zeile mit "proxy_pass" vorhanden ist. Diese Zeile deutet darauf hin, dass NGINX als Reverse Proxy eingesetzt wird und ein Aufruf nicht direkt auf dem Server landet, sondern weitergeleitet wird.

location /webshop {
proxy_pass http://opencart.itrig.local;
}

location /landkarte {
proxy_pass http://192.168.100.99;
}

Es gibt verschiedene "Vorteile" für so eine Weiterleitung.

So kann der Nginx als HTTPS Endpunkt dienen und die Struktur dahinter kann unverschlüsselt agieren. Auch bietet NGINX die Möglichkeit als Reverse Proxy und als Load Balancer gleichzeitig zu arbeiten, die Details sind weiter oben zu lesen.

Weiter erlaubt der vorgeschaltete Server eine Caching Funktion, was zum schnelleren Ausliefern von Webseiten beitragen kann.

Hier ein Beispiel mit gesplittetem Cache aus der offiziellen NGINX Cache Dokumentation.

proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m
                 max_size=10g inactive=60m use_temp_path=off;
proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m
                 max_size=10g inactive=60m use_temp_path=off;

split_clients $request_uri $my_cache {
              50%          “my_cache_hdd1”;
              50%          “my_cache_hdd2”;
}

server {
    # ...
    location / {
        proxy_cache $my_cache;
        proxy_pass http://my_upstream;
    }
}

Das Thema Sicherheit spielt ebenso eine Rolle, da durch den vorgeschalteten Server, die Angriffsfläche kleiner gehalten wird.


NGINX mit Regex

Richtig interessant wird es, sobald die aufgerufene URL verschiedene Eigenschaften besitzt bzw. ein besonderes Verhalten zeigen sollte.

Diese Eigenschaften werden mit regulären Ausdrücken umgesetzt.

Hier sind ein paar Beispiele von regulären Ausdrücken für NGINX :

# Die URL ist durch * case insensitive
 location ~* /itrig/ {
    #...
    #...
    }

# Die URL ist case sensitive das ^ sorgt dafür das nur z.B. /itrig/logo.jpg gültig ist und nach dem ersten Match gestoppt wird.
 location ^~ /itrig/ {
    #...
    #...
    }

# Bilder anhand der Endung umleiten
 location ~ \.(gif|jpg|png)$ {
    root /data/images;
    }

# Unnötige Endungen aussperren (case insensitive)
 location ~* "\.(old|orig|original|php#|php~|php_bak|save|swo|aspx?|tpl|sh|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rdf)$" {
    deny all;
    }

# Einen Alias setzen
 location /_/static {
        alias /path/to/glory;
    }

# Rewrite einer URL,  "pfad" wird entfernt
    location /pfad {
        rewrite ^/pfad(.*)$ $1 break;
        proxy_pass http://splunk-api:8080;
    }

Es bietet sich immer an, eigene Befehle zu testen, bevor sie produktiv eingesetzt werden, denn neben Einschränkungen auf URLs kann ebenso Haus und Hof geöffnet werden.

Ein Regex Test sollte daher immer gemacht werden. Hier findet sich so ein Tool online regex.datahoarder.dev.

Das Tool kann jederzeit auf der eigenen Umgebung gehostet werden und ist auf Github zu finden.

Nginx_Regular_Expression_Tester

 

netplan unter Ubuntu Server 18.04 LTS konfigurieren oder entfernen

Seit einiger Zeit stellt Canonical für seine Distributionen die Netzwerkkonfiguration via netplan bereit.

Mit der Einführung der Serverversion 18.04 LTS ist diese fester Bestandteil der Long Term Support Edition.

Doch wo ist der Unterschied zur alten Konfiguration und welche Befehle werden benötigt?

netplan.iologo

netplan.io

Anders als die alten Netzwerkkonfigurationsdateien, beruht netplan auf der YAML Syntax. Außerdem werden als Renderer Networkmanager (Desktop), sowie system-networkd (Server) unterstützt.

Die Funktion ist relativ schnell erklärt: Beim Bootvorgang wird aus allen yaml Dateien  /etc/netplan/*.yaml eine Konfiguration generiert und unter /run abgelegt.

Die Konfiguration lässt sich aber auch im laufenden Betrieb anpassen.

Eine klassische Konfigurationsdatei /etc/netplan/01-netcfg.yaml mit fester IP-Adresse würde wie folgt aussehen:

system
network:
        version: 2
        renderer: networkd
        ethernets:
                eth0:
                        dhcp4: no
                        dhcp6: no
                        addresses: [192.169.1.100/16]
                        gateway4: 192.169.1.1
                        nameservers:
                                search: [itrig.lokal]
                                addresses:
                                    - "1.1.1.1"
                                    - "4.4.4.4"

Als Renderer ist in diesem Fall networkd hinterlegt, es kann aber genauso renderer: NetworkManager angegeben werden, beispielsweise bei einem Desktop Betriebssystem.

Die Notation des Subnetzes erfolgt hier im CIDR Format. Als kleine Hilfestellung hier eine Tabelle wink

Prefix   | Subnet mask IPv4 | Subnet mask IPv6
/24      | 255.255.255.0    | 11111111.11111111.11111111.00000000
/25      | 255.255.255.128  | 11111111.11111111.11111111.10000000
/26      | 255.255.255.192  | 11111111.11111111.11111111.11000000
/27      | 255.255.255.224  | 11111111.11111111.11111111.11100000
/28      | 255.255.255.240  | 11111111.11111111.11111111.11110000
/29      | 255.255.255.248  | 11111111.11111111.11111111.11111000
/30      | 255.255.255.252  | 11111111.11111111.11111111.11111100
/31      | 255.255.255.254  | 11111111.11111111.11111111.11111110
/32      | 255.255.255.255  | 11111111.11111111.11111111.11111111

Um die neue Konfiguration zu generieren und anzuwenden werden folgende Befehle verwendet.

sudo netplan generate
sudo netplan apply

Eine Kontrolle kann mit neuen

sudo netplan try

sudo netplan --debug apply

sudo netplan config show

oder alternativ auch mit alten Befehlen erfolgen.

ip a

Hier gilt zu beachten, dass netplan apply keine virtuellen Geräte wie Netzwerkbrücken oder Netzwerkbündel entfernt, auch wenn sie nicht mehr in der Netplan Konfiguration stehen.

Hier muss momentan noch mit ip link delete dev bond0 operiert werden.

netplan.io

 

/etc/network/interfaces

Zum Vergleich eine alte Konfiguration, welche unter  /etc/network/interface zu finden ist.

auto lo eth0
iface lo inet loopback
iface eth0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    network 192.168.1.0
    gateway 192.168.1.1
    #dns-nameservers 1.1.1.1 8.8.8.8
    dns-search itrig.lokal


netplan.io entfernen oder deaktivieren

Es besteht die Möglichkeit die oben beschriebene frühere Variante weiter zu verwenden. So bleibt eine alte Konfiguration beispielsweise bei einem Update von 16.04 auf 18.04 erhalten.

Bei einer Neuinstallation von 18.04 LTS kann ein Administrator ebenso auf die alte Variante schwenken, dazu muss das benötigte Paket installiert werden.

sudo apt-get install ifupdown

sudo apt -y purge netplan.io

Nun kann die Netzwerkkonfiguration unter /etc/network/interfaces abgelegt werden, sowie ein Neustart des Dienstes erfolgen.

sudo systemctl restart networking

[Update]

Zu Bedenken sind noch die DNS Settings, welche unter /etc/systemd/resolved.conf  abgelegt wurden, was sich unter Ubuntu 18.04 im Vergleich zu früher geändert hat.

Die Datei kann wie folgt modifiziert werden

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
DNS=8.8.8.8 1.1.1.1 8.8.4.4
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

Nun den Dienst neu starten und die DNS Server überprüfen

sudo systemctl restart systemd-resolved.service
sudo systemd-resolve --status

Alternativ kann auch das resolv Paket installiert werden.

sudo apt install resolvconf

Danach kann die Datei /etc/resolvconf/resolv.conf.d/head editiert und angepasst werden.

# Make edits to /etc/resolvconf/resolv.conf.d/head.
nameserver 1.1.1.1 
nameserver 8.8.8.8
sudo service resolvconf restart

Nun sollten die Netzwerkeinstellungen wieder der von Ubuntu 16.04 LTS oder 14.04 LTS entsprechen.

Ubuntu - immer Up2date mit unbeaufsichtigten Updates

Die Woche war lang und das Wochenende hat schon einen Fuß in der Tür. 
Dennoch ein kleiner Tipp zum Freitag.

Damit ein System auf einem aktuellen Stand bleibt und keine Sicherheitslücken aufweist, müssen regelmäßig Updates installiert werden.
Dies kann händisch via apt-get upgrade oder mit Orchestrierungs- Lösungen alà Landscape (siehe Artikel), Ansible und Co gelöst werden.


Ubuntu selbst bringt allerdings ebenfalls Funktionen mit, ein System mit den neuesten Updates zu versorgen.
Bei kleinen Netzwerken mit drei bis vier Ubuntu Systemen, bietet sich diese Möglichkeit durchaus an, denn Landscape und Co wären hier zuviel des Guten.

Unattended Updates unter Ubuntu nutzen

Das Paket "unattended-upgrades" ermöglicht die automatische Installation von Updatepaketen.
Aber nicht nur die Installation, sondern auch Neustarts und Prioritäten von Updatepaketen können darüber definiert werden.

unattended-updates-einrichtungBevor das Paktet konfiguriert werden kann, sollte es installiert werden.

sudo apt-get install unattended-upgrades apt-listchanges

Nach der Installation wird eine Config Datei benötigt. Diese kann händisch angelegt werden oder automatisch mit

sudo dpkg-reconfigure -plow unattended-upgrades

Creating config file /etc/apt/apt.conf.d/20auto-upgrades with new version

angelegt werden. Hier erscheint eine zusätzliche Abfrage auf dem Bildschirm (siehe Screenshot).

Bei einem Blick auf die nun generierte Datei finden sich ein paar Einträge.

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

 
Hier muss eigentlich Nichts weiter angepasst werden.
Nutzer die bereits apticron in Verwendung haben, könnten die erste Zeile theoretisch entfernen, da über dieses Paket bereits die Listen regelmäßig aktualisiert werden

Konfiguration von unbeaufsichtigten Updates

Jedoch wird eine weitere Datei angelegt, in der diverse Einstellungen gemacht werden sollten.

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
  • In diesem Beispiel werden nur Sicherheitsupdates automatisch installiert.
  • Danach wird eine Mail an root versendet.
  • Im Fehlerfall wird ebenfalls eine Nachricht versendet (der Punkt // Unattended-Upgrade::MailOnlyOnError "true"; sollte auskommentiert bleiben).
  • Nicht mehr verwendete Abhängigkeiten werden mit diesen Einstellungen automatisch entfernt.
  • Um den automatischen Updatevorgang abzuschließen, wird das System um 3:30 Uhr neu gestartet.

Alle aktiven Punkte sind fett markiert.



// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";

//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};


// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";

// Install all unattended-upgrades when the machine is shuting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
// Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// Automatically reboot *WITHOUT CONFIRMATION*
//  if the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

Viel mehr muss nicht konfiguriert werden. Sollte ein Update gelaufen sein, wird automatisch eine E-Mail versendet, welche über die gelaufenen Updates oder entstandene Fehler informiert.

unattended-updates-linux


 

pgAdmin4 - Installation und ein erster Blick auf die neue PostgreSQL Schaltzentrale

Vor gut einem Monat ist die erste Beta Version von pgAdmin erschienen.
Die neue Version 4 (der mittlerweile in die Jahre gekommenen Version 3) wurde komplett überarbeitet und neu geschrieben.

Inzwischen wurde Beta 3 veröffentlicht, höchste Zeit einen kurzen Blick auf die Installation und das neuen Design zu werfen.

pgadmin4-logoDie Schaltzentrale für PostgreSQL Datenbanken hat einen modernen Anstrich erhalten und zeigt sich bei einem ersten Blick auf die neue Weboberfläche recht übersichtlich. So stellt das neue Dashboard die wichtigsten Aktivitäten auf einer Datenbank live dar. Die Ansicht ist responsive und erlaubt somit auch den Aufruf via Tablet und Co.

Insgesamt wurde auf eine einfache und übersichtliche Darstellung geachtet, so sind viele Einstellungen via Schieberegler zu aktivieren (siehe Screenshot).

Auch die Flexibilität wurde stark erhöht. Tabs lassen sich nun beliebig auf der Oberfläche verschieben und platzieren.

Besonders zu erwähnen ist die doppelte Funktion von pgAdmin. Es kann als Webserverwendung oder Clientsoftware genutzt werden.

pgadmin4-stats

Die komplett überarbeitete DB Software wurde in Python geschrieben und verwendet das  Flask Framework als Backend. Das Frontend besteht aus dem bekannten Mix von Javascript und jQuery.

Durch das moderne Redesign von pgAdmin sind aber auch ein paar wenige Funktionen auf der Strecke geblieben, so stehen der Query Builder, sowie der Datenbank Designer nicht mehr zur Verfügung.

pgadmin4-einstellungen

Die Installation

fällt durch die Hilfe von PIP recht leicht und kann in wenigen Schritten erledigt werden.

Zunächst müssen die benötigten Pakete geladen werden. Dazu zählt natürlich ein Datenbank Server, sowie der Python Pakete Manager PIP. Basis System ist Ubuntu 16.04 LTS.

sudo apt-get install postgresql-9.5
sudo apt-get install python-pip
sudo apt-get install libpq-dev
wget https://ftp.postgresql.org/pub/pgadmin3/pgadmin4/v1.0-beta3/pip/pgadmin4-1.0b3-py2-none-any.whl

Alte Versionen sind hier zu finden

https://ftp.postgresql.org/pub/pgadmin3/pgadmin4/v1.0-beta1/pip/pgadmin4-1.0_beta1-py2-none-any.whl
https://ftp.postgresql.org/pub/pgadmin3/pgadmin4/v1.0-beta2/pip/pgadmin4-1.0b2-py2-none-any.whl

Nun folgt die Paketinstallation

pip install pgadmin4-1.0_beta3-py2-none-any.whl
Please add the directory containing pg_config to the PATH

or specify the full executable path with the option:

    python setup.py build_ext --pg-config /path/to/pg_config build ...

or with the pg_config option in 'setup.cfg'.

pgadmin4-installation

Vor dem ersten Start muss eine Config Datei angelegt werden

cd /usr/local/lib/python2.7/dist-packages/pgadmin4
touch config_local.py

Diese lokale Konfiguration muss auf jeden Fall folgende Werte enthalten:

SECRET_KEY = 'GeheimesGeheimnis2'
SECURITY_PASSWORD_SALT = 'GeheimesGeheimnis3'
CSRF_SESSION_KEY = 'GeheimesGeheimnis1'

Die vorhandenen Werte können der config.py entnommen werden

cat config.py |grep CSRF
CSRF_SESSION_KEY = 'GeheimesGeheimnis1'

cat config.py |grep SECRET_KEY
SECRET_KEY = 'GeheimesGeheimnis2'

cat config.py |grep SECURITY_PASSWORD_SALT
SECURITY_PASSWORD_SALT = 'GeheimesGeheimnis3'

Weitere Konfigurationen, wie beispielsweise eine andere Serveradresse "DEFAULT_SERVER = '0.0.0.0" müssen nicht zwingend hinterlegt werden, hier gelten die Default Werte aus der Hauptkonfiguration. 

Bei einem Betrieb als Webserver sollten die einzelnen Einstellungen genau unter die Lupe genommen werden.

Danach kann die Anwendung zum ersten Mal gestartet werden

    cd /usr/local/lib/python2.7/dist-packages/pgadmin4
    python ./pgAdmin4.py

            pgAdmin 4 - Application Initialisation
            ======================================


            The configuration database - '/home/lars/.pgadmin/pgadmin4.db' does not exist.
            Entering initial setup mode...
            NOTE: Configuring authentication for SERVER mode.

            Enter the email address and password to use for the initial pgAdmin user account:

            Email address: xxx@test.de

Ein Aufruf der Anwendung erfolgt über den Browser

http://127.0.0.1:5050

Die Anmeldung erfolgt mit den bei der Ersteinrichtung hinterlegten Daten.

Für die Einrichtung und Verwendung des neuen pgAdmin4 wurde bereits eine ausführliche Dokumentation zur Verfügung gestellt.

Fazit

Über den Release Termin der finalen Version konnte ich leider keine Informationen finden. Die aktuelle Beta Version sieht schick aus, besticht durch ihre aufgeräumte Oberfläche und macht Lust auf mehr. Auch für Windowsnutzer steht bereits eine lauffähige Testversion zur Verfügung.

Nun heißt es warten auf die finale Version, um ein endgültiges Fazit ziehen zu können. Bis jetzt ist die Tendenz sicherlich positiv.

Lynis 2.2.0 - Neue Version zur Linux Systemhärtung verfügbar

Das Auditing Tool Lynis hat ein Major Update erhalten und ist bei Version 2.2.0 angelangt.

Ich hatte diesen Sicherheitscheck für Linux Systeme bereits im Blog vorgestellt.

Lynis prüft auf unsichere Einstellungen, Konfigurationsfehler und gibt Tipps zur Absicherung des Systems.

Alle Schritte können im Prinzip auch händisch vorgenommen werden. Für einen schnellen und automatisierten Audit, bietet sich das Tool aber durchaus an.

lynis

Die Version 2.2.0 unterstützt nun Debian 8 Installationen und erkennt VMware Umgebungen. Die Überprüfung von FreeBSD wurde verbessert, sowie weitere Prüfbereiche (z.B. NTP oder USB) ergänzt. Hier geht es zum Changelog.

Lynis - Installation und Anwendung

Die Installation ist wie so oft recht einfach.

wget https://cisofy.com/files/lynis-2.2.0.tar.gz

sha256sum lynis-2.0.0.tar.gz

Hash Summe auf der Homepage gegenprüfen und dann entpacken

tar -xvf lynis-2.2.0.tar.gz

cd lynis

./lynis

Beim Ausführen ohne Parameter werden alle Zusatz- Kommandos angezeigt über die das Programm verfügt. Die üblichen zur Überprüfung des Systems wären beispielsweise:

./lynis --check-all

./lynis --check-all --quick (kein Enter notwendig)

./lynis audit dockerfile datei (Docker Container prüfen)

./lynis update release      (Update Lynis Version)

./lynis --cronjob

 

Fazit

Die Alternativen im Bereich des automatisierten Sicherheitsaudit auf Linux Systemen stellen meines Wissen Bastille oder Tiger dar. Beide sind leider etwas veraltetet und stellen somit wenig Konkurrenz dar. Vergleichbares ist eventuell noch beim Linux Security Auditing Tool (LSAT) zu finden. Dieses Tool habe ich allerdings noch nicht getestet. Schlußendlich bleibt, neben der Handarbeit, für einen freien Systemschnellcheck wenig anderes außer Lynis übrig.