# "dev/random" leergesaugt

## ZX-81

Habe heute tomcat mit ssl konfiguriert. Ständig hat irgendwas rumgesponnen. keytool (keygenerator) ist gehangen und auch tomcat hat beim Starten Zicken gemacht. Nach langer Suche bin ich draufgekommen, dass in "/dev/random" einfach keine Zufallszahlen mehr waren. Ich habe dann durch künstliche HD-Zugriffe den randomgenerator etwas auf die Beine geholfen. Gibt es eine bessere Möglichkeit?

----------

## m.b.j.

Probier mal die 

hardened-dev-sources

Ich hab dort mal was von "enhanced entropy pools" gesehen, weiß aber nicht mehr, obs in Zusammenhang mit /dev/random irgendwelche Vorteile bringt.

Ok ich gebs zu, ist ein schwacher Post, aber vieleicht bringts ja jemanden auf die richtige Idee...

----------

## Mr_Maniac

Gibt es nicht auch /dev/urandom?

----------

## rukka

Larger entropy pools sind im Grsecurity-Patch enthalten, oder man sucht sich die entsprechenden Zeilen unter <kernel>/drivers/char/random.c selbst raus und ändert es dementsprechend. Irgendwo gab es mal einen Hinweis die Entropy nicht zu hoch zu setzen, warum und wo werde ich nochmal nachschauen.

Den Unterschied zwischen /dev/random und /dev/urandom erklärt dir "man 4 random" wunderbar! (Besser als ich es könnte)  :Wink: 

Erwähnenswert wäre vielleicht noch media-sound/audio-entropyd und media-video/video-entropyd, die sorgen wohl dafür, dass dein /dev/random nicht verhungert, es wird immer brav mit neuen (zufälligen) Daten gefüttert.

Hoffe das hilft dir (bzw. euch) ein wenig.

bye

----------

## Fauli

Im Kernel gibt es noch einen Treiber "Intel/AMD/VIA HW Random Number Generator support". Den habe ich aber noch nie ausprobiert.

----------

## rukka

Ja, den Intel/AMD/VIA HW Random Number Generator Support gibt es im Kernel aber der ist nur mit Intel i8xx-, AMD 76x-basierten Motherboards und Via Nehemiah CPUs kompatibel. Wenn du also sowas hast kannst du dich glücklich schätzen. Auch hier ist die Funktionsweise unter <kernel>/Documentation/hw_random.txt nachzulesen.  :Wink: 

Interessant wären vielleicht noch die rng-tools, zu beziehen bei SourceForge. Im Prinzip machen die nichts anderes als die beiden entropyds im Post vorher, nur etwas flexibler.

Nun denn ... viel Spass noch beim füttern.  :Wink: 

Edit: Die Quelle zu dem Thema mit dem grösseren Entropy Pool.

```
# Warning: Enabling this while using grsecurity with "Larger

#          entropy pools", will consume huge amounts of memory.

#          So make sure that you have more than 512 MB of memory

#          before using this.

#          If you don't know what grsecurity is, you don't have it. 
```

 ... aber ob das im Zusammenhang steht!?

Alternativ kann man auch per echo (als root) ein paar Zahlen wie 32, 64, 128, 256, 512, 1024 oder 2048 nach /proc/sys/kernel/random/poolsize senden, dann brauch man auch zwangsläufig nicht den Kernel patchen.

----------

## ZX-81

Echt Klasse die Response hier!  :Very Happy: 

@m.b.j. und @rukka: Zu hardened-sources bzw. grsecurity

Die hatte ich ursprünglich für den Server vorgesehen, hatte dann aber zuviel Angst dass ich mich mit den Sicherheitseinstellungen nur selber aussperre so dass ich es gelassen habe.  :Embarassed:  Das Monster muss ich erstmal im LAN in den Griff bekommen.

Danke @rukka für den man Tip mit urandom, so genau habe ich es bisher noch nicht gewusst.

@Fauli & @rukka: "Intel/AMD/VIA HW Random Number Generator support"

An den habe ich auch gedacht. Der hat sich auf anderen Systemen bisher immer dadurch hervorgetan, dass er sich nicht laden lies. Und hier finde ich ihn nicht im menuconfig.  :Rolling Eyes: 

EDIT: Habe den Eintrag jetzt gefunden (nachdem ich Watchdog aktiviert und wieder deaktiviert habe, war er plötzlich darunter da) und aktiviert, aber wie bei so vielen meiner Intels-Boards lässt er sich nicht laden. Nach verschiedenen Internetfunden scheint es ein rechter Bullshit damit zu sein (Hardware RNGs Conclusion, hw_random and the missing Intel RNGs)

Nachdem ich mich jetzt nach einigen Stunden wieder eingeloggt habe, hatte ich "/proc/sys/kernel/random/entropy_avail = 1", mit "emerge --sync" konnte ich sie dann auf einen brauchbaren Wert hochkitzeln. System macht anscheinend im Leerlauf so wenig, dass es nichtmal zum Erzeugen von Zufallszahlen reicht.   

Herzlichen Dank für Eure zahlreichen Antworten

ZX

----------

## ZX-81

So ein shit,  "/proc/sys/kernel/random/entropy_avail" steht schon wieder auf 1. Irgendwas schient da immer die ganze Entropie aufzufressen. Wie komm ich da nur dahinter was das ist?

----------

## m.b.j.

Hast du die genannten entropyd(s) mal ausprobiert?

----------

## ZX-81

Nein, es ist ein Root-Server und ich habe keine Video und Audio-Treiber installiert. Auch die Maus als Entropiequelle fällt in diesem Fall aus. Der Witz ist aber, dass es auf derselben Hardware mit der vorherigen Installation (gentoo 1.4) keine derartigen Probleme gegeben hat. Naja, dem "Entropiefresser" werde ich schon noch auf die Spur kommen  :Wink: 

----------

## m.b.j.

Ich bin zufällig auf einen Post von dir gestoßen, bei dem du erwähntest, das du 3GB Festplattenkapazität (auf deinem Server) hättest, kann es sein, dass du einen virtuellen Server hast (wegen der doch etwas geringen Kapazität), falls dem so ist kann es ja sein, das dir andere Nutzer die Entropy leersaugen?

Es gibt auber auch spezielle crypto Beschleunigungskarten, hab sowas schonma gesehen (nat hab ich jetzt keinen Link zur Hand)...

----------

## ZX-81

Nein, es ist kein virtueller Server, aber nachdem auf dem Server nicht viel installiert ist, belegt er auf der Hauptpartition nicht  einmal 2 GB (3 GB war die alte Installation).

----------

## ZX-81

Hatte zunächst Tomcat bzw. verschieden Webapps in Verdacht, aber /dev/random wird auch leergesaugt wenn tomcat nicht läuft.

Auch die read/write-Rechte von /dev/random auf root einzuschränken verhindert das Leersaugen nicht.

Auf der Kiste läuft nur metalog, ntpd, sshd und vixie-cron.

Dass für jeden ssh login ein paar Zufallszahlen gebraucht werden ist mir klar, aber solche logins gibt es nur wenige (ssh läuft  nicht auf Standardport). 

Hat sonst noch niemand dieses Problem gehabt?

----------

## rukka

Schönen guten Abend auch.

Du könntest eventuell die Prozesse, die auf /dev/*random zugreifen, mittels /bin/fuser oder /usr/sbin/lsof aufspüren. Die Programme sind in den Paketen sys-process/psmisc bzw. sys-process/lsof enthalten, zusammen mit /usr/bin/watch lässt sich da vielleicht was basteln und der/die Übeltäter wird/werden (hoffentlich) überführt.

Leider habe ich auch keine Vermutung was deine Entropy so stark leersaugt.  :Confused: 

Viel Erfolg bei der Suche, bye: rukka

----------

## ZX-81

Danke für den Tip, ich habe jedoch befürchtet, dass der Zugriff so kurz sein könnte, dass man damit kaum Chancen hat den Übeltäter zu ermitteln. Deshalb war ich mutig und habe /dev/random in /dev/random2 umbenannt.  Der überraschende Effekt war nicht nur, dass das keinerlei Einfluss auf sshd zu haben scheint, sondern auch, dass auch so das Leersaugen nicht aufhört. Ich vermute den Übeltäter jetzt eher im Kernel selbst (vielleicht wird /dev/urandom zyklisch aus /dev/random gefüttert).

Glücklicherweise scheint Tomcat nach dem Start für ssl auch nichts mehr aus /dev/random zu brauchen. Damit kann ich meine Applikation jetzt laufen lassen, aber ich befürchte dass ich bald wieder auf Probleme stossen werde.

----------

## m.b.j.

<idee>

Falls du diese Umbenennung im laufenden System durchgeführt hast, wirst du keine Probleme gemerkt haben, da ein Programm, dass /dev/randumg geöffnet hat einen sogenannten Filedeskriptor für diese "öffnung" zugeteilt bekommen hat. Und vonunan über diesen auf das Device/File/Netzwerk zugreifen kann. Der Deskriptor ist selbst nach umbennenen noch gültig. Also falls ein Serverdienst läuft, der /dev/random öffnete wird er jetzt weiter auf /dev/random2 zugreifen, ohne es zu merken.

Probleme kannst du allerdings erst bekommen, wenn du den Serverdienst neustartest, und er vergeblich versucht /dev/random zu öffnen...

</idee>

Allerdings kreiert z.B. der sshd für jede "erfolgreiche" Verbindung einen Kindprozess, der dan seinerseits versuchen wird /dev/random neu zu öffnen... (es sei denn er erbt die Filedeskriptoren)

----------

## ZX-81

 *m.b.j. wrote:*   

> Also falls ein Serverdienst läuft, der /dev/random öffnete wird er jetzt weiter auf /dev/random2 zugreifen, ohne es zu merken.

 

Das hätte ich dann aber mit fuser sehen müssen (denke ich).

 *m.b.j. wrote:*   

> Probleme kannst du allerdings erst bekommen, wenn du den Serverdienst neustartest, und er vergeblich versucht /dev/random zu öffnen...

 

Zumindest mit sshd habe ich das getestet (Der Rechner steht beim Provider und ich hatte Angst, dass ich mich mit meinen Spielchen aussperre, deshalb habe ich den Rechner mit umbenanntem /dev/random auch nicht neu gebootet).

Nachdem es nur Probleme beim Schlüsselgenerieren und beim Start von Tomcat (nicht aber im Betrieb) zu geben scheint, bin ich mir auch gar nicht mehr so sicher, ob die Problematik bei der alten Installation einfach nur zufällig nicht aufgetreten ist. Jetzt habe ich ein 2005.0 mit vanilla-sources-2.6.11.7 und udev installiert, vorher 1.4 mit vanilla-sources-2.4.xx und devfs. Leider scheint die Netzwerkaktivität nicht als Entropiequelle verwendet zu werden. Bei einem Server bleibt dann anscheinend nur noch die Festplattenaktivität und die hält sich bei ausreichend Speicher auch sehr in Grenzen  :Confused: 

Danke, für Eure rege Anteilnahme  :Wink: 

----------

