Kann SIP nen Server vom Netz trennen?

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?

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...

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 -.-

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

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.

Zitat

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 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:

-- 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: INVITE

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

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:

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:

root@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...

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?

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...

Zitat

So steht's ja auch in deinem Angebot (zumindest in meinem).

Jaaa, genau wie Microsoft seine Nicht-System-Builder-Lizenzen für tollen Telefonsupport verkauft, wo man dann einen Deppen nach 10min 0900er-Warteschleife drankriegt.
Was irgendwo steht und behauptet wird, muss nicht der Realität entsprechen.

Naja, hoffentlich werden die bald fertig.
Mein Server ist (mal wieder) nicht erreichbar. Noch so ein Aussetzter heute und mein Heim-PC hat mehr Uptime...

Aaaah, es klappt!

root@red:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
^C
--- 192.168.0.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
(kein Verbindungsabbruch zur Shell)

Telefonate funktionieren nun ebenfalls.