--- Bitte löschen, ich war zu blöde für die Seitenblätterfunktion ---
Beiträge von Artimis
-
-
Ja, aber denke daran, vorher das Verzeichnis zu wechseln. Sonst kommt es zum GAU.
Ansonsten kannst du statt des "./" (mit Punkt!!!!!) auch den absoluten Pfad des GameServer-Verzeichnisses nehmen. -
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 xDEDIT2:
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:
Code
Alles anzeigen-- Executing [1000@DLPN_Default:1] Dial("SIP/1001-09d68d70", "SIP/1000&IAX2/1000") in new stack Audio is at 82.211.8.227 port 12282 Adding codec 0x4 (ulaw) to SDP Adding codec 0x2 (gsm) to SDP Adding non-codec 0x1 (telephone-event) to SDP Reliably Transmitting (NAT) to 87.122.168.53:32768: INVITE sip:1000@192.168.0.12:15060 SIP/2.0 Via: SIP/2.0/UDP 82.211.8.227:5060;branch=z9hG4bK7105412f;rport From: "Christopher Kleen" <sip:1001@82.211.8.227>;tag=as0f0249d9 To: <sip:1000@192.168.0.12:15060> Contact: <sip:1001@82.211.8.227> Call-ID: 39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227 CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Date: Sat, 16 Jan 2010 15:13:51 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: 263 v=0 o=root 23878 23878 IN IP4 82.211.8.227 s=session c=IN IP4 82.211.8.227 t=0 0 m=audio 12282 RTP/AVP 0 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv --- -- Called 1000 [Jan 16 16:13:51] WARNING[24271]: app_dial.c:1202 dial_exec_full: Unable to create channel of type 'IAX2' (cause 3 - No route to destination) <--- SIP read from 87.122.168.53:32768 ---> SIP/2.0 100 Trying Via: SIP/2.0/UDP 82.211.8.227:5060;branch=z9hG4bK7105412f;rport=5060 From: "Christopher Kleen" <sip:1001@82.211.8.227>;tag=as0f0249d9 To: <sip:1000@192.168.0.12:15060>;tag=3438380469 Call-ID: 39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227 CSeq: 102 INVITE Contact: <sip:1000@192.168.0.12:15060> Content-Length: 0 <-------------> --- (8 headers 0 lines) --- <--- SIP read from 87.122.168.53:32768 ---> <-------------> <--- SIP read from 87.122.168.53:32768 ---> SIP/2.0 180 Ringing Via: SIP/2.0/UDP 82.211.8.227:5060;branch=z9hG4bK7105412f;rport=5060 From: "Christopher Kleen" <sip:1001@82.211.8.227>;tag=as0f0249d9 To: <sip:1000@192.168.0.12:15060>;tag=3438380469 Call-ID: 39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227 CSeq: 102 INVITE Contact: <sip:1000@192.168.0.12:15060> Allow-Events: message-summary, refer Content-Length: 0 <-------------> --- (9 headers 0 lines) --- -- SIP/1000-09d72710 is ringing <--- SIP read from 87.122.168.53:32768 ---> <-------------> <--- SIP read from 87.122.168.53:32768 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 82.211.8.227:5060;branch=z9hG4bK7105412f;rport=5060 From: "Christopher Kleen" <sip:1001@82.211.8.227>;tag=as0f0249d9 To: <sip:1000@192.168.0.12:15060>;tag=3438380469 Call-ID: 39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227 CSeq: 102 INVITE Contact: <sip:1000@192.168.0.12:15060> Supported: replaces Allow-Events: message-summary, refer Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 197 v=0 o=1000 15006 8 IN IP4 192.168.0.12 s=Mapping c=IN IP4 192.168.0.12 t=0 0 m=audio 15006 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv <-------------> --- (12 headers 10 lines) --- Found RTP audio format 0 Found RTP audio format 101 Peer audio RTP is at port 192.168.0.12:15006 Found audio description format PCMU for ID 0 Found audio description format telephone-event for ID 101 Capabilities: us - 0x6 (gsm|ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw) Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) Peer audio RTP is at port 192.168.0.12:15006 list_route: hop: <sip:1000@192.168.0.12:15060> set_destination: Parsing <sip:1000@192.168.0.12:15060> for address/port to send to set_destination: set destination to 192.168.0.12, port 15060 Transmitting (NAT) to 87.122.168.53:32768: ACK sip:1000@192.168.0.12:15060 SIP/2.0 Via: SIP/2.0/UDP 82.211.8.227:5060;branch=z9hG4bK297cd9f4;rport From: "Christopher Kleen" <sip:1001@82.211.8.227>;tag=as0f0249d9 To: <sip:1000@192.168.0.12:15060>;tag=3438380469 Contact: <sip:1001@82.211.8.227> Call-ID: 39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227 CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- -- SIP/1000-09d72710 answered SIP/1001-09d68d70 -- Packet2Packet bridging SIP/1001-09d68d70 and SIP/1000-09d72710 Scheduling destruction of SIP dialog '39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227' in 32000 ms (Method: INVITE) set_destination: Parsing <sip:1000@192.168.0.12:15060> for address/port to send to set_destination: set destination to 192.168.0.12, port 15060 Reliably Transmitting (NAT) to 87.122.168.53:32768: BYE sip:1000@192.168.0.12:15060 SIP/2.0 Via: SIP/2.0/UDP 82.211.8.227:5060;branch=z9hG4bK26b09c5d;rport From: "Christopher Kleen" <sip:1001@82.211.8.227>;tag=as0f0249d9 To: <sip:1000@192.168.0.12:15060>;tag=3438380469 Call-ID: 39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227 CSeq: 103 BYE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 --- == Spawn extension (DLPN_Default, 1000, 1) exited non-zero on 'SIP/1001-09d68d70' <--- SIP read from 87.122.168.53:32768 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 82.211.8.227:5060;branch=z9hG4bK26b09c5d;rport=5060 From: "Christopher Kleen" <sip:1001@82.211.8.227>;tag=as0f0249d9 To: <sip:1000@192.168.0.12:15060>;tag=3438380469 Call-ID: 39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227 CSeq: 103 BYE Contact: <sip:1000@192.168.0.12:15060> Supported: replaces Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 <-------------> --- (10 headers 0 lines) --- Really destroying SIP dialog '39bb4e8752e46e7358c87c3b79ce52f8@82.211.8.227' Method: INVITEMan sieht schon, dass er da irgendwas mit der internen IP des VoIP-Telefons anstellt:
CodeINVITE 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:
Coderoot@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:Code
Alles anzeigenroot@red:~# ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1000ms root@red:~# ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. ^C --- 192.168.1.2 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1000ms root@red:~# ping 192.168.0.100 PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data. ----------------------------------------------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.
-
Zitat
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).
-
Zitat
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.ZitatUnd 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!
-
Zitat
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?
-
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 -
Zitat
Hast du im VCP (vServer Control Panel) vielleicht Firewall Regeln, die dich aussperren?
Dann wäre er fleißig gewesen:Zitatdynamische 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?
-
681
Zitatbtw: so gesehen hab ich mit dem v(olks)server den super griff gemacht
Ooooh jaaa, ich hab auch einen *g*