PostgreSQL 13 Cluster auf PostgreSQL 14 aktualisieren

Die neue Version 14 der Datenbanksoftware ist bereits einige Tage verfügbar.

Es gibt dazu einen ausführlichen Release Log, den ihr euch gerne zu Gemüte führen dürft.

postgres

Installation und Update auf PostgreSQL 14 unter Debian/Ubuntu

# Create the file repository configuration:
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

# Import the repository signing key:
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

# Update the package lists:
sudo apt-get update

# Install the latest version of PostgreSQL.
sudo apt-get -y install postgresql-14

# Sicherung erstellen
sudo su postgres
pg_dumpall > Sicherung
exit

#Vorhandene Cluster anzeigen
pg_lsclusters

#Neues Cluster anhalten
sudo pg_dropcluster --stop 14 main

#Vorhandenes Cluster aktualisieren
sudo pg_upgradecluster 13 main

 postgres14_updateNachdem die Datenbanken aktualisiert und getestet wurden, kann die alte Version gelöscht werden.

sudo pg_ctlcluster 14 main status

pg_ctl: server is running (PID: 60700)
/usr/lib/postgresql/14/bin/postgres "-D" "/var/lib/postgresql/14/main" "-c" "config_file=/etc/postgresql/14/main/postgresql.conf"

sudo pg_isready

/var/run/postgresql:5433 - accepting connections
sudo pg_dropcluster 13 main

 

Serverumzug mit Serendipity - Datenbank Update notwendig

Vor einiger Zeit ist ITrig auf einen neuen Server umgezogen.

Nach dem Umzug wollte das Blog nicht mehr so richtig funktionieren. Auch der Adminbereich war nicht mehr erreichbar und zeigte komische Fehler an. Nach etwas Recherche war schnell klar, dass bei Serendipity Pfade leider hart in der Datenbank stehen, welche nicht mehr auf die neue Serverstruktur passten.

Da diese Schritte nicht in der Umzugsanleitung der S9y Seite vorhanden sind, bzw. ich sie einfach nicht gefunden habe, möchte ich hier das Vorgehen dokumentieren.

s9y-logo

Serendipity Blog Pfad in der Datenbank anpassen

Zunächst wird die Ausgabe des aktuellen Pfads geprüft.

mysql -uroot -p
USE s9y_db;
SELECT * FROM `serendipity_config` WHERE name='serendipityPath'

               serendipityPath               /alterPfad/html/www/

Nun kann der Pfad auf die neue Struktur aktualisiert werden.

UPDATE `serendipity_config` set value = '/neuerPfad/' WHERE name = 'serendipityPath';

Ein weiterer Wert, der vielleicht angepasst werden muss ist serendipityHTTPPath.

SELECT * FROM `serendipity_config` WHERE name='serendipityHTTPPath'

UPDATE `serendipity_config` set value = '/NeuerPfad/' WHERE name = 'serendipityHTTPPath';

Sollte sich zusätzlich die URL geändert haben, dann kann auch diese direkt angepasst werden.

SELECT * FROM `serendipity_config` WHERE name = 'defaultBaseURL';

UPDATE `serendipity_config` set value = 'https://neuedomain.de' WHERE name = 'defaultBaseURL';

Nun sollte das System wieder wie gewohnt auf dem neuen Server erreichbar sein.

Nagios - Icinga: Debian Bullseye check_interfaces schlägt fehl

icinga-logo

Ein kurzer Tipp fürs Interface Monitoring mit Icinga oder Nagios unter Debian.

Nach einem Update auf Debian Bullseye kann es vorkommen, dass einige Check Plugins fehlschlagen. So geschehen mit check_interfaces.

Das Plugin bringt nur noch folgende Ausgabe:

Plugin-Ausgabe
/usr/lib/nagios/plugins/check_interfaces: error while loading shared libraries: libnetsnmp.so.30: cannot open shared object file: No such file or directory

Zunächst kann man natürlich versuchen, die nötigen Dateien auf anderen Systemen zu suchen oder das Paket libsnmp40 zu installieren, leider bringt dies unnötige Arbeit, bzw. keine Abhilfe.

Die Lösung ist ein einfaches neu builden des Plugins:

debian_bullseye

apt-get update
apt-get -y install git build-essential libsnmp-dev

wget https://github.com/NETWAYS/check_interfaces/archive/refs/tags/v1.4.tar.gz

tar xvf v1.4.tar.gz

cd check_interfaces-1.4/

./configure --libexecdir=/usr/lib/nagios/plugins

make
make install

Der Zielpfad kann natürlich je nach Check Plugin Verzeichnis angepasst werden. Nach dem erneuten Builden unter Debian Bullseye sollte das Plugin wieder ohne Probleme funktionieren.

Security: GVM 21.04 - mit Docker in 15 Minuten zum OpenVAS Schwachstellen Scanner

OpenVAS bzw. Greenbone Vulnerability Manager ist nicht ganz einfach zu installieren, da viele Abhängigkeiten und Pakete gebaut werden müssen.
Eine etwas ältere Anleitung ist noch auf ITrig zu finden.

Mithilfe von Docker kann der Installationsprozess stark beschleunigt werden.
Händische Konfigurationen und Updates fallen weg und innerhalb kurzer Zeit steht ein vollständig eingerichtetes Schwachstellenmanagement zur Verfügung.

Greenbone_Security_Assistant

GVM 21.04 mit Docker Compose installieren

Zunächst sollte Docker installiert werden.

Docker Debian installieren

apt remove docker docker-engine docker.io containerd runc
apt update
apt install apt-transport-https ca-certificates curl gnupg lsb-release git

curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

apt update
apt install docker-ce docker-ce-cli containerd.io

Docker Ubuntu installieren

sudo apt remove docker docker-engine docker.io containerd runc 
sudo apt update
sudo apt install apt-transport-https ca-certificates curl gnupg lsb-release git

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

sudo echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io

Docker Compose darf ebenfalls nicht fehlen

Docker Compose Debian/Ubuntu installieren

sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

sudo chmod +x /usr/local/bin/docker-compose

docker-compose --version

Installation GVM 21.04 mit Docker

# Clonen/Installieren
cd /opt
sudo git clone https://github.com/immauss/openvas.git

# Admin pw anpassen
cd openvas/
nano docker-compose.yml

# System starten
docker-compose up -d
#Logs anschauen
docker-compose logs -f
#Server überprüfen
ss -lntp |grep 8080

Der erste Start kann recht lange dauern, da im Hintergrund alle NVTs geladen werden.

Der Installationsfortschritt kann mit docker-compose logs -f verfolgt werden.

Sollten Fehler passieren, hilft meist ein Neustart des Vorgangs. Gleiches gilt für ein Update der Signaturen.

openvas-docker

#Neustart oder Signaturen aktualisieren
cd /opt/openvas
sudo docker-compose down && docker-compose up -d

#Neueste Logs prüfen
sudo docker-compose logs --tail="50"


Schlussendlich ist das Tool unter http://localhost:8080/login erreichbar und einsatzfähig.


Allerdings empfehle ich einen Proxy mit HTTPS vorzuschalten und den Port 8080 auf Localhost umzubiegen.

Ein Proxy könnte im Docker-Compose File integriert oder direkt installiert werden.

Docker-Compose anpassen

Das Umbiegen auf Localhost, kann im Docker Compose File vorgenommen werden.

#Beispiel für eine Anpassung der docker-compose.yml

version: "3"
services:
  openvas:
    ports:
      - "127.0.0.1:8080:9392"
    environment:
      - "PASSWORD=notyouradmin!"
      - "USERNAME=admin"
      - "RELAYHOST=172.17.0.1"
      - "SMTPPORT=25"
      - "REDISDBS=512" # number of Redis DBs to use
      - "QUIET=false"  # dump feed sync noise to /dev/null
      - "NEWDB=false"  # only use this for creating a blank DB
      - "SKIPSYNC=false" # Skips the feed sync on startup.
      - "RESTORE=false"  # This probably not be used from compose... see docs.
      - "DEBUG=false"  # This will cause the container to stop and not actually start gvmd
      - "HTTPS=false"  # wether to use HTTPS or not
      - "GMP=false"    # to enable see docs
    volumes:
      - "openvas:/data"
    container_name: openvas
    image: immauss/openvas
volumes:
  openvas:

Nginx Proxyserver einrichten

Hier ein Beispiel für einen Nginx Proxyserver (ohne Docker)

apt install nginx
sudo rm /etc/nginx/sites-enabled/default

Ein Zertifikat erstellen

 sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 365 -nodes   -keyout gvm.itrig.key -out gvm.itrig.crt -subj "/CN=gvm.itrig.de"   -addext "subjectAltName=DNS:security.itrig.de,DNS:gvm.itrig.de,IP:192.168.0.111"
#Beispiel für eine Nginx Proxy Config

nano /etc/nginx/sites-available/openvas

server {
  server_name localhost;
   listen 443 ssl http2;
   ssl_certificate     /etc/ssl/gvm.itrig.de.crt;
   ssl_certificate_key /etc/ssl/gvm.itrig.de.key;
   ssl_session_timeout 1d;
   ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
   ssl_session_tickets off;
   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
   ssl_prefer_server_ciphers off;
   resolver 127.0.0.1;
   

    location / {
        proxy_pass http://localhost:8080;
    }
}
# Symlink setzen
cd /etc/nginx/sites-enabled/
ln -s ../sites-available/openvas openvas

#Neustart Nginx
systemctl restart nginx

#Kontrolle mit
systemctl status nginx
#oder
ss -lntp

Der Scanner ist nun via https://localhost/login erreichbar.

 

Fazit

Für einen schnellen Test und dem Lernen am System ist GVM via Docker von github.com/immauss/openvas sicherlich geeignet. Die Builds werden übrigens wöchentlich aktualisiert und beinhalten zusätzlich auch die neuesten Feed-Updates.

Um Docker, Container, Images und Co besser im Blick zu behalten, verweise ich an dieser Stelle auf Lazydocker. Das Tool bietet einen grafischen Überblick, über alle aktiven und inaktiven Docker Komponenten.

 

10 wichtige Befehle um Windows schnell und einfach zu reparieren

Für Windows gibt es verschiedene Varianten, um ein System auf Schäden zu prüfen und zu reparieren. Die bekannteste dürfte der Befehl DISM (Deployment Image Servicing and Management) sein. Diese befindet sich unter c:\windows\system32  kann aber einfach über die Kommandozeile oder PowerShell aufgerufen werden.

dism

Windows – Reparatur bei Problemen mit DISM und SFC

Voraussetzung für die Verwendung von DISM oder sfc ist eine Kommandozeile oder eine PowerShell mit Administratorrechten. Ansonsten erhaltet ihr den Fehler: 740.

Prüfung von Windows auf Beschädigungen

Dism /Online /Cleanup-Image /ScanHealth

Windows auf beschädigte Systemdateien testen

Dism /Online /Cleanup-Image /CheckHealth

Wiederherstellung von Windows und Prüfung auf beschädigte Systemdateien

Dism /Online /Cleanup-Image /RestoreHealth

Wiederherstellung von Windows und Prüfung auf beschädigte Systemdateien mithilfe eines sauberen Images

Dism /Image:C:\offline /Cleanup-Image /RestoreHealth /Source:c:\test\windowimage
#alternativ geht dies auch im Online Modus
Dism /Online /Cleanup-Image /RestoreHealth /Source:c:\test\windowimage /LimitAccess

Start des System File Checkers  (ein etwas älteres Tool zu Systemreparatur)

sfc /scannow

Bootphasen Reparatur

Sollte sich das System schon so weit verabschiedet haben, dass ein Bootvorgang scheitert, können zusätzlich Maßnahmen ergriffen werden, um zum Beispiel den Boot Sektor zu reparieren. Mit dem Wiederherstellungsmodus ist das aus einer bestehenden Windows Installation möglich.

Computerreparaturoptionen -> Problembehandlung -> Erweiterte Optionen -> Eingabeaufforderung.

Ist auch der Wiederherstellungsmodus nicht erreichbar, sollte von einem extra Windows Stick gebootet werden.

Microsoft selbst beschreibt 4 Bootphasen, welche teilweise mit verschiedenen Befehlen repariert werden können.

Bootphasen

Bootloader Phase reparieren

Boot Codes und Boot Sektor der Systempartition reparieren

bootrec /fixmbr
bootrec /fixboot

Suche nach verwaisten Windows Installationen im Bootmanager

bootrec /scanos

Windows Boot Konfigurationsdaten neu aufbauen

bootrec /rebuildbcd

# Sollte kein verwaistes System gefunden werden kann wie folgt weit gesucht werden (windows installation: 0)
bcdedit /export c:\bcdbackup
attrib c:\\boot\\bcd -r –s -h
ren c:\\boot\\bcd bcd.old
bootrec /rebuildbcd

#Scanning all disks for Windows installations. Please wait, since this may take a while ...
#Successfully scanned Windows installations. Total identified Windows installations: 1
#D:\Windows  
#Add installation to boot list? Yes/No/All:

Als letzten Befehl noch der Klassiker um eine defekte Festplatte zu reparieren

Festplatte prüfen und reparieren

chkdsk /f /r