Hope This Helps

Ich stelle hier ein paar Skripte zur Verfügung, welche einem die Migration eines Printservers etwas vereinfachten. Selbstverständlich kann man das auch mir Printmig oder anderen Tools durchführen. Ich wollte meinen neuen Printserver from scratch neu installieren, daher der etwas andere Weg. Die Migration wird in vier Teile erfolgen:

Part #1: Export TCP- und LPR-Ports
Part #2: Export Drucker mit allen Settings in eine XML-Datei
Part #3: Import TCP- und LPR-Ports
Part #4: Import aller Drucker mit allen Settings

Part #2: Export Drucker mit allen Settings in eine XML-Datei
Mit dem nachfolgenden Skript erfolgt der Export aller installierten Drucker, welche Netzwerkdrucker sind. Es wird eine CSV mit den grundlegenden Druckerinformationen erstellt. Außerdem wird für jeden Drucker die Konfiguration in eine XML-Datei exportiert, welche die komplette Konfiguration der Schächte und Papierquellen etc. enthält. Mit diesen Informationen können später die Drucker vollständig auf dem neuen Server wiederhergestellt werden.

Export-Printer_and_Printerconfiguration.ps1

<# 
.NAME
    Export-Printer_and_Printerconfiguration.ps1

.AUTHOR
    Ralf Entner

.SYNOPSIS
    Script exports all network printers and printer settings.

.DESCRIPTION 
    Script exports all network Printers with all settings to a single csv file.
    The printer configurations are also exported in a xml file for each printer name (printername.xml)
    The export includes name, shared name, port name, driver name, location, comment und publishing information.

.NOTES 
    The script exports only network printers.

.COMPONENT 
    No powershell modules needed

.LINK 
    No Links
 
.Parameter ParameterName 
    $CSVPath - Define export path of the csv file
    $XMLPath - Define export path of xml file for each printer configuration
#>
# Export CSV path
$CSVPath = "C:\Printmig\Printers.csv"
$XMLPath = "C:\Printmig\"

# Get all printers and informtaions
$Printers = Get-Printer | ?{$_.PortName -ne "PORTPROMPT:"} | select Name, ShareName, PortName, DriverName, Location, Comment, Published, Shared

# Export Printers to csv
$Printers | Export-Csv -Path $CSVPath -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Foreach ($Printer in $Printers){

    #Exportpaht for XML

    $XMLFilePath = $XMLPath + $Printer.Name + ".xml"

    # Export PrinterConfiguration to XML
    $GPC = get-printconfiguration -PrinterName $Printer.Name
    $GPC.PrintTicketXML | out-file $XMLFilePath
}

Ich stelle hier ein paar Skripte zur Verfügung, welche einem die Migration eines Printservers etwas vereinfachten. Selbstverständlich kann man das auch mir Printmig oder anderen Tools durchführen. Ich wollte meinen neuen Printserver from scratch neu installieren, daher der etwas andere Weg. Die Migration wird in vier Teile erfolgen:

Part #1: Export TCP- und LPR-Ports
Part #2: Export Drucker mit allen Settings in eine XML-Datei
Part #3: Import TCP- und LPR-Ports
Part #4: Import aller Drucker mit allen Settings

Part #1: Export TCP- und LPR-Ports
Für den späteren Import der zwei Port-Typen werden unterschiedliche Informationen benötigt, daher habe ich hierfür zwei Skripte erstellt, welche die Konfigurationen exportieren:

Export-PrinterPorts_TCP_to_CSV.ps1

<# 
.NAME
    Export-PrinterPorts_TCP_to_CSV.ps1

.AUTHOR
    Ralf Entner

.SYNOPSIS
    Script exports all TCP Printer Ports to a csv file.

.DESCRIPTION 
    Script exports all TCP Printer Ports with all settings to a csv file. In the csv file there are address, port number and smtp settings.
 
.NOTES 
    The script exports only TCP Ports, not LPR Ports (see other script).

.COMPONENT 
    No powershell modules needed

.LINK 
    No Links
 
.Parameter ParameterName 
    $CSVPath - Define export path of the csv file
#>

# Export CSV path
$CSVPath = "C:\Printmig\PortsTCP.csv"

# Get Printerports with all nessesary informations
$Printerports = Get-PrinterPort | ?{$_.Description -like "*TCP*"} | select Name, PrinterHostAddress, PortNumber, SNMPCommunity, SNMPEnabled 

#Export informations to CSV
$Printerports | Export-Csv -Path $CSVPath -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Export-PrinterPorts_LPR_to_CSV.ps1

<# 
.NAME
    Export-PrinterPorts_LPR_to_CSV.ps1

.AUTHOR
    Ralf Entner

.SYNOPSIS
    Script exports all LPR Printer Ports to a csv file.

.DESCRIPTION 
    Script exports all LPR Printer Ports with all settings to a csv file. In the csv file there are name, protocol, port nubmer and printer host address.
 
.NOTES 
    The script exports only LPR Ports, not TCP Ports (see other script).

.COMPONENT 
    No powershell modules needed

.LINK 
    No Links
 
.Parameter ParameterName 
    $CSVPath - Define export path of the csv file
#>
# Export CSV path
$CSVPath = "C:\Printmig\PortsLPR.csv"

# Get Printerports with all nessesary informations
$Printerports = Get-PrinterPort | ?{$_.PortMonitor -eq "LPR Port"} | Select-Object Name, Protocol, PortNumber, PrinterHostAddress

#Export informations to CSV
$Printerports | Export-Csv -Path $CSVPath -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Problem
Ich habe einen KMS Server aufgesetzt und das Volume Activation Management Tool (VAMT) installiert um die Produkt Keys zu aktivieren. Dabei konnte ich die Server 2019 Keys nicht hinzufügen. Server 2016 und Server 2022 haben problemlos funktioniert. Beim Server 2019 habe ich immer die folgende Fehlermeldung erhalten:

The specified product key is invalid or is unspported by this version of VAMT.
An update to support additional products may be available online.

Ursache
Nach einiger Internetsuche bin ich auf ähnliche Einträge mit anderen Windows Versionen gestoßen. Scheinbar kann das VAMT den Schlüssel nicht korrekt identifizieren. Die Identifikation erfolgt über die pkconfig Files im Ordner
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\VAMT3\pkconfig
auf dem VAMT Server.

Lösung
Nach etwas Recherche hat sich gezeigt, dass diese Dateien auch auf den jeweiligen Server-/Client-Betriebssystemen existieren. Diese findet man unter C:\Windows\System32\spp\tokens\pkeyconfig
Hier geht es um die dort befindliche Datei pkeyconfig-csvlk.xrm-ms
Diese ist auf dem VAMT-Server auch bereits vorhanden. Die Lösung sieht nun wie folgt aus:
- Datei pkeyconfig-csvlk.xrm-ms auf dem VAMT-Server umbenennen
- Datei vom zu aktivierenden OS in das Verzeichnis kopieren (in meinem Fall von einem Server 2019)
- VAMT starten und Produkt Key eintragen
- VAMT schließen und originale Datei pkeyconfig-csvlk.xrm-ms auf dem VAMT-Server wieder umbenennen

Ich habe das Problem nicht bei Mircrosoft identifizieren können. Es gab scheinbar beim Server 2012 R2 schon mal das Problem. Dieser Artikel hat mich zumindest auf die richtige Spur gebracht.

Quelle: Microsoft Learn: VAMT known issues

Leider wurde heute ein cve für die xz-utils veröffentlicht. Hier wurde eine supply-chain attack durchgeführt und schadhafter Code eingeschleust.
https://www.tenable.com/blog/frequently-asked-questions-cve-2024-3094-supply-chain-backdoor-in-xz-utils

Ich hab dann meine Server durch gescannt nach verwundbaren Versionen. Hier das ansible-playbook dazu.

---
- name: Scan for xz-utils and output Version
  hosts: all
  become: true
  gather_facts: true
  tasks:
    - name: Get Packages
      ansible.builtin.package_facts:
        manager: apt
      register: packages
    - name: scan for xz-utils
      ansible.builtin.set_fact:
        xz_ver: "{{ packages.ansible_facts.packages['xz-utils'][0].version }}"
    - name: ouput Package Version
      ansible.builtin.debug: 
        var: xz_ver

Der Output sieht dann so aus :

TASK [ouput Package Version] ******************
 ok: [HOSTNAME] => { "xz_ver": "5.4.1-0.2" }
 ...

Links:
https://www.tenable.com/cve/CVE-2024-3094
https://lists.debian.org/debian-security-announce/2024/msg00057.html
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

Manchmal kann es vorkommen das unter Proxmox ein Node nur ein graues Ausrufezeichen zeigt. Das ist meistens auf einen Fehler mit dem Storage zurückzuführen. In meinem Fall hatte ich testweise den Proxmox Backup Server virtualisiert, das Storage kann dann beim booten nicht verbunden werden und sorgt für einen Fehler, daraus resultiert das graue Ausrufezeichen.

Ein Neustart des Dienstes pvestatd auf dem betroffenen Node hat den Fehler behoben und der Node wurde grün

systemctl restart pvestatd.service

Eins Vorweg Port Knocking ist kein 100% Schutz für den ssh Dienst , eine saubere Konfiguration ist notwendig. Was man aber damit erreicht ist das Portscanner diesen Port als nicht offen sehen. Somit hat man schon mal einen Teil der Angriffe weggefiltert. Hat der Angreifer jedoch die Möglichkeit den Traffic zwischen Client und Server mitzuschneiden kommt er früher oder später auf die Sequenz und kann den Port öffnen. Ich habe das einfach mal aus Interesse eingerichtet und getestet, und es funktioniert

Installation von knockd (Server und Client)

apt install knockd

Installation von iptables (Server)

apt install iptables iptables-persistent

Konfiguration des knockd (Server)

Die Konfiguration des knock Daemon (knockd) wird in der Datei /etc/knockd.conf und /etc/default/knockd durchgeführt.

In der Datei /etc/default/knockd ändern wir die Startart und definieren die KNOCKD_OPTS.

...
START_KNOCKD=1
KNOCKD_OPTS="-i enp0s3"

enp0s3 ist hier der Networkinterface Name.
START_KNOCKD=1 sorgt dafür das der Daemon beim Systemstart mit gestartet wird.

Jetzt kümmern wir uns um die Datei /etc/knockd.conf und schließen die Konfiguration ab.

[options]
        logfile = /var/log/knockd.log

[openSSH]
        sequence    = 8000,7000,9000,2123:udp
        seq_timeout = 5
        command     = /usr/sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9000,7000,8000,2123:udp
        seq_timeout = 5
        command     = /usr/sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

Alle Konfigurationsmöglichkeiten kann man sich mit man knockd anschauen (und es gibt viele). Für das Beispiel hier verwende ich eine rudimentäre Konfiguration. Die Ports die unter Sequenz (sequence) angegeben sind muss man nacheinander "anklopfen" dann wird das command ausgeführt. Hier sieht man das iptables den Client auf den SSH Port freigibt. Und eben wieder entfernt wenn die Sequenz für closeSSH übergeben wird.
Nachdem die Konfiguration abgeschlossen ist muss der Dienst aktiviert und gestartet werden.

systemctl enable knockd && systemctl start knockd

Jetzt bereiten wir die Firewall für den Einsatz vor. Hiermit erstellen wir eine Regel das vorhandene Verbindungen nicht getrennt werden

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

in der folgenden Regel verbieten wir die Connection auf den Port 22

iptables -A INPUT -p tcp --destination-port 22 -j DROP

jetzt wird das ganze noch gespeichert das es einen reboot überlebt

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

Wenn ihr euch jetzt den Server einmal mit nmap anschaut, natürlich von einem anderen Client, ist der Port geschlossen.

Ruft man jetzt knock auf dem Client mit der richtigen Sequenz auf wird der Port geöffnet

knock SERVERIP 8000 7000 9000 2123:udp

das kann man auch wieder schön mit nmap ermitteln.


Im Logfile von knockd sieht das ganze dann so aus. Im ersten Block wurde die Sequenz richtig angegeben und somit der Client zugelassen. Im zweiten Block wurde die Sequenz richtig angegeben und der Port wurde wieder geschlossen.