PowerShellAdmin

Moin, mich würde an dieser Stelle einfach mal eure Meinung und Lösungsansatz interessieren. SPF Records sind nicht durchgehend verbreitet und ein korrektes RDNS Setup "war" nie ein Standard. Eine saubere DNS/RDNS Konfiguration ist aber seit Jahren in den meisten Konzepten bestandteil und wird auch von vielen großen Providern umgesetzt. Von obigen ausgehend komme ich derzeit zu der Aufassung: SPF Records sind nicht zwingend erforderlich, müssen aber berücksichtigt werden falls vorhanden. DNS/RDNS Prüfung sollten für jede Email vorgenommen werden. Abschließend - mir ist durchaus bewusst, dass Spammer heute großteils über ganz andere Kanäle fungieren und dies nur Teil eines Lösung / Konzepts ist, ähnlich wie Greylisting => Am Ende zählt aber die Summe. Nun würde mich hier die Umsetzung interessieren. Im Exchange 2010 gibt es die Option Sender-ID und baut damit ja bereits eine Technik vor. Aber mir scheint diese Technik ungenügend: RDNS Prüfung wird nicht ausgeführt. Wenn ich von einen gültigen SMTP Server die Domäne fälsche, erhält diese Email lediglich den Status Softfail udn wird nicht direkt gesperrt. Zusätzlich gibt es die Absenderzuverlässigkeit - Hier habe ich ein Scoring anhand dessen ich wohl auch die RDNS Prüfung indirekt mit einfließen lassen kann. Aber dazu kommt dann noch das N Stunden Blacklisting und es ist mir nicht transparent genug. Das Feature ist völlig untransparent und das Scoring auch nicht gut dokumentiert. Den Punkt SPF könnte ich via Transport- oder Virenschutz-Regel lösen => Headerfields prüfen und zurückweisen. VG PSAdmin

Wird als DBMS ein MS-SQL Server eingesetzt ? Auf einem Azure System konnte ich die Query Performance auf einem SQL Server 2014 immerhin verdoppeln (Achtung gilt nur für den SQL Server 2014 - Das Ganze nicht direkt in der Produktion umsetzen). Prüfung der Ursprungsperformance via sql Query Stress 0.9.7 und nach den Optimierungen erneut prüfen. https://www.mssqltips.com/sqlservertip/2730/sql-query-stress-tool/ Hier ruft man eine möglichst auslastende Prozedur in der DB aus und lässt diese z.B. 1000-10000 durchlaufen und merkt sich den Mittelwert. Optimierungs Möglichkeiten: -Compatiblity Level der Datenbank auf neustes setzen (z.B. SQL Server 2014(120) => Erst dadurch greifen diverse Performance Verbesserungen im jeweiligen SQL Server Bei SQL Server 2014 z.B: -kleine SSD im Server montieren => Funktion Speicher für Temporäre DB & Bufferpool (http://searchsqlserver.techtarget.com/definition/buffer-pool) -Temporäre DB auf SSD auslagern: USE MASTER GO ALTER DATABASE tempdb MODIFY FILE (NAME= tempdev, FILENAME= 'D:\sqlcache\tempdb.mdf') GO -Bufferpool aktivieren (Achtung ! Bufferpool darf maximal die vierfache (bei der Standard-Edition) Größe des Arbeitsspeichers betragen, ansonsten startet der SQL Server nicht mehr). Beim SQL Server 2014 Express liegt das Limit wohl sogar bei nur 1GB. Falls der SQL Service nicht mehr startet, muss man den Bufferpool wieder via SQLCMD deaktivieren und im Anschluss mit den geringeren Werten wieder aktivieren. --enable Buffpool USE master GO ALTER SERVER CONFIGURATION SET BUFFER POOL EXTENSION ON (FILENAME = 'D:\sqlcache\SQL2014.BPE', SIZE = 16 GB); GO

Im Unternehmen nutzen wir seit einer Weile Owncloud. Bin soweit sehr zufrieden, auch die Anbindung an das lokale Active Directory ist kein Problem und funktioniert tadellos. Auch von den Mitarbeitern ansich gerne genutzt - eignet sich sehr gut, zum einfachen Datenaustausch mit dem Kunden. Womöglich gibt es mittlerweile auch weitere Alternativen, aber wir sind mit Owncloud sehr zufrieden. Das Ganze ist selber gehostet und liegt nicht bei einem Webhoster.

Der Trojaner kommt über gekaperte Teamviewer Accounts, die auf Rechner noch Zugriffe haben - also keine Schwachstelle in Teamviewer ansich.

Was ja für ein Umdenken spricht. Websiten und Dienste sollten generell auf https umgestellt werden, nicht mehr nur die privaten Bereiche. Eine große Gefahr der klassischen Trennung ist auch, dass Entwickler verschlüsslungswürdige Bereiche (unabhängig von Man in the Middle) nicht nachpflegen oder einfach vergessen. Die Kosten und Aufwändungen in kleinen Umgebungen sind ja auch überschaubar, anders sieht es mit großen Plattformen aus. Da können dann durch die Performance sicherlich spürbare Mehrkosten entstehen.

Bei der PS gibts auch schicke Sicherheitskonzepte - Signierung des Codes. Es ist ohne Frage besser via https - das ist für mich völlig nachvollziehbar und eure Begründung durchweg schlüssig. Für mich war die Risikobewertung nur ein wenig irritierend, da ich in gekaperten Webservern ein höheres Risiko sehe. Das Thema ist aber auch sicherlich nicht mein Fachgebiet, daher nehme ich das gerne auch mit. Vielleicht bin ich mittlerweile auch etwas abgestumpft - Da man als Admin eben nie so darf wie man will. Gerade bei Großunternehmen habe ich da schon so einiges erlebt - auch im Bereich Sicherheit (rede hier von weltweit tätigen Firmen mit X000 Ma).

@lefg Ansich hast du recht, wollte hier auch keinen weiteren Nebenkriegsschauplatz lostreten. Aber in dem Fall fand ich es durchaus berechtigt - man lernt schließlich nie aus. @Blub & Testperson Danke für Info, das ist nachvollziehbar, auch wenn ich die Abschätzung des Risikos überschaubar finde. Das tatsächliche Risiko sollte doch sehr gering sein. Aber wieder was mitgenommen :-)

Danke für die Ergänzung, das interessiert mich jetzt doch. Daher auch noch mal eine weitere Anmerkung. Prinzipiell ist das aber auch bei SSL Verbindungen durchaus möglich - allerdings erheblich erschwert. Ebenso benötigt man einen Einfallspunkt - bei öffentlichen Netzen natürlich deutlich "leichter" gegeben. Klar heute hat man andere Rechenleistung und eine Verschlüsselung ist im Regelfall umsetzbar - mit verträglicher Auslastung. Nur ist hier tatsächlich so eine Gefahr ? Public Content "war" zumindestens nie verschlüsselt (klar heute wissen wir schon lange, dass Aussagen wie "never change a running system" absolut falsch sind). Wäre hier ein Prüfsummenverfahren nicht sinnvoller - (ach was wäre es toll, ein Browser mit Abfrage - nach dem Download muss man die Prüfsumme auf der Website kopieren, damit der Download ohne Warnung freigegeben wird). Ansonsten ist eine kompromittierte Website wohl erheblich wahrscheinlicher und dann nützt einem die SSL Verbindung auch nichts.

Hey Blub, ich stimme dir ja generell zu - aber "https-gesicherten DownloadSeiten" hat welchen Hintergrund :rolleyes: ? Es werden hier keine vertraulichen Daten übermittelt, die verschlüsselungswürdig sind. Natürlich könnte man daraus wieder Daten über das Downloadverhalten erfassen - dies könnte natürlich über den Provider, als auch durch weitere Zutritte im Netz geschehen. Bitte nicht falsch verstehen - mich interessiert hier nur der fachlische Hintergrund :-) VG

Heute eine Email von "Paypal" gefunden - der nächste Versuch. Anhang ist eine HTML Website. In der Email steht, dass man einen Browser mit aktiviertem Java Skript benötigt...

Ich denke der Thead läuft etwas aus dem Ruder, auch wenn ich die Nebendiskussion nicht verkehrt finde. Den Vergleich finde ich nur etwas kontrovers, MS essentials und seine Nachfolger waren früher recht schlecht. Kostenlos waren sie für Unternehmen eigentlich nie. Ich möchte damals essentials, da es klein und schlank war. In der Company nutzen wir Eset AV - läuft ähnlich schlank und sind sehr zufrieden. ( im Vergleich zu AVG und kostenpflichtig Avira ). ESMX 6 ist übel, die Dokumentation unzureichend, der Support teilweise überfordert und das Produkt hat noch kleine Bugs und leider auch Einschränkungen. Ansonsten läuft es wirklich gut und im Ergebnis bin ich zufrieden ( bis auf Kleinigkeiten).

Sicherheit ist unbequem aber das ist alles relativ. Die Einschränkungen werden zumeist durch Benutzerignoranz erst zu Problemen. Selbst bei transparenter Informationsplitik wird dann die Info Mail ignoriert und sich dann gewundert, wenn man in Restriktionen läuft. Ich bin kein Freund von Verboten, aber in einer gewissen Form ist es heute notwendig

Tja Javaskript ist im Web fest verankert. Doc Dateien immer noch nicht ganz abgewöhnt. Sicherheit ist ja ansich ein Bestreben, man kann es also nur verbessern nicht erreichen. Man darf leider nicht immer wie man will, als Admin ergeben sich daraus immer auch Diskussionen. Der konkrete Fall wäre vermeidbar gewesen - weder ESET ESMX als auch der ESET Client Schutz haben das Virus gefunden. Allerdings hätte eine einfach Dateiregel diesen Vorfall unterbunden. Ich tendiere immer mehr zum Blockall & Exceptions,aber da fehlt auch oftmals die Akzeptanz. Wir haben unser Mailing mittlerweile sehr restriktiert, bei akzeptabler Nutzbarkeit.

Moin, ja Systeme sind soweit alle ok - war ja nur der Client betroffen. Die anderen Systeme sind sauber. Freigaben wurden bereits wiederhergestellt. Das mit der Anzeige ist mir bekannt und hatte ich weitergegeben, sollte ja auch Online über das NRW Portal gehen und ohne großen Aufwand. Allerdings sehe ich das Ganze eher nüchtern. Der Schaden ist in diesem Fall ja zum Glück sehr überschaubar -> ein nur halbversauter Freitag ;)

Ahoi, hatte hier bei einem kleiner Kunden jetzt auch einen Vorfall. Nach Locky sieht das Ganze aber nicht aus, eher nach einem schlechten Trittbrettfahrer. Ähnlich wie bei Locky wurden einige Daten auf dem System und Server verschlüsselt. Der Schaden war gering, eine Sicherung auf dem Server wurde bereits wiederhergestellt und der Client wird neu eingerichtet. Bei der Untersuchung des betroffenen Clients sind mir jetzt zwei Dateien aufgefallen: Dateien werden in .Xort verschlüsselt. Im Userverzeichnis habe ich den Übeltäter und zwei weitere interessante Dateien gefunden: confimation.key xort.key Mein Verdacht ist, dass der Verschlüsselungskey nicht gelöscht wurde und die Daten restaurierbar sind. Würde mich doch interessieren, ob ich da mit vertretbaren Aufwand noch dran komme :) VG

Und schön die Daten nach Amerika :-O Auf MSXFAQ.de stand der Ansatz noch folgender Ansatz: "Es dauert einige Timeouts, bis Outlook aufgibt und dann doch RPC/HTTP macht. Leider scheint die Telekom diesen "Service" per Default für alle Kunden aktiviert zu haben und muss von jedem Anschlussinhaber individuell im Kundencenter abgeschaltet werden. Es könnte also ein Workaround sein, den CASARRAY-Namen im Internet zu pflegen und auf eine IP-Adresse zu lenken, die auf den Verbindungsversuch 135/TCP schnell mit einem "RESET" antwortet." Das wird natürlich wieder schwierig - beim TLD Local wird das ganze sehr problematisch und schwer lösbar. Außerdem wirklich eine Bastellösung. Wieder so eine Umsetzung, die konzeptfremd ist.. hauptsache noch weitere Werbeeinnahmen....

so ein kleines Update, es lag tatsächlich an der Telekom. hatte das Feature deaktiviert und Router neugestartet, DNS Cache geleert, aber scheinbar hat das etwas mehr Zeit benötigt... NSLookUp auf die interne IP Adresse des Exchange CAS => keine Auflösung (also so korrekt). Davor gab es eine IP zurück. Outlook schnurrt wieder :) Danke für die Unterstützung !

Danke das wäre ja ein Anhalspunkt. Teste es an dem Standort heute Abend über einen weiteren Client um dies auszuschließen. Tolles Stück natürlich in Outlook 2016 "(2) bei der RPC Proxy Konfiguration nur den Punkt "Bei langsamen Verbindungen zuerst per HTTP und dann per TCP/IP verbinden" auswählst" => ehm ja... ;) -Hatte die Navigationshilfe der T-Com testweise deaktiviert => keine Besserung.

Moin Nobbyaushb, auf dem Client lief in der Vergangenheit O2007 und das System ist länger im Betrieb. Ist ein Buchhaltungsrechner - daher laufen hier doch diverse weitere Programme (welche aber nicht direkt mit Outlook Anywhere kollidieren sollten). Provider: -Am Standort ein einfacher Telekom Business Anschluss (VDSL 50). Probleme sind hier nicht bekannt und aufällig geworden. -Die Verkabelung zum Gateway/Router ist Gigabit Mit RPCDiag fällt auf, dass der Verbindungsaufbau sehr, sehr lange dauert. @Traceroute von was ? Zur IP des Exchange-Servers ?

Guten Morgen, ich habe hier ein etwas verzwicktes Problem mit einem Client und mich würde interessieren ob ihr noch eine Idee habt. Wir haben einen Exchange 2010 im Einsatz - Der Zugriff über Outlook 2016, 2010, 2013 intern, als auch außerhalb über Outlook Anywhere läuft allgemein ohne Probleme. Exchange: Windows 2008r2 (aktuelle Updates), Exchange 2010 - SP3 - RU11 Client: Windows 7 x64, Office 2016 (aktuelle Updates), ESET NOD32, kein Mitglied der Domäne Problem: Ein einzelner externer Client braucht Minuten bis zum Verbindungsaufbau über Outlook Anywhere (aktiviere ich die VPN am betroffene Client, wird sofort verbunden). Lösungsansetze: -Kennwörter aus dem Passworttresor von Windows gelöscht -Edit: Outlook-Profile gelöscht und Outlook Settings -Das Problem bestand bereits mit Outlook 2010 auf diesem Client, 2013 oder 2016 haben keine Besserung gebracht -Autodiscover Einstellungen werden von Outlook 2016 ohne Probleme erkannt (Verbindungsaufbau erfolgt ja auch erfolgreich - aber er braucht halt..) -Testweise Registrierungseintrag gesetzt (http://www.haveyourebooted.com/outlook-2016-autodiscover-slow-with-hosted-exchange/) Hinweis: Wie oben bereits steht - Autodiscover funktioniert ohne Probleme. Habe selbst Windows 10 mit ESET und Outlook 2010 - 2016 dort im Einsatz und das Problem ist ein absoluter Einzelfall.

office 2007 + Makro Officedocs blocken, Office 2003 blocken (da Makros dort nicht in eigene Dateiformate ausgelagert wurden). Soweit das Sicherheitskonzept innerhalb Office 2007+ hier funktioniert, sollte man damit viel vomTisch haben. EMSX bietet auch eine Inhaltsfilterung für Makro Dateien, wie gut die funktioniert werde ich nochmal die nächste Woche anschauen (sollte dann unabhängig von der Erweiterung funktionieren). Nachteilig ist, dass die Email dafür bereits eine Zustellungquittierung kriegt....

Ich kann dir nur von solchen Projekten als Abschlussprüfung abraten. Spreche hier aus eigener Erfahrung - mein Projekt hatte damals einfach den vielfachen Umfang der Vorgabe. Das Ganze in die Rahmenbedingung zu argumentieren war wirklich nicht einfach. Migration einer kleinen IT Landschaft ( 2 kleine Server) auf neue Hardware und Software. Da hing neben der Domäne eine Wawi und eine Tobitmailserver dran.. (letztere Migration hatte mich viel Energie gekostet) und das ohne Unterstützung ;). Gerade die schriftliche Dokumentation hat mich erschlagen, da die Vorgaben viel zu klein waren um dies vernünftig abzubilden. Die zeitlichen Vorgabe war außerhalb der Diskussion, diese wurde ebenfalls um ein vielfaches gesprengt. Am Ende waren die mündlichen Prüfer begeistert - ob man sich den Stress antun muss (gibt ja auch noch die Prüfungen..)... ich finde nicht, auch wenn ich sicherlich viel gelernt hatte.

A) Dass er Netzwerkressourcen mit Zugriff selbstständig findet B)Ganz klar die Umsetzung der Emails - die weicht erheblich von bisherigen Angriffen ab. Aufmachung und Absender ( Server von echten Firmen genutzt ) C) wer weiß was es für Schwachstellen in Docx und Office gibt ... Warte erstmal die nächsten Tage ab. Zielführend werden nur noch Makro Dateien blockiert...

Als Reaktion auf den derzeitgen Stand habe ich temporär die Blockierung im AV deutlich restriktiert. Soweit ein Kunde oder Partner uns Office Docs zustellen möchte, muss er diese mit einen Passwort packen und uns zusenden. Das Ganze reduziert natürlich nochmals deutlich das Gefährdungspotential. Mittelfristig werde ich wohl wieder Office Dateien - ausgenommen Makro Dateien zulassen. Möchte aber erstmal abwarten, wie sich das Ganze entwickelt. Verschlüsselte Archive sind aber sicherlich auch nicht die beste Lösung. Locky ist ja ein ziemlicher Badass, da er eben Netzwerkweit (abhängig vom Zugriff) fungiert und es dieses mal eine enorme Professionalität aufweist. => Hatte eine der besagten Emails diese Woche im Postfach - Die Email lag im Rechnungspostfach, die Email und Absenderfirma waren absolut authentisch, die Rechnung und das Dateiformat (docm) als solche in diesem Zusammenhang natürlich direkt auffällig, vor der Löschung wurde noch der Absender gegooglet => 10 Punkte... Locky Weder mein Clientschutz, noch der Exchange Serverschutz hatte zu dem Zeitpunkt reagiert. So eine Sensibilisierung kann man vom Anwender einfach nicht mehr erwarten. Der Trend geht halt klar Richtung "Whitelisting" und möglichst viel restriktieren bzw. via Prüfverfahren bereitstellen. Aber in großen ITs - führenden Banken, läuft es ja nicht anders (auch wenn hier selbst noch diverse Schwachstellen sind). Ich warte jetzt erstmal gespannt, auf die kommenden Ableger und werde dies auch zum Anlass nehmen, die internen Policies zu überarbeiten.

Hi Norbert, schön dass du dich meldest. Das Tool sieht auf den ersten Blick sehr interessant aus. Hast du Erfahrungswerte mit dem Tool - sieht auf den ersten Blick sehr passend aus. VG :-)