ntop : Eigene Anwendung zu Port zuordnen

Erstmal was ist ntop eigentlich.
ntop (network top) ist eine quelloffene und freie Software, mit der Netzwerkverkehr mitgeschnitten und analysiert werden kann.
Quelle : https://de.wikipedia.org/wiki/Ntop

Diese Software kann schön genutzt werden um z.B. auf einem Gateway oder einer Firewall zu monitoren wo der Traffic so hin läuft. Es werden schon ein ganzer Pack Plugins mitgeliefert aber eigene Anwendungen werden nicht erkannt. Ich habe hier eine kleine Anwendung geschrieben die über udp Port 5404 Daten versendet. Jetzt möchte ich natürlich das auch in meinem Gateway angezeigt bekommen um zu beurteilen wieviel Traffic darüber läuft. Das kann man relativ einfach realisieren jedoch hat es mir auch etwas Arbeit gekostet diesen einfachen Weg zu finden ;-)

Erstellt eine Datei in der später die Protokolle hinzugefügt werden.
touch /usr/share/ntopng/httpdocs/protocol-app.txt
Jetzt füge ich meine Anwendung hinzu, das diese auch im Webfrontend nicht mehr unter UNKNOWN läuft.
echo "udp:5404 @MyApp" > /usr/share/ntopng/httpdocs/protocol-app.txt 
dann müssen wir noch dafür sorgen das diese Datei auch beim Start von ntopng gelesen wird dazu editieren wir das configfile unter /etc/ntopng mit dem Befehl.
echo "-p /usr/share/ntopng/httpdocs/protocol-app.txt" >> /etc/ntopng/ntopng.conf
Dann starten wir den Server neu mit dem Befehl
service ntopng restart
Wenn dann bei den Protokollen MyApp steht wurde alles richtig gemacht ;-) ntop beispiel

Mehr Infos :
http://www.ntop.org/ndpi/configuring-ndpi-for-custom-protocol-detection/

AWS : Mount eines S3 Buckets unter Debian

Installation des benötigten Packetes auf der Debian Kiste.
apt install s3fs
Erstellen einer Passwort Datei im Home Directory
touch ~/.passwd-s3fs
echo "accessKeyId:secretAccessKey" > ~/.passwd-s3fs
Wenn mehrere Amazon S3 Buckets verwendet werden müssen kann auch der Name des Buckets vor den Zugangsdaten hinzugefügt werden.
echo "bucketName:accessKeyId:secretAccessKey" > ~/.passwd-s3fs
Da hier sensible Zugangsdaten in der Datei stehen müssen die Rechte auf 600 geändert werden !
chmod 600 ~/.passwd-s3fs
Wenn alles richtig ist kann das Amazon S3 Buckets gemountet werden
s3fs [BUCKET-NAME] [MOUNT-POINT]
Der Eintrag für /etc/fstab sieht dann so aus, hier ist debug noch aktiv. Das sollte für einen Betrieb in der Produktion deaktiviert werden.
# MOUNT S3 MIT DEBUG
[BUCKET-NAME] [MOUNTPOINT] fuse.s3fs _netdev,allow_other,dbglevel=dbg,curldbg 0 0
# MOUNT S3 OHNE DEBUG
[BUCKET-NAME] [MOUNTPOINT] fuse.s3fs _netdev,allow_other 0 0

Quellen :
https://cloud.netapp.com/blog/amazon-s3-as-a-file-system
https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon

Debian 9 : hohe CPU Last durch systemd-journald

Problem : Ein Server mit Debian 9 hat eine durchgehend hohe Systemlast. Beim prüfen der Last fällt auf das "systemd-journald" der Grund ist. Nachdem ich mit journalctl -xe nachgeschaut habe woran das liegen könnte sind mir die folgenden Zeilen aufgefallen die sich immer wieder wiederholen.
Sep 08 14:33:27 HOSTNAME sh[293]: /sbin/dhclient-script: 28: .: Can't open /usr/share/sendmail/dynamic
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPDECLINE on eth0 to 255.255.255.255 port 67
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPDECLINE on eth0 to 255.255.255.255 port 67
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPREQUEST of XXX.XXX.XXX.XXX on eth0 to 255.255.255.255 port 67
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPREQUEST of XXX.XXX.XXX.XXX on eth0 to 255.255.255.255 port 67
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPOFFER of XXX.XXX.XXX.XXX from XXX.XXX.XXX.XXX
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPOFFER of XXX.XXX.XXX.XXX from XXX.XXX.XXX.XXX
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPACK of XXX.XXX.XXX.XXX from XXX.XXX.XXX.XXX
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPACK of XXX.XXX.XXX.XXX from XXX.XXX.XXX.XXX
Sep 08 14:33:27 HOSTNAME sh[293]: RTNETLINK answers: File exists

Der Grund für den andauernden Neustart Wahn des dhclient war diese Zeile
Sep 08 14:33:27 HOSTNAME sh[293]: /sbin/dhclient-script: 28: .: Can't open /usr/share/sendmail/dynamic
Lösung : In meinem Fall lief ein Skript Amok.
/etc/dhcp/dhclient-exit-hooks.d/sendmail
Da ich hier sowieso auf eine andere Art der Überwachung setzte hab ich das Skript einfach mit folgenden Befehl gelöscht
rm /etc/dhcp/dhclient-exit-hooks.d/sendmail
seitdem ist die Systemlast wieder auf dem gewohnten Stand unterwegs. Wenn man das allerdings benötigt kann man auch diesen Befehl in den Terminal hämmern.
mkdir -p /usr/share/sendmail && touch /usr/share/sendmail/dynamic

Debian 9 : Apache 2.4 Load Balancer für statischen Inhalt

Einen Load Balancer auf Basis von Apache 2.4 für statischen Inhalt aufzubauen ist kein Hexenwerk. Für dynamische Inhalte sieht das etwas anders aus ;-) aber wir fangen erstmal klein an. Wenn ihr auch den Artikel "Debian 9 : Gateway mit DNS und DHCP" druchgespielt habt sieht euer Netz wenn ihr fertig seit so aus.
Topologie Testaufbau
Auf die beiden Server web-01 und web-02 gehe ich nicht weiter ein, das sind Standard Installationen Debian 9 mit Apache

erstmal brauchen wir auf dem Server web-lb der das Apache Loadbalancing übernehmen soll natürlich Apache. das übernimmt dieser Befehl unter root.
apt update && apt install apache2
danach müssen wir noch die benötigten Module aktivieren
a2enmod proxy_balancer proxy lbmethod_* headers status
wie man hier sieht aktiviere ich immer gleich alle lbmethod_* für den Balancer.
Nun folgt ein Neustart des Apache Servers
systemctl restart apache2.service
Nun müssen wir die site für den Balancer konfigurieren. Das erledigen wir in vi mit dem Befehl
vi /etc/apache2/sites-available/balancer.conf
Hier ist meine Beispiel Konfiguration, ich hab hier absichtlich nur eine simple Grundkonfiguration erstellt.
[VirtualHost *:80]
        ServerAdmin webmaster@localhost
        Header add X-Balancer "%{BALANCER_WORKER_NAME}e"
        [Proxy balancer://webintern]
                BalancerMember http://172.16.0.20:80
                BalancerMember http://172.16.0.21:80
                ProxySet lbmethod=byrequests
        [/Proxy]
        ProxyPass "/balancer-manager" !
        ProxyPass "/" "balancer://webintern/"
        ProxyPassReverse "/" "balancer://webintern"
        [Location "/balancer-manager"]
                SetHandler balancer-manager
                Require ip 192.168.2
        [/Location]
        ErrorLog ${APACHE_LOG_DIR}/balancer_error.log
        CustomLog ${APACHE_LOG_DIR}/balancer_access.log combined
[/VirtualHost]
Syntax Highlighting versagt hier leider [ = < und ] = >

Jetzt müssen wir die Site noch aktivieren das erledigt a2ensite für uns.
a2ensite balancer
und noch ein Neustart des Apache Servers
systemctl restart apache2.service
Zur Erklärung :
Header add X-Balancer "%{BALANCER_WORKER_NAME}e"
dient nur dem debuggen und kann nach erfolgreichen einrichten auskommentiert werden. Wenn alles eingerichtet ist und euer Loadbalancer steht bekommt ihr bei jedem Request einen Eintrag im Header mit dem Namen X-Balancer der verifiziert von welchem Server ihr die Antwort erhalten habt.

Balancer Header 01

Das funktioniert solange ihr keine Sessions oder dynamischen Content habt. Wenn ihr das benötigt muss man dafür Sorgen das der Client der den Loadbalancer anfragt auch immer auf dem selben Webserver raus kommt. Ist klar sonst sind die Sessions ja nicht mehr gültig ;-)

Apache Dokumentation zum Modul proxy_balancer

Debian 9 : Gateway mit DNS und DHCP

1.) Aufsetzten des Gateways mit DNS und DHCP für das interne Netzwerk
2.) installieren des Debian Grundsystems und aktualisieren auf den aktuellsten Stand
3.) installieren der benötigten Packete für den Gateway
apt install dnsmasq vim resolvconf iptables-persistent
benötigte Einstellungen im Kernel vornehmen.
vi /etc/sysctl.conf
# auskommentieren von 
net.ipv4.ip_forward=1
benötigte Einstellungen in den IP-Tables vornehmen
vi /etc/iptables/rules.v4
das reinkopieren, hier ist gleich der port 22 für ssh geöffnet und die Weiterleitung von Port 80 und 443
auf den internen Server 172.16.0.10 umgesetzt.

enp0s3 und enp0s8 sind meine Netzwerkkarten sollten die bei euch einen anderen Namen tragen
Muss dieser natürlich angepasst werden

*nat
-A POSTROUTING -o enp0s3 -j MASQUERADE
-A PREROUTING -i enp0s3 -p tcp --dport 80 -j DNAT --to 172.16.0.10:80
-A PREROUTING -i enp0s3 -p tcp --dport 443 -j DNAT --to 172.16.0.10:443
COMMIT
# -----------------------------------------------------
*filter
-A INPUT -i lo -j ACCEPT
# wenn angefragt dann erlauben
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# ssh erlauben
-A INPUT -i enp0s3 -p tcp -m tcp --dport 22 -j ACCEPT
# Webserver
-A FORWARD -p tcp -d 172.16.0.10 --dport 80 -j ACCEPT
-A FORWARD -p tcp -d 172.16.0.10 --dport 443 -j ACCEPT
# Alles andere DROP
-A INPUT -i enp0s3 -j DROP
COMMIT
Aktivieren der IPTABLES mit
iptables-restore /etc/iptables/rules.v4
Konfigurieren der Netzwerkschnittstelle ins interne LAN
vi /etc/network/interfaces
das reinkopieren
# internal LAN (int)
allow-hotplug eth1
iface enp0s8 inet static
address 172.16.0.1
broadcast 172.16.0.254
netmask 255.255.255.0
dann kümmern wir uns direkt um die dnsmasq.conf
vi /etc/dnsmasq.conf
Da jedes Netzwerk anders ist kann meine nur als Anregung verstanden werden, für meinen Test habe ich alle Kisten in der Domain ph.lan
# DNS CONFIG
domain-needed
bogus-priv
interface=enp0s8
listen-address=127.0.0.1
listen-address=172.16.0.1
bind-interfaces
domain=ph.lan
local=/ph.lan/
# DNS Weiterleitung
server=8.8.8.8
server=8.8.4.4
filterwin2k
# -------------------------------------------------------------
# DHCP CONFIG
# -------------------------------------------------------------
dhcp-range=lan,172.16.0.2,172.16.0.254,12h
dhcp-option=lan,3,172.16.0.1
dhcp-option=lan,6,172.16.0.1
# FESTE HOSTS
# dhcp-host=[E/A nach dem Muster XX:XX:XX:XX:XX:XX],[HOSTNAME],[IP-ADRESSE],infinite
dhcp-host=08:00:27:cc:69:b0,web-lb,172.16.0.10,infinite
so damit wird uns jetzt nicht selbst verarschen editieren wir noch die Datei /etc/hosts
127.0.0.1       localhost
#127.0.1.1      web-gw.ph.lan   web-gw
172.16.0.1      web-gw.ph.lan   web-gw
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
wenn wir das nicht machen antwortet auf einem Ping des Gateways immer die 127.0.1.1 die Datei wird auch zur Auflösung der Adressen im Netzwerk hergezogen.

Jetzt passen wir noch die Datei /etc/resolvconf/resolv.conf.d/head an. Hier mein Inhalt.
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 172.16.0.1
search ph.lan
keine Angst die Warnung können wir hier ignorieren, beim start wird die Datei /etc/resolv.conf gebaut, damit man in dieser Datei (etc/resolv.conf) nichts ändert ist diese Warnung da.

Jetzt starten wir mal die Kiste durch
systemctl restart

Wenn hier alles richtig gemacht wurde ist der web-gw jetzt konfiguriert jetzt könnt ihr einen 2. Server aufsetzen der seine Netzwerkkarte nur im internen Netzwerk hat. Alle Rechner/Server bekommen jetzt im internen Lan ihre DHCP / DNS Einstellungen vom Server web-gw, jetzt kann man anfangen das Apache Loadbalancing aufzubauen. Dazu folgt aber ein weiterer Eintrag von mir.

PostgreSQL : Backup einer Datenbank incl. Indexes

Problem : Man möchte eine postgreSQL Datenbank inkl. der Indexes sichern, normalerweise ist die Idee suboptimal aber wenn die Datenbank so groß ist das ein Berechnen der Indexes schon 3 Tage benötigt sichert man diese eben mit.

Lösung : Hier zeige ich einen Weg auf der bei mir funktioniert.

Als erstes legen wir die benötigten Ordner an
mkdir -p /postgres/archives
mkdir -p /postgres/backup
dann passen wir die Konfiguration des Servers an
vi /etc/postgresql/9.4/main/postgresql.conf
ans Ende kommt unsere zusätzliche Konfiguration
max_wal_senders=1
wal_level=hot_standby
archive_mode=on
archive_command='cp %p /postgres/archives/%f'
dann passen wir noch die pg_hba.conf an
vi /etc/postgresql/9.4/main/pg_hba.conf
dort schreiben wir an das Ende
local   replication     postgres                                trust
dann starten wir den Dienst erstmal neu
systemctl restart postgresql
Jetzt können wir ein Backup mit dem Tool pg_basebackup durchführen
pg_basebackup -x -Ft -P -p 5432 -D /postgres/backup/$(date +%Y%m%d)
Wenn der Befehl durchgelaufen ist sollte im Ordner /postgres/backup/[DATUM]/ die Datei base.tar vorhanden sein


Einspielen des Backups
systemctl stop postgresql
in den Data Ordner wechseln z.b. /var/lib/postgresql/9.4/main dort mit tar zurückspielen
tar -xvf /backup/20170726/base.tgz
dann den Server neu starten und glücklich sein
systemctl start postgresql
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)