# Hackerangriff dringend!

## Tinitus

Hallo,

habe gerade gesehen, daß jemand eine Wörterbuchattacke gefahren hat. Dabei kam dann der Fehler:

Jul 28 19:17:39 server sshd[27430]: reverse mapping checking getaddrinfo for 221.hosting-3.xtream.co.il failed - POSSIBLE BREAKIN ATTEMPT!

ist das dann schon kritisch?

G. Roland

----------

## psyqil

Gewöhn Dich dran, oder leg SSH auf 'nen anderen Port.

Edit: http://www.whitedust.net/view.php?PageID=27 gibt eine kleine Zusammenfassung.Last edited by psyqil on Thu Jul 28, 2005 5:52 pm; edited 1 time in total

----------

## z4Rilla

ssh root login ausgeschalten ?

keine "test" benutzer ?

----------

## Tinitus

 *psyqil wrote:*   

> Gewöhn Dich dran, oder leg SSH auf 'nen anderen Port.

 

Naja ich habe es schon mit einem Script versucht, welches die Absenderadresse per Firewall nach einpaar Versuchen blockt. Aber der hier hat seine Absenderadresse ja noch gefälscht...denke ich.

Wie geht das bzw. wie kann ich dem entgegenen?

G. R.

----------

## /dev/blackhawk

 *Tinitus wrote:*   

>  *psyqil wrote:*   Gewöhn Dich dran, oder leg SSH auf 'nen anderen Port. 
> 
> Naja ich habe es schon mit einem Script versucht, welches die Absenderadresse per Firewall nach einpaar Versuchen blockt. Aber der hier hat seine Absenderadresse ja noch gefälscht...denke ich.
> 
> Wie geht das bzw. wie kann ich dem entgegenen?
> ...

 

Wie psygil schon sagte, den sshd auf einen anderen Port legen!  :Wink: 

MFG

/dev/blackhawk

----------

## Diskus

HAllo,

blöde Frage-wie stelle ich den Port um?

Danke für die Info

Diskus

----------

## psyqil

In /etc/ssh/sshd_config, da kannst Du auch gleich den root-login verbieten!

----------

## think4urs11

 *Diskus wrote:*   

> blöde Frage-wie stelle ich den Port um?

 

 *psyqil wrote:*   

> In /etc/ssh/sshd_config, da kannst Du auch gleich den root-login verbieten!

 

und wenn du eh schon dabei bist auch gleich noch die Password-Auth ganz abschalten und nur noch public key erlauben.

----------

## Eric E.

Neulich bei mir  :Very Happy: 

```
p450 everything # grep Invalid log-2005-07-24-07\:28\:58

Jul 24 08:11:12 [sshd] Invalid user army from 64.151.101.172

Jul 24 08:11:14 [sshd] Invalid user enter from 64.151.101.172

Jul 24 08:11:16 [sshd] Invalid user test from 64.151.101.172

Jul 24 08:11:18 [sshd] Invalid user enter from 64.151.101.172

Jul 24 08:11:21 [sshd] Invalid user test from 64.151.101.172

Jul 24 08:11:26 [sshd] Invalid user london from 64.151.101.172

Jul 24 08:11:28 [sshd] Invalid user america from 64.151.101.172

Jul 24 08:11:30 [sshd] Invalid user password from 64.151.101.172

Jul 24 08:11:32 [sshd] Invalid user europe from 64.151.101.172

Jul 24 08:11:34 [sshd] Invalid user devil from 64.151.101.172

Jul 24 08:11:36 [sshd] Invalid user fuckyou from 64.151.101.172

Jul 24 08:11:38 [sshd] Invalid user username from 64.151.101.172

Jul 24 08:11:40 [sshd] Invalid user user1 from 64.151.101.172

Jul 24 08:11:42 [sshd] Invalid user user2 from 64.151.101.172

Jul 24 08:11:44 [sshd] Invalid user user3 from 64.151.101.172

Jul 24 08:11:46 [sshd] Invalid user user4 from 64.151.101.172

Jul 24 08:11:49 [sshd] Invalid user user5 from 64.151.101.172

Jul 24 08:11:51 [sshd] Invalid user user6 from 64.151.101.172

Jul 24 08:11:53 [sshd] Invalid user user7 from 64.151.101.172

Jul 24 08:11:55 [sshd] Invalid user user8 from 64.151.101.172

Jul 24 08:11:57 [sshd] Invalid user user9 from 64.151.101.172

Jul 24 08:12:00 [sshd] Invalid user user10 from 64.151.101.172

Jul 24 08:12:02 [sshd] Invalid user testuser from 64.151.101.172

Jul 24 08:12:04 [sshd] Invalid user mailtest from 64.151.101.172

Jul 24 08:12:07 [sshd] Invalid user ftpuser from 64.151.101.172

Jul 24 08:12:11 [sshd] Invalid user dream from 64.151.101.172

Jul 24 08:12:13 [sshd] Invalid user dreams from 64.151.101.172

Jul 24 08:12:15 [sshd] Invalid user michael from 64.151.101.172

Jul 24 08:12:18 [sshd] Invalid user gerge from 64.151.101.172

Jul 24 08:12:20 [sshd] Invalid user jan from 64.151.101.172

Jul 24 08:12:22 [sshd] Invalid user key from 64.151.101.172

Jul 24 08:12:25 [sshd] Invalid user anderson from 64.151.101.172

Jul 24 08:12:27 [sshd] Invalid user edu from 64.151.101.172

Jul 24 08:12:29 [sshd] Invalid user xxx from 64.151.101.172

Jul 24 08:12:31 [sshd] Invalid user abc from 64.151.101.172

Jul 24 08:12:34 [sshd] Invalid user music from 64.151.101.172

Jul 24 08:12:36 [sshd] Invalid user mp3 from 64.151.101.172

Jul 24 08:12:38 [sshd] Invalid user winamp from 64.151.101.172

Jul 24 08:12:40 [sshd] Invalid user dos from 64.151.101.172

Jul 24 08:12:42 [sshd] Invalid user admin from 64.151.101.172

Jul 24 08:12:45 [sshd] Invalid user administrator from 64.151.101.172

Jul 24 08:12:47 [sshd] Invalid user mary from 64.151.101.172

Jul 24 08:12:49 [sshd] Invalid user guy from 64.151.101.172

Jul 24 08:12:51 [sshd] Invalid user ghost from 64.151.101.172

Jul 24 08:12:54 [sshd] Invalid user weed from 64.151.101.172

Jul 24 08:12:56 [sshd] Invalid user bogus from 64.151.101.172

Jul 24 08:12:58 [sshd] Invalid user weed from 64.151.101.172

Jul 24 08:13:00 [sshd] Invalid user bogus from 64.151.101.172

Jul 24 08:13:02 [sshd] Invalid user cyber from 64.151.101.172

Jul 24 08:13:05 [sshd] Invalid user sex from 64.151.101.172

Jul 24 08:13:07 [sshd] Invalid user sexy from 64.151.101.172

Jul 24 08:13:10 [sshd] Invalid user sexi from 64.151.101.172

Jul 24 08:13:12 [sshd] Invalid user girl from 64.151.101.172

Jul 24 08:13:14 [sshd] Invalid user cola from 64.151.101.172

Jul 24 08:13:16 [sshd] Invalid user boy from 64.151.101.172

Jul 24 08:13:18 [sshd] Invalid user pepsi from 64.151.101.172

Jul 24 08:13:20 [sshd] Invalid user sprite from 64.151.101.172

Jul 24 08:13:22 [sshd] Invalid user fanta from 64.151.101.172

Jul 24 08:13:25 [sshd] Invalid user manager from 64.151.101.172

Jul 24 08:13:27 [sshd] Invalid user book from 64.151.101.172

Jul 24 08:13:29 [sshd] Invalid user reebot from 64.151.101.172

Jul 24 08:13:31 [sshd] Invalid user start from 64.151.101.172

Jul 24 08:13:33 [sshd] Invalid user stop from 64.151.101.172

Jul 24 08:13:36 [sshd] Invalid user mircea from 64.151.101.172

Jul 24 08:13:38 [sshd] Invalid user adi from 64.151.101.172

Jul 24 08:13:40 [sshd] Invalid user cristi from 64.151.101.172

Jul 24 08:13:42 [sshd] Invalid user christian from 64.151.101.172

Jul 24 08:13:44 [sshd] Invalid user jamelia from 64.151.101.172
```

----------

## Diskus

Hallo danke für die infoś,

in meiner sshd_config sind aber alle Zeilen auskommentiert sprich(# davor) ist das normal?

an 

Think4UrS11

"und wenn du eh schon dabei bist auch gleich noch die Password-Auth ganz abschalten und nur noch public key erlauben." geht das etwas genauer?

DAnke

Diskus:roll:

----------

## b3cks

 *Diskus wrote:*   

> 
> 
> "und wenn du eh schon dabei bist auch gleich noch die Password-Auth ganz abschalten und nur noch public key erlauben." geht das etwas genauer?
> 
> DAnke
> ...

 

https://forums.gentoo.org/viewtopic-t-296499.html

http://www.gentoo.de/doc/de/security/security-handbook.xml?part=1&chap=10#doc_chap11

----------

## Silicoid

Ja, das ist normal. Die auskommentierten sind normalerweise die Defaultvalues. Wenn du also was ändern willst, den # weg und ändern.

----------

## pir187

scheint ja gerade wieder einmal mode zu sein, den sshd zu stressen. hab auch solche einträge im log gefunden.

werde gleich mal o.g. maßnahmen durchführen (public key, no-root hab ich schon, anderer port).

was wollen die leute eigentlich, wenn sie rein kommen würden? ein spam-relay aufbauen? tolle wurst!

pir187

----------

## slick

 *pir187 wrote:*   

> was wollen die leute eigentlich, wenn sie rein kommen würden? ein spam-relay aufbauen?

 

Damit kann man sicher Bücher füllen. Irgendwo habe ich mal das passende Zitat gelesen, in der Form: "Ein Root-Server in den falschen Händen ist eine Waffe."

Was mir so spontan einfällt sind:

- Spam-Relay

- Warez-/Porno-Seiten

- (D)DOS-Client

- Relay für div. Remoteangriffe

- Datenklau (Deiner Daten)

- Datenklau (der Daten der Nutzer dieser Maschine)

...

Allgemein siehe auch diese Threads:

https://forums.gentoo.org/viewtopic-t-218284.html

https://forums.gentoo.org/viewtopic-t-210089.html

----------

## tango

Ich habe zu dieser Dokumentation noch eine Frage:

 *Quote:*   

> Stellen Sie auch sicher, dass Sie nicht UsePAM yes in Ihrer Konfigurationsdatei gesetzt haben, da so der Mechanismus zur Authentifizierung durch öffentliche Schlüssel überschreiben wird.

 

Meine sshd_config:

```
Port 22

Protocol 2

ListenAddress 0.0.0.0

# HostKeys for protocol version 2

#HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

KeyRegenerationInterval 1h

ServerKeyBits 1024

SyslogFacility AUTH

LogLevel INFO

LoginGraceTime 1m

PermitRootLogin no

StrictModes yes

MaxAuthTries 3

RSAAuthentication no

PubkeyAuthentication no

AuthorizedKeysFile   .ssh/authorized_keys

RhostsRSAAuthentication no

HostbasedAuthentication no

IgnoreUserKnownHosts no

IgnoreRhosts yes

PasswordAuthentication yes

PermitEmptyPasswords no

ChallengeResponseAuthentication yes

UsePAM yes

AllowUsers +++

AllowTcpForwarding yes

GatewayPorts no

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

PrintMotd yes

PrintLastLog yes

TCPKeepAlive no

UseLogin no

UsePrivilegeSeparation yes

PermitUserEnvironment no

Compression yes

ClientAliveInterval 10

ClientAliveCountMax 5

UseDNS yes

PidFile /var/run/sshd.pid

MaxStartups 5
```

Jetzt wird die gesamte Authentifizierung ja via pam gesteuert, ist das auch in Ordnung oder hat das "Nachteile" ?

tango

----------

## norbert

Gefährliche Konfiguration!!! Vergiss jede Art von Passwörtern bei öffentlich erreichbaren Servern für SSH! Nutze !NUR! Public Key Authentifizierung!

Setze 

```
PasswordAuthentication no
```

Keine Authentifizierung über Passwort mehr möglich. Damit fallen alle Wörterbuchangriffe weg.

```
UsePAM no
```

Wenn dieser Parameter auf yes steht, wird damit der Parameter PasswordAuthentication ausgehebelt. Quelle: ??? Irgendeine ssh man page

```
RSAAuthentication yes

PubkeyAuthentication yes

RhostsRSAAuthentication no

```

Der Vollständigkeit halber. Nur Login mittels RSA Key erlauben und keine Hostkeys.

Zusätzlich: Suche mal nach Port knocking. War auch in einer der letzten ct oder iX beschrieben.

----------

## tango

zunächst ist der Server nur lokal eingerichtet (Verbote liegen in hosts.deny und sshd_config vor)

Einen anderen Port brauche ich eigentlich auch nicht, denn dafür habe ich ja:

LoginGraceTime 1m

MaxAuthTries 3 

Desweiteren weiß ich nicht genau wie die Authentifizierung nun funktioniert, PuTTy kann sich nicht mehr verbinden, es bricht einfach ab.

Ich habe die Änderungen wie du sie gesagt hast gemacht, eigentlich war ich sicher das ich sshd gut konfiguriert hatte...

Eine Frage habe ich übrigens noch, es gibt ja viele Authentifizierungsmethoden (RSAA,DSA,Kerberos,GSSAPI) welche davon ist sicher und sollte benutzt werden ?

Wenn ich mehr Infos hätte könnte ich auch genauer Googeln, oder wo gibt es eine gute Einführung in die Konfiguration von ssh ?

tango

----------

## norbert

Schön ausgesperrt  :Very Happy: 

Wenn Du Dich auf der Serverconsole ssh testuser@localhost einloggst, sollte so eine Ausgabe rauskommen: Permission denied (publickey,keyboard-interactive). Das ist wahrscheinlich auch der Grund für den PuTTY Abbruch.

Für die Public Key Authentifizierung wird natürlich eine Public Key benötigt. Wird mit ssh-keygen erzeugt. Siehe man-page. Der Public Teil wird dann auf dem Server hinterlegt, in $USER/.ssh/authorized_keys. Irgendwo im Netz gibt es auch einen Anleitung für Putty und OpenSSH Keys.

Bei den Authentifizierungsmethoden muss zwischen den rein kryptographischen und den allgemeinen unterschieden werden. RSA und DSA stützen sich rein auf die Keys, ohne weitere Rückfragen im System. Kerberos, GSSAPI, PAM usw. sind Verfahren zur Absicherung von primär Passwortbasierten Logins. In dem Fall geht es ja um einen Server und da bin ich der Meinung, dass ein möglichst "einfaches" Verfahren genutzt werden soll, damit man immer noch einen Zugang hat, wenn sonst nix mehr geht. So was wie sshd -> pam -> ldap ist nett, aber gefährlich, wenn eine Stufe ausfällt. 

Ich benutze nur RSA 4096 Bit - auf Server und Clientseite. Bei RSA sollten heute noch 2048 Bit genügen. DSA ist ein etwas anderes Verfahren, welches mit 1024 Bit als sicher gilt. Egal was Du nimmst, es ist nur so sicher wie das Mantra für den Private Key. Der sollte in keinem Fall gestreut werden.

----------

## tango

Ich habe das mal mit einem 2048 DSA Key und Putty realisiert, obwohl im Netzwerk eigentlich nur 2 Rechner stehen und es auf 0.0.0.0 beschränkt ist, aber egal  :Wink: 

Wäre nett wenn du nochmal drüberschauen könntest, danke

sshd_config

thx

tango

----------

## STiGMaTa_ch

 *tango wrote:*   

> [...] 0.0.0.0 beschränkt ist, aber egal  

 

Was heisst hier Beschränkung?

mit 0.0.0.0  beschränkst du nichts sondern bindest es an ALLE verfügbaren Adressen!

Lieber Gruss

STiGMaTa

----------

## kobler

"RSAAuthentication yes" würde ich auf no setzen wenn du pubkey nutzt...dann brauchst du ja dieses authen....mechanismus nicht....

lg

kobler alois

----------

## tango

 *Quote:*   

> Was heisst hier Beschränkung?
> 
> mit 0.0.0.0 beschränkst du nichts sondern bindest es an ALLE verfügbaren Adressen!

 

habe ich extra nochmals nachgelesen, du hast ja Recht...

Zum Glück hatte ich noch in der Firewall und in der hosts.allow (dort steht zum Glück 192.168.1.0/255.255.255.0) eine Blockade, sonst wäre der Server von überall erreichbar gewesen...

Ich habe damals die 0.0.0.0 in Bezug auf die hosts Datei kennen gelernt und dachte immer dies wäre ein synonym für das lokale Netzwerk  :Embarassed: 

Vielen Dank für den Hinweis  :Idea: 

tango

----------

## norbert

Sieht ganz gut aus. Setze am besten noch 

```

ListenAddress <meine IP>

```

damit sich der sshd nicht an alle IPs hängt.

Zu RSAAuthentication sagt die man-page: Ein Version 1 Parameter. Ein yes oder no sollte keine Auswirkung haben, da Version 2 verwendet wird. Der entscheidende Parameter ist PubkeyAuthentication. Sorry für die Ungenauigkeit.

----------

## pir187

@tango: welche rechte darf/muß 

```
/etc/hosts.allow
```

 bzw. 

```
/etc/hosts.deny
```

 haben?

ich habe diese dateien nicht auf meinem system und will sie nun einrichten. ich will aber nicht zu viele/zu wenige rechte vergeben.

als owner kommt ja eigentlich nur 

```
root:root
```

 in frage, gelle?

thx, pir187

----------

## Inte

 *psyqil wrote:*   

> Gewöhn Dich dran, oder leg SSH auf 'nen anderen Port.

 

... und der ganz paranoide benutzt zusätzlich: net-misc/knock

----------

## pablo_supertux

wahnsinn, ich hab 2581 Invalid User ....

und viele IPs sind immer noch online...

----------

## SkaaliaN

 :Arrow:  1. ich mach ssh nur dann wenn ich es brauche

 :Arrow:  2. den port habe ichb geändert und route den trotzdem nur dann durch wenn ich ssh auch wirklich laufen lassen muss

 :Arrow:  3. immer die key-datei erstellen. mit passwort ist echt nicht gut 

nach den Regeln arbeite ich. bin ich bisher gut mit gefahren.  :Wink: 

----------

## nic0000

 *pablo_supertux wrote:*   

> wahnsinn, ich hab 2581 Invalid User ....
> 
> und viele IPs sind immer noch online...

 

Da hat sich mal ein ScriptKiddy aber ganz schön ausgetobt.  :Wink: 

grüße

nico

----------

## tango

 *Quote:*   

> @tango: welche rechte darf/muß...

 

ich habe die einfach als root angelegt:

vi /etc/hosts.deny 

Dinge eingetragen, fertig..

tango

----------

## TheCurse

 *pablo_supertux wrote:*   

> wahnsinn, ich hab 2581 Invalid User ....
> 
> und viele IPs sind immer noch online...

 

Jaja, und die haben sicherlich alle eine statische IP-Adresse  :Wink: 

----------

## SkaaliaN

lol. ich weiß echt nicht was manche leutz für langeweile haben müssen um das net nach ssh zu scannen *g

----------

## piezza

Ich hab mir mal vor kurzem die Mühe gemacht, ein PAM-Modul zu schreiben, das Hosts ne gewisse Zeit sperrt, wenn sie Passwörter raten.

Das Modul ist sicherlich noch weit weg von der Perfektion, aber laufen tut es zumindest mal, wie es scheint  :Wink: 

Hier dir URL für alle interessierten: http://www.r00tserver.de/~piezza/

----------

