Hacker in meinem Asterisk Server

Hallo Gemeinde,

mal so ein kleiner Zwischenstand - ich habe ja fail2ban und auch alel anderen Modifikationen seit geraumer Zeit konfiguriert, was dazu führt das ich täglich 2-3 BANs erhalte.

Meist Seiten aus mysteriösen Gegenden, China, Mexico, Rumänien etc

Wer also noch nicht die Modifikationen fährt, dem sei dringendst angeraten dies zu tun - würde ich noch "nichts" tun, so hätte ich mal ganz simpel hochgerechnet (3x30 Tage) 90 Hacker pro Monat im System, von denen es dann ggf. 2-3 schaffen würden das richtige Passwort und die richtige Extension zu ermitteln...

Es lebe Fail2Ban!

LG Stefan
 
Fail2Ban funktioniert nur wenn iptables vom Hoster des vServers unterstützt wird. Ist bei mir leider nicht der Fall. Mit Hostdeny habe ich es nicht hingekriegt, vermutlich aus ähnlichen Grund.

Die Anzahl der Attacken halten sich "im Rahmen". Alle paar Tage während etwa einer Minute.

Habe jedoch folgende Vorkehrungen in Sip.conf:

[general]
alwaysauthreject=yes
allowguest=no
... sowie diverse
deny=113.105.152.220/0.0.0.0
.... weiter:

Für die Extensions nicht ausschliesslich Nummern, also bspw.:

[abc!30]
callerid=Phone 1 <30>
host=dynamic
domain=IP_myAsterisk
user=30
secret=ein_sehr_sehr_starkes_Passwort
...

Hatte während einer Zeit viele Attacken mit verschiedenen IPs vom gleichen Server/Provider in Frankreich. Nach ein paar Emails an abuse mit der Aufforderung diese illegalen Aktivitäten zu stoppen, ist von dieser Seite her Ruhe.
 
Hey,

mit abuse habe ich schlechte Erfahrungen, IMHO juckt das keine Sau ob da jemand meckert oder net, vorallem wenn es nicht in der innerdeutschen Grenze passiert und somit sicherlich kein "Kunde" einen Abuse sendet...

Hast Du es mal mit fail2ban OHNE iptables probiert - ich denke ja mal wir gehen von einem vserver aus..?

Am besten wäre es natürlich zu wissen welche IPs zugreifen dürfen und alle anderen würden dicht gemacht - dann hätte man schon ziemliche Ruhe - hat natürlich seinen Haken in dynamischen Ranges etc.

Soweit, LG Stefan
 
Hallo,

hab alle Türen verrammelt, auf die ich in diesem Thread aufmerksam gemacht wurde, bis auf fail2ban, und anscheinend brauch ich das auch nicht.
Während früher seitenweise Scans in der messages-Datei waren, ist seit ein paar Monaten absolute Ruhe.
Ich führe das ausschließlich auf

bindport != standart (5060, SIP) bzw
bindport != standart (4569, IAX) und
bindaddr = vserver-IP

zurück.
So einfach kann das Leben sein :)
Oder hab ich was übersehen?
 
Das Verwenden von abweichenden Ports hilft natürlich gegen Scans.
In manchen Fällen ist das jedoch nicht praktikabel, sei es, weil die Endgeräte das nicht unterstützen, oder weil es zu viele Nutzer gibt, die das nicht hinbekommen.
 
Leuchtet mir ein.
Danke für die Antwort
 
Nachbau?

Bei mir wurde bereits nach wenigen Stunden Onlinzeit der Asterisk missbraucht. Wahrscheinlich wurden meine 4-stelligen Zahlenpasswörter geknackt. (Man lernt dazu, dann und wann sehr schnell sogar.) Zudem hatte ich keine [default]-exten konfiguriert und allowguest=no war ebenfalls nicht eingetragen.

Wie kann ich jetzt einen Angriff auf meinen Asterisk 'nachbauen', simulieren?
Mein Soft-Phone verbindet nicht mit meinem * solange ich nicht auch User und Pass mitgebe. Selbst wenn ich allowguest=yes konfiguriere kann mein Soft-Phone sich nicht verbinden.
 
Hallo und willkommen im Forum!

HobbyStern hat unter dem Beitrag #182 ein Hackertool vorgestellt.
Einfach mal anschauen.
 
Hast Du es mal mit fail2ban OHNE iptables probiert - ich denke ja mal wir gehen von einem vserver aus..?
Ja vServer bei einem Hoster in D. Mit hostdeny hat es auch nicht funktioniert. Das Problem scheint generell darin zu bestehen, dass aus anderen Sicherheitsgründen ein Zugriff auf die Netzwerkressoucen des Host-Systems unterbunden wird.

Betreffend SSH:
Schließe mich IEEE an - Port von 22 auf zBsp 59022 wechseln - dann sollten die einfachsten Angriffe (wie Deine im Log) weg sein.
Befürchte, dass ich den Kontakt zu meinem vServer "verlieren" könnte wenn ich nicht richtig vorgehe. Deshalb meine vielleicht triviale Frage: Wo ist diese Anpassung auf dem vServer überall vorzunehmen. Habe lenny installiert.
 
Zuletzt bearbeitet:
Ich glaube in diesem Thread bereits mehrmals darauf hingewiesen zu haben das fail2ban mit hostsdeny sinnlos ist, da asterisk die libwrap nicht verwendet und anscheinend die /etc/hosts.deny auch selbst nicht auswertet. Sofern iptables also nicht nutzbar sind, kann man sich fail2ban sparen.

Mir ist es übrigens ein Rätsel warum man auf diesen vserver Produkten keine iptables nutzen kann. Normalerweise ist das bei virtuellen Server (zb. XEN) überhaupt kein Problem. Ich hab zb. mehrere virtuelle Server bei linode.com (kann ich sehr empfehlen) und setze problemlos iptables Regeln ein.

Was das Umkonfigurieren von ssh auf einen anderen Port angeht muss man hier - normalerweise - keine Angst haben sich auszusperren. Einfach den port in der /etc/ssh/sshd_config ändern und den Dienst neu starten. Offene Verbindungen werden dabei i.d.R. nicht getrennt.
 
... /etc/ssh/sshd_config ändern und den Dienst neu starten.
Ok, sshd_config ist angepasst. Beschäftige mich anscheinend aber zu wenig mit dem vServer bzw. Debian, so dass ich für einfache Dinge nachfragen muss: Was heisst "den Dienst neu starten"? Mit der CLI komme ich nicht ins Verzeichnis /etc/ssh. Habe es mit "restart" und "reload" unter /etc versucht, geht aber auch nicht. Braucht es dafür vielleicht einen reboot?
 
Hallo Met, versuche es mit:
Code:
/etc/init.d/ssh restart


Gruß
R.
 
Danke "I triple E" und rmh. Es HATTE ursprünglich funktioniert. Jetzt komme ich momentan gar nicht mehr rein, nicht einmal zum manuellen Passwort... Vielleicht habe ich mich mit ein paar Versuchen selbst ausgeschlossen? Mal abwarten und Tee trinken ...

Nachtrag: Tatsächlich ist meine IP aus irgend einem Grund gesperrt worden. Mit einer anderen IP habe ich normalen Zugang, dies mit geändertem Port.
 
Zuletzt bearbeitet:
SSH: Port 22 ändern und DenyHost

Es ist DenyHost, der mich nach Änderung des Ports ausgesperrt hat. Gut zu wissen, dass DenyHost funktioniert ... leider aber (noch?) nicht richtig:

1) Wenn die Verbindung zum vServer mit einer noch nicht blockierten IP aufgebaut wird funktioniert dies. Der Key wird überprüft und die Verbindung steht. Diese IP wird von DenyHost gleichzeitig aber auch in die Liste der zu blockierenden IPs eingetragen. Der nächste Versuch mit dieser IP eine Verbindung zum vServer aufzubauen wird dann hingegen blockiert. Ich meine dies jetzt mit der Option RESET_ON_SUCCESS = yes gelöst zu haben. Damit ist es aber noch nicht getan.

2) Wenn ich einen File auf dem vServer aufrufe und darin Änderungen vornehme, kann ich diesen dann nicht mehr speichern; der Vorgang wird blockiert. Einen File von meinem Computer auf den vServer kopieren funktioniert hingegen.

Hat vielleicht jemand von Euch eine Idee weshalb dies jetzt nicht mehr so rund läuft wie vorher ?

Nachtrag: Habe eben nochmals versucht Files zu ändern und jetzt auf einmal funktioniert es (wieder) :confused:
(Wie kann ich den jetzt nicht mehr zutreffenden Teil des Beitrags durchstreichen anstatt löschen?)
 
Zuletzt bearbeitet:
Richtig, sshd wertet (im Gegensatz zu asterisk - damit wir das nicht durcheinander bringen) die hosts.deny aus, daher funktioniert es auch.

Warum bei Dir aber auch korrekte Logins ins deny rasseln kann ich nicht sagen. Offenbar kommt es im Zuge der Authentifizierung zur irgendwelchen Log Einträgen die fail2ban als Fehlversuche wertet. Versuch mal im Zuge eines Logins die auth.log und die fail2ban.log zu beobachten.

Zu Deinem anderen Problem kann ich nichts sagen, es hat mit Sicherheit aber nichts mit der Portumstellung oder mit ssh an sich zu tun.
 
Ich weiss wirklich nicht was da los ist. Jetzt kann ich auf einmal wieder keine geänderten Files speichern, vorher ging es wieder :confused: Mit Fail2Ban hat es anscheinend nichts zu tun, da es keine Einträge in dessen Log gibt.

Vielleicht kann jemand von Euch mehr aus diesem auth.log entnehmen:
Code:
[U]Ausloggen[/U]:
Oct 30 20:09:19 vs8709 sshd[24702]: Connection closed by xx.xxx.xx.xxx
Oct 30 20:09:19 vs8709 sshd[24702]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Oct 30 20:09:19 vs8709 sshd[24702]: pam_unix(sshd:session): session closed for user root
Oct 30 20:09:19 vs8709 sshd[24702]: Transferred: sent 70136, received 8848 bytes
Oct 30 20:09:19 vs8709 sshd[24702]: Closing connection to xx.xxx.xx.xxx port 10078
Oct 30 20:09:19 vs8709 sshd[31289]: Connection closed by xx.xxx.xx.xxx
Oct 30 20:09:19 vs8709 sshd[31289]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Oct 30 20:09:19 vs8709 sshd[31289]: pam_unix(sshd:session): session closed for user root
Oct 30 20:09:19 vs8709 sshd[31289]: Transferred: sent 9560, received 24560 bytes
Oct 30 20:09:19 vs8709 sshd[31289]: Closing connection to xx.xxx.xx.xxx port 10422

[U]Einloggen[/U]:
Oct 30 20:09:35 vs8709 sshd[10179]: error writing /proc/self/oom_adj: Permission denied
Oct 30 20:09:35 vs8709 sshd[10179]: Connection from xx.xxx.xx.xxx port 10809
Oct 30 20:09:36 vs8709 sshd[10179]: Failed none for root from xx.xxx.xx.xxx port 10809 ssh2
Oct 30 20:09:36 vs8709 sshd[10179]: Found matching RSA key: yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy
Oct 30 20:09:36 vs8709 sshd[10179]: Found matching RSA key: yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy
Oct 30 20:09:36 vs8709 sshd[10179]: Accepted publickey for root from xx.xxx.xx.xxx port 10809 ssh2
Oct 30 20:09:36 vs8709 sshd[10179]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Oct 30 20:09:36 vs8709 sshd[10179]: pam_unix(sshd:session): session opened for user root by (uid=0)
Oct 30 20:09:36 vs8709 sshd[10184]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory

[U]File speichern[/U]:
Oct 30 20:15:00 vs8709 sshd[15202]: error writing /proc/self/oom_adj: Permission denied
Oct 30 20:15:00 vs8709 sshd[15202]: refused connect from xx.xxx.xx.xxx (xx.xxx.xx.xxx)
Oct 30 20:15:11 vs8709 sshd[16449]: error writing /proc/self/oom_adj: Permission denied
Oct 30 20:15:11 vs8709 sshd[16449]: refused connect from xx.xxx.xx.xxx (xx.xxx.xx.xxx)
Oct 30 20:15:21 vs8709 sshd[16472]: error writing /proc/self/oom_adj: Permission denied
Oct 30 20:15:21 vs8709 sshd[16472]: refused connect from xx.xxx.xx.xxx (xx.xxx.xx.xxx)
Oct 30 20:15:29 vs8709 sshd[16514]: error writing /proc/self/oom_adj: Permission denied
Oct 30 20:15:29 vs8709 sshd[16514]: refused connect from xx.xxx.xx.xxx (xx.xxx.xx.xxx)

Nachtrag: Danach hatte ich ausgeloggt. Beim neuen Einloggen war die IP dann wieder blockiert.
 
Zuletzt bearbeitet:
Hallo MET,

gehen wir es ruhig an.

Fail2Ban ist ja nicht viel mehr als ein Dämon der laufend Dateien öffnet, "cat"et und mit einer FILTERDATEI in filter.d vergleicht.

Findet er dort einen Match, wird er reagieren - wie konfiguriert.

Schau mal in Deine (Standard-Debian-Verzeichnis) /etc/fail2ban/filter.d/sshd.conf

Dort steht per default drin was Fail2Ban sucht...bei mir :

Code:
#
failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from <HOST>\s*$
            ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
            ^%(__prefix_line)sFailed (?:password|publickey) for .* from <HOST>(?: port \d*)?(?: ssh\d*)?$
            ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$
            ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
            ^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers$
            ^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$
            ^%(__prefix_line)sauthentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=<HOST>(?:\s+user=.*)?\s*$
            ^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$
            ^%(__prefix_line)sAddress <HOST> .* POSSIBLE BREAK-IN ATTEMPT\s*$

Bei Dir sehe ich jetzt

Code:
..refused connect from..

Das KÖNNTE (!!) sich mit dem Match oben gleich sein - damit hättest Du Dein Possible Match. ABER! Solltest Du Fail2Ban und natürlich Dein EmailProgramm (Exim4?) richtig konfiguriert haben, so würdest Du über diesen Zustand eine Email erhalten, genauer gesagt würde diese ROOT erhalten und dann entsprechend der /etc/email-adresses weiterleiten.

ALso - bevor wir hier ganz und gar off topic gehen - schau Dir bitte nochmal die LOGDATEI von Fail2Ban an - diese musstest Du IMHO auch manuell konfigurieren und prüfe Deine Emaileinstellungen.

Anbei - wer loggt sich denn für jede Arbeit mit "Root" ein ? ;)

:spocht:

LG Stefan
 
[sinnvoller Doppelpost]

Nur ein Status am Rande - zum eigentlichen Thread-Sinn.

Ich kann hier definitiv beobachten das - wenn es draußen kälter und ungemütlicher wird - dei Angriffe auf den Asterisken steigen, s.h.

Angriffe auf den Asterisk steigen aktuell auf 2-3 / Tag an, Fail2Ban reagiert und alles ist gut. Gebiete (wie immer) Asien, USA, Osteuropa
Es gibt keine vorgreifliche Uhrzeit - ein AUsschnitt sei gegönnt ... :

Code:
2010-10-24 01:03:32,125 fail2ban.actions: WARNING [asterisk-iptables] Ban 211.167.240.179
2010-10-24 04:20:44,337 fail2ban.actions: WARNING [asterisk-iptables] Ban 64.22.82.2
2010-10-24 11:49:58,017 fail2ban.actions: WARNING [asterisk-iptables] Ban 89.115.177.208
2010-10-24 19:52:07,517 fail2ban.actions: WARNING [asterisk-iptables] Ban 91.121.68.157
2010-10-25 00:45:26,697 fail2ban.actions: WARNING [asterisk-iptables] Ban 211.167.240.179
2010-10-25 06:24:23,441 fail2ban.actions: WARNING [asterisk-iptables] Ban 192.83.181.171
2010-10-25 06:28:36,697 fail2ban.actions: WARNING [asterisk-iptables] 192.83.181.171 already banned
2010-10-30 04:52:43,873 fail2ban.actions: WARNING [asterisk-iptables] Ban 74.52.164.2
(alle UNBANs entfernt)
 
Komme dem "Geheimnis" langsam auf die Schliche. Da im Fail2Ban-Log keine Einträge zu finden waren, glaubte ich, dass dies nur mit hostdeny zu tun hat. Dem scheint aber nicht ganz so zu sein.

Als ich Gewissheit hatte, dass Fail2Ban bei mir mit iptables nicht funktionieren kann, hatte ich im jail.conf unter [asterisk-iptables] als action hostdeny eingetragen. (@"I triple E": ja, ja ich weiss...) Dies hat tatsächlich gewirkt. Gemäss syslog (die anderen logs hatte ich jeweils wieder gelöscht) gab es im ganzen Monat Oktober nur 4 Registrierungsversuche, nämlich am 2, 19. 23. und 28. Es gab etwas mehr vereinzelte Versuche mit TelNr@IPasterisk direkt zu telefonieren. Das Besondere scheint zu sein, dass hostdeny die IP schneller blockiert als es Fail2Ban tun würde. Es ist vermutlich dies der Grund, dass es im Log von Fail2Ban keine Einträge gibt. (Die Mailbenachrichtigung geht bei mir nicht, da kein Mailprogramm installiert ist.)

Der Wechsel der SSH Port nummer scheint für hostdeny nicht zulässig zu sein und trägt deshalb meine IP jeweils in die deny-Liste ein. Ich hatte versucht die in hosts.deny eingetragene eigene IP wieder zu löschen, dies scheint aber nicht zu genügen, die IP wird nachträglich irgenwie wieder eingetragen. Muss mal versuchen meine IP nach der Registrierung sofort in hosts.allow einzutragen. Oder hat jemand noch einen anderen Vorschlag wie ich einfacher verhindern kann, dass mich hostdeny aussperrt?

Nachtrag:
Hatte eben versucht alle IP-Einträge in hosts.deny zu löschen. Dafür habe ich vorgängig hostdeny gestoppt. Nach dem erneuten Start von hostdeny waren dann aber alle IPs wieder vorhanden. Deshalb meine Frage: Wie kann man IPs entgültig aus hosts.deny entfernen?
 
Zuletzt bearbeitet:
Hi MET,

auch wenn ich der Erklärung zu hosts.deny so nicht ganz zustimmen würde - natürlich hat hosts.deny auch eine whitelist :

Code:
/var/lib/denyhosts/allowed-hosts
Alle IPs hierin werden NIE geblockt.

Ich bin aber immer noch irritiert das fail2ban ohne iptables nicht läuft, habe es zwar selber nie so genutzt (mein vserver kann iptables) aber es zahlreiche Male gelesen, hier, nach diesem voip-info HOWTO. WIederum, im fail2ban DOC wird es ja auch nochmals unterstrichen :

Code:
You will probably need at least one firewall software like [I]iptables[/I] or [I]shorewall[/I].

Also wahrscheinlich geht es nur mit ip oder shore.

LG Stefan
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.