Hope This Helps

Kleines lokales Plugin für check_mk um die HAProxy Backends zu monitoren.

das Skript muss unter /usr/lib/check_mk_agent/local angelegt werden.

touch /usr/lib/check_mk_agent/local/haproxy-local.sh

Dort dann den nachfolgenden Code reinkopieren und Konfiguration anpassen.

#!/bin/bash
#
# checks haproxy
#

_awk_bin=$(which awk)
_status_url="http://localhost:9090/haproxy/"
_server_name="ha-cap-"
a=0

# $(curl -s ${_status_url}\;csv | grep "^${_server_name}" | grep -vE "(FRONTEND|BACKEND)")

for line in $(curl -s ${_status_url}\;csv | grep "^${_server_name}" | grep -vE "(FRONTEND|BACKEND)"); do
        _name=$(echo $line | ${_awk_bin} -F',' '{ print $1; }' )
        _host=$(echo $line | ${_awk_bin} -F',' '{ print $2; }' )
        _stat=$(echo $line | ${_awk_bin} -F',' '{ print $18; }')
        STATUSTXT="${_name}  ${_host}  ${_stat}"
        if [ ${_stat} == "UP" ]; then
                _check_response="0"
        else
                _check_response="2"
        fi
        if [ ${a} -lt 10 ]; then
                echo "${_check_response} BEHIND-HAPROXY-0${a} - ${STATUSTXT}"
        else
                echo "${_check_response} BEHIND-HAPROXY-${a} - ${STATUSTXT}"
        fi
        a=$((a+1))
done

Ergebnis sieht dann so aus

Natürlich muss auch der haproxy so konfiguriert sein das er die Statusseite ausliefert. Hier Auszug aus der haproxy.cfg

listen status
    bind *:9090
    mode http
    stats enable
    stats uri /haproxy
    acl localhost  src  127.0.0.1
    acl stats      path_beg  /haproxy
    http-request allow if stats localhost
    http-request deny  if stats !localhost

Es kommt immer wieder vor das die Webserver unter Volllast geraten da jemand unsere API exzessiv anfragt. Da hier alle anderen Anfragen auch mit betroffen sind ist hier ein möglicher Weg einen Apache dagegen abzusichern. In meinem Fall handelt es sich um ein Debian 9 bei anderen Linux Derivaten sollte es ähnlich funktionieren.

Distributor ID:	Debian
Description:	Debian GNU/Linux 9.5 (stretch)
Release:	9.5
Codename:	stretch

Erstmal installieren wir die benötigten Packete

apt install libapache2-mod-qos fail2ban

Dann machen wir die Konfiguration für mod_qos

vi /etc/apache2/conf-available/mod_qos.conf

dort tragen wir erstmal eine Grundkonfiguration ein

## QoS Settings
<IfModule mod_qos.c>
    # Gleichzeitige Verbindungen von 100000 IP Adressen zulassen 
    QS_ClientEntries 100000
    # maximal 20 Verbindungen pro IP Adresse
    QS_SrvMaxConnPerIP 20
    # maximale Anzahl der aktiven TCP Verbindungen hier 256
    MaxClients              256
    # QS_SrvMaxConnClose <Nummer> [%] definiert die maximale Anzahl der gleichzeitigen TCP-Verbindungen,
    # bis der Server Keep-Alive für diesen Server deaktiviert (die Verbindung wird nach jeder Anforderung geschlossen. 
    # Sie können die Anzahl der Verbindungen als Prozentsatz von MaxClients angeben, wenn Sie das Suffix hinzufügen '%' auf den angegebenen Wert.
    QS_SrvMaxConnClose      70%
    # minimum request/response speed (https://de.wikipedia.org/wiki/Slowloris Schutz):
    QS_SrvMinDataRate       150 1200
    # QS_SrvMinDataRate <bytes pro seconds> [<max bytes pro second> [<connections>]], definiert den minimalen Upload / Download-Durchsatz
    # QS_SrvMaxConnExcludeIP <addr>
    # QS_SrvMaxConnExcludeIP 192.168.x.xxx
    #
    # Quelle : https://www.mankier.com/1/mod_qos
</IfModule>

Jetzt geben wir noch die Statusseite für qos frei damit wir auch sehen was hier so passiert.

<Location /qos>
   SetHandler qos-viewer
   Require ip [Eigene IP Adresse oder IP Range (CIDR)]
   # z.B. Require ip 127.0.0.1
</Location>

Jetzt aktivieren wir noch das Modul und die Konfiguration

a2enmod qos
a2enconf mod_qos

dann der obligatorische Neustart des Apaches

systemctl restart apache2

nun kann man den ersten Test durchführen, von einem anderen Rechner die IP Adresse des Servers über das Apache Benchmark Tool einfach mal anfragen mit diesen Werten

ab -n 1500 -c 100 http://[IP des Webservers]/index.html

im Errorlog des Apaches sollten jetzt solche Meldungen erscheinen

[xxx] [:error] [xxx] mod_qos(034): access denied, QS_SrvMinDataRate rule (in): min=354, this connection=26, c=192.168.x.xxx
[xxx] [:error] [xxx] mod_qos(031): access denied, QS_SrvMaxConnPerIP rule: max=50, concurrent connections=51, c=192.168.x.xxx

Dann machen wir mit fail2ban weiter

vi /etc/fail2ban/jail.d/http-requests.conf

dort fügen wir diesen Inhalt ein

[http-requests]
enabled = true
port = http,https
filter = http-requests
logpath = /var/log/apache2/access.log
# maxretry bedeutet wieviele GET / POST wir im Log finden bevor wir die IP sperren
maxretry = 30
# findtime ist die Zeitperiode in der wir GET/POST zählen (10 Sekunden)
findtime = 10
# Wielange wird die IP gebannt in Sekunden (600 Sekunden = 10 Minuten)
bantime = 600
action = iptables[name=HTTP, port=http, protocol=tcp]

den Filter dazu erstellen

vi /etc/fail2ban/filter.d/http-requests.conf

und dort diesen Inhalt rein

# Fail2Ban configuration file
# http-requests.conf
#
[Definition]
# failregex = es wird gegen GET/POST im Logfile gematched
failregex = ^<HOST> -.*"(GET|POST).*
# ignoreregex = 
ignoreregex =

ein neustart von fail2ban aktiviert die Config

systemctl restart fail2ban

Jetzt kann wieder mit dem Apache Benchmark Tool getestet werden, bevor wir allerdings das Benchmark Tool von einem anderen Rechner aus starten öffnen wir lokal das Logfile von fail2ban damit wir sehen was passiert.

tail -f /var/log/fail2ban.log

jetzt den Benchmark starten wie oben angegeben. Im Log sollten jetzt solche Meldungen erscheinen

2018-07-20 00:25:27,998 fail2ban.filter         [6203]: INFO    [http-requests] Found 192.168.x.xxx
2018-07-20 00:25:27,998 fail2ban.filter         [6203]: INFO    [http-requests] Found 192.168.x.xxx
2018-07-20 00:25:28,096 fail2ban.actions        [6203]: NOTICE  [http-requests] 192.168.x.xxx already banned
2018-07-20 00:25:29,098 fail2ban.actions        [6203]: NOTICE  [http-requests] 192.168.x.xxx already banned

In fail2ban kann man sich jetzt den Status anzeigen lassen

root@ddev-01: fail2ban-client status http-requests
Status for the jail: http-requests
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	1629
|  `- File list:	/var/log/apache2/access.log
`- Actions
   |- Currently banned:	1
   |- Total banned:	2
   `- Banned IP list:	192.168.x.xxx

möchte man die IP wieder entsperren genügt ein

fail2ban-client set http-requests unbanip 192.168.x.xxx

wenn eine bestimmte IP oder eine IP Range freigegeben werden muss ist das in der jail.conf zu erledigen

vi /etc/fail2ban/jail.conf

dort nach ignoreip = suchen und die eigene IP hinzufügen

Quellen :
http://mod-qos.sourceforge.net/#variables
https://de.wikipedia.org/wiki/Slowloris
https://www.fail2ban.org/wiki/index.php/Main_Page
https://sourceforge.net/p/mod-qos/discussion/
http://mod-qos.sourceforge.net/#statusviewer
http://mod-qos.sourceforge.net/glossary.html
http://mod-qos.sourceforge.net/dos.html

Problem : In manchen Fällen bekommt man Dateien von Kunden geschickt die irgendein unbekanntes encoding enthalten. mit recode und iconv kam in meinem Fall auch nur Mist raus.

Lösung :
Die Datei mit vim öffnen und das encoding auf utf8 festnageln.

set fenc=utf8

dann können die unbekannten Zeichen ersetzt werden. Hier ein paar Beispiele.

:%s#\%x86#Ü#g
:%s#\%x9f#ü#g
:%s#\%x8a#ä#g
:%s#\%x9a#ö#g
:%s#§#ß#g

Problem:
Ich hatte das Problem, dass meine Backup-Platte defekt war und ich daher die Veeam-Sicherung neu einrichten musste. Dazu wollte ich aber nicht die ganze Software deinstallieren. Ich wollte nur die komplette Konfiguration löschen und neu einrichten.

Lösung:
Mit der nachfolgenden Prozedur wird die komplette Backup-Historie und -Konfiguration gelöscht!
Die Backup-Daten bleiben aber erhalten.

1.) Folgenden Registry-Key setzen:

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Endpoint Backup
Value Name: RecreateDatabase
Value Type: DWORD
Value: 1 (= Reset Database)

2.) Neustart des Dienstes "Veeam Agent for Microsoft Windows"

3.) Neustart von Veeam Backup und es öffnet sich der Konfigurationsassistent! FERTIG!

Quelle:
tinkertry.com: How to manually reset your Veeam Endpoint Backup FREE database

Problem:
Ablauf der PublicFolder-Migration von Exchange 2007 auf Exchange 2013

Lösung:
Hier stelle ich meine Skript-Sammlung und Ablauf-Prozedur für meine Migration da.
Ich habe hier meine öffentliche Ordner von einem Exchange 2007 auf einen Exchange 2013 CU16 erfolgreich migriert.
Dabei gibt es einige Ecken, die man wissen muss, sonst wunder man sich über das Verhalten und die Vorgehensweise.

Vorbereitung:
- Laden Sie sich die Public Folder Migration Scripts von Microsoft herunter (Link finden Sie unten bei den Quellen)
- Kopieren Sie die Skripte auf den alten und neuen Exchange-Server unter "C:\PFMigration\"
- Notieren Sie sich die FQDN des alten und neuen Exchange-Servers
- Sie benötigen einen Exchange-Administrator-Konto
- Alle Postfächer sind bereits auf dem Exchange 2013 migriert
- Es wird eine Downtime für die öffentlichen Ordner geben!
- Holen Sie sich eine Kanne Kaffee, das Szenario kann etwas dauern

Ablauf:

--- START AUF EXCHANGE 2007 ---

1.) Snapshot der "alten Public Folders"
Mit dem nachfolgendem Befehl wird ein Snapshot der PublicFolder-Struktur (Ordner, Struktur und Berechtigungen) angefertigt.

Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

2.) Prüfen der Struktur
Mit diesem Befehl werden die Ordner-Namen nach "\" im Namen, da diese nicht migriert werden können und der Prozess hier dann abbricht. Vorher müssen alle entsprechenden Ordner in der alten Struktur umbenannt werden.

Get-PublicFolderDatabase | ForEach {Get-PublicFolderStatistics -Server $_.Server | Where {$_.Name -like "*\*"}}

WICHTIG: Falls es hier zu Änderungen kommt, muss ein erneuter Snapshot (Punkt 1) erstellt werden!

3.) Migrations-Prüfung
Hiermit prüfen Sie, ob bereits eine Migration läuft und noch nicht abgeschlossen ist.

Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete

4.) CSV mit Ordernamen generieren
Hiermit wird eine CSV mit den Ordnernamen und Größen erstellt

.\Export-PublicFolderStatistics.ps1 PFStat.csv 

5.) PFStat.csv auf Exchange 2013 kopieren
Kopieren Sie die gerade erstellt PFStat.csv auf den Exchange 2013 in das Verzeichnis der Migrationsskripte "C:\PFMigration\"

--- WECHSEL AUF EXCHANGE 2013 ---

1.) Erstellen der nötigen PublicFolder.csv
Hier werden die Anzahl an PublicFolders berechnet und eine CSV für die Erstellung erzeugt.

.\PublicFolderToMailboxMapGenerator.ps1 10GB PFStat.csv FolderToMailbox.csv

2.) Umbenennen der PublicFolder-Mailbox (OPTIONAL)
In der gerade erstellten FolderToMailbox.csv heißt die neue PublicFolder-Mailbox Mailbox1, Mailbox2 etc.
WICHTIG: Man kann diese hier anpassen und muss aber dann auch die nachfolgenden Skripte ebenfalls anpassen!
Bitte beachten: Ich habe diese hier zu "PublicFolder01" umbenannte und meine Skripte daran angepasst.

3.) Neue PublicFolder-Datenbank erstellen
Hiermit wird die neue PublicFolder-Datenbank erstellt und für die Migration reserviert.

New-Mailbox -PublicFolder PublicFolder01 –HoldForMigration: $true

4.) Migration starten
Jetzt den Migrations-Prozess starten

New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server ) -CSVData (Get-Content FolderToMailbox.csv -Encoding Byte)

5.) Migrationsstatus prüfen
Hiermit kann man den Migrationsstatus prüfen und eventuelle Fehler analysieren.
Minimale Ausgabe des Status:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics

Status-Ausgabe mit Details

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

ACHTUNG - WICHTIG: MIGRATION LÄUFT NUR BIS 95% UND STOPPT DANN - DAS IST GEWOLLT!
Solange der Parameter PreventCompletion = true ist, wird die Migration nicht vollständig abschließen

ACHTUNG - AB JETZT GIB ES DOWNTIME DER PUBLIC FOLDERS!
NACH DEM NACHFOLGENDEM SCHRITT GIBT ES KEIN ZUGRIFF MEHR AUF LEGACY PUBLIC FOLDER!

6.) Alte Public Folders sperren für endgültige Migration
Mit dem nachfolgendem Befehl werden die alten öffentlichen Ordner für den Zugriff und die endgültige Migration gesperrt.

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

7.) Freigabe für finale Migration (letzten 5% der Migration)

Set-PublicFolderMigrationRequest -Identity \PublicFolderMigration -PreventCompletion:$false 

8.) Migration wieder starten
Hiermit wird die zuvor gestoppte Migration wieder gestartet um die letzten 5% abzuschließen.

Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

9.) Prüfen des Migrationsstatus mit Details
Nun müssen Sie die finale Migration überwachen:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

Sollte die Migration nicht abschließen, dann prüfen Sie die Fehlermeldungen in der Detailausgabe. Wenn hier etwas mit „StalledDueToMailboxLock“ oder „Relinquishing job because the mailbox is locked“ zu lesen ist, dann müssen Sie den Informationstore auf dem alten Exchange 2007 einfach durchstarten. Danach können Sie die Migration erneut starten mittels:

Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

Nun sollte alles bis 100% durchlaufen!

10.) Zugriff mit einzelnem Benutzer testen
Um den Zugriff zu testen und nicht gleich alle Benutzer umzustellen verwenden Sie den nachfolgenden Befehl:

Set-Mailbox -Identity TESTUSER -DefaultPublicFolderMailbox mailbox1

11.) Finaler Abschluß der Migration
Erst geben wir den neuen Public Folder für alle frei

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false 

Nun schließen wir noch die Migrationsbatch ab

Set-OrganizationConfig -PublicFolderMigrationComplete:$true

Jetzt setzen wir den neuen Public Folder für ALLE Postfächer

Set-OrganizationConfig -PublicFoldersEnabled Local

12.) Prüfen der Migration
Nun prüfen wir noch, ob die Migrationsbatch auch als abgeschlossen angezeigt wird

Get-OrganizationConfig | FL PublicFolderMigrationComplete

Außerdem prüfen wir noch, ob der Public Folder für andere Benutzer als Default angezeigt wird

Get-Mailbox SOMERANDOMUSER | FL DefaultPublicFolderMailbox

13.) Aufräumarbeiten
Jetzt müssen wir noch den RemotePublicFolder-Eintrag wieder löschen

Set-OrganizationConfig -RemotePublicFolderMailboxes $null

Set-OrganizationConfig -PublicFoldersEnabled Local

14.) Clients testen
Nun ist es Zeit die Clients zu testen. Das kann etwas dauern, bis die neuen PublicFolders angezeigt werden - AD-Replikation!
Bei mir hat es teilweise bis zu 30 Minuten gedauert, bis auch die letzten Clients die öffentlichen Ordner angezeigt bekommen haben!

LETZTER HINWEIS: Sollte der Benutzer öffentliche Ordner als Favoriten eingetragen haben, dann muss er diese wieder neu setzen...leider!

Quellen:
ENOW: Legacy Public Folder Migration – Notes from the Field
MSExchangeGuru.com: Public Folders Migration from Exchange 2007/2010 to Exchange 2013
Microsoft: Download Public Folders Migration Scripts

Problem:
Alle Windows 10 Clients und Windows 2016 Server haben sich plötzlich Ihre Updates nicht vom WSUS sondern direkt von Microsoft geholt. Da ich die Kontrolle über meine Updates haben wollte, habe ich mich mit dem Problem beschäftigt und fand auch die Ursache "Dual Scan". Hierbei handelt es sich um einen Update-Mechanismus von Microsoft, der mit Windows 10 1607 bzw. dem Cumulative Update KB4034658 vom August 2017 eingeführt wurde. Wie kann ich jetzt meine Updates wieder selbst kontrollieren?

Lösung:
Dualscan wird immer dann aktiviert, wenn man per GPO einen WSUS-Server den Clients zuweist und gleichzeitig Qualitäts- oder Feature-Updates zurückstellt.
Um das "Problem" zu kontrollieren benötigen Sie die GPOs von Windows 10 1607 und das obengenannte Update KB4034658 für Windows 10 und Server 2016. Wenn Sie die Updates und GPOs (zentrale GPOs bei einer AD) eingespielt haben
Danach finden Sie in den GPOs unter
"Computerkonfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows Update" den Punkt ""Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird" Diesen aktivieren Sie und danach wird der Client wieder seine Updates vom WSUS beziehen.
Sollte eine GPO nicht möglich sein, dann können Sie das Ganze auch über die Registry steuern:

Registry Path: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
Value Name: DisableDualScan
Value Type: REG_DWORD
Values: 1 (Enabled) oder 0 (Disabled)

Quelle: Tchnet: Windows 10 Updates and Store GPO behavior with DualScan disabled and SCCM SUP/WSUS managed