Vlákno názorů ke zprávičce Zyxel má pevně zabudované přihlašovací údaje ve 100 000 zařízeních od cziss - Tak to je síla, myslel jsem, že je...

Tak to je síla, myslel jsem, že je Zyxel dobrá značka.... Ten účet je tam chybou nebo záměrně?

Z informací na stránkách Zyxel: "The account was designed to deliver automatic firmware updates to connected access points through FTP."
Takže tam byl záměrně.

Zyxel u mě skončil.

Ha, to zní úplně jak nějaká marketingová pravda :)

No to gratuluji k rozhodnuti. A ted dalsi pravda. ZyNOS se pouziva i mimo zarizeni zyxelu.
Zyxel pronajima nebo pronajimal licence a devkit tretim stranam takze jsem zvedav nakolik bude ta kompilace OS na jinych zarizenich natolik jina ze tam ten ucet nebude.
Zyxel ma dlouhodobe bordel v security a LTS podpore zarizeni. Ani kdyz si koupite drazsi zarizeni nebo nedejboze DSLAM (pred cimz varuji, je lepsi vzit nejakou proverenou cinu).
Na tom je nejhorsi to ze ta zarizeni jsou svymi schopnostmi celkem dobre a stabilni produkty - vyjma tech dslamu. Dost veci se da nakonfigurovat. Jen kdyby ta podpora byla. Resil jsem i CPE provisioning a taky to byla bida kdyz nenahrajete zakosum ani novy firmware protoze je tam buga jak vysusena bazina na jizni morave...

8. 1. 2021, 16:02 editováno autorem komentáře

Udajne sevjedna o konto pro automaticky update firmware v AP. Asi pouzivaji stejny zaklad pro controllery i v dalsim firmware a dostalo se to i do jinych zarizeni. To, ze ten ucet funguje i jinak a ma vysoka prava je dost pruser.

To mi přijde jako diletantsví, jakkoliv mohl být původní záměr myšlen v dobrém (ehm). U takového řešení je jen otázkou času, kdy ten účet/heslo někdo objeví a pak z toho bude kolosální průser. Když automatický update FW přímo od výrobce, tak jedině ze strany zařízení a rozhodně ne naopak, a pokud se používá controller, tak bych to řešil za pomoci klíčů nastavených explicitně správcem sítě.

S updatem ze strany zařízení byste se daleko nedostal na setupu, který má víc než jeden aktivní prvek a má nějak stabilně a předvídatelně fungovat. Nicméně tenhle způsob implementace je dost nešťastný.

Tak jasně, pak bych to ale řešil tím kontrolerem a ručně nastavenými klíči. Možná by se dalo polemizovat o tom, jestli by ještě bylo v pořádku tam ve výchozím nastavení mít nějaký výchozí účet pro hromadnou vzdálenou konfiguraci. Pokud by se to vhodně implementovalo, tak asi proč ne, ale podmínil bych to třeba tím, že dokud se ten účet nepřekonfiguruje, tak nepůjde zařízení dál konfigurovat, jinak by to byla zase jen bezpečnostní díra.

Nahodou - je to spis systemove selhani Linuxu.

Jsem pred tydnem instaloval pure-ftpd, protoze APC UPS dokaze nahravat logy o provozu na FTP. Vse nastavim - a nejede to. Az pote, co jsem zmenil shell, z /bin/false, na /bin/bash, se dalo prihlasit na FTP.

Takze se ptam - jak udelat ucet, vuci kteremu pujde unix-auth (passwd/shadow), ale nepujde se tam prihlasit skrze SSH ? Jedu na Linuxu 13+ let, ale rizeni tech zakladnich prav ohledne prihlasovani a autentifikaci sluzeb to ma dost marnou (ve stylu - vsechno anebo nic).

Jedním z "old times" řešení, které je k dispozici i na zařízeních s omezeným softwarovým vybavením, nalinkovat /bin/false třeba na /usr/local/bin/a­llow-ftp a /usr/local/bin/a­llow-ftp přidat do /etc/shells. FTP pak půjde, ale shell uživatel nezíská.

Je fakt, že tenhle problém asi nemá úplně pěkné řešení. Co jako shell v takovém případě nastavit třeba /bin/cat? Domnívám se, že by to bylo z hlediska bezpečnosti podstatně lepší než bash (pokud by náhodou heslo k účtu padlo do nesprávných rukou), ale i tak by mě celkem zajímalo, jestli by tam byla nějaká možnost zneužití (ponechme stranou potenciální zneužitelnost typu buffer overflow přímo v té binárce).

EDIT: nebo existuje něco jako nologin, ale tak, aby místo skončení nenulou hned po spuštění třeba jen čekal v nekonečné smyčce?

7. 1. 2021, 14:51 editováno autorem komentáře

Jak to proboha souvisí?:-)

Ten problém s nevalidním shellem se dá řešit třeba takto:

echo "/bin/false" >> /etc/shells

A nebo použít proftpd, který funkční shell nevyžaduje, resp. jde tak nastavit.

u ssh používáme vždy nastavení allowUsers, kde se vyjmenují uživatelé, kteří mohou se na ssh přihlásit. Je k dispozici i nastavení DenyUsers, DenyGroups, AllowGroups...

On má někdo povolené přihlášení heslem po SSH?