Hacker in meinem Asterisk Server

Also aus meiner Sicht muss ein Dienst entweder gegen die libwrap gelinkt sein (das kann man mit ldd /usr/sbin/asterisk testen - da find ich in meinem Fall kein libwrap), oder von sich aus selbst die hosts.allow/hosts.deny auswerten, damit das einen Sinn hat (Samba zum Beispiel wertet die beiden Datein selbst aus wenn ich nicht irre.)

Zu Deiner Frage:
Auf meinen Server kam ich wieder indem ich hinging und den Bildschirm eingeschaltet habe ;-)
 
5- fail2ban starten mit /etc/init.d/fail2ban start
Habe jetzt die ganze Installation nochmals durchgeführt aber unter /init.d/ befindet sich wiederum kein file fail2ban ???

Im README steht
Fail2Ban should be correctly installed now. Just type:
> fail2ban-client -h
dies liefert dann auch alle diese Befehls-Optionen:
PHP:
Usage: /usr/bin/fail2ban-client [OPTIONS] <COMMAND>

Fail2Ban v0.8.4 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.

Options:
    -c <DIR>                configuration directory
    -s <FILE>               socket path
    -d                      dump configuration. For debugging
    -i                      interactive mode
    -v                      increase verbosity
    -q                      decrease verbosity
    -x                      force execution of the server (remove socket file)
    -h, --help              display this help message
    -V, --version           print the version
.....

Habe dann mit diesen Befehlen versucht zu starten:
PHP:
vs1234:~# fail2ban-client -s reload
vs1234:~# fail2ban-client -s start
Jedes mal werden die Befehls-Optionen aufgelistet. Keine Ahnung, ob das Ding läuft oder nicht, vermutlich aber nicht, da keine Mail erhalten.

Any ideas?

Marcel
 
Und wie genau hast du die installation durchgefuehrt? Glaskugel wird gerade im Niger gewaschen, sorry ...
 
@MET

Schaut für mich so aus als hättest Du fail2ban händisch aus den Sourcen installiert. In dem Fall musst Du selbst dafür sorgen das es läuft (fail2ban-client start) oder Du schnappst Dir eins der init-skripts aus dem "files" Verzeichnis des Installationspakets und kopierst es Dir nach /etc/init.d
 
Als Linux-Analphabet hatte ich mir die einzelnen Befehle notiert:

cd /usr/src
wget http://downloads.sourceforge.net/fail2ban/fail2ban-0.8.4.tar.bz2
tar -jxf fail2ban-0.8.4.tar.bz2
cd fail2ban-0.8.4
apt-get install python iptables
python setup.py install

Fehlte da etwas?

IEEE schrieb:
... oder Du schnappst Dir eins der init-skripts aus dem "files" Verzeichnis des Installationspakets und kopierst es Dir nach /etc/init.d
:gruebel: siehe oben betreffend Analphabet.

Marcel

Nachtrag: Habe fail2ban-client vom Verzeichnis /usr/src/fail2ban-0.8.4/ nach /etc/init.d/ kopiert. Wollte dann starten:
vs1234:~# /etc/init.d/fail2ban-client start
-bash: /etc/init.d/fail2ban-client: Keine Berechtigung
Geht so anscheinend nicht.
 
Zuletzt bearbeitet:
Nimms mir nicht krumm, aber wenn Dir diese Anweisungen schon nichts sagen, dann werden wir das Ding hier im Rahmen dieses Threads nicht konfiguriert kriegen. Entweder Du besserst Deine Linuxkenntnisse auf oder Du gibst jemandem ssh Zugang der es Dir installieren kann.
 
Ich hätte mal was anderes. Wie ich berichtet hatte, wurde ich von IP 218.93.205.205 angegriffen. Was würde eigentlich passieren, wenn wir alle diese IP anpingen würden?
Dann könnte er gar nichts mehr machen, oder?
 
Ich hätte mal was anderes. Wie ich berichtet hatte, wurde ich von IP 218.93.205.205 angegriffen. Was würde eigentlich passieren, wenn wir alle diese IP anpingen würden?
Dann könnte er gar nichts mehr machen, oder?

Ich bitte Dich... So ein ping kratzt niemand. Da müssten schon richtige DDOS Angriffe her und dafür wirst Du nicht genug Rechner zusammenkriegen. Zudem kannst Du von hier aus nicht sagen wem Du wirklich schadest und das es illegal wäre lass ich mal ganz aussen vor.
 
Bin einen Schritt weiter. Habe nach dem Kopieren auch die Eigenschaften gemäss denjenigen im ursprünglichen File angepasst:

Gruppe: 1000
Eigentümer: 1000
Rechte oktal: 0755

Hoffe das ist richtig so. Auf jeden Fall kommen nach

/etc/init.d/fail2ban-client start

Folgende Warnungen und Fehlermeldungen:
vs1234:~# /etc/init.d/fail2ban-client start
WARNING 'action' not defined in 'php-url-fopen'. Using default value
WARNING 'action' not defined in 'lighttpd-fastcgi'. Using default value
WARNING 'enabled' not defined in 'ssh'. Using default value
WARNING 'logpath' not defined in 'ssh'. Using default value
WARNING 'filter' not defined in 'ssh'. Using default value
ERROR /etc/fail2ban/filter.d/.conf and /etc/fail2ban/filter.d/.local do not exist
ERROR Unable to read the filter
ERROR Errors in jail 'ssh'. Skipping...
Anscheinend werden die Files jails.conf und jails.local im Verzeichnis /filter.d/ gesucht anstatt im Verzeichnis /fail2ban/

Verschiebe ich jedoch die beiden Files ins Verzeichnis /filter.d/ kommt folgende Meldung:
vs1234:~# /etc/init.d/fail2ban-client start
ERROR /etc/fail2ban/jail.conf and /etc/fail2ban/jail.local do not exist
2010-05-15 21:55:41,179 fail2ban.server : INFO Starting Fail2ban v0.8.4
2010-05-15 21:55:41,179 fail2ban.server : INFO Starting in daemon mode
Naja, da scheine ich wieder einen Schritt weiter gekommen zu sein. Warum braucht fail2ban aber diese beiden Files an zwei Orten? ABER, lege ich im Verzeichnis /fail2ban/ Kopien der beiden Files ab, bekomme ich jedoch wieder die erste Fehlermeldung mit dem "..Skipping".

Hat jemand eine Idee und kann mir an dieser Stelle vielleicht - trotz Analphabet - auf die Sprünge helfen. Danke.

Bin ich übrigens der Einzige der hier auch versucht fail2ban einzurichten und dieses Problem hat?
 
Zuletzt bearbeitet:
Was machtn Ihr da eigentlich?
alwaysauthreject=yes in die sip.conf und gut is, dann können keine accounts mehr gefunden werden für den password-bruteforce.
 
Hatte auch diese Hackangriffe. Zum Glück hatte ich die Passwörter so geändert, dass mindestens dort Endstation ist. Bei einem früheren Angriff wurde diese IP 193.170.134.152 der Uni Linz verwendet. Eine Mail an abuse blieb unbeantwortet.

Zitat von erdnuss0815
Wenn es nur um Asterisk geht:
In der sip.conf.
Mit deny und permit
z.b: deny=0.0.0.0/0.0.0.0 ;blockt alles
und permit=192.168.178.0/255.255.255.0 lässt nur Adressen beginnend mit 192.168.178.xxx zu.

Dies scheint aber nur zu gehen wenn man eine feste IP hat. Oder habe ich ein Brett vor dem Kopf? Ich sehe auch nicht wie dies mit DynDNS gehen könnte. Was macht ihr bei sich ändernder IP?

(Ein Brett nicht - vielleicht einen Denkfehler);)
Die geblockten IP's sind die,die sich anmelden möchten. Mit deiner erhaltenen ip von deinem Provider hat das nichts zu tun. Das sind zwei paar Schuhe! Und die Localen adress-bereiche wirst du ja kennen (in denen z.B. dein dhcp arbeiet) und bei "permit" eintragen können.
 
(Ein Brett nicht - vielleicht einen Denkfehler);)
Die geblockten IP's sind die,die sich anmelden möchten. Mit deiner erhaltenen ip von deinem Provider hat das nichts zu tun. Dass sind zwei paar Schuhe! Und die Localen adress-bereiche wirst du ja kennen (in denen z.B. dein dhcp arbeiet) und bei "permit" eintragen können.
Dass dies nichts mit der IP der SIP-Provider zu tun hat war mir schon klar. Meine Überlegungen bezogen sich auf die IP meines ISP. Mein Asterisk ist auf einem externen vServer und nicht im LAN eingebunden. Ab und zu gibt es hier schon Unterbrechungen entweder von Elektrizität oder dem Internet selbst, bei denen mir der ISP jedes mal wieder eine neue IP zuweist.
 
Dass dies nichts mit der IP der SIP-Provider zu tun hat war mir schon klar. Meine Überlegungen bezogen sich auf die IP meines ISP. Mein Asterisk ist auf einem externen vServer und nicht im LAN eingebunden. Ab und zu gibt es hier schon Unterbrechungen entweder von Elektrizität oder dem Internet selbst, bei denen mir der ISP jedes mal wieder eine neue IP zuweist.

Ich meinte schon die IP die du von deinem ISP bekommst.
Logischerweise musst du die internen IP's in externe Bereiche deiner Telefone abändern...
aber mal nebenbei: wenn einer meiner Serveranbieter auch nur 2 Ausfälle im Jahr hätte, würde ich aber richtig schnell wechseln & kündigen. Aber das ist deine Sache.

UND siehe: http://www.asterisk.org/doxygen/trunk/Config_sip.html
 
Tja, erdnuss - nicht ueberall in der welt ist man so luxurioes angebunden wie in Deutschland ...

Hast du mal geschaut, wo MET lebt? Und wie er angebunden ist? Und er hat - im vergleich zu mir - noch einen verhaeltnismaessig guten anschluss! Und den wechselt man auch nicht eben mal so von heute auf morgen (selbst wenn es was besseres gaebe, worueber ich gar nicht sicher bin).

Chris
 
Sorry, hab ich nicht - da ich nebenbei noch andere sachen erledigen muss.
deshalb hab ich auch geschrieben: dass dies seine sache ist. Er wird sich schon etwas dabei gedacht haben.
ich wollt es ja nur mal erwähnt haben. Asche auf mein Haupt.
 
alwaysauthreject=yes in die sip.conf und gut is.
Danke fuer den tip! Hab ich gleich eingetragen, kannte ich bislang nicht.

Diese security spezis behaupten allerdings, mit ihrer software koenne man das alwaysauthreject umschiffen (ohne zu erklaeren, wie ...) - wenn's stimmt, koennen das die boesen buben sicher auch.

Aber vielleicht kann das ja nicht jedes script-kiddy ... :)

Schoenen sonntag wuenscht
Chris
 
Diese security spezis

sind keine, es gibt keine Attacke ohne Szenario.
Die wollen bloss Geld.

Wer Zugriff auf seine Firewall hat kann ja noch zusätzlich eine UDP-Flood Sperre einrichten:
http://www.ip-phone-forum.de/showthread.php?p=1517889#post1517889

Solche fail2ban scripte dürften zu langsam sein bei grossvolumigen Angriffen von verteilten Hosts und könnten Server mit begrenzter CPU durch Überlastung DOSsen.

... und wer sagt, dass eure Asterisk (oder sonstige) Boxen auf 5060 laufen müssen?

Viele Provider machen sich nicht die Mühe und respektieren andere Portangaben nicht und schicken INVITEs trotzdem an 5060/udp.
 
Zuletzt bearbeitet:
Ab welcher Asterisk-Version gibt es alwaysauthreject=yes ?
Ich finde es bei mir irgendwie nicht.
 
Das geht mit 1.4 und 1.6 (1.2 hab ich nie verwendet).
Ein Auszug aus der sip.conf.sample des Quellcodes:
Code:
;alwaysauthreject = yes         ; When an incoming INVITE or REGISTER is to be rejected,
                                ; for any reason, always reject with an identical response
                                ; equivalent to valid username and invalid password/hash
                                ; instead of letting the requester know whether there was
                                ; a matching user or peer for their request.  This reduces
                                ; the ability of an attacker to scan for valid SIP usernames.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,831
Beiträge
2,219,105
Mitglieder
371,533
Neuestes Mitglied
ipeee
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.