Beiträge von darkstar

    Falsche Fehlermeldung aufgrund defekter Software, die schlicht versucht falsche Servernamen und Authentifizierungsmechanismen zu erraten. Denk Dir Deinen Teil dazu.

    Du brauchst den konkreten IMAP/SMTP-Server, also mxeXXX.netcup.net.
    Das braucht die manuelle Einrichtung des Accounts, da muss übrigens SPA deaktiviert werden.

    Wenn Du mit Netcup-Firewall alles dicht machst hilft die sicherlich auch.
    Sie hilft aber nicht gegen Anmeldeversuche wenn Du den Dienst - hier RDP - durchlässt. Und das ändert sich auch nicht, wenn der Dienst ein anderer ist.

    Generell gehe ich erfahrungsgetrieben davon aus, dass bei Windows ein generelles Sicherheitsrisiko besteht.

    Die Mail eines Antivirus-Anbieters, der mich erst um die Zusendung einer mit Schadsoftware befallenen Datei bat und dann nach 3 Tagen Sendepause schrieb, dass sie nun auch festgestellt hätten, dass ihre Software das Virus nicht erkennt, habe ich noch irgendwo.
    Wohlgemerkt: in einem Netzwerk mit um die 400 Usern, 2 RZ. Citrix-Servern und Windows-Domain. Wir haben dann das Netzwerk zwischen Weihnachten bis inklusive Silvester in Segmente getrennt und unter Zuhilfenahme von mir als Externen und aller 6 MA von IT und Betriebselektrik das Virus mehr oder weniger per Hand von jeder einzelnen Festplatte/Installation entfernt und nach Abschluss eines Netzsegments dieses wieder online gebracht.

    Warum sollte die Netcup Firewall nicht helfen? Wenn ich sämtliche Ports blocke und nur über Mesh-VPN zugreife, was soll dann passieren? Wo ist die Angriffsfläche?

    Ich sehe jetzt den Widerspruch zu einem Zugriff nur per VPN nicht.

    Ein Mesh-VPN ist nur eine etwas spezielle Form eines VPN, die ich außerhalb von sog. VPN-Diensten bisher nicht in freier Wildbahn gesehen habe.

    Auch habe ich jetzt erstmal nachgelesen, wozu ein Mesh-VPN im Gegensatz zu einer stinknormalen VPN-Verbindung gut sein soll - ich hab das bisher schlicht nicht gebraucht.
    Ich denke nicht, dass es hier einen erheblichen Geschwindigkeitsvorteil bietet, wenn das interne Netz zwischen VPN-Server und Windows Server über das Netcup-VLAN läuft. Zudem brauche ich so keinen von mir nicht kontrollierten Koordinationsserver sondern brauche im Zweifelsfall nur die IP des VPN-Servers (nichtmal DNS).

    Zum Thema Anmeldung und nur blauer Bildschirm (Hintergrundbild):
    Explorer.exe startet nicht, ggf. kaputtes Profil oder irgendein virtio.sys-Problem mit irgendeinem Windows-Update.

    Die Anmeldefehler/Sperrungen zeigen eigentlich nur, dass du einen Windows-Server ins Internet gestellt hast, vermutlich auch noch ungehärtet (mindestens für einen kurzen Zeitraum).
    DAS TUT MAN NICHT.
    Auch die Netcup-Firewall würde - solange auch nur ein Dienst durchgeht - daran wenig ändern.

    Tue Dir einen Gefallen, baue einen kleinen VPN-Server davor (separater VPS/RS) und nutze das VLAN und mach den direken Zugriff von außen auf den Windows-Server dicht. Wenn Du den VPN-Server generell auch als default Gateway nimmst, kannst Du ggf. auch die public ipv4 für den Windows-Server abmelden.
    Ich hab mir da mit strongswan/swanctl unter Linux was mit ipsec gebastelt, da hängen mehrere LAN-LAN-Verbindungen (andere Seite sind VPN-Router) drauf, dazu kann ich mich z.B. mit Handy oder Tablet über die eingebaute VPN-Funktion im IOS von irgendwoher anmelden. Lediglich der Zugriff von den VPN-Clients auf Internet-Inhalte braucht ein wenig iptables-Extra, damit dafür auch ein NAT erfolgt.

    Anschließend würde ich die Windows-Kiste neu installieren, denn ich hab keine Ahnung, durch wieviele Sicherheitslücken dort schon was läuft wovon niemand eine Ahnung hast. Alternativ diverse Virenscanner laufen lassen, alles an Programmen runterschmeißen was Du nicht kennst und fein säuberlich solange durch die Windows-Ereignisanzeige wühlen und alle Probleme klären bis dort nur noch klares Wasser kommt, d.h. keine unerklärlichen Warnings oder Errors (dokumentierte Falschmeldungen ausgenommen).

    Bei mir ist nur Fail2ban fleißig…

    Kleine Auswertung der Jails:

    Code
    for jail in $(sudo fail2ban-client status | grep "Jail list:" | sed "s/ //g" | tr ',' '\n' | cut -d: -f2); do echo -n "$jail: "; sudo fail2ban-client status $jail | grep "Currently banned:" | grep -oE '[0-9]+'; done

    Derzeit:
    dovecot: 0
    postfix: 59
    postfix-sasl: 1504
    sshd: 191

    bantime = 1h

    findtime = 60 min

    maxretry = 2

    Und als besonderes Schmankerl für die besonders Hartnäckigen:

    bantime.increment = true
    bantime.rndtime = 30m
    bantime.maxtime = 5w
    bantime.factor = 4

    Am Anfang gab es noch manchen User der noch irgendwo einen halbkonfigurierten Email-Account hatte und plötzlich keine Mails mehr senden konnte. Da ist jetzt aber Ruhe.

    It looks like you are missing the default route and you can communicate only inside your network:

    Linklocal-Version
    sudo ip -6 route add default via fe80::21c:73ff:fe00:99 dev eth0

    Or if you got a default gateway from Netcup (value from ip neigh)
    sudo ip -6 route add default via 2a0a:4cc0:0:1000::1 dev eth0

    Diese Methode gibt es, ist es aber in diesem Fall nicht. Man kann der Email entnehmen, dass es eine automatische Antwort auf eine "Supportanfrage" an die Support-Emailadresse ist und keine Versandbestätigung eines Webformulars. Das ist "Backscatter".

    Ich hatte, als ich geantwortet habe, nur den Anfang des Headers aus der Mail von slackito, nicht den kompletten aus dem Log.
    Im letzteren sehe ich auch kein netcup mehr...

    Das kommt über einen Exploit des Jira-Systems von Netcup.

    D.h. öffentliches Supportformular ausfüllen, Ticket wird erstellt, Automatisches Reply...

    Der Spammer gibt als Betreff die Werbebotschaft ein, dazu als Empfänger eine Maillinglistenadresse.
    Schon bekommt jeder, den man in die Mailingliste (hier irgendwas bei Google) aufgenommen hat eine legitime Email von Netcup.

    Die Mail stammt dann tatsächlich authentisch von Netcup, deswegen DKIM etc. korrekt.

    Schnellste sinnvolle Lösung: Formular nur via CCP zugänglich machen, am Besten dann schon mit allen wesentlichen Daten versehen.
    Vermutlich einzig sinnvolle Lösung, wenn es öffentlich bleiben soll: Versandbestätigung im Browser anzeigen, keine Bestätigungsmail.
    Ansonsten viel Glück beim Formularspam-Blocken.

    Ansonsten bekomme ich gerade eine Idee, was gerade im Ticketsystem abgeht und der Support überlastet ist.

    Hab gerade überlegt meinen DNS-Server als Vermögensübersicht zu missbrauchen.
    Bis mir dann einfiel, dass das Ausweisen des Wertes ja einer Bewertung bzw. Aufdeckung verdeckten Vermögens gleichkommt und u.U. bei bilanzierungspflichtigen Unternehmen als Bilanzgewinn auch der Steuer unterliegt.

    Also bitte nochmal genau darüber nachdenken.

    Die 8,5 GB waren ein Upload am Vortag…

    Da hätte ich jetzt erwartet, dass das gezählt wird und ich nicht mitten im Monat 1 GB Traffic (pro Monst?) auf dem aktivsten Server angezeigt bekomme (und am nächsten Tag 3 GB). Oder zählt da nur von meinem Server ausgehender Traffic?

    Kann der die enthaltene Email auch in einem IMAP-Ordner ablegen? Dies ist für meinen Workflow im Ticketsystem „FreeScout“ notwendig: Lesen oder weiterleiten könnte ich auch in der Mail.app, brauche aber das Original-Mail in meiner Mailbox…

    Nicht direkt, er kann aber ein EML-Attachment öffnen und hat eine Mailfunktion um das Ganze per Apple Mail weiterzusenden. Ist aber alles manuell auf dem iPhone.

    Zwei Dinge:

    Ich traue der Traffic-Anzeige im SCP nicht: Die Traffic-Anzeige zeigt bei einem Server genau 1GiB obwohl ich gestern allein 8,5 GB in nur einer Datei hochgeladen habe


    Verbesserungspotenzial:

    Ich hätte gerne eine Info auf welchem Host (Name/ID) mein RS gerade aktuell läuft. Würde irgendwelche Problemdiskussionen (Paketverluste etc.) deutlich zielführender gestalten und ich könnte mich selbst vergewissern, dass mein active/passiv-Cluster auf zwei verschiedenen Hosts liegt.


    Eventuell kann man das später auch noch mit Zusatzattributen wie Brandabschnitt etc. verknüpfen und ggf. später einmal und gerne auch aufpreispflichtig den Brandabschnitt festlegen in dem der RS/VPS umziehen kann und auch die gleichzeitige Nutzung desselben VHosts durch Server desselben Clusters systemseitig verhindern?

    Ich hatte nur noch 2 weitere Regel für den Sipprovider angelegt, da ich vermute, dass der Anlage 10K-20K reichen, der Sipprovider braucht vermutlich 15K-30K, das würde ich zukünftig noch trennen.

    Unabhängig davon was Deine TK-Anlage (bzw. Software) kann - Ich würde mit 2 Kanälen/Ports pro Rufnummer rechnen. Alles andere ist oversized.
    Was Dein Netcup-Serverlein kann ist eine andere Frage, hängt auch vom Codec ab, ob irgendwelche Skripte laufen etc.

    Nur zur Sicherheit: das Präfix::5060 ist so beabsichtigt?
    Ansonsten fällt mir auf: Rule 13 erlaubt eigentlich eingeschränkt das, was bereits Rule 12 erlaubt.
    Und bei Rule 9 würde ich nochmal schauen, ob das TCP oder doch wie bei ipv4 auch UDP sein sollte.
    TCP ist ja bereits für alle Ports in den Rules 5 und 6 erlaubt.
    Wenn es UDP sein soll, dann erlaubt Rule 9 etwas, was mit Rule 11 viel breiter erlaubt ist.

    Und finally: Sind es die Kanäle 10000-30000 oder 10000-20000?

    Hallo Zusammen,

    Ja, die wurde automatisch durch die erst OUTGOING Regel aktiviert und steht ganz unten bei den Impliziten Regeln. ;)

    Das erklärt es natürlich.

    Wenn ich mir das Konglomerat an Rules anschaue, die in der Firewall gelandet sind, so fehlt letztlich die Freigabe für INCOMING UDP beliebige IP, beliebiger port an serverip, 5060/5061 bzw. 10000-20000

    Das sollte man aber in 2 rules packen. Aber genau die Regeln - sollten sie als Policy eventuell schon existieren - sehe ich jetzt noch nicht in der Firewall für den Server. Das fehlt.

    OUTGOING ANY ist ja bereits erlaubt (Rule 9), das sollte auch UDP zulassen.

    Für DHCP stehts ja auch im NetCup-Wiki, aber wir habe ja statische :). Darüber bin ich auch schon gestolpert und konnte nicht auf den Server zugreifen =O

    Das ist noch ne andere Nummer.

    Die Adressen und Ports stehen dort oben, da gibt es nicht zu raten.

    Die Anlage funktioniert zu 100% wenn ich die Firewall ausschalte.

    Also muss die Firewall spezielle Einstellungen benötigen, welche ich bisher übersehe.

    Ich verstehe nur mit den von Dir angegebenen Regeln nicht einmal, warum dort irgendwas NICHT durchkommen sollte.
    Es sind ja bei Dir ausschließlich ACCEPT-Regeln.

    Ich hab bei mir ja auch die NETCUP-Firewall an, nicht eine Firewall-Policy definiert und es gibt nur die Standard-ICMP- und ALLOW-ALL-Blöcke. Damit erreicht man alles auf den Servern, unabhängig davon, ob die Firewall ein- oder ausgeschaltet ist.

    Die Firewall pro Server ist ja das Ergebnis einer Zusammenstellung von Firewall-Policies in einer von Dir weitestgehend bestimmten Reihenfolge, die von oben nach unten abgearbeitet wird. Ich vermute daher, dass es eine DROP-Policy vor dem systemseitigen ACCEPT-ALL-Block am Ende gibt.
    Daher nochmal die Frage: Ist dem so? Welche Policy-Überschriften stehen in der Server-bezogenen Firewall in welcher Reihenfolge?

    Bei mir gibt es nur

    netcup Ping allow

    Implizite Regeln


    Was gibt es bei Dir?

    Du müsstest da eine Art DROP ALL-Policy definiert haben, damit da überhaupt irgendwas geblockt wird.
    Ist Deine VOIP-Firewall-Policy überhaupt Teil der Firewall des Servers?
    Steht diese in der Firewall des Server ÜBER der VOIP-Policy oder danach?

    Kannst Du bitte Deine Ports 5060/5061 und 10.000-20.000 checken, vielleicht mal mit einem einfachen
    "netstat -a|grep LISTEN"?
    Welche Ports lauschen da und haben vielleicht eine wichtige Funktion?