Nette libc Graphik:

Nette libc Graphik: (68 Beiträge, 896 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hier gibt es eine schöne Graphik der Paketabhängigkeiten bei Ubuntu - wird bei anderen Distris zumindest um das Zentrum ähnlich sein:

http://tech-foo.blogspot.co.at/2013/01/visualising-ubuntu-package-repository.html

Das wichtige Bild ist das:
http://1.bp.blogspot.com/-D4aETrYxFL8/UO4tBzuDxZI/AAAAAAAAFZc/mrezk5uYPIE/s1600/colour_overview_full.png

mit der libc in der Mitte... Und genau die libc hat ne kritische Sicherheitslücke:
http://www.computerwelt.at/news/technologie-strategie/security/detail/artikel/114579-gravierende-sicherheitsluecke-in-fast-allen-linux-distributionen/

Also -rasch- updaten!
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

mit der libc in der Mitte... Und genau die libc hat ne kritische
Sicherheitslücke:
http://www.computerwelt.at/news/technologie-strategie/security/detail/artikel/114579-gravierende-sicherheitsluecke-in-fast-allen-linux-distributionen/

die Lücke für sich ist kritisch, sie aber ausnutzen zu wollen bedarf dann schon etwas mehr und somit ist sie dann schon nicht mehr so kritisch.

entweder man in the middle attack in der DNS communication oder den DNS server kapern, den das Opfer verwendet.

entweder man in the middle attack in der DNS communication

Das bekommst i.d.R. in einem Firmennetz leicht hin....
Dazu noch der Fakt, dass die meisten Angriffe von innen kommen...

Voila.

IMHO schon kritisch.

@home:
Viele ADSL/...-Modems mit alter Original-Firmware lassen sich remote kapern..
Weil die gleichzeitig oft der DNS-Server für daheim sind - auch eine schöne Kombi konstruierbar.

So oder so - updaten ist hier IMHO Pflicht.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Das bekommst i.d.R. in einem Firmennetz leicht hin....
Dazu noch der Fakt, dass die meisten Angriffe von innen kommen...

Voila.

viel spass bei 802.x auth und allen möglichen Schweinereien. meist sind in firmen die AD Controller zeitgleich auch die DNS server und wenn du da was leicht hinbekommen solltest, dann is eine ungepatchte libc dein geringstes problem.

viel spass bei 802.x auth

?

Wenn man sich nur darauf verlässt: Die Hardwarekosten um das zu umgehen belaufen sich auf ca. 1-5€... Je nachdem, was ein Hub gerade auf ebay kostet

Ein böswilliger Mitarbeiter pappt den zwischen seinen PC und seinen NW-Anschluß.... Und kann sich mit seinem Laptop voller Angriffstools mal das Netz ansehen.

Also -nur- 802.1x bringt mal genau Nüsse.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Dafür hat man Portsecurity =)

"I am serious. And don't call me Shirley."

Nutzt leider nicht viel.

1.) Immer mehr Firmen brauchen mehrere erlaubte Mac-Adressen auf einem PC - für Virtualisierungen
2.) Auch wenn da fix nur eine MAC am Switch erlaubt ist... Dann bleibt derselbe Angriffsvektor:
i.) Hub mit Angriffslappy kommt zwischen FirmenPC und Firmennetz.
ii

FirmenPC sperrt 802.1x auf
iii) FirmenPC wird abgehängt (der Switch bekommt das nicht mit, weil der Status des Interface ja noch auf UP ist - hängt ja der HUB dran)
iv) Bis zum nächsten Reauth (30 Mins?) kann man nun mit dem Angriffslappy machen, was man will. MITM geht sich da lockerst aus.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

1.) Immer mehr Firmen brauchen mehrere erlaubte Mac-Adressen auf einem PC -
für Virtualisierungen

dann hams ein problem beim design ihrer Netzwerke.

die virtualisierung bleibt da wo sie ist. entweder im datacenter oder fernab vom firmennetz. Entwickler sind generell in einem eingeschränkten netz wenn sie erhöhte rechte haben, etc.

alles nur eine frage des designs. und wenn der CSO der Bude mein, nein das muss alles aufgemacht werden und man holt sich den mist rein, na dann wird er das dementsprechend unterschreiben und den kopf hin halten. und spätestens wenn einer das explizit freigeben muss und die Rübe dafür hinhalten muss, ist schicht im Schacht.

die virtualisierung bleibt da wo sie ist. entweder im datacenter oder fernab
vom firmennetz.

Das mag für die bei Dir verwendeten Softwarelösungen gelten.

Beispiel, wo das Sinn machen könnte:
http://www.heise.de/ix/meldung/Sicherer-Browser-fuer-Privatanwender-und-Unternehmen-1241320.html
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Beispiel, wo das Sinn machen könnte:
http://www.heise.de/ix/meldung/Sicherer-Browser-fuer-Privatanwender-und-Unternehmen-1241320.html

aber warum sollt ich für die Box zwangsläufig eine gültige IP im eigenen LAN benötigen. Der Browser kann ja immer noch in einer "NAT" - Box laufen.

aber warum sollt ich für die Box zwangsläufig eine gültige IP im eigenen LAN
benötigen. Der Browser kann ja immer noch in einer "NAT" - Box laufen.

Ohne mir das jetzt im Detail durchgedacht zu haben und nur aus dem Bauch raus:

Wenn Du über NAT fährst, hast deinen Internettraffic im selben LAN wie dein Firmenlan.
Niemand könnte verhindern, dass aus der virtualisierten Lösung Zugriffe auf deine Produktionsserver stattfinden.

Wenn Du aber nicht über NAT fährst, kannst wahrscheinlich eine eigene IP-Range verwenden, wo es keine Verbindung zwischen deinem Firmenlan und dem Internetlan gibt.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Wenn Du über NAT fährst, hast deinen Internettraffic im selben LAN wie dein
Firmenlan.
Niemand könnte verhindern, dass aus der virtualisierten Lösung Zugriffe auf
deine Produktionsserver stattfinden.

sollte am host bzw. in der jeweiligen vm Implementierung ja auch möglich sein, weil der host ja selbst auch eine ip aus dem NAT Bereich für den gast haben muss, da er ja als GW für den gast arbeitet.

Wenn Du aber nicht über NAT fährst, kannst wahrscheinlich eine eigene IP-Range
verwenden, wo es keine Verbindung zwischen deinem Firmenlan und dem
Internetlan gibt.

womit ich den switch port für den client aber auch "aufmachen" müsste.

sollte am host bzw. in der jeweiligen vm Implementierung ja auch möglich sein,
weil der host ja selbst auch eine ip aus dem NAT Bereich für den gast haben
muss, da er ja als GW für den gast arbeitet.

Eh. Und das ist ja genau das Problem: Durch NAT hast im Netzwerk keine saubere Trennung mehr zwischen Internet- und Produktionstraffic. Du könntest dann in deiner VM noch immer einen Drive-By-Download zum Opfer fallen, der gleich deine Firmenserver attackiert.

womit ich den switch port für den client aber auch "aufmachen" müsste.

Genau - du müsstest eine zweite Mac-Adresse am Switch erlauben - eben die von der VM.

Es ist eine Pest vs. Cholera-Entscheidung, das ist eh klar.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Ich werd das mal bei uns probieren ob das so klappt, wäre interessant.

"I am serious. And don't call me Shirley."

wenn cisco equipment vorhanden ist und an den Defaults nicht geschraubt wird, hast 60 sek. bis zum re-auth

Also ich geh mal davon aus das es nicht default ist und das unsere Kollegen sich da was größeres überlegt haben.

"I am serious. And don't call me Shirley."

gemäß: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/sw8021x.html

Users who fail authentication remain in the restricted VLAN until the next re-authentication attempt. A port in the restricted VLAN tries to re-authenticate at configured intervals (the default is 60 seconds).

Warum sollte es nicht gehen?
https://de.wikipedia.org/wiki/IEEE_802.1X#Mehrere_Endger.C3.A4te_pro_Anschluss
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Weil ein Kollege aus der Linuxtruppe mal einen Hub mitgebracht hat und sich da ans Netz klemmen wollte und das ging nicht.

Ich bin kein Netzwerktechniker, ich weiß nicht was die da zusätzlich implementiert haben.

"I am serious. And don't call me Shirley."

vielleicht ipsec.

das problem mit hubs beschreibt microsoft etwa hier im Jahre 2005

https://technet.microsoft.com/en-us/library/cc512611.aspx

aber wie gesagt bei default re-auth Interval 60 sec. oder wenns das noch weiter runtergeschraubt haben, ist die zeit für den Angriff sehr limitiert.

vielleicht ipsec.

Irgendso eine Software ist da auch mit im Spiel, bin leider nur ein AIX Admin und kenn die Netzwerksecurity nicht so genau, aber das mit dem Hub werd ich mal testen, was das kingt doch eher unangenehm.

"I am serious. And don't call me Shirley."

Morgen!

Also ich hatte da schon recht, grad mit unseren Netzwerkern gesprochen, prinzipiell stimmt das mit dem Up-Link, aber sobald in der ARP-Tabelle für den Port eine zweite MAC registriert wird, wird der Port disabled.

"I am serious. And don't call me Shirley."

prinzipiell stimmt das mit dem Up-Link, aber sobald in der ARP-Tabelle für den
Port eine zweite MAC registriert wird, wird der Port disabled.

Ja und wieso vergibst auf dem zweiten Gerät nicht dieselbe Mac wie auf dem ersten? Das hatten wir doch schon in dem Thread...
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Das geht mit den CISCO Geräten angeblich nicht ? So eine ARP-Inspection soll das verhindern, angeblich.
Noch dazu läuft so eine Software auf den Clients die den PC itself authentifiziert. Angeblich mit diesem "Package" kann man verhindern das sich Fremdgeräte ins Netz hängen bzw. Du eine valide DHCP-ADresse bekommst. (Das war jetzt eine Zusammenfassung von 10 Minuten unverständlichem Netzwerkblabla).

"I am serious. And don't call me Shirley."

dhcp wär ja Wurscht, wenn die ip statisch gesetzt wird. aber kann schon sein, dass bspw. mit dem nps von microsoft noch einige Schweinereien implementiert sind.

Also das kann ich leicht morgen testen und die IP vom Kollegen mal nehmen - ob das klappt.

"I am serious. And don't call me Shirley."

Und?

Hat es geklappt?
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Nein, der Port ging zwar nicht down, aber ich konnte aus dem VLAN ned raus, dürfte das dann nicht routen.

"I am serious. And don't call me Shirley."

Also mal ein guter Startpunkt um alle Rechner in dem VLAN anzugreifen... Insbesondere die Server :-D
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Insbesondere die Server

Wer in dem LAN, in dem er Clients hat, auch seine Serverstruktur hostet, gehört eh bestraft.

Edit: Aber da müsstest direkten Zugriff auf ein Gerät haben das ja bereits authentifiziert ist und daran wirds eher scheitern.

"I am serious. And don't call me Shirley."

25.02.2016, 16:52 Uhr - Editiert von A national Acrobat, alte Version: hier

Edit: Aber da müsstest direkten Zugriff auf ein Gerät haben das ja bereits
authentifiziert ist und daran wirds eher scheitern.

Wenn man es schafft, physisch an einen Port zu kommen (Gangdrucker? Besprechungsräume? ...) - ist das eher simpel.

----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Ich will da jetzt keine infinite-loop in der Diskussion starten, warum Du eben mit irgendeinem Gerät nicht rankommst, selbst mit gefakter MAC etc. haben wir ja schon besprochen.

"I am serious. And don't call me Shirley."

hiesse aber, dass der angriff mit hub prinzipiell funktionieren würde.

Da sich da der Spanning Tree ändern würde ebenso nicht.

"I am serious. And don't call me Shirley."

was soll ich am Spanning tree ändern. der switch port sieht von dem hub exakt die eine ip/mac Kombination. da wechselt doch nichts.

Es erkennt aber wieviele Geräte dazwischenhängen.
"I am serious. And don't call me Shirley."

du vergibst dem zweiten gerät die selbe mac Adresse wie dem authentifizierten.

im übrigen könntest sogar ein gerät am hub stellen, das per dementsprechenden rules die auth requests an das gerät weiterleitet, die das auch beherrscht und den erst vom traffic an dein gerät mit Schadsoftware.

was willst mit einem hub in einem geswitcheten Netzwerk? bei 802.x auth mit Zertifikaten, portsecurity und was weiss ich alles hängst du gar nix ins netz.

wenn dann noch applocker und emet + virenscanner am client sind und der Mitarbeiter keine lokalen admin rechte hat, ist da sehr schnell schicht im Schacht.

bei 802.x auth mit Zertifikaten, portsecurity und was weiss ich alles hängst
du gar nix ins netz.

Nochmal:

Angenommen, auf meinem Firmenrechner sind die 802.1x-Credentials - und der Switchport ist so konfiguriert, dass
- er nur nach erfolgreicher 802.1x-auth aufsperrt, und dass
- er nur die eine MAC-Adresse von meinem Firmenrechner durchlässt.

Dann brauch ich eben nur einen Hub dazwischenhängen.
Der Firmen-PC meldet sich mit seiner Mac-Adresse und den 802.1x-Credentials beim Switch... Der radiusd (oder was auch immer) sperrt dann den Port auf.

Danach ist der Port bis zum nächsten Reauth für die Mac-Adresse offen - und die kann ich inzwischen meinem Angriffslaptop vergeben, der auch am Hub hängt.

Solange Mac<->Ip-Zuordnungen dynamisch über ARP/RARP passieren, ist das bitter.
AFAIK gibt es kryptographische Extensions für ARP/RARP, die eine Lösung wären - nur ich kenne keinen, der das verwendet.
Ebenso gibt es die Möglichkeit, ARP/RARP auf den Clients zu unterbinden und mit statischen Arp-Einträgen zu arbeiten... Die Anzahl der Firmen, die ich kenne und das so fahren, kann ich aber an den Fingern einer Hand abzählen.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

soweit richtig alles.

deine zeit als Angreifer ist aber sehr limitiert. bei cisco ist gemäß http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/sw8021x.html das Default re auth Intervall bei 60 Sekunden.

Guter Punkt.

Aber seien wir doch ehrlich...

Wenn einer von uns 2 da was bauen würde, würde er den Angriffslappy zuerst mal mitsniffern lassen, wie oft die Reauthentication kommt.

Wenn der Lappy wüsste, dass das alle 60 Sekunden passiert - dann würde er halt immer direkt nach der Reauth den Firmenrechnerport am Hub downnehmen, 55 Sekunden hackeln und dann wieder den Firmenrechnerport am Hub freischalten und schweigen, bis die Reauth passierte.

Das Script wäre recht schnell gezimmert.

Wir haben im Beispiel 55 Sekunden zum Unsinn treiben alle 60 - also Elf Zwölftel der Zeit.

Wenn man noch davon ausgeht, dass wir wahrscheinlich zumindest 100MBit/s zur Verfügung haben - das reicht dicke für Shellcodes. Und wir brauchen ja nur 1x erfolgreich sein...

802.1x ist IMHO seeehr überbewertet. Die Kombination mit der port Security macht es besser - aber im Endeffekt ist es noch immer seeehr offen. Wenn da nicht weitere Mechanismen am Werk sind, ist es für Leute mit auch nur etwas Fachwissen kein Problem, voranzukommen. Distris wie Kali liefern einem ja gute Unterstützung und alle Tools gleich mit.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

eigentlich kommt noch eine dritte Komponente zum tragen. ipsec. dann wird es richtig haarig für den Angreifer

eigentlich kommt noch eine dritte Komponente zum tragen. ipsec. dann wird es
richtig haarig für den Angreifer

Wenn Du IPSEC-End-zu-End-Verschlüsselung im Firmenlan hast... DANN hast mal ordentlich an der Levelschraube nach oben gedreht - da bin ich mit Dir.

Wobei - ganz aktuell:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike

A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and IKE version 2 (v2) code of Cisco ASA Software could allow an unauthenticated, remote attacker to cause a reload of the affected system or to remotely execute code.

----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

20.02.2016, 19:37 Uhr - Editiert von kombipaket, alte Version: hier

wir haben keine cisco geräte. leider oder Gott sei dank.

wir haben keine cisco geräte. leider oder Gott sei dank.

Wollts keine Backups bei der NSA, oder wie kommt das?

och reicht schon das die Leute ganz oben mac's und iPhones und cloud haben wollen oder haben. ausserdem cisco als NG FW ganz vorne - na ich weiss nicht. ich hab noch immer Albträume wenn ich irgendwo einen cisco admin sehe, der den ganzen Fixup mist einschaltet.

Bin jetzt kein DNS-Profi, aber afaik gibts dort auch die Möglichkeit DNS-Requests an den primary-DNS forzuwarden. Also Du kannst Dir nicht sicher sein wo Du genau landest und das ist die Gefahr dahinter.

"I am serious. And don't call me Shirley."

ehm in der /etc/resolv.conf steht der DNS server wo die reise hingeht. wenn davor noch eine nette firewall bzw. router ist, dann geht die reise auch nur exakt an die dns server die da hinterlegt sind.

du kannst nur nicht bestimmen ob das ding bei der Auflösung sich an die Reihenfolge hält oder irgendeinen eingetragenen verwendet

ehm in der /etc/resolv.conf steht der DNS server wo die reise hingeht.

Was machst wenn die REise dich zu einem Forwarding-DNS bringt ? WEißt du zu 100% wie der DNS - Server eingestellt ist ?

"I am serious. And don't call me Shirley."

der client kommt nie direkt zu einem forwarding DNS. der client ist hinter einer FW und kann per DNS nur die AD Controller befragen. Die AD Controller können die DNS Server beim Provider befragen per forwarding. Alle anderen DNS Server im Internet sind durch die FW gesperrt. Zudem läuft auf der FW dann noch ein IPS.

Somit müsste als erstes in der kette erstmal einer die Provider DNS hacken. Dann kommt das IPS der FW in Spiel, dass eigentlich derart komische Pakete blocken sollte. Wir ja etwas mehr im Paket drinnen sein als ein normaler A Record oder was auch immer. Geht es da durch kommt es zu einem Windows DNS. Keine Ahnung wir der drauf reagiert und das überhaupt 1:1 zum Client durchschleift. Oder nur den legitimen Teil der Antwort Cached und weitergibt.

Anders sieht das sicherlich aus, wenn da ein Ubuntu Desktop Client irgendwo hinter einem Router hängt und Gott und die Welt mit DNS befragen kann.

Du gehst immer nur von einem Angriff von außen aus...

Wie oft kontrollieren denn Mitarbeiter, ob
- ihr PC wirklich direkt an einer NW-Dose hängt?
- Die Dose in der Wand wirklich direkt zu einem Patch-Panel führt?
- ...

Oder:
Wer überprüft den Administrator des AD, ob er nicht genau die DNS-Einträge einfügt, die ihn einen Linux-Rechner (Server?) übernehmen lassen?

Oder:
Wer überprüft die Netzwerk-Administratoren, ob die da nicht doch mal einen anderen DNS-Server in den Weg hängen?

OderOderOder...

Bei kleinen Firmen mit einer kleinen IT-Staffel - hast meist eh weniger Sicherheitsmechanismen am Werk - da sollte ein DNS Cache Poisoning/... leichter gehen.

Bei großen Firmen, wo AD/Server/PC/Anwendungen/... in einzelne, mehr oder minder unabhängige Teams aufgesplittet ist - wird jedes Team nun die Möglichkeit haben, Server zu übernehmen und Unsinn anzustellen.

Wer über bleibt, ist der SERVER_Admin... Wenn er nicht patcht.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

alles sicherlich mögliche szenarien, die aber alle nur von privilegierten Personen ausgeführt werden kann. und da stellt sich dann die frage ob der fehlende patch das Risiko ist oder der Mitarbeiter, wenn ich denen nicht vertrauen kann.

Wer über bleibt, ist der SERVER_Admin... Wenn er nicht patcht.

der admin kann nur nach Anweisung patchen bzw. nach einem regelwerk im unternehmen wenn man es genau nimmt. dafür gibt es ja die wartungs- bzw. patchfenster oder eben die Anweisung von oben das gleich zu tun. wenn er dann nicht folgt, dann bleibt er übrig.

alles sicherlich mögliche szenarien, die aber alle nur von privilegierten
Personen ausgeführt werden kann

Bei Großfirmen - ja.

Bei Kleinfirmen - wird es wahrscheinlich jeder können (weil i.d.R. keine enterprise-Security mit IDS/IPS/...). (daher gilt der Rest des Posts nur für Großfirmen).

ob der fehlende patch das Risiko ist oder der Mitarbeiter, wenn ich denen
nicht vertrauen kann.

Das Risiko der Mitarbeiter hast sowieso... Das Risiko mit dem fehlenden Patch kommt nur dazu.

BTW, wir wollen auch nicht auf Leute wie Fly vergessen... Leute, die bezahlt werden, um mit ihren Skills als Social Engineer privilegierte Personen zu motivieren, die Lücken für sie aufzumachen, die sie brauchen (so stelle ich mir zumindest ungefähr Flys Job vor

)

der admin kann nur nach Anweisung patchen bzw. nach einem regelwerk im
unternehmen wenn man es genau nimmt

Joa eh... Da war ich unscharf in der Formulierung, stimmt.
Der -Serververantwortliche- ist in der Pflicht...

wartungs- bzw. patchfenster

Wenn wir von einer Großfirma ausgehen, kann man immer ein paar Server aus den jeweiligen Clustern jederzeit ohne Serviceunterbrechung töten kann.... Und damit auch upgraden.

So oder so:
Je nach Firmenstruktur wird der Entscheidungsträger rasch ein Upgrade der libc testen [lassen] müssen - und dann auf den Produktionsservern durchführen [lassen].
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

So oder so:
Je nach Firmenstruktur wird der Entscheidungsträger rasch ein Upgrade der libc
testen [lassen] müssen - und dann auf den Produktionsservern durchführen
[lassen].

bei uns sind alle gut 60 linux server seit spätestens 18.2. gepatched. dennoch wurde das Risiko in Abstimmung mit CSO und den Gegebenheiten im unternehmen nur mit mittel bewertet. die Lücke Ansich ohne die Vorort Gegebenheiten hätten wir ansonsten mit schwer bewertet.daher das patching auch über mehrere tage verteilt.

bei uns sind alle gut 60 linux server seit spätestens 18.2. gepatched.

Schöne Reaktionszeit... Aber wahrscheinlich wenig Zeit zum Testen gehabt...

daher das patching auch über mehrere tage verteilt.

Ich gehe mal davon aus, dass das bedeutet, dass ihr die "unwichtigsten" Systeme zuerst gepatcht habt... Oder eben Clusterelemente.

Ich bin aber eh bei Dir - je nach Firmeninfrastruktur kann die Lücke auch nur verschwindend geringes Risiko bedeuten.
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Schöne Reaktionszeit... Aber wahrscheinlich wenig Zeit zum Testen gehabt...

ja korrekt… da blieb nicht viel. wobei man sich bei virtualisierung auch kurz mal selbst helfen kann und im worst case einfach mal mit snapshots zum "testen" arbeitet.

Ich gehe mal davon aus, dass das bedeutet, dass ihr die "unwichtigsten"
Systeme zuerst gepatcht habt... Oder eben Clusterelemente.

japp. da gibt es generell einen plan der Reihenfolge wann im falle eines Patches welches system zu patchen wäre. egal ob jetzt an einem tag oder über mehrere tage verteilt.

Ich bin aber eh bei Dir - je nach Firmeninfrastruktur kann die Lücke auch nur
verschwindend geringes Risiko bedeuten.

das seh ich auch so. was mich vielfach bei sowas nervt sind so online Medien für die alles gleich der Weltuntergang ist

das seh ich auch so. was mich vielfach bei sowas nervt sind so online Medien
für die alles gleich der Weltuntergang ist

Grundsätzlich ist es aber schon seeehr böse, wenn es einen Exploit in der glibc gibt... Das ist fast gleich schlimm, wie wenn es einen Exploit im Kernel gibt.

Ausserdem hat die Opensource-Community eh super reagiert - Bugfixes für alle Distris sind AFAIK schon da.
Blöd nur wieder mit den ganzen HW-Trümmern, in denen auch eine libc drin ist - beispielsweise WLAN-RTR, ...
----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

ja gilbc, kernel, openssl is immer ziemlich mies.

patches waren wie immer zeitnah da. insofern ok.

richtig fies wird es aber, und das ist mir jetzt schon mehrfach untergekommen, wenn die tollen Medien von Sachen schreiben, die eigentlich längst gefixed sind.

heise fällt da manchmal bei vmware ungut auf. früher haben sie auch gerne mal von ie Problemen geschrieben, die aber in irgendeiner uralt version von IE Gültigkeit hatten oder bei fehlendem service pack bzw. die durch andere Patches längst eliminiert waren.

früher haben sie auch gerne mal von ie Problemen geschrieben, die aber in
irgendeiner uralt version von IE Gültigkeit hatten

Völlig oT: Was ist denn eine uraltversion?

Ich habe gerade bei mir gecheckt... Die aktuellste Version vom IE, die ich auf meinen Rechnern habe, ist die 6.0.2900

Und das trotz SP3 bei XP....

Aber dein Punkt war eh ein anderer... Mir ist jedenfalls lieber, sie warnen 1x zu oft als 1x zu selten .

heise fällt da manchmal bei vmware ungut auf

Vielleicht hatte die VMware ja "zuwenig" Inserate geschalten?

20.02.2016, 21:11 Uhr - Editiert von kombipaket, alte Version: hier

Völlig oT: Was ist denn eine uraltversion?

ich habe es noch aus Zeiten von windows 2000 in Erinnerung, wo über sicherheitsproblemen in IE 5 berichtet wurde, wo es längst IE 6 für Windows 2000 gab und dort das dann gefixed war. oder noch besser über lücken von IE 6 schreiben wo IE 6 Sp1 längst released war und gegen die Lücken immun war.

Also -rasch- updaten!

Und rebooten - auch wenns kein Kernelupdate ist .

"I am serious. And don't call me Shirley."

Und rebooten - auch wenns kein Kernelupdate ist .

sollt man in der linux weit generell bei jedem update, auch wenn das die junkies nicht hören wollen. selbst bei dynamischen libs weiss in Wahrheit keiner ob da wirklich bei einem update alles beim preloaden dann richtig von statten geht oder doch noch irgendwo alter code im memory rumschwirrt

Jo lieber ein sicheres System als hohe Uptime, stimm ich mit Dir überein.

"I am serious. And don't call me Shirley."

VMWare ESXi auch betroffen.

gibt mittlerweile Patches von VMware für 5.5

Danke für die Info!

----------------------------------------------------------------------------------

Wenn man sich wundert, warum ich die Aussagen mancher Deppen komplett ignoriere...
... diese Armlöcher sind geplonkt - die lese ich nicht einmal.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung