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

Migration Exchange 2007 auf 2013: Benutzer mit Outlook-Anywhere bekommt keine Öffentlichen Ordner angezeigt

Problem:
Nachdem ich einen externen Benutzer von Exchange 2007 auf Exchange 2013 umgezogen hatte, hat dieser die Öffentlichen Ordner nicht mehr angezeigt bekommen. Der Zugriff erfolgt in der Migrations-Phase über die Discovery-Mailbox-Methode auf den Exchange 2007 (Erklärung siehe TechNet-Quelle unten). Von den intern Outlook-Clients funktioniert der Zugriff problemlos.
Nach einiger Recherche mittels Fiddler habe ich herausgefunden, dass bei dem Client ein zweiter Autodiscover läuft und hier auf die interne Domäen abgefragt wird (https:\\autodiscover.domäne.intern/autodiscover/autodiscover.xml).
Warum der zweite Autodiscover?

Lösung:
Des Rätsels Lösung ist ganz einfach. Dadurch, dass der Client auf die alten Öffentlichen Ordner auf dem Exchange 2007 über das Discovery-Postfach zugreift, läuft für dieses Postfach ebenfalls noch ein Autodiscover. Da ich dem Discovery-Postfach keine öffentliche Mail-Adresse zugewiesen habe (warum auch??), versucht der Client mittels Domäne der primärer Mail-Adresse (die ja intern ist) auf die Autodiscover-URL zuzugreifen (Erklärung wie der Client die Autodiscover-URL ermittelt finden Sie unten in den Quellen).

Die Lösung ist simpel:
Vergeben Sie der Public-Folder-Discovery-Mailbox eine öffentliche Mail-Adresse als Primäre Mail-Adresse und das Autodiscover wird vom externen Client erfolgreich sein.

Quellen/Hilfen:
Hope-This-Helps: Exchange Autodiscover: Wie wird die Autodiscover-URL ermittelt?

https://technet.microsoft.com/de-de/library/dn690134(v=exchg.150).aspx

Exchange Autodiscover: Wie wird die Autodiscover-URL ermittelt?

Problem:
Für mich hat sich die Frage gestellt, wie der Outlook-Client (gerade außerhalb der Organisation über Outlook Anywhere) den Autodiscover FQDN bekommt, die er anfragt um seine Autodiscover-Informationen zu bekommen.

Lösung:
Der Outlook-Client geht hier nach einem fest definierten Schema vor, dass man wissen sollte, da man sonst nicht versteht, warum der Client keine Autodiscover-Informationen erhält.

WICHTIG VORWEG: Als Mail-Domäne nimmt der Client nicht die Windows-Domäne sondern die Mail-Domäne der PRIMÄREN Mail-Adresse des Benutzers
Das kann Probleme machen, wenn man einem Benutzer nur eine interne Mailadresse gibt oder dieser verschiedene externe Mail-Adresse zugewiesen bekommen hat. Vor allem, wenn der Benutzer per Outlook Anywhere zugreift und keinen SCP erreichen kann und somit die Autodiscover-URLS abklappert.

Folgenden Ablauf durchläuft der Client für das Autodiscover-Ermittlung:
1.) Abfrage SCP (Service Connection Point) aus dem AD (ClientAccessServer AutodiscoverServiceInternalURI)
2.) Anfrage auf https://mail-domäne/autodiscover/autodiscover.xml
3.) Anfrage auf https://autodiscover.mail-domäne/autodiscover/autodiscover.xml
4.) Anfrage auf http://autodiscover.mail-domäne/autodiscover/autodiscover.xml
5.) Abfrage eines SRV-Records
6.) Verwendung der lokalen autodiscover.xml, soweit bereits vorhanden

Quelle: SebastianHetzel.net: Exchange Autodiscover

Exchange 2013: Rückmigration von Postfach Exchange 2013 auf 2007 schlägt fehl/funktioniert nicht

Problem:
Ich musste ein bereits migriertes Postfach vom Exchange 2013 auf den Exchange 2007 zurück verschieben.
Die Migrationsbatch wurde erzeugt, lief aber niemals los.

Lösung:
Aus mir leider nicht ganz verständlichen Gründen, muss man die erste Migration des Postfaches ZUM Exchange 2013 in der Migrationsübersicht löschen und danach ist eine Rückmigration problemlos möglich.
Sie können diese Löschen in der ECP-Website unter "Postfach" -> "Migration".
Hier die entsprechenden Batches des Postfaches suchen und alle löschen.
Nach der Löschung (kann etwas dauern - immer wieder aktualisieren) kann das Postfach auf den alten Exchange verschoben werden!
“Das Alzheimer-Gesetz der Programmierung: Wenn du einen von dir vor zwei Wochen geschriebenen Code ansiehst, kommt es dir vor als hättest du ihn noch nie gesehen.”
Dan Hurvitz – Software-Entwickler