Praktische Vorgehensweise "portaudit"

[Mardor]

Hallo,

ich wollte kurz fragen wie Ihr vorgeht, wenn Ihr beispielsweise unter "portaudit -Fda" einen Problem angezeigt bekommt, aber noch kein neues Paket für "portupgrade" verfügbar ist.

Im Moment existiert bei mir das Problem bzgl. "wordpress".

Ich weis nicht ob es sinnvoll wäre den blog bis zum Erscheinen abzuschalten bzw. die neue Version "von Hand" zu installieren, da ich nicht weis, ob es dann Probleme mit den ports (bzgl.portupgrade) in den darauffolgenden Versionen gibt.

Wie geht Ihr normalerweise vor ?

Gruß Mardor

 

[Endorphine]

Man bekommt doch nachts eine Mail, ob portaudit neue Sicherheitslücken gefunden hat.

Da ich zu faul bin, jeden Tag auf jedem System die Mails zu checken, habe ich einfach in meine /etc/csh.login folgendes eingetragen (plz nicht schlagen):

tail -n 300 /var/mail/root | grep problem | uniq

So bin ich beim einloggen immer auf dem neuesten Stand und muss portaudit nicht hinterherlaufen, sondern sehe, ob ich neue Sicherheitslücken in meinen Paketen habe.

Dann hab' ich noch ein kleines Skript, was mir das Gewusel mit portsnap und den Abgleich erspart. Mit portconfig -a und portupgrade -a ist mit aktuellem Portbaum dann alles recht zügig wieder aktualisiert, bei Bedarf.

 

[spaulding]

@Speziell zu AMP-Anwendungen:
Also bei meinen gehosteten AMP-Anwendungen ( WordPressen, Wikis, phpBB3, vBulletin, etc.) warte ich nicht bis auf einen möglichen Portupgrade sondern spiele die jew. Patches direkt gemäß dem jew. Patch Framework ein.

Genau genommen habe ich bei den Anwendungen noch NIE von den Ports installiert sondern den aktuellen Versionsstand gezogen und eingespielt. Somit ergibt sich nicht die Notwendigkeit, in sync mit den Ports sein zu wollen oder auf etwas warten zu müssen. Man kommt dann auch nicht drum herum, sich mit der Struktur der jew. Anwendung zu beschäftigen, da auch Plugins und Themen nach Wünschen modifiziert bzw. neu geschrieben werden, um zwischen der eigentlichen Engine der Anwendung (wo die Patches greifen) und dem selbst gemodeten und somit wohl weltweit zum Unkat erklärten Themenbereich zu unterscheiden.

Bei Apache, MySql, PHP verlasse ich mich jedoch streng auf die Portupgrades von BSD, weil ich mir in dem Bereich ein sinnvolles, eigenständiges Patchen nicht zutraue. Es ist halt ein Unterschied ob man sich nur an Skripten versucht oder wirklich in Kerntechnologien eingreift.

 

[Yamagi]

Nun, wenn bei mir Lücken auftauchen, wird entschieden ob diese kritisch sind. Wenn ein nur intern erreichbares DBMS hier ein paar Löcher aufweist, kräht da kein Hahn nach. Löcher in öffentlich erreichbaren Diensten werden meist innerhlab weniger Tage behoben, nachdem das Update in der Testumgebung durchgespielt und einer Reihe Tests unterzogen wurde.
Häufen sich in Diensten die Fehler, wird nach Alternativen gesucht und sie wenn möglich ausgetauscht. Auf längere Sicht ist dies die beste Wahl, denn es gibt immer wieder Anwendungen, die irgendwie dazu neigen die Probleme anzuziehen oder die halt einfach "insecure by Design" sind.

 

[Endorphine]

Häufen sich in Diensten die Fehler, wird nach Alternativen gesucht und sie wenn möglich ausgetauscht. Auf längere Sicht ist dies die beste Wahl, denn es gibt immer wieder Anwendungen, die irgendwie dazu neigen die Probleme anzuziehen oder die halt einfach "insecure by Design" sind.

Dann verstehe ich nicht, wieso du BIND scheinbar vorziehst, und nicht wie ich djbdns-Fanboy wirst.

 

[Yamagi]

Weil ich mit BIND nie Probleme hatte und das Ding nur von einer einzigen IP aus (für Hidden Primary Snychronisation) erreichbar ist. Sollte der sehr unwahrscheinliche Fall auftreten, dass er mal hochgenommen wird, kann der Angreifer sich in einem ansonsten leeren Jail mit stark eingeschränktem Netzwerkzugang austoben. Ich stelle es denn hinterher wieder her.

Gegen djbdns spricht vor allem, dass es kaum wirkliche Doku gibt oder gab, sondern nur Unmengen eher unqualifiziertes BIND-Gebashe. Außerdem mag ich persönlich Herrn Bernstein und seine Ansichten über Lizenzen, Software und die Welt allgemein nicht.