Böse logs?

[Nordin]

Hallo Leute,

ich haben ne ganze mänge von diesen Logs gefunden... immer die selbe IP...
Könnt ihr mir sagen was der genau vorhatte?


Jun 12 23:22:35 v29352 sshd[26477]: Address 207.44.194.31 maps to tfc30.oesm.org, but this does not map back to the address - POSSIBLE BREAKIN ATTEMPT!
Jun 12 23:22:36 v29352 sshd[26531]: Address 207.44.194.31 maps to tfc30.oesm.org, but this does not map back to the address - POSSIBLE BREAKIN ATTEMPT!
Jun 12 23:22:37 v29352 sshd[26585]: Invalid user admin from 207.44.194.31
Jun 12 23:22:37 v29352 sshd[26585]: Address 207.44.194.31 maps to tfc30.oesm.org, but this does not map back to the address - POSSIBLE BREAKIN ATTEMPT!
Jun 12 23:22:38 v29352 sshd[27668]: Invalid user admin from 207.44.194.31

Thx Nordin

[Wene]

Ganz einfach: da wollte sich einer über SSH an dem Server anmelden. Solange der Zugriff verwehrt wird ist das ja kein Problem.

Wenn du die Sicherheit erhöhen willst, lass SSH auf einen anderen Port lauschen.

Und stelle sicher dass kein root Login möglich ist sowie ein sicheres Passwort verwendet wird.

[Nordin]

also ich denke das password ist ziehmlich sicher es besteht aus buachstaben, zahlen und zeichen mit einer länge von 14 zeichen...


Wenn du die Sicherheit erhöhen willst, lass SSH auf einen anderen Port lauschen.Hmm hört sich kompliziert an *g*

[marce]

... ist es aber nicht. Einfach mal in der sshd.config nachschauen :-)

[eule]

Da laeuft nur das uebliche Skript gegen deinen sshd. Die nerven schon seit Jahren herum und muellen die Logfiles zu.
Nichts worueber man sich Sorgen machen muss, sofern dein sshd sicher konfiguriert ist.

[HEMIcuda]

Wenn du die Sicherheit erhöhen willst, lass SSH auf einen anderen Port lauschen.
Yeah, security by obscurity :D

'cuda

[Wene]

Yeah, security by obscurity :D

'cuda
Hat in solchen Fällen immer geholfen. :p

[comrad]

Das ist halt das normale Hintergrundrauschen im Internet ;)

[eule]

Hat in solchen Fällen immer geholfen. :p
Dadurch wird der Rechner nicht sicherer, sondern es bleiben lediglich die Logfiles sauber.
Sicher wird der Rechner nur durch eine saubere Konfiguration, nicht durch das verstecken von Problemen.
Bei einem gut konfigurierten sshd ist es voellig egal, ob die Skripte an der Tuer ruetteln.

[Wene]

Dadurch wird der Rechner nicht sicherer, sondern es bleiben lediglich die Logfiles sauber.
Sicher wird der Rechner nur durch eine saubere Konfiguration, nicht durch das verstecken von Problemen.
Bei einem gut konfigurierten sshd ist es voellig egal, ob die Skripte an der Tuer ruetteln.

Es erhöht durchaus auch ein Wenig die Sicherheit, kann aber auf keinen Fall als einzige Massnahme eingesetzt werden. Lies doch nochmal mein erstes Posting. Da hab ich bereits was von Konfiguration und Passwörtern geschrieben.

Sein Problem am Anfang waren ja die Einträge im Logfile, was damit hoffentlich gelöst wird.

PS: Je weniger an einer Tür gerüttelt wird desto grösser ist die Chance dass sie zu bleibt. :p

[marce]

Es erhöht nicht die Sicherheit. Wo das Schlüsselloch an der Tür sitzt macht keinen Unterschied, wenn es nicht ein Sicherheitsschloss ist. Der Einbrecher muss sich nur erst ein bisschen bücken oder strecken um dran zu kommen.

Was weniger wird sind die dummen Jungs, die Kaugummi in's Schloss drücken :-)

[Der Gestreifte]

Sein Problem am Anfang waren ja die Einträge im Logfile, was damit hoffentlich gelöst wird.Dann macht der nächste einen Portscan um das Schlüsselloch zu finden, und dann sind sie wieder da, die Einträge ins Log ;o)

[psy]

Den SSHD auf einem anderen Port laufen zu lassen bringt trotzdem den Vorteil, dass nicht jedes automatische Script die Logs vollmüllt.
Auch wenn es Security by Obscurity ist, es vermindert das Gefahrenpotenzial ;)

[Sören Schneider]

...
Bei einem gut konfigurierten sshd ist es voellig egal, ob die Skripte an der Tuer ruetteln.

Und wie sähe sowas aus? :confused:

[zyrusthc]

Und wie sähe sowas aus? :confused:

Hat psy doch schon erläutert, desweiteren sollte man auch fail2ban einrichten!

Greeez Oli

[Roger Wilco]

Hat psy doch schon erläutert, desweiteren sollte man auch fail2ban einrichten!
Nö.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4321
http://www.ossec.net/en/attacking-loganalysis.html

[nemesis77]

mal by the way... wie wäre denn dann die syntax um wieder via shell und shh auf gewünschten Port zu connecten?

[marce]

man ssh meint dazu:

-p port
Port to connect to on the remote host. This can be specified on
a per-host basis in the configuration file.

[MiGo]

Oder du verbietest einfach den login per Passwort und authentifizierst dich nur noch per Keys.
Dann kannst du jeden Einlogversuch getrost ignorieren.

Den Schlüssel sollte man allerdings sorgfältigst sichern, sonst sperrt man sich recht fix aus der Kiste aus mit einer Neuinstallation des Rechners zu Hause....

[ThomasG_gPM]

Die beste Alternative wäre wohl Portknocking einzurichten - ist zwar aufwändiger, aber wenigstens tatsächliche Sicherheit, da auch bei einem kompletten Portscan kein SSH-Port auftaucht.

[nemesis77]

Hallo, ich bekomme fail2ban aber auch DenyHost leider nicht installiert. er meckert ständig wegen meiner Version von python-central herum. ( Auf Debian 3 Sarge/v-Server)
Da ich aber nicht unstable arbeiten will, gibts also für mich nur die relative Lösung den Port zu verlegen um das vollaufen meiner logs zu unterbinden.
Wenn ich den Port verlege - wie komm ich denn wieder an mein ssh?

user@ip:port?

Sry aber so gut kenn ich mich noch immer nicht aus

[marce]

man ssh
sollte alles drinstehen...

[Wene]

Sry aber so gut kenn ich mich noch immer nicht aus

Tipp: probier es zuerst Zuhause aus bevor Du Dich aus Deinem eigenen Server aussperrst. Wichtig ist auch dass am Server keine Firewall den neuen Port blockiert.