Posts by Artimis

    Ich muss gestehen, dass ich das gerne getan hätte, mir jedoch 20€ pro Device ein wenig zu viel ist.
    Ich habe noch einen Backup-vServer bei einem anderen Anbieter (wegen Ausfallsicherheit). Der hat zwar ein Traffic-Limit, hat aber volle Unterstützung. D.h., Interfaces sind nach Lust und Laune anlegbar.
    Dort geht alles super.
    Vielleicht liegt das am Routing hier bei Netcup?
    Hast du mal den Traffic mitgeschnitten, was da so passiert, ob die Daten zu dem Zielhost überhaupt über openVPN geroutet werden oder irgendwo im LAN verschwinden?

    Ja, habe ich schon vor ein paar Tagen.


    Deshalb spame ich ja hier im Forum: Damit der Support weiß, was genau das Problem ist. Wobei: Herr Wacher hat vorgestern schon gesehen, dass ein Packet im Adressraum 192.168.0.xxx den Server 30min vom Netz trennt.


    Keine Ahnung, ich teste das nochmal und rufe -glaube ich- dann nochmal an...



    EDIT:
    Na toll, nun ist mir der Server wieder ohne mein Zutun abgeschmiert. Witzbolde!
    Und ganz vergessen: Telefon ist Sonntags ja nicht xD



    EDIT2:
    Aber eines muss man netcup in jedem Fall lassen:
    Support leisten die rund um die Uhr.
    Von Felix Preuß kriege ich Emails gegen 2:00 nachts,
    von Oliver Werner am Sonntag...

    Na super!
    Der Server ist vom Netz - Ich war's nicht.
    Habt iht mich nun zwangsgetrennt, weil ich versuche, den privaten Adressraum zu "hacken"?
    Oder sind hier Witzbolde im Forum unterwegs (nicht angegriffen fühlen, nicht unbedingt Member...), die das ausnutzen?

    Soo, habe jetzt mal, um Fehler meinerseits bei der Konfiguration von Asterisk ausschließen zu können, das Ganze auf meinem kleinen Backup-vServer installiert, exakt in den gleichen Schritten.


    Dort läuft alles auf Anhieb einwandfrei.




    So sollte es aussehen:

    Man sieht schon, dass er da irgendwas mit der internen IP des VoIP-Telefons anstellt:

    Code
    INVITE sip:1000@192.168.0.12:15060 SIP/2.0
    usw. bis:
    set_destination: set destination to 192.168.0.12, port 15060
    Reliably Transmitting (NAT) to 87.122.168.53:32768:

    Und da liegt der Hase begraben:
    Durch den Bug ist es momentan unmöglich, die Telefonanlage auf dem Server zu betreiben. Von den gravierenden Sicherheislöchern einmal abgesehen.
    Liebes Support-Team: Bitte tut da etwas!




    EDIT:

    Code
    root@red:~# ping 192.168.0.12
    PING 192.168.0.12 (192.168.0.12) 56(84) bytes of data.
    ------------------------------

    Der Server ist immernoch nicht zu gebrauchen :mad:



    EDIT die 2te:
    Es betrifft wohl nur den Adressraum 192.168.0.xxx:


    Also, so langsam würde ich meienen Server gerne benutzen, falls möglich...

    Um das Thema mal wieder aufzugreifen:


    Wie lange soll TS3 nun eig. bei der Beta12 hängenbleiben?
    Bis TS4 rauskommt? TS2 war immerhin schon bei RC2.
    Der Trend gefällt mir iwie nicht xD

    Kannst noch die Shell auf /bin/false oder so setzen und ohne Shell-Login den Tunnel starten.
    Außerdem kann man die geringe Unsicherheit des Passwortes (wird aber oft überbewertet) durch verwendung von ordentlichen Schlüsseln noch weiter in die Paranoia treiben.
    Dazu einfach in den /etc/shadow statt des Passwort-Hashes ein "!" oder so eintragen und in die ~/.ssh/authorized_keys den Public-Key des Private-Keys vom Client eintragen. Mit PuTTY-Keygen kann man schön einfach Schlüssel erzeugen. So ein 4096b-RSA-Key sollte die nächsten Jahrzehnte unknackbar sein. Aber bitte: Nicht selbst aussperren, ok? xD
    Wenn du da noch mehr Infos zu brauchst, gib Laut, ich schreibe dir dann ein Tut.


    Aber ansonsten sieht das schon schier aus!


    Vor allem der Gedanke, den viele vergessen: mySQL ist normalerweise völlig unverschlüsselt und muss praktisch über SSH getunnelt werden. Auf die unstable-Lösung mit sicherem mySQL würde ich nicht unbedingt setzten, wenn es sich vermeiden lässt.

    Quote

    Bei mir ist Local eine Datenbank krachen gegangen.


    Das kenne ich.
    Seit dem setze ich auf eine Backup-Datenbank auf Zellulose-Basis. Der Client funktioniert mit Graphit. Die Datenbank hat zwar kein Passwort, aber lässt sich mit Keys schützen (allerdings nur ein statischer). ;)

    Quote

    Das konnte ich auf einem alten gekündigten vServer (v200) gerade nicht reproduzieren:

    Ich glaube/hoffe auch nicht, dass das nicht die Regel ist xD
    Auf meinem vServer konnte ich das Problemlos mit einem ICMP-Packet auslösen.



    Quote

    Und genau das sollte jede halbwegs ordentliche Hard- und Software, die im professionellen Umfeld eines RZ's eingesetzt wird, nicht erlauben. Ob das wirklich der Fall ist, ist natürlich eine andere Frage...

    Ich weiß ehrlich gesagt nicht, ob das möglich ist. Es geht ja lediglich um ein Packet. Es ist ja vergleichbar mit einem Brief, auf den der falsche Absender geschrieben wurde. Naja, gut, der Class-C-Adressraum kann natürlich problemlos gefiltert werden.




    Aber das oben genannte Szenario ist ja schon ein Dickes.
    Es geht zumindest bei mir deutlich einfacher:
    Ich stelle einen "Monitoring-Service" für Freunde und Bekannte bereit.
    Dort kann man einfach eine IP und einen Port eintragen und ein PHP-Cron prüft per Socket, ob da etwas antwortet und schickt ggf. ne Alarm-Mail.
    Oder einen Web-Tracert-Dienst.
    Was ist nun, wenn jemand so oberschlau ist und bereits weiß, dass er im LAN eine IP hat, und diese von außen versucht anzupingen (klar, dass es Schwachsinn ist, aber es kommt tatsächlich vor). Dann öffnet das PHP-Script einen Socket,jagt ein Packet los und reißt den Server aus dem Netz.
    Ob das im Sinne eines "Servers" ist, IP-Bereiche auf keinen Fall "anwählen" zu dürfen...?

    Soo, habe inwzischen die Lösung:


    Da ist ein dicker Bug in der Firewall bzw. im Router, an dem der vServer hängt:
    Sobald ein Paket irgendeiner Art, es kann auch ein einfacher Ping sein, an einen privaten Adressraum wie 192.168.0.x gesendet wird, wird der gesamte Netzwerkverkehr des vServers ca. 30min gesperrt.


    Ich hoffe, es wird bald behoben. Nicht auszudenken, was man damit alles anstellen könnte.
    Man nehme an, jemand kommt auf die Witzige Idee, einen SYN-Flood auf den vServer zu starten. Damit man ihn nicht sofort drankriegt, bedient er sich IP-Spoofing und trägt kreativ die "192.168.0.1" ein. Dann reicht genau ein solche Packet, um einen Totalausfall des Servers zu provozieren!



    Für alle, die nicht wissen, was ein SYN-Flood mit IP-Spoofing ist:


    Jemand nutzt die Eigenart des TCP, dass eine Verbindung über den 3-Way-handshake ausgehandelt wird: Er setzt ein SYN-Packet an den Server ab, gibt aber in den Paketheader eine gefälschte Adresse (192.168.0.1) ein.
    Der Server empfängt das SYN-Packet, öffnet einen Socket und antwortet mit einem ACK-Packet an die Adresse aus dem Header.
    Diese geht dann ins Nichts und der Server lässt den Socket noch eine Weil offen, in der Hoffnung, da kommt noch etwas. Der Angreifer sendet aber erneut SYN-Packete und öffnet so immer mehr Sockets, bis es zum DoS kommt.
    Normalerweise! In diesem Fall sendet der Server das ACK-Packet an die im Header angegebene Adresse und wird sofort vom Netz getrennt.
    Der Anfreifer hat also nichts zu tun und kann nen Kaffee trinken und sich einen Keks dazu freuen, bis er nach 30min wieder ein einzelnes Packet losjagt, um den Server permanent down zu kriegen.


    Bitte nicht nachmachen!

    Quote

    Darum ging es ja ;)


    Omfg. Es ist nun nicht so, dass ich deinen Post nicht gelesen hätte.
    Keine Ahnung, es ist einfach rein und wieder rausgegangen. Bin iwie recht unkonzentriert im Moment...
    Aber schöne Glanzleistung von mir, das Thema des Threats zwischendurch nochmal einzubringen, was? :D

    Bitte, setzt nicht Spamhaus ein!
    Das ist ein Unternehmen, was ganz üble Machenschaften praktiziert.
    (War da nicht auch mal was hier im Forum?)


    Naja, um es auf den Ounkt zu bringen:
    Die erpressen und sperren ganze Blöcke Unschuldiger just for fun.

    Was ich mal gebracht habe:


    Server schön über Stunden hinweg aufgesetzt, alles schön konfiguriert, die Backups, die ich vor dem Plätten angelegt habe, eingespielt und danach gelöscht,...
    und jetzt kommts:
    IP-Tables eingerichtet und aktiviert
    Und dann noch überlegt: Man könnte den SSH-Port mal verlegen.


    BAM!^^ Firewall hat den neuen SSH-Port gesperrt, eine Rescue-Lösung gab es nicht, meine Backups habe ich wie gesagt gelöscht
    => Totaler Ausfall xD

    Quote

    Hast du im VCP (vServer Control Panel) vielleicht Firewall Regeln, die dich aussperren?


    Dann wäre er fleißig gewesen:

    Quote

    dynamische IP, inode.at


    Von einer Firewallregel kann man, denke ich absehen. Auch von Tools wie DenyHosts, die ja ebenfalls nur einzelne IPs blockt.

    OK, scheinbar war die Annahme, dass es mit dem alten SIP-ATA bestens lief, ein Trugschluss.
    Das hat wohl das verdammte zarafa verbasselt.
    Da gibt es immernoch Probleme, dass er das zarafa-webaccess nicht deinstallieren will. Und irgendwo dort hat er eine Menge "broken" Packages fabriziert, die er einfach gelöscht hat. Toooooll.


    Naja, gut, ist wohl mit einem erneuten Aufsetzen von Asterisk zu meistern -.-

    So, da der Server ja bis auf die Kleinigkeit Netzwerk durchläuft, habe ich mal per Cronjob alle 5min "ps aux" und und "netstat -ae --numeric-ports" in Logfiles gelenkt.
    Mal sehen, was rauskommt.
    Habe das ganze nochmal provoziert. Komisch, dass Gespräche mit dem Asterisk-Voice-Menu möglich sind, aber keine Gespräche mit Personen...


    naja, Server ist erst 20min down, das wird wohl noch 10min dauern...







    Soo, da sind sie, die Logs.
    Nichts Außergewöhnliches. Keine wilden offenen Ports, kein höherer CPU-Load, keine höhere Speicherauslastung.


    Ich checks nicht...

    Hallo Leute,


    da ist irgendwas total Verrücktes im Gange:
    Ich habe mir ein Siemens Gigaset C475IP zugelegt. Wie der Name schon sagt mit IP-Telefonie, sprich SIP.
    Nun habe ich auf meinem vServer schon länger Asterisk laufen und nutze es auch schon mit Soft- und Hardware-Telefonen (z.B. X-Lite und dem SIP-ATA von Allnet).
    Nun, da ich den SIP-ATA gegen das Telefon getauscht habe, habe ich den Eindruck, dass der Server sich vom Netz nimmt, sobald ich ein Gespräch von oder zum neuen Telefon starte. Btw: Ich kann nichts hören und nach ein paar Sekunden wird getrennt.
    Der Server ist nicht down. nach mehreren Minuten kann wieder Traffic stattfinden und der Server "petzt" erstmal per Email, dass der den rsync im Cronjob nicht starten konnte. Denn es ist nach dem "Telefonat" kein Traffic möglich, in beiden Richtungen nicht.


    Kann mir wer sagen, woran das liegen kann?
    Eigentlich sollte Asterisk es doch latte sein, welches Telefon sich verbindet, oder? Und sonst sollte Asterisk doch nicht die gesamte Anbindung des Servers lahmlegen können, oder? (zumal als unprivilegierter User gestartet und so doch eig. keinen Zugriff auf "niedrige" Ports).


    Hiiiilfääää! Was ist das?