"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?
_________________
... and Windows is for Solitaire.

[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...
_________________
root@mbj # echo "sys-pizza/calzone -tunfish" >> /etc/paludis/use.conf
root@mbj # paludis -i calzone --dl-blocks discard

[Mr_Maniac]

Gibt es nicht auch /dev/urandom?
_________________
AMD Ryzen 5900X
64 GB DDR4 RAM
GeForce RTX 3080
Gentoo Linux (most recent stable kernel - amd64)
Windows 11 x64

[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)

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.

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.

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

[ZX-81]

Echt Klasse die Response hier!


@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. 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.

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
_________________
... and Windows is for Solitaire.

[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?
_________________
... and Windows is for Solitaire.

[m.b.j.]

Hast du die genannten entropyd(s) mal ausprobiert?
_________________
root@mbj # echo "sys-pizza/calzone -tunfish" >> /etc/paludis/use.conf
root@mbj # paludis -i calzone --dl-blocks discard

[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
_________________
... and Windows is for Solitaire.

[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)...
_________________
root@mbj # echo "sys-pizza/calzone -tunfish" >> /etc/paludis/use.conf
root@mbj # paludis -i calzone --dl-blocks discard

[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).
_________________
... and Windows is for Solitaire.

[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?
_________________
... and Windows is for Solitaire.

[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.

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.
_________________
... and Windows is for Solitaire.

[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)
_________________
root@mbj # echo "sys-pizza/calzone -tunfish" >> /etc/paludis/use.conf
root@mbj # paludis -i calzone --dl-blocks discard

[ZX-81]