Ein Blog über den alltäglichen Wahnsinn im Leben eines Fachinformatikers
Auf einem Server kam es nach einem Update der Anti-Virensoftware Trend Micro zu einer ungewöhnlich hohen CPU-Auslastung. Grund hierfür war ein Hintergrundprozess zu dem die ganze Zeit von einem Messgerät eine Vebrindung aufgebaut wird:
Vor einiger Zeit hat ein Blitzeinschlag mein Audiointerface „zerstört“. Genau in dem Moment als es draußen gleißend hell wurde, wurde es relativ still. Die Anzeigen des Interfaces wurden dunkel und es tat sich nichts mehr. Der Blitz muss durch den Rechner und dann über den USB-Anschluss ins Interface gelangt sein. Nachdem das Interface neu angeschlossen wurde leuchteten zwar die Anzeigen am Interface wieder und es gab sogar einen Ausschlag auf den Anzeigen als ich Musik abspielte. Leider aber gab es über keinen der Ausgänge mehr etwas zu hören. Ebenso wenig ließ sich ein Signal über den Instrumenteneingang noch über den Mikrofoneingang aufnehmen.
Naja halb so wild, ein Fall für die Hausratversicherung, sofern Blitzeinschläge abgesichert sind. Allerdings wollte die Versicherung das zuerst nicht zahlen, da die Spezialisten nichtfür die richtige Adresse recherchiert haben.
Für einen eigenen vernünftigen Nachweis hat mir die Webseite https://kachelmannwetter.com/de/blitze extrem weitergeholfen. Nachdem ich die detaillierten Infos zu den Blitzeinschlägen bei uns, sowie eine Zeugenaussage der Nachbarn, bei der Versicherung eingereicht habe gab es die Entschädigung.
In der Zwischenzeit konnte ich für einen Bruchteil des Neupreises ´gebrauchten Ersatz kaufen, sodass die ganze Geschichte sogar für einen Gewinn gesorgt hat 😉
Aufgrund der GoBD ist es seit Anfang 2017 für die digitale Aufbewahrung von Belegen, selbst für Nebengewerbe, nötig diese „revisionssicher“ in einem Dokumenten-Management-System zu speichern. Das Ablegen der Dateien in einem normalen Dateisystem wird vom Gesetzgeber nicht mehr gestattet, da es laut diesem zu viel Spielraum für Manipulationen bietet.
In der Cloud, wo man selber keine Möglichkeit haben dürfte an den Kern des Dokumenten-Management-Systems zu gelangen, dürften die Manipulationsmöglichkeiten gering(er) sein. Eine lokale Lösung hingegen dürfte gegenüber einem normalen Dateisystem kaum einen Vorteil in Bezug auf die tatsächliche Revisionssicherheit der einzelnen Belege bringen. Gerade bei einem Nebengewerbe, wo im Regelfall eine Person für alles zuständig ist, ist die Nutzung eines DMS kein Mehrgewinn.
So sind Manipulationen ganz einfach möglich, indem man selber Änderungen in der Datenbank vornimmt. Hier beispielsweise bei dem DMS Bitfarm:
Der älteste Trick der Welt, der schon manche Test-Lizenz verlängerte, lässt sich natürlich auch nutzen: An der Systemuhr drehen, danach ein Dokument im DMS einfügen. Hier beispielsweise beim DMS CompuDMS:
Im extremsten Fall kann man, mit entsprechendem Zeitaufwand, ein komplettes Archiv von Grund auf neu aufbauen, indem man für jede Änderung die Uhrzeit und das Datum verstellt. Wenn man dies in der richtigen reihenfolge macht, wären sogar die IDs innerhalb der Datenbank in der richtigen Reihenfolge!
Meiner persönlichen Meinung nach ist vermutlich kein DMS, zumindest wenn man Administrator ist und dieses lokal nutzt, wirklich brauchbar in Bezug auf die rechtlichen Anforderungen. Bestraft werden durch den Mehraufwand dank des Gesetzes die Leute, die bisher ehrlich waren. Die, die bisher beschießen haben, werden dies mit Mehraufwand auch in der Zukunft tun!
Es ist recht einfach alle Powershell-Skripte zur Ausführung auf einem Computer zuzulassen. Hierzu muss man einfach nur folgenden Befehl als Admin absetzen:
|
1 |
Set-ExecutionPolicy Unrestricted |
Was ich bis vor einiger Zeit gar nicht wusste, ist dass man aber auch ohne Admin-Rechte jegliche Powershell-Skripte starten kann. Hierzu muss man nur das Skript wie folgt aufrufen:
|
1 |
PowerShell.exe –ExecutionPolicy Unrestricted –NoProfile –File "C:\Skript.ps1" |
Grund ist, dass die ExecutionPolicy für jede Powershell-Sitzung neu eingestellt werden kann und das von jedem Benutzer! Hiervon machte z.B. einer unserer Software-Anbieter Gebrauch, weshalb mir das erst aufgefallen ist, da die Skripte trotz restriktiver ExecutionPolicy gestartet werden.
Da ein Standard-Benutzer sowieso nicht weiß was ein Powershell-Skript ist und dass man dieses per Kontextmenü ausführen kann, spricht meiner Meinung nach nichts dagegen die ExecutionPolicy auf Unrestricted zu setzen. Schützen kann sie ja sowieso nicht, wenn jeder Benutzer oder ein Schadprogramm, das im Benutzer-Kontext ausgeführt wird, sie aushebeln kann. Das einzige was dann wirklich schützt wäre ein komplettes Deaktivieren von Powershell-Skripten für bestimmte Benutzergruppen.
Weitere Infos:
http://www.admin-source.de/BlogDeu/401/powershell-executionpolicy-richtig-verstehen-2
Eine weitere Odyssee im DSL-Dschungel ist noch nicht zu Ende. Aus verschiedenen Gründen habe ich die Leitung bei der Telekom gekündigt. Da hier eh nicht mehr als 16 MBit/s verfügbar sind, wollte ich dann zu einem Billig-Anbieter gehen. Bei o2 gibt es übertrieben günstige Tarife, sogar ohne MVLZ. Zwar gibt es dort eine Volumendrosselung, aber diese greift erst nach ein paar Monaten des Über-die-Strenge-Schlagens. Da ich dort eh nur übergangsweise hinwollte also halb so wild. Also der Telekom gekündigt und bei o2 online bestellt. Ich bekam eine Mail bzgl. meiner Bestellung, allerdings ohne wirkliche Informationen zur Bestellung, mit dem Hinweis es folge eine Auftragsbestätigung. Aber die folgte nicht, auch bis heute nach 5 (!) Wochen nicht …
Eine Woche habe ich o2 gegeben bevor ich dort anrief und mich vergewissern wollte, dass auch alles glatt läuft. Tja, was soll man sagen. Wenn man es hasst bei der Hotline der Telekom oder von 1&1 anzurufen, dann wird man die o2-Hotline lieben. Direkt beim ersten Versuch war die Hotline wegen technischer Probleme gar nicht erreichbar. Am nächsten Tag war sie erreichbar, mit einer Wartezeit von ca. 30 Minuten und nach dem Weiterverbinden von weiteren 15 Minuten, nach der mir mitgeteilt wurde, dass das neue Kundensystem offline sei und man mir grad nicht helfen könne. Am nächsten Tag kam ich nach ca. 20 Minuten durch, nach denen mich die Mitarbeiterin mit einem Kollegen verbunden hat, was wiederum 20 Minuten dauerte. Insgesamt habe ich 4 oder mehr Stunden in der Hotline vertrödelt. Mehr dazu kann man noch in dem Forenbeitrag lesen, den ich in der o2-Community eingestellt hatte, lesen. Die ist übrigens voll von Beiträgen gleicher Art. Dort jubeln die Leute wenn es jemand schafft zu kündigen und bei einem anderen Provider landet. Abschließend bleibt mir nur zu sagen: o2 ist ein Schrottanbieter – bloß meiden!!!
Übrigens habe ich meinen Widerruf über 2 Fax-Nummern dort hingeschickt. Per E-Mail ist o2 unter keiner einzigen Mail-Adresse greifbar!!! Selbst bei einer Mail an info@o2.de kommt eine Nicht-zustellbar-Mail zurück. Wo gibt es denn sowas? Ich rechne nicht damit, dass ich noch eine Bestätigung für irgendetwas bekomme. Vermutlich hat meinen Auftrag bis heute eh niemand angefasst.
Deshalb geht es jetzt zurück zur Telekom 😀
Allerdings nicht auf meinen Namen, wodurch wir wieder in den Genuss einer Routergutschrift und diverser Neukunden-Boni, die man mir nicht in dieser Höhe geben wollte, kommen werden. Effektiv kostet die Leitung dann ca. 19 € im Monat. Warum nicht gleich so? Zur Überbückung werden jetzt Testkarten von der Telekom mit 10 GB kostenlosen LTE-Volumen verbraten 😎
Eine Mitarbeiterin von einem Unternehmen in dessen Namen die Worte „Mark“, „Office“ und „Trade“ vorkommen rief an und behauptete jemand würde gerade versuchen den Firmennamen meines Arbeitgebers als .net-Domain, die bisher noch frei war, zu registrieren. Angeblich würde man uns wegen eines Vorrechts aufgrund des Firmen- bzw. Markennamens anbieten die Domain „wegzuschnappen“. Da sich die Domain aber nun im Registrierprozess befindet, sei es nicht mehr möglich die Domain normal über einen Provider zu registrieren, sondern man müsse die nun direkt bei diesem Anbieter übernehmen. Klar, natürlich nur für einen saftigen Obulus von 300 € für eine Laufzeit von 10 oder 15 Jahren. Ob die 300€ jährlich gemeint waren weiß cih an der Stelle agr nicht. Die Domainchecks bei allen gängigen Providern zeigten die besagte Domain aber alle als frei käuflich an.
Hier wird anscheinend darauf abgezielt Firmen die eventuell keine eigene IT-Abteilung haben dazu zu bringen die Domain aus Angst, dass nachher wirklich jemand unter dem Firmennamen eine Domain betreibt, zu kaufen.
Ein ähnlicher Vorfall wird hier bei domain-factory beschrieben:
https://www.df.eu/blog/hinweis-auf-betrugsmasche-und-warnung-vor-angeblichen-anrufen-des-hostproviders/
IST-Zustand:
Es gibt eine auf iptables basierende OpenSuse-Firewall. Diese wird im Normalfall durch den Firewallbuilder administriert. Es gibt eine DMZ mit öffentlichen IP-Adressen. Ob das grundsätzlich so die beste Lösung ist, lasse ich an dieser Stelle außen vor. Eine neue schnellere Internetanbindung bei einem anderen Provider kommt dazu.
SOLL-Zustand:
Da die neue Leitung schneller ist und der Chef meistens ungerne Geld für etwas ungenutztes ausgibt, sollte die Leitung natürlich sofort genutzt werden. Da sich aber bei der Umschaltung der DMZ viele kleine Probleme ergeben können und auch die Domains auf die neuen IPs gewechselt werden müssen, bin ich hier lieber einzeln vorgegangen. Also musste für den anstehenden Providerwechsel die DMZ schrittweise auf ein anderes öffentliches IP-Netz umgestellt werden.
Hier habe ich mal den für dieses Szenario relevanten Teil des Netzes grafisch dargestellt:
Problematik:
Das Intranet auf den neuen Zugang umzustellen kann man relativ unkompliziert machen. Anfragen ins Internet gehen dann über die geänderte Default-Route über den neuen Router und die Antworten kommen über diesen wieder zurück und werden an die Clients im Intranet geliefert:
Im Fall der DMZ, oder auch bei Freigaben per Port Forwarding, die noch über eine der alten öffentlichen IPs realisiert werden (wie z.B. oft für Exchange OWA), hat man nun allerdings aufgrund der geänderten Default-Route ein Problem. Die Anfragen kommen über ISP 1 aus dem Internet an, passieren die Firewall und gehen an den entsprechenden Server. Die Antwort vom Server geht aufgrund der Default Route in der Firewall aber an Router 2 und damit unter einer der neuen öffentlichen IPs über ISP 2 raus ins Internet. Das funktioniert so nicht, da der anfragende Computer diese IP in dem Kontext nun gar nicht kennt und die ankommenden Pakete verwerfen wird:
Das Problem besteht also darin, dass für die alte DMZ die neue „Default Route“ der Firewall, laut der Pakete über den neuen Router raus ins Internet geschickt werden, übergangen werden muss. Eine einfache Regel dafür lässt sich leider im Firewallbuilder nicht erstellen. Somit muss man leider drum herum manuell am Routing basteln.
Info:
Ebenfalls hilfreich ist die Lösung dieses Artikels wenn man dauerhaft 2 Internetleitungen nutzen möchte, z. B. eine Leitung fürs Surfen und eine weitere für VPNs oder eine DMZ.
Lösungsansätze:
Eine Möglichkeit wäre es die entsprechenden Pakete, die von einer bestimmten Source kommen, in diesem Fall aus der alten DMZ, und an ein der Firewall nicht bekanntes Ziel geschickt werden zu markieren und entsprechend dieser Markierung abzufangen und dann an ein anderes als das Default-Ziel umzuleiten. Das war mir aber zu viel des guten.
Die einfache Lösung für dieses Problem nennt sich „Policy Based Routing“ oder in diesem speziellen Fall „Source Based Routing“. Hierbei wird für das Routing nicht nur die Ziel-Adresse berücksichtigt, sondern auch die Quell-Adresse. Wie es sich für einen Nerd gehört kam ich nachts um 3 Uhr auf diese Lösung, als ich übelst krank gewesen bin und habe direkt nachts die Testumgebung dafür hochgezogen 😉
Meine Testumgebung besteht aus 5 virtuellen Maschinen auf denen OpenSuse läuft:
Auf die Einrichtung der iptables-Firewall soll dieser Artikel nicht eingehen. In der Test-Firewall steht nicht viel drin. Für den Live-Betrieb ist diese natürlich nicht verwendbar, da ich einfach alles zulasse.
Unter /etc/firewall habe ich das iptables-Skript firewall.fw abgelegt und in der
/etc/init.d/boot.local für den automatischen Start beim Systemstart eingetragen.
Für das Routing habe ich zwei Regeln erstellt, um die Default Route entweder über Router 1 oder Router 2 zu realisieren. Durch das Aktivieren der jeweils anderen Regel kann man hier leicht hin- und herwechseln.
In der Datei /etc/iproute2/rt_tables werden die Routing-Tabellen, die beim Systemstart aufgebaut werden, festgelegt. Entweder kann man einen neuen Eintrag für eine weitere Routing-Tabelle direkt in die Datei schreiben oder mit folgendem Befehl hinzufügen:
|
1 |
echo 200 dmz >> /etc/iproute2/rt_tables |
Diese Routing-Tabelle muss nun nur noch mit Regeln gefüllt werden. Da diese nach einem System-Neustart wieder flöten gehen, legt man dafür am besten ein eigenes Skript an. Ich habe dafür unter /etc/firewall das Skript dmz.sh erstellt und ausführbar gemacht. Auch dieses Skript wird in der /etc/init.d/boot.local für den automatischen Start beim Systemstart eingetragen.
Die erste Regel die benötigt wird gibt an wann die Routing-Tabelle genutzt werden soll. In diesem Beispiel bei Traffic aus dem Netz 192.168.3.0/24:
|
1 |
ip rule add from 192.168.3.0/24 dev enp0s3 table dmz |
In diese Tabelle kommt nun noch die Default Route über den alten Router:
|
1 |
ip route add default via 192.168.1.1 dev enp0s8 table dmz |
Das reicht aber noch nicht. Es fehlen noch die Routen für die anderen Netze, ansonsten sind diese von dieser Routing-Tabelle aus nicht mehr erreichbar:
|
1 2 3 4 |
ip route add 192.168.1.0/24 dev enp0s8 src 192.168.1.2 table dmz ip route add 192.168.2.0/24 dev enp0s9 src 192.168.2.2 table dmz ip route add 192.168.3.0/24 dev enp0s3 src 192.168.3.1 table dmz ip route add 192.168.4.0/24 dev enp0s10 src 192.168.4.1 table dmz |
Quellen:
http://www.marcosorfila.com/site/firewall-builder-with-multiple-isp-connections
http://www.marcosorfila.com/site/wp-content/uploads/Firewall-Builder-with-multiple-ISP-connections/ip_rules
http://wiki.linux-club.de/opensuse/Policy_Based_Routing
http://www.cyberciti.biz/faq/howto-linux-configuring-default-route-with-ipcommand/
http://www.linuxjournal.com/content/linux-advanced-routing-tutorial?page=0,3
http://superuser.com/questions/784331/hooking-linux-machine-to-secondary-router-isp-how-to-setup-routing-correctly
http://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming/23345#23345
http://opensuse.14.x6.nabble.com/yast2-advanced-routing-td3083578.html
http://www.rjsystems.nl/en/2100-adv-routing.php
http://www.linuxhorizon.ro/iproute2.html
Wenn man eine zweite Internet-Leitung hat, die über einen weiteren Router aus dem Netzwerk nutzbar ist, lässt sich der POP3-Mailabruf auf einem Small Business Server im Notfall oder zur Lastverteilung über diesen umleiten. Dies ist zwar kein optimales Setup, aber in einer kleineren Umgebung durchaus eine vorübergehende „Absicherung“ wenn eine der Leitungen ausfällt.
Als erstes benötigt man die IP-Adressen des POP3-Servers:
|
1 2 3 4 5 6 7 8 9 |
nslookup pop.gmx.de Server: fritz.box Address: 192.168.1.1 Nicht autorisierende Antwort: Name: pop.gmx.net Addresses: 212.227.17.169 212.227.17.185 Aliases: pop.gmx.de |
Den Traffic an diese IP-Adressen leitet man dann an den zweiten Router:
|
1 2 |
route add -p 212.227.17.169 mask 255.255.255.255 192.168.1.2 route add -p 212.227.17.185 mask 255.255.255.255 192.168.1.2 |
P steht für „persistant“ und sorgt dafür, dass die Routen dauerhaft, also auch nach einem Neustart, bestehen.
Um die Routen wieder loszuwerden, benötigt man nur folgenden Befehl für die beiden Adressen:
|
1 |
route delete -p 212.227.17.169 |
Wenn man sich diese Befehle in Batch-Dateien speichert kann man so recht einfach zwischen den beiden Leitungen hin und her wechseln.
Nutzbar wäre dies z.B. auch für den Mail-Versand über SMTP oder den Abruf von Updates über den WSUS.
Wenn eine überschaubare Anzahl von extern gelagerten E-Mail-Konten auf einen Exchange-Server verschoben werden soll, lässt sich dies recht leicht mit Hilfe von Outlook bewerkstelligen. In diesem Fall war ein Großteil der Konten von vornherein schon auf dem Exchange und eine Hand voll Außendienstmitarbeitern hatten ihre Konten direkt vom Provider auf ihren Geräten eingebunden.
Nach der Anlage des entsprechenden Benutzers und seines Mail-Kontos im Active Directory holt man sich als Administrator die vollen Rechte für das Mail-Konto und bindet dieses als Zusatzkonto in Outlook ein.
Am besten ist es, wenn sich die Konten per IMAP einbinden lassen, was heutzutage bei jedem halbwegs vernünftigen Provider kein Problem darstellen sollte. Zusätzlich zum Exchange-Konto bindet man nun das extern gelagerte Postfach per IMAP in Outlook ein. Natürlich nur ausgehend davon, dass der betroffene Mitarbeiter dieser Aktion zugestimmt hat bzw. das Mail-Konto ausdrücklich nur beruflich genutzt werden darf!
Nun verschiebt man alle Mails aus dem Posteingang, Gesendete Elemente, etc. in das Exchange-Konto. Nachdem alle Elemente verschoben sind kann man bei Nutzung eines POP3-Connectors auf dem Exchange-Server dort nun das Konto für den automatischen Abruf hinzufügen. Der Grund warum man dies nicht von vornherein machen sollte liegt an dem anfallenden Traffic zu dem es kommen kann, wenn man den Abruf aller alten E-Mails über den Connector laufen lässt. Da dies unter Umständen einige Zeit in Anspruch nehmen kann, ist die Zustellung von E-Mails an bereits auf dem Exchange-Server befindliche Mail-Konten sonst mit einer längeren Wartezeit verbunden.
Hat der betroffene Mitarbeiter seine Mails bisher per POP3 abgerufen, ist zu beachten, dass je nach Einstellung beim Client eventuell bereits alle Mails auf dem Server gelöscht wurden. Außerdem liegen die gesendeten Elemente dann nur auf dem Client. Wenn möglich sollte man das Exchange-Konto in diesem Fall auf dem Endgerät des Mitarbeiters hinzufügen und den Mail-Transfer dort vornehmen.
Unbedingt beachten: Wenn man schon längere Zeit bevor man die Exchange-Konten aktiv nutzen will diese auf dem Exchange-Server anlegt muss man vorerst einen abweichenden E-Mail-Alias eintragen als den tatsächlich zu nutzenden. Ansonsten hat man das Problem, dass alle intern geschickten Mails an den Mitarbeiter schon im Exchange-Postfach landen und nicht mehr an das externe Mail-Konto zugestellt werden können. Zusätzlich sollte man in den Eigenschaften des Postfachs die Mail-Adresse in der Exchange-Adressliste ausblenden. Ansonsten besteht ebenfalls die Gefahr, dass Outlook-Nutzer versehentlich schon E-Mails an das neue Exchange-Konto senden.
Nachdem alle Konten umgestellt sind, sollte man sich, sofern man eine eigene Domain besitzt, dann komplett vom POP3-Connector trennen und die Mails direkt per MX-Eintrag an einen sogenannten Smart-Host, z.B. einen Postfix-Server, schicken und von dort an den Exchange-Server weiterleiten.
Der Ordner „C:\Windows\Installer“ beinhaltet Dateien, die eventuell für die Deinstallaton von Software benötigt werden. Besonders schön kann man so eine Speicherverschwendung mit der Freeware WinDirStat visualisieren.
Dieser Ordner war bei mir mittlerweile 24 GByte groß. Den Ordner einfach zu löschen ist allerdings eine schlechte Idee, da sich dort Dateien befinden könnten die zu noch installierten Programmen gehören. Stattdessen kann man das Programm PatchCleaner verwenden um diese Dateien zu beseitigen.
Das Programm zeigt die löschbare Datenmenge an. Bei mir waren es schon beachtliche 16 GByte:
Statt die Dateien direkt zu löschen kann man diese erst einmal verschieben, was auch so vom Hersteller der Software empfohlen wird:
Nach ein paar Tagen ohne Probleme habe ich die Dateien dann endgültig gelöscht.
Quelle:
http://techmixx.de/windows-10-ordner-installer-loeschen/