"Ha én tudok hamarabb a hibáról, mint hogy kihasználják, és tudok érdembe tenni ellene"
Nagyon nagy százalékban előbb jön a frissítés, mint ahogy publikálják a sebezhetőséget... sokkal fontosabb akár a napi automatikus frissítés az automatizált regressziós és validációs tesztekkel, mint az, hogy itt a piros-hol a piros játékot játssz a szolgáltatások portjával...
"A speciális beállításokkal igazad lehet, de egy 22 ssh portot nem fogok elfelejteni átrakni, ellenőrizni, és elég hamar ki is fog derülni, ha mégis."
Nem is erről van szó... átírod például az sshd_config fájlban a portot, aztán jön a frissítés, odateszi a sshd_config.rpmnew fájlt és kézzel kell összefésülnöd... jó esetben lemaradsz valami új feature-ről, rossz esetben nyitva marad egy biztonsági rés és/vagy nem fog működni egy régi feature. Ez üzemeltetési kockázat.
Nem vagyok ellene ezeknek a megoldásoknak, de tegyétek mellé a plusz adminisztrációt, a plusz dokumentációs kényszert, a plusz betanítási köröket, a plusz kockázatokat és a többi költségelemet és nézzétek meg, hogy arányban áll-e a támadással és annak sikerességével ez a védekezés.
Nem az SSH-n keresztül fognak megtörni, hanem egy nem kellő gyakorisággal frissített komponensen keresztül jönnek be vagy egy egyedi fejlesztésű kódbázison találnak rést.
És ismét hangsúlyozom: tegye fel a kezét, aki automatikusan frissít és az automatizált regressziós és validációs tesztek eredménye alapján automatikusan engedélyezi az adott frissítést egy kiadási szinttel feljebb; tegye fel a kezét, aki automatikusan újratelepíti a szervereit egy-két havonta; tegye fel a kezét, aki automatikusan újraindítja a szervereit pár naponta. A "nem nyúlok hozzá, mert működik" szemlélet nagyon nagy üzemeltetési kockázatot rejt, mert tényleg nem fog működni, amikor egy-másfél-két évvel később frissíteni kell vagy újra kell indítani...