Hacker in meinem Asterisk Server

[IBM-FAN]

Welche 1.6er Version nutzt Du? Patches im SIP?

Standard-Versionen von Debby & Ian = 1.6.2.9-2+squeeze10

 

[merkc]

Also, ich habe im laufe der Zeit, die Sicherheit ausserhalb von Asterisk "hochgefahren". Damit laufe ich ganz gut. Da ich einen VPS nutze, habe ich sowohl eine fixe IP, wie auch keine Möglichkeit eine externe Firewall dranzuhängen.
Hier mein Massnahmenkatalog:
1. SuSEFirewall läuft
2. SSH erlaubt KEINE Passwörter
3. SSH erlaubt eine Identifikation nur über ein (selbst ausgestelltes) Zertifikat (und ein weiteres bei einem Spezl, damit ich mich nicht selbst aussperre)
4. im /etc/crontab läuft ein Job alle 10 Minuten, der die aktuellen Blacklisten-IP runterläd
5. im /etc/hosts.allow ist meine IP Range aufgeführt, und naturlich die IPs von meinen ISPs resp von meinen SIP Providern.
6. im /etc/hosts.deny werden alle geblacklisted IPs von Punkt 4 reingeschrieben.
7. ach ja, sollte eher #2 oder so sein: die SSH Einstellungen im /etc/ssh/ssh_config sollte SEHR restriktiv gesetzt werden. Anleitungen dazu gibts bei google.de (alle Möglichkeiten schliessen, die es nicht braucht, aber gleichzeitig aufpassen, dass man sich selber nicht aussperrt).

Seitdem habe ich "Ruhe". Das heisst, mein VPS wird zwar alle paar Minuten "attackiert", ja es gibt auch regelmässige DDoS Attacken, aber es kann schlicht niemand aus China, Russland, Südamerika etc mehr rein. Die können auch kein SIP oder sonst was mehr machen. Mein Log-File (/var/log/messages) zeigt mir "unendlich" viele Attacken... Bitte nicht vergessen, mein Asterisk ist seit 8 Jahren online.

Ausserdem habe ich angefangen, den zuständigen Admin (whois Anfrage) eine Mail mit einer Beschwerde und einem Auszug aus dem Log File zu senden. Interessanterweise habe ich dann häufig für ein paar Tage mehr oder minder Ruhe. Daher muss ich davon ausgehen, dass es Kiddies sind, die sich austoben, und keine Behörden mit staatlichem Auftrag.

****** blockIP vom Crontab ******
#/bin/sh


cd /usr/local/adm/blacklisting
rm -f all.txt* sip.txt*
wget http://lists.blocklist.de/lists/all.txt
wget http://lists.blocklist.de/lists/sip.txt
touch sip.liste
zcat -f sip.txt sip.liste | sort -u > sip.sorted
mv sip.sorted sip.liste
rm sip.txt
zcat -f all.txt >> liste-server
sort -u liste-server > sorted-list
mv -f sorted-list liste-server
rm -f deny-liste
cp header.deny deny-liste
for i in `cat liste-server`
do
echo "ALL: "$i"/255.255.255.255" >> deny-liste
done
cp deny-liste /etc/hosts.deny
cd ..
*******************************

 

[IEEE]

Find ich gut.
Allerdings geb ich - wie schon mehrmals in dem Thread wenn ich nicht irre - zu bedenken das meiner Beobachtung nach asterisk die tcpwrapper (hosts.allow, hosts.deny) nicht auswertet. Zumindest haben das meine Tests ergeben, die zugegebenermaßen schon etwas zurückliegen. Hast Du mal probiert eine IP von Dir dem deny File hinzuzufügen und dann geschaut ob tatsächlich nichts mehr geht am Asterisk?

 

[merkc]

Also, bei mir funzt alles prima. Du solltest evt, wie oben beschrieben, im ssh_config ein bischen "Feintuning" machen. Ich bin auch nicht von jetzt-auf-gleich zu dieser radikalen Lösung gekommen. Es war einfach notwendig. Speziell nachdem ich rausgefunden habe, dass die Hacker so weit gehen, selbst über in Deutschland gehostete Strato Server zu gehen. Evt. liegt das auch an "tor" und ähnlichen anonmymisiereren. Beim ssh_config gibts noch ein paar nette Einträge.
Ich wollte noch hinzufügen, dass beim hosts.allow auch noch eigene Einschränkungen gemacht werden können:
***
sendmail::ALL
ALL : PARANOID : RFC931 20 : deny
ALL: .br .cn .fr .hk .it .pl .jp .pl .ru .tw .us : deny
ALL: chello.pl : deny
ALL: corexchange.com : deny
ALL: fastwebnet.it : deny
ALL: hichina.com : deny
****

***** sshd_config **** nur ein AUSZUG !!!*******
#Protocol 2,1
Protocol 2
DenyUsers root bin daemon lp mail news games man at wwwrun named postfix mysql snort ntp ldap popa3d cyrus messagebus haldaemon tomcat open-xchange webadmin nobody psaadm psaftp squid
HostbasedAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
UsePAM no
X11Forwarding no
MaxStartups 4:10:8
******

grad der MaxStartups erlaubt es, Angreifer (DDoS, Asterisks Hackers) in die Schranken zu weisen.

Ich bin gespannt auf Euren Erfolg... und freue mich auf alle Verbesserungsvorschläge

 

[IEEE]

Das der sshd die hosts.allow/deny auswertet steht ausser Frage. Das funktioniert sicher. Aber ich wollte halt nochmal herausarbeiten das - zumindest meiner Erfahrung nach - der asterisk diese Dateien nicht auswertet. Das heisst das so eine problematische IP die im deny file drin steht immer noch Registrierungen und Calls senden kann.

 

[merkc]

Hallo Michael / IEEE,
ich glaub, bei mir übernimmt die SuSEFirewall den "Blockierdienst" der IPs. Auf jeden Fall funzt es so bei mir, da ich u.a. eine IP auf diese Art gesperrt habe, von jemanden, der früher mal über meinen Asterisk telefonieren konnte, und der es bis heute nicht geschafft hat, seine Zyel P2002 vom Netz zu nehmen und mich damals konstant "nervte" mit "unsuccessful registrations"...

Aber ich gebe Dir recht, dass es sicher ganz nett wäre, wenn Asterisk, die Software, die hosts.deny selbstständig berücksichtige.

 

[IBM-FAN]

Entweder sind die Skriptbabys auf Klassenfahrt oder es gibt andere Gründe:
Seitdem ich schlicht den ssh-Port "umgelegt" habe, ist (ausser ein paar fake auth rejection) völlige Ruhe. Kann es sein, dass die HackBots zunächst prüfen, ob ein Asterisk/Server überhaupt per ssh manipulierbar sein könnte, bevor die Brute Force-Attacken gegen den Asterisk starten?

 

[HobbyStern]

Kann es sein, dass die HackBots zunächst prüfen, ob ein Asterisk/Server überhaupt per ssh manipulierbar sein könnte, bevor die Brute Force-Attacken gegen den Asterisk starten?

Unwahrscheinlich. Ich lege als ersten Schritt immer den SSH Port um und erhalte trotzdem täglich 5-10 abgewehrte Angriffslogs.

LG Stefan

 

[Hamal]

<-- ab da hat er dann telefonieren können, und ja; das Log startet tatsächlich mit Call from extension, da hatte er vorher nichts anderes angeworfen, er hat zwar vorher direkt eine fake auth provoziert auf einen anderen Nutzernamen, aber das war es. Da hätte meine intrusion detection greifen müssen, hat sie aber nicht (ist eine pearl Lösung, die manchmal versagt), allerdings sind davor auch nur fünf verschiedene Nutzer die er probiert.

Bitte nicht böse sein, falsch ich etwas zynisch klinge, jedoch

ich wehre mich gegen den Vorwurf, der schlechten Sicherung.

Anscheinend hat derselbe Hacker sich auch an meinem Asterisk versucht. Ich hatte - nachdem ich von den aktuellen Angriffen gelesen hatte - auch Verbose-Nachrichten geloggt. Hier ist ein Auszug aus meinem Log:

[2013-02-12 05:48:25] NOTICE[1132] chan_sip.c: Registration from '<sip:1001@meine-ip>' failed for '4.59.192.170:10656' - No matching peer found
[2013-02-12 05:48:26] NOTICE[1132] chan_sip.c: Registration from '<sip:1001@meine-ip>' failed for '4.59.192.170:10656' - No matching peer found
[2013-02-12 05:48:29] VERBOSE[1132] netsock2.c: == Using SIP RTP TOS bits 184
[2013-02-12 05:48:29] VERBOSE[1132] netsock2.c: == Using SIP RTP CoS mark 5
[2013-02-12 05:48:29] VERBOSE[12661] pbx.c: -- Executing [00972599163133@from-sip-external:1] NoOp("SIP/xxx-000000a7", "Received incoming SIP connection from unknown peer to 00972599163133") in new stack
[2013-02-12 05:48:29] VERBOSE[12661] pbx.c: -- Executing [00972599163133@from-sip-external:2] Set("SIP/xxx-000000a7", "DID=00972599163133") in new stack
[2013-02-12 05:48:29] VERBOSE[12661] pbx.c: -- Executing [00972599163133@from-sip-external:3] Goto("SIP/xxx-000000a7", "s,1") in new stack
[2013-02-12 05:48:29] VERBOSE[12661] pbx.c: -- Goto (from-sip-external,s,1)
[2013-02-12 05:48:29] VERBOSE[12661] pbx.c: -- Executing [s@from-sip-external:1] GotoIf("SIP/xxx-000000a7", "0?checklang:noanonymous") in new stack
[2013-02-12 05:48:29] VERBOSE[12661] pbx.c: -- Goto (from-sip-external,s,5)
[2013-02-12 05:48:29] VERBOSE[12661] pbx.c: -- Executing [s@from-sip-external:5] Set("SIP/xxx-000000a7", "TIMEOUT(absolute)=15") in new stack
[2013-02-12 05:48:29] VERBOSE[12661] func_timeout.c: Channel will hangup at 2013-02-12 05:48:44.606 CET.
[2013-02-12 05:48:29] VERBOSE[12661] pbx.c: -- Executing [s@from-sip-external:6] Answer("SIP/xxx-000000a7", "") in new stack
[2013-02-12 05:48:30] VERBOSE[12661] pbx.c: -- Executing [s@from-sip-external:7] Wait("SIP/xxx-000000a7", "2") in new stack
[2013-02-12 05:48:32] VERBOSE[12661] pbx.c: -- Executing [s@from-sip-external:8] Playback("SIP/xxx-000000a7", "ss-noservice") in new stack
[2013-02-12 05:48:32] VERBOSE[12661] file.c: -- <SIP/xxx-000000a7> Playing 'ss-noservice.gsm' (language 'en')

So wie es aussieht, prüft er zunächst, ob er sich registrieren kann bzw. ob fake auth aktiv ist. Dann versucht er einfach, ohne Registrierung (also im Default-Context) zu wählen, was bei mir erstmal funktionert, da ich wegen ENUM allowguest auf yes habe. Allerdings läuft er bei meinem Default-Context direkt in eine Sackgasse, es sei denn er trifft zufällig eine meiner Inbound-Nummern, dann würde es bei mir klingeln. Er versucht verschiedene Wege, um eine Amtsleitung zu erhalten (zusätzliche 0, 9, 99, 8 vorwählen), gibt aber dann auch relativ schnell auf.

In deinem Fall vermute ich einfach mal, dass dein Default-Context das zulässt. Es liegt also nahe, dass dein Asterisk vielleicht doch nicht ausreichend gesichert ist, denn aus meiner Sicht hat er es bei dir geschafft, ohne Registrierung zu telefonieren.

 

[HobbyStern]

Schaut Euch doch einfach mal so ein Brute-Force Tool an und attackiert Euren eigenen Server - "er" macht ja nichts wirklich intelligentes, sondern bruted einfach per Skript los.

Ich habe irgendwann mal in diesem Post ein solches Tool vorgestelllt und auch gegen meinen * laufen lassen..

 

[MaverrickTM]

[Edit rentier-s:]

Das lassen wir mal, da nicht ganz legal (auch wenn nur zu Testzwecken).


[Edit]
An diese äusserst sinnfreie Regelung, im Bezug auf das Verbot solcher administrativen Werkzeuge, werde ich mich nie gewöhnen können...

Sorry!
[/Edit]

 

[akue]

ich klink mich mal ein:

@Hamal: Danke für das Log. Hat Inovatoor nicht aber geschrieben, dass er allowguest=no hat? Dann dürfte doch in seinem Default-Context nichts ankommen, oder sehe ich das falsch?

@inovatoor (und andere, die vielleicht draus schlau werden):
Warum hast Du einen default-Context in der extensions.conf, obgleich der Eintrag in der sip.conf auf den Context "telefone"verweist? Sollte an sich nichts ausmachen, da der Inhalt bei "telefone" ja identisch ist. Gibt es vielleicht einen zweiten Context "telefone" in der extensions.conf? Das passiert ja ganz schnell mal, dass man was doppelt vergibt.

Was bedeutet in den beiden Contexten den ${5000}? Wird die Extension über die Variable ${5000} gewählt? Wie wird die denn vergeben? Was passiert im Context "vm-intro" mit Calls, die keiner Extension zugeordnet werden können?

@HobbyStern: Wollte Dir schon lange mal für Dein Engagement hier danken. Du hast mich vor Jahren als blutigen Anfänger wach gerüttelt und bist mit Deinem Engagement hier bis heute ein großes Vorbild, bestimmt nicht nur für mich.

 

[Hamal]

Du hast natürlich Recht, dass bei allowguest=no das eigentlich gar nicht passieren dürfte. Es bleibt natürlich auch zu klären, ob es sich um denselben Hacker handelt, obwohl das Vorgehen und die gewählte Nummer darauf hindeuten. Andererseits glaube ich nicht, dass ein Hacker beim 2. oder 3. Versuch ein 12-stelliges Passwort mit Sonderzeichen knackt. Es stellt sich also die Frage, wie er es gemacht hat? Wenn er es genauso gemacht hat, wie er es bei meinem Asterisk versucht hat, dann konnte er eben doch im Default-Context telefonieren.

 

[HobbyStern]

@Svenja - zu Testzwecken an einem eigenen Server ist es doch IMHO mehr oder weniger egal, aber Du hast natürlich Recht, öffentlich würde ich dieses hier nicht einfach hinstellen...

Wenn also jemand die zu kompilierenden Quellcodes für dieses Ding haben möchte, dann würde ich mit Angabe eines guten Grundes per PM das Ganze nochmals raussuchen. Es macht ja Sinn zu verstehen warum und wie jemand uns angreifen kann...

EDIT :

@HobbyStern: Wollte Dir schon lange mal für Dein Engagement hier danken

:rotwerd: Danke, Gerne!

Grüsse,

Stefan

 

[HobbyStern]

Hallo Gemeinde,

ich möchte einmal folgenden Kenntnisstand in meiner Kaffeepause offenbaren.
Durch ein durch Google gefundenes "Scanning-Tool für SIP" habe ich einmal meinen öffentlichen Zugang attackiert - als Test.

Erst scannen der IP...

someone@apc:/usr/src/TOOL# ./TOOL.py my-own-public-ip
| SIP Device          | User Agent | Fingerprint |
--------------------------------------------------
| my-own-public-ip:5060 | brickysip  | disabled    |

Okay, ich bin lokalisiert

Weiter...finden der registrierbaren SIP Kanäle :

someone@apc:/usr/src/TOOL# ./TOOL2.py my-own-public-ip
ERROR:TakeASip:SIP server replied with an authentication request for an unknown extension. Set --force to force a scan.

Okay - er mag nicht so wie ich will und --force soll helfen....:

someone@apc:/usr/src/TOOL2# ./svwar.py my-own-public-ip --force
WARNING:TakeASip:Bad user = SIP/2.0 401  - TOOL2 will probably not work!
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP my-aggressor-public-ip:5060;branch=z9hG4bK-3146033203;received=my-aggressor-public-ip;rport=5060\r\nFrom: "100"<sip:100@my-own-public-ip>;tag=31303001383633363532383635\r\nTo: "100"<sip:100@my-own-public-ip>;tag=as18460d0a\r\nCall-ID: 3425039019\r\nCSeq: 1 REGISTER\r\nUser-Agent: brickysip\r\nAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY\r\nSupported: replaces\r\nWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="245fa822"\r\nContent-Length: 0\r\n\r\n'
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP my-aggressor-public-ip:5060;branch=z9hG4bK-3939443820;received=my-aggressor-public-ip;rport=5060\r\nFrom: "101"<sip:101@my-own-public-ip>;tag=3130310131303830383437333231\r\nTo: "101"<sip:101@my-own-public-ip>;tag=as544247f7\r\nCall-ID: 9901961\r\nCSeq: 1 REGISTER\r\nUser-Agent: brickysip\r\nAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY\r\nSupported: replaces\r\nWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="413c5fb6"\r\nContent-Length: 0\r\n\r\n'
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP my-aggressor-public-ip:5060;branch=z9hG4bK-942409199;received=my-aggressor-public-ip;rport=5060\r\nFrom: "102"<sip:102@my-own-public-ip>;tag=3130320133303433363135393839\r\nTo: "102"<sip:102@my-own-public-ip>;tag=as183c4891\r\nCall-ID: 552181409\r\nCSeq: 1 REGISTER\r\nUser-Agent: brickysip\r\nAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY\r\nSupported: replaces\r\nWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="58a8c105"\r\nContent-Length: 0\r\n\r\n'
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP my-aggressor-public-ip:5060;branch=z9hG4bK-1665748051;received=my-aggressor-public-ip;rport=5060\r\nFrom: "103"<sip:103@my-own-public-ip>;tag=3130330133383131363639343830\r\nTo: "103"<sip:103@my-own-public-ip>;tag=as0d2dbc6e\r\nCall-ID: 2895053195\r\nCSeq: 1 REGISTER\r\nUser-Agent: brickysip\r\nAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY\r\nSupported: replaces\r\nWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="5cdec92e"\r\nContent-Length: 0\r\n\r\n'
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP my-aggressor-public-ip:5060;branch=z9hG4bK-3968094277;received=my-aggressor-public-ip;rport=5060\r\nFrom: "104"<sip:104@my-own-public-ip>;tag=3130340133363132363832323939\r\nTo: "104"<sip:104@my-own-public-ip>;tag=as3d962acc\r\nCall-ID: 846490985\r\nCSeq: 1 REGISTER\r\nUser-Agent: brickysip\r\nAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY\r\nSupported: replaces\r\nWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="0b26e3bf"\r\nContent-Length: 0\r\n\r\n'
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP my-aggressor-public-ip:5060;branch=z9hG4bK-2235380825;received=my-aggressor-public-ip;rport=5060\r\nFrom: "105"<sip:105@my-own-public-ip>;tag=31303501373332363033343336\r\nTo: "105"<sip:105@my-own-public-ip>;tag=as7658c148\r\nCall-ID: 3110844340\r\nCSeq: 1 REGISTER\r\nUser-Agent: brickysip\r\nAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY\r\nSupported: replaces\r\nWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="480c0775"\r\nContent-Length: 0\r\n\r\n'
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP my-aggressor-public-ip:5060;branch=z9hG4bK-1895016006;received=my-aggressor-public-ip;rport=5060\r\nFrom: "106"<sip:106@my-own-public-ip>;tag=3130360133393734323631393532\r\nTo: "106"<sip:106@my-own-public-ip>;tag=as1b8d9be7\r\nCall-ID: 1924794655\r\nCSeq: 1 REGISTER\r\nUser-Agent: brickysip\r\nAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY\r\nSupported: replaces\r\nWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="51dafe30"\r\nContent-Length: 0\r\n\r\n'
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP my-aggressor-public-ip:5060;branch=z9hG4bK-4004204516;received=my-aggressor-public-ip;rport=5060\r\nFrom: "107"<sip:107@my-own-public-ip>;tag=3130370132383639333032373430\r\nTo: "107"<sip:107@my-own-public-ip>;tag=as4617584d\r\nCall-ID: 2946528571\r\nCSeq: 1 REGISTER\r\nUser-Agent: brickysip\r\nAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY\r\nSupported: replaces\r\nWWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="548dffb4"\r\nContent-Length: 0\r\n\r\n'
WARNING:someone:found nothing

Das war´s hier wurde ich geblockt und für eine Stunde als nicht gut befunden - sollte das jemand nachmachen darf er einen Gedanken daran verschwenden was BLOCK auf einem remote system bedeutet

Also kurzum - ich würde behaupten das dieses eine Tool noch so arbeitet wie ich es vor 2-4 Jahren getestet hatte, es versucht halt Extensions mit aufsteigenden Nummern auf Treffer, findet es etwas - meldet es dies und ERST DANN würde es mit einem Passwort angreifen wollen. Durch fail2ban ist man daher schon recht sicher, KANN man den Port 5060 verlegen ist es wohl sehr sicher, da in diesem Tool IMMER von 5060 gestartet wird.

Wenn Ihr bessere, intelligentere Tools findet - beschreibt doch mal was Ihr dort erlebt habt.

Ich darf Svenja hoer nochmals deutlich in Erinnerung rufen - das hier soll keine Anleitung für Skript-Dussel werden, sondern helfen ggf. Neuere Angriffsmöglichkeiten zu entdecken. Mich nervt es schon genug das ich in Schritt ersteinmal zu finden bin...das würde nur abschaltbar sein wenn man ALLE IPs ausschließt die man nicht nutzt...

Grüsse,

Stefan

 

[akue]

ich bereite auch gerade das "tool" vor. Aber mal davon abgesehen:

Ist es nicht so, dass ein Hacking des Asterisk unmöglich ist, wenn er hinter einem NAT-Router steht? Inovatoor z.B. hat nat=yes in der sip.conf. Ich dachte bislang immer, ich muss Port 5060 zwingend an den Asterisken leiten, habe aber hier http://forums.asterisk.org/viewtopic.php?t=74786#p147162 die Anregung bekommen, alle Ports des Routers zuzumachen. Hab ich probiert. Asterisk läuft, auch nach neuer IP-Vergabe, outbound und inbound. Auch ssh muss für die meisten Homeserver wohl nicht über das Netz erreicht werden.

Also nochmal die Frage an die Experten: Muss ich @home hinter Router Ports freischalten oder nicht?

 

[MaverrickTM]

Soweit ich weiss, muss im Gateway ein Forwarding für den SIP-Port durchgeführt werden. Andernfalls wird Dein VoIP-Provider nicht uneingeschränkt kommunizieren können.

Der Grund warum es derzeit bei Dir funktioniert ist folgender: Beim Register baust Du eine Verbindung zum Provider auf. Dein Router hinterlegt, beim Aufbau, automatisch einen Eintrag in seiner NAPT-Tabelle. Die Kommunikation läuft nur solange reibungslos, wie Du regelmässig SIP-Pakete an Deinen Provider sendest. Wenn Du eine Weile keine Kommunikation mit deinem Provider führst, wird dieser NAPT-Eintrag wieder gelöscht und Dein Provider ist nicht mehr in der Lage, Dich zu kontaktieren. Das geht erst dann wieder, wenn Du dich vorher bei ihm gemeldet hast.

 

[akue]

Danke, ist verständlich dargestellt. Aber macht das nicht gerade der regelmäßige Refresh bei der Registrierung? Ich hab schon einige Tage den Asterisken auf einem anderen Port am Lauschen (und 5060 am Router gesperrt) und es lief ohne Probleme (jedenfalls habe ich keine bemerkt). Ich bekomme aber recht wenig voip inboud. Nach Deiner Darstellung müsste ja wohl auch der Port vergessen werden (und die IP auch, wenn es nicht gerade der Internet-Provider selbst ist).

Zitat von hier: http://www.pbxinaflash.com/community/index.php?threads/asterisk-info-slow-to-update-sip-registrations.8992/ (#2):

put "yes" in the Qualify field on the extension definition on the Freepbx admin interface. This will cause Asterisk to send it an OPTIONS keepalive request every 60 seconds. If there is loss of connectivity, then Asterisk will know about it in 60 seconds or less. That might fix your symptom (the SIP peers showing the device still registered), but won't tell you why the device is losing connectivity. If it is behind a NAT router, that could be the explanation (as UDP connections will generally be flushed from a NAT table after 120 seconds of no traffic). You need to check on the device config: see what its registration timeout value is set to, and check on the other registration parameters, such as how many times it tries to reregister in event of a failure, etc.

Und hier noch vom Guru persönlich: http://www.ip-phone-forum.de/archive/index.php/t-136390.html?

betateilchen
12.05.2007, 18:22
Grundlagenwissen :-Ö

Du mußt die Ports nehmen, die Du in der /etc/asterisk/rtp.conf angegeben hast. Standardmäßig sind das die Ports von 10000 - 20000

Womit meine Frage ja eigentlich beantwortet ist. Dann ist das Sicherheitsproblem für die Home-Server doch praktisch erledigt, oder?

 

[MaverrickTM]

Wenn Du jeden potentiellen balancer, Server und was es da noch alles bei Deinem Provider gibt mit Qualify monitorst wird es sicherlich funktionieren. Kommt jedoch ein neuer Server hinzu dann gibts Probleme wenn er mir Dir kommunizieren muss. Ich weiss auch nicht, wie Dein Provider reagiert, wenn nun sämtliche Leute anfangen die Server mit keepalive Pakete vollzumüllen.

Ich kann mir nur schwer vorstellen, dass das auf Dauer reibungslos funktionieren kann...

Gibt es vielleicht jemand, der sein Setup genau so fährt und Erfahrungen liefern kann?

 

[akue]

ja, genau so mache ich es ... qualify bei allen balancern etc.

Du meinst also, ich habe nur die Wahl, keepalive-Müll zu produzieren und damit den Provider zu belasten oder meinen Asterisk Angriffen von extern auszusetzen? Dann ist die Antwort für mich klar. Das muss der Provider aushalten.

Um zum Sicherungsthema zurück zu kommen:

Hier http://www.dslreports.com/forum/r26964016-Asterisk-Changing-default-SIP-Port nimmt jemand den Mund sehr voll:

Every Asterisk installation only needs 3 lines in iptables to be secure if you register to or qualify your trunks for up/down status.

1
2
3
4

-A INPUT -i eth0 -p udp --dport 5060 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth0 -p udp --dport 5060 -j DROP
-A INPUT -i eth0 -p udp --dport {RTP_Start_port}:{RTP_End_port} -j ACCEPT

It's that simple.

If you need to allow registration of remote extensions, you just add the following line before the "--dport 5060 -j DROP" line.

1
2

-A INPUT -i eth0 -p udp --dport 5060 -m string --string "REGISTER sip:mypbx.domain.tld" --algo bm -j ACCEPT

.. and if you need to accept SIP URI calls, just add this pair of lines for each URI username:
1
2
3

-A INPUT -i eth0 -p udp --dport 5060 -m string --string "INVITE sip:SIPURINAMEGOESHERE" --algo bm -j ACCEPT
-A INPUT -i eth0 -p udp --dport 5060 -m string --string "BYE sip:SIPURINAMEGOESHERE" --algo bm -j ACCEPT

If you do that, your system runs 100% opaque to scans, it's 100% secure against random INVITE requests, and in order for registration attempts to go through they have to be done by DNS hostname. If you use a DNS A Record that doesn't match the reverse DNS PTR record, it would be nearly impossible for some random attacker to guess the hostname.

Ich verstehe von iptables nichts aber vielleicht gibt dies einen ergänzenden Ansatz für alle, die sich nicht hinter NAT verstecken können/wollen (wobei auch hier qualify=yes vorausgesetzt wird)