Příspěvky

Ano, dělají se chazené dveře racku, dělají se malé klim. jednotky na rack a dělají se i malé jednotky dovnitři racku. Use Google :-)

a mate s tym skusenost, mate to niekde nasadene?

Ty chlazené dveře se používají tam, kde nedokážeš rack uchladit studenou uličkou. Osobně znám dvě instalace, kde se takhle chladí skoro 15kW/rack. Dělají se buďto s vodním chlazením (potřebuješ chiller) nebo s vnější jednotkou. Každopádně je kolem toho spousta trubek :-(
Ty krabičky na/do racku se dělají buďto "vše v jednom" - potom Ti budou ohřívat tu chodbu a stejně se budeš nejak muset postarat o kondezát, nebo zase vodní nebo s vnější jednotkou - spousta trubek, nic hezkýho, o bezpečnosti ani nemluvím.
No a společnou nevýhodou je, že se to dá těžko nějak zdvojit. Takže když se to rozbije, máš vážnej problém.
Osobně si myslím, že nejjednodušší řešení je do střechy toho racku dát takovou tu věc se čtyřma větrákama. A chodbu chladit nějakou blblou kancelářskou klimkou.

Ano, dělají se chazené dveře racku, dělají se malé klim. jednotky na rack a dělají se i malé jednotky dovnitři racku. Use Google :-)

Tak jo, tak to myslím můžeme uzavřít s tím, že PermitRootLogin No je lepší než drátem do voka

Rezavým určitě.

Administrátorská hesla mají tendenci povalovat se v různých obálkách v různých podivných trezorech

No to je jednak samo o sobě daleko prekérnější než povolený root login, jednak pokud bude potřeba přihlásit se přes jiný než rootovský účet, tak na tom papírku ten login nejspíš bude napsaný taky, ne?

Spíš ne, předpokládá se, že se v nejhorším dostaneš ke konzoli.

Pokud to adminuje víc lidí a všichni znají rootovo heslo ...

...tak nepomůže ani mantra Na Nachma Nachman Meuman http://goo.gl/aTUZB  , natož PermitRootLogin Protože tak jako tak se všichni nějak k rootovi musí umět dostat, takže je jedno, který z těch hesel leakne, nebo jestli leakne jedno heslo, který používají všichni.

Ne tak docela:

• V logu bude, že se přihlásil Franta Admin a ne hromadný root
• Někdy je jednodušší zrušit jeden účet, než distribuovat nové rootovo heslo (třeba když Frantu Admina vyrazí)

Pokud je přihlášení roota povolené, zná případný útočník polovinu z toho, co potřebuje (už. jméno), chybí jen heslo

To neni tak uplne pravda. Jednak login neni "polovina", protoze heslo by melo jit vyrazne hur uhodnout, jednak login je vicemene verejny udaj (kde jsou ty casy, kdy mail uzivatel@x znamenal "uzivatel na stroji x").

No nevím, já mám v logu "Authentication failure for user root", for user test, for user games, ale for <myuser> nikdy.

Heslo může "leaknout" - buďto ho někdo uhodne, nebo získá např. sociálním inženýrstvím

Moc mě nenapadá, jak by mohlo leaknout heslo bez toho, aby zaroven leaknul login

• Administrátorská hesla mají tendenci povalovat se v různých obálkách v různých podivných trezorech
• Pokud to adminuje víc lidí a všichni znají rootovo heslo ...

V SSHd může být chyba (viz např. nedávný problém s generováním klíčů na Debianu)

...napriklad takova, ze PermitRootLogin bude ignorovat Tohle je poměrně nesmyslný argument, zvlášť když sshd obvykle běží pod rootem...

... nebo taková, že projde autentizace, i když by neměla a zarazí se to až na PermitRootLogin ...
[/list]

Prosím poučte mě teda mam ssh hesslo na root jena ja, pak proftpd kde maj přístup jen určití lidé, do určitych složek, je v v tom problém?

V zásádě v tom problém není. Jen pokud jsou ty FTP účty klasické "shellové", musíš si uvědomit, že se ti uživatelé můžou přihlásit i přes SSH a pak zkoušet nějaké "nasty tricks" (lokální exploity na eskalaci práv a tak). Já bych to řešil tak, že bych ssh povolil jen pro určitou skupinu uživatelů (AllowGroups v sshd_config), případně by ti uživatelé pro ftp mohli být "virtuální".
Otázkou je, jestli by nestálo za to nastavit pro přístup přes FTP chroot, tak aby "viděli" jen ty svoje složky.
Jo - jméno a heslo se při přístupu přes FTP přenáší nešifrovaně - takže je otázka, jestli nezvážit spíš scp/sftp případně FTP via TLS.
No a já bych tedy zakázal přihlášení roota přes ssh, udělal bych si tam normální účet a administroval to přes sudo.

Na rozdíl od změny portu je zakázání roota celkem standardní nastavení. Rozbije spoustu věcí = heslo je napsané v nějakých skriptech? OOPS ...

Co prosím? S povoleným rootem se normálně klíčem k přihlásím jako root a udělám co potřebuju. Se zakázaným rootem se přihlásím jako uživatel, musím přes to SSH spustit su/sudo, tomu nějak předat heslo, které *musí být někde uložené* a až přes to spustit potřebný skript. Nastavit "PermitRootLogin" na "no" je naprostá kravina, která reálnou bezpečnost systému vůbec nezvýší.

No konečně mi to někdo pořádně vysvětlil ... Teď abych pověsil klávesnici na hřebík a zalezl do studené uličky ... Sudo se dá nastavit tak, aby heslo nechtělo. Pro PermitRootLogin No hovoří:

• Pokud je přihlášení roota povolené, zná případný útočník polovinu z toho, co potřebuje (už. jméno), chybí jen heslo
• Heslo může "leaknout" - buďto ho někdo uhodne, nebo získá např. sociálním inženýrstvím
• V SSHd může být chyba (viz např. nedávný problém s generováním klíčů na Debianu)
• Chrání Tě to před sebou samým (pokud si do profilu nedáš sudo su - :-) )

No a kromě toho:

• Praví se to ve všech hardening guidech
• Chtějí to všichni bezpečáci a auditoři

Změna portu moc nepomáhá, to už lepší je riskovat několik neúspěšných pokusů o zadání hesla na ssh na standardním portu, než nechat volný průběh na portu vyšším.

To je divný, mně změna portu pomohla dost. Je to téměř nepoužívaný čtyřčíselný port.

Měli bychom se držet standardů ... Pokud máš to SSH jen pro sebe, tak OK, ale pokud tam máš i jiné uživatele (třeba taky SCP/SFTP pro aktualizaci webů), dostáváš se do problémů. Stejně Ti to pomůže maximálně od script-kiddies, pokud se někdo bude vážně snažit, tohle ho fakt nezastaví.

• Zakaž přihlášení roota přes ssh (PermitRootLogin = no v sshd_config) - tak se Ti tam nepřihlásí ani v případě prolomení hesla

Už psal, že heslo má dobré (a pokud by měl slabé, má řešit slabé heslo a ne nějaké nesmyslné obfuskace). V čem PermitRootLogin No pomůže? Akorát to rozbije spoustu věcí typu zálohování.

Na rozdíl od změny portu je zakázání roota celkem standardní nastavení. Rozbije spoustu věcí = heslo je napsané v nějakých skriptech? OOPS ...

Prepacte ale chcem poradit, dovod preco to nerobim tak ako niekto pise nemusite riesit. Ak nechcete poradit nemusite, ale prosim vas nepiste tu blbosti, preco to nerobim tak a tak. Keby tam bol filesystem ako ZFS stavalo by sa mi to iste ako sa mi stava pri ext4? nie...krista ved uz ma konecne pochopte...

• zakaž automatický mount toho filesystému (noauto ve fstabu)
• zakaž automatický start té Samby
• do rc.local si dej skript, který udělá fsck (bez dotazů) a pak startne tu Sambu

V tomhle postupu nevidím žádný problém, jen musíš nějak zajistit, aby Ti někdo jiný nemountnul ten FS dřív ...

V době SPF Ti ti nebude fungovat úplně spolehlivě.

• Zakaž přihlášení roota přes ssh (PermitRootLogin = no v sshd_config) - tak se Ti tam nepřihlásí ani v případě prolomení hesla
• Pokud to jde, povol na firewallu port 22 jenom z vyjmenovaných adres
• Pokud to nejde (dynamické IP a podobně), popřemýšlej např. o OpenVPN
• Pokud Tě nějaká IP moc štve, blokni ji ručně. Jakékoliv automatické blokování je IMHO asking for troubles