poradna.net a short_open_tag
Na uvodní stránce poradna.net se mi na začátku zobrazuje níže uvedený PHP kód.
Někdo tam dělal nějaké úpravy a zapomněl na to, že máte v PHP short_open_tag zakázaný případně ho někdo zakázal a na stránce poradna.net chybí několikrát za hranatou závorkou a otazníkem php: <?php
Já si říkal, že si toho někdo všimne, ale když už to tam vidím minimálně několik hodin a nic se neděje... tak si to opravte.
<?
$langs = array("sk" => 0, "cs" => 0);
foreach (explode(",", $_SERVER["HTTP_ACCEPT_LANGUAGE"]) as $lang) {
$pattern = '/^(?P<primarytag>[a-zA-Z]{2,8})(?:-(?P<subtag>[a-zA-Z]{2,8}))?(?:(?:;q=)(?P<quantifier>\d\.\d))?$/';
$splits = array();
if (preg_match($pattern, $lang, $splits)) {
$primarytag = isset($splits["primarytag"]) ? $splits["primarytag"] : "";
$quantifier = isset($splits["quantifier"]) ? (float)$splits["quantifier"] : 1;
$langs[$primarytag] = max($quantifier, isset($langs[$primarytag]) ? $langs[$primarytag] : 0);
}
}
$lang = $langs["sk"] > $langs["cs"] ? "sk" : "cs";
$domains = array(
"pc" => array(
"url" => "http://pc.poradna.net/",
"sk" => array(
"title" => "Počítače",
"description" => "V tejto poradni nájdete rady týkajúce sa počítačov, hardvéru a softvéru."
),
"cs" => array(
"title" => "Počítače",
"description" => "Dotazy týkající sa počítačů, počítačových komponent a programů."
),
),
"tera" => array(
"url" => "http://tera.poradna.net/",
"sk" => array(
"title" => "Teráristika",
"description" => "Poradňa pre všetkých teráristov, herpetológov a ľudí so záujmom nielen o plaziu problematiku."
),
"cs" => array(
"title" => "Teraristika",
"description" => "Poradna pro všechny teraristy, herpetology a lidi se zájmem nejen o plazí problematiku."
),
),
"akva" => array(
"url" => "http://akva.poradna.net/",
"sk" => array(
"title" => "Akvaristika",
"description" => "Miesto pre virtuálne stretnutie akvaristov a všetkých, ktorých akvaristika zaujíma."
),
"cs" => array(
"title" => "Akvaristika",
"description" => "Místo pro virtuální setkání akvaristů a všech, které akvaristika zajímá."
),
),
"kutil" => array(
"url" => "http://kutilska.poradna.net/",
"sk" => array(
"title" => "Kutilstvo",
"description" => "Veľa šikovných kutilov Vám poradí nielen pri stavbe domu a rekonštrukcii bytu."
),
"cs" => array(
"title" => "Kutilství",
"description" => "Hodně šikovných kutilů Vám poradí nejenom při stavbě domu a rekonstrukci bytu."
),
),
"hry" => array(
"url" => "http://hry.poradna.net/",
"sk" => array(
"title" => "Hry",
"description" => "Tu diskutujeme o hrách počítačových i ostatných, hru kráľovskú nevynímajúc."
),
"cs" => array(
"title" => "Hry",
"description" => "Zde probírame hry počítačové i ostatní, hru královskou nevyjímaje."
),
),
"pravo" => array(
"url" => "http://pravo.poradna.net/",
"sk" => array(
"title" => "Právo",
"description" => "Na tomto fóre sú pripravení riešiť vaše právne problémy odborníci z profesionálnych právnych kancelárií."
),
"cs" => array(
"title" => "Právo",
"description" => " Na tomto fóre sú pripravení riešiť vaše právne problémy odborníci z profesionálnych právnych kancelárií."
),
),
"ekonomicka" => array(
"url" => "http://ekonomicka.poradna.net/",
"sk" => array(
"title" => "Ekonomická",
"description" => "Máte nejakú otázku ohľadom financií? Trápia vás splátky požičky, prípadne neviete vyjsť s peniazmi? Chcete podnikať a neviete ako na to? Máte problémy s daňami? Spýtajte sa na ekonomickej poradni."
),
"cs" => array(
"title" => "Ekonomická",
"description" => " Máte nějakou otázku ohledně financí? Trápí vás splátky půjček, případně se vám nedaří vyjít s penězi? Chcete podnikat a nevíte jak na to? Máte problémy s daněmi?
Zeptejte se na ekonomické poradně."
),
),
"zivot" => array(
"url" => "http://zivot.poradna.net/",
"sk" => array(
"title" => "Život",
"description" => "Máte nejaký problém vo svojom živote? Trápi vás nadváha, či neviete variť, cestujete niekam a potrebujete sa niečo spýtať? Ste na správnom mieste. Život je príliš krátky na to, aby ste strácali čas učením sa na vlastných chybách, skúste sa poučiť zo skúsenosti našich používateľov. Vitajte na zivot.poradna.net!"
),
"cs" => array(
"title" => "Život",
"description" => "Máte nějaký problém v životě? Trápí vás nadváha, neumíte vařit, cestujete někam a potřebujete se na něco zeptat? Potom jste zde správně. Život je příliš krátký na to, abyste ztráceli čas učením se z vlastních chyb - zkuste se poučit ze zkušeností našich návštěvníků. Vítejte na zivot.poradna.net!"
),
),
);
?>
Mně to nedělá.
To je divné, mně to dělá v různých zařízeních v různých prohlížích všude.
Takto to u mě vypadá:
Tak to vypada hodne divne. U mna vsetko vyzera uplne normalne.
Zeby preto, ze som to 20min pred tvojim prispevkom opravil?
Njn, každý dobrý skutek, čin nebo úmysl musí být po zásluze potrestán, ať uděláš cokoliv... Platí to snad ve všech oblastech
Minuly tyzden som upgradoval cely server, takze je tam novsi apache aj php a tak sa prejavili chyby, ktore starsie verzie prehliadali.
Opravene.
Upgradovat byste toho měli víc.
Nevidím přesně, jestli je to před serverem, kde je poradna (vidím Debian 10, ale možná jedete na 11), nebo jestli jde přímo o to kde poradnu je, ale kupříkladu ten OpenSSH (OpenSSH 7.9p1 → CVE-2023-38408 9.8) nebo zastaralý Apache/2.4.59 ktery snad nepovazujes za bezpecny a je vytstaven jak na 80/tcp tak i na 443/tcp.
U základního testu tam máte 4–6 vážných a zneužitelných CVE chyb, zbytečně otevřené a vystavené porty.
Aspoň u toho IP*:22 si dejte ověření SSH klíčem (stačí jen pozměnit nebo přidat do configu: PubkeyAuthentication yes) a ne heslem, vypnou ident na portu 53/tcp open domain ISC BIND 9.11.5 IP**:113 viz CVE-2026-3592 -
Uživatele lze odhadnout poměrně snadno tipnul bych, že jméno z jednoho ADMIN by pasovalo (k tomu je ve vypisu nápoved :|_auth-owners: root) a heslo lze prolomit pomocí brute‑force, spraying nebo dictionary attacku, který jde stáhnout nebo vytvořit.
(Nastavte si alespoň: po 3× nesprávném pokusu o přihlášení přes SSH automatický BAN IP).
I když DNS prozrazuje verzi BIND (pres prikaz : dig @92.xxx.xxx.xx version.bind CHAOS TXT +short), zbytek je OK
Poradna bezala cele roky na Debian 8.
A nikomu to nevadilo, nikto to neriesil.
Trosku nechapem preco zrazu to pozdvihnutie okolo toho prave v dobe, ked som sa konecne dokopal k tomu, ze s tym idem nieco robit a verejne zverejnil, ze server upgradujem (kvoli spatne vazbe).
Napriek mnohym CVE som celkom presvedceny, ze hacknuta poradna nebola, nie je tam ziaden podozrivy pohyb, traffic, nic co by naznacovalo cudzi element v systeme. Ak sa to niekomu podarilo nevieme o tom je sikovny, pripustam aj tuto moznost;o).
Teraz je poradna na Debian10, mam spravenu uz kontrolu na prechod na 11, ktora sa spravi asi buduci tyzden. Nasledne prejdeme na Debian12, kde je php v8 a to bude najvacsie vyzva, pretoze tam sa uz udialo kopec zmien.
Problem upgradu je, ze poradna obsahuje 10k riadkov kodu, ktory nie je moj a konkretne najvacsie problemy sposobuju zmeny v php....vid toto vlakno.
Ten kod som nepisal ja, neviem presne kde co je a nie som profesionalny programator a naozaj mi to trva mnoho hodin skontrolovat a uistit sa, ci pripadny upgrade nieco nedomrvi...a vidis aj tak som si nevsimol uvodnu stranku.
root ma zakazany pristup cez ssh, momentalne kvoli upgradu povoleny cez ssh kluc, takze s bruteforcom neuspejes. Heslo na roota splnalo poziadavky na komplexicitu uz roky dozadu, takze buiteforce nebude uspesny ani keby si server hackoval lokalne s max rychlostou.
Moje heslo splna tiez a keby si ho aj prelomil stale si len na servri so standardnymi user opravneniami, nie som clen root grupy a potrebujes vediet root heslo na spustenie su(do).
K tebou uvadzanej chybe bindu...je fajn, ze si najdes, ze mame na servri sluzbu, ktora ma vo verzii nejake CVE...ale treba povedat aj be, ake podmienky treba splnit aby bola dana sluzba napadnutelna....a tie my nesplname, takze poznamky o tomto CVE su irelevantne.
OpenSSH je uz uplne mimo, uvadzas verziu 10u3, my mame momentalne verziu u4, kde je uz oprava zahrnuta. Ak keby aj na zneuzitie musim mat JA zranitelneho ssh agenta, pripojit sa kompromitovany ssh sever a agent musi pouzit forwarding, ktory je standardne vypnuty. Nic z toho nesplnam.
Pozri ak mas pocit, ze sa dokazes do poradne dostat nech sa paci, som ochotny za oznamenie a prevedenie skutocnej bezpecnostnej diery aj zaplatit a podakovat, v opacnom pripade len strielate do tmy slepymi nabojmi.
Mně to vadilo a řešil jsem to
https://pc.poradna.net/questions/3308774-proc-poradna-jede-na-starem-softwaru
A bude aj Debian 13? Až v Debianu 13 je kvantově odolné šifrování
Když to hodíš AI tak ti to opraví nebo když to hodíš na github, tak ti to lidi tipuju opraví.
Jsem naprostý PHP amatér a 10k řádků mi teda nepřijde moc.
Ale short_open_tag nebyl vůbec žádný problém, jednalo se pouze o nastavení PHP. S short_open_tag On v poho běží i PHP 8.5, normálně používám short_open_tag On, mám On lokálně i na freehostingu a není problém. A klidně používám i "<?".
Aby si sa z toho kvantovo odolneho sifrovania nepototo... Toto je poradna, nie iBanking, alebo eshop. Tu je to zbytocny kanon na vrabce. Alebo aj do Tesca chodis nakladnou Tatrovkou na nakup?
No a co, že je to poradna? Já šifruju kvantově odolným šifrováním i mezi svým lokálním serverem a prohlížečem
Každej to bere z jiného úhlu pohledu, já to beru jako indicii toho, že web je schopný aktualizovat software a záleží mu na aktuálních a podporovaných verzích. Není to žádný kanón na vrabce, i freehosting na Endoře mi jede na mlkem768x25519. Je to pro ně problém zajistit takovou komunikaci i na freehostingu? Není.
Kdyby byl mlkem768x25519 nějaký kanón na vrabce, tak by nebyl defaultní hodnota pro komunikaci v OpenSSL:
https://github.com/openssl/openssl/blob/master/ssl/t1_lib.c
je to pod TLS_DEFAULT_GROUP_LIST
X25519MLKEM768 je na prvním místě, tady tu hodnotu používají defaultně i webové servery s OpenSSL 3.5 a novějším a jelikož to umí i aktuální prohlížeče, tak se takto normálně běžně dnes šifruje.
Já bych to od roku 2024 nazval spíš určitou normou, ne zbytečnýcm kanónem na vrabce.
V roce 2024 vyšla OpenSSL 3.5 a od té doby je to defaultně na prvním místě.
Myslím, že došlo k omylu Ivan.
Pokud to vyznívá jako nějaké rýpání nebo honba za chybami, bylo to špatně napsané, protože toto vůbec nebylo záměrem.
Když jsem jen viděl to vlákno, vzpomněl jsem si, jak jsme kdysi upgradovali servery, které služby jsme prioritne kontrolovali a jak což jsem zběžně zkusil a jen"přátelsky" na vysledek upozornil.
Nicméně s upgradem na Debian 12 bych nespěchal, pokud se obáváš o PHP.
IMHO stačí Debian 11 ELTS, zbytek je v podstatě jen o upgradu aktuálních služeb. Jestli se nepletu, Debian 11 má stále výchozí PHP verzi 7.4, zatímco Debian 12 už přechází na verzi 8* tam bych se o rozbití služeb asi uz obával.*.
Kromě toho, jestli jsi ten celý PHP kód poradny.net nepsal a neznáš jeho přesnou strukturu (tuším, že to byl LOS, kdo se o to staral), tak by ti jeho kompletní ošetření a upgrade zabralo extrémně hodně času, skoro až nemožné jen tak po někom převzít celý PHP WEB a ošetrit ho ..
Jako už tak "Bravo" za to, co se ti až do teď podařilo, a také za tvůj čas, protože to mě asi sere nejvíc že tě to demoralizuje, což mě fakt mrzí, ale jak říkám, nejde o dětské popichování nebo kritiku !!
Mohl jsi klidně ve svém omezeném, krátkém volném čase sedět na gauči a sledovat Netflix, namísto snažit se to tu držet pohromadě a hlídat, aby všechno jelo.
Apropo vážných chyb , to bych zaprvé nezveřejňoval ve vlákně, ale poslal v SZ a zadruhé jsem žádnou tak závažnou chybu nenašel, jen některé zbytečně vystavené služby nebo otevřené porty. S přátelským pozdravem Michal/HPET.
Ono je aj moznost mat viacero beziacich php na servery, taketo prasaciny mam aj u zakaznikov, typicky ak chce, aby na jednom servery bezal owncloud a nextcloud naraz. Kym next si vyzaduje php v8, own zase nevie na tom bezat a vyzaduje si v7.
Ale asi skoncim zatial na Debian 11 pre istotu, fakt to zerie kopec cas a trosku mi aj ritku stiskalo po upgradoch, ci som to nerozmrvil a nebudem musiet volat (ne)ochotnym losom.
Tak nám všechno jede v Proxmoxu, jina situace a postup.
Pro příklad při upgradu naší support stránky jsme měli aktivní dvě verze: jednu na Debianu 11 a druhou offline na Debianu 12, která se postupně ošetřovala a testovala. Kromě toho je to bezpečnější.
Ale takové plkání bychom mohli vést hodinu, je to nepodstatné.
Co se týče uvedeného příkladu aplikací (owncloud a nextcloud), které vyžadují rozdílné verze PHP, to jde podle mě jednoduše vyřešit přes Docker coz je IMHO jedno z nejlepsich reseni
I když OS podporuje PHP 7.*, v Dockeru si můžeš klidně pustit OWN nebo jinou službu na PHP 8* a druhou na PHP 7.* bez potřeby upgradovat celý serveru/OS, nebo řešit konflikty mezi verzemi PHP (nemusi vyhovovat zakaznikovy, chapu).
Neviem, Docker mi nikdy neprirastol k srdcu, ale losovia ho tlacili dopredu. Mame hotovy server, kde bezi vsetko z Dockeru, mali sme tam uz prenesenu aj databazu, server bol mozno na 99% dokonceny...ale nikdy sme ho nenasadili. Dodnes je stale na Proxmoxe...vypnuty.
Aj my bezime na Proxmoxe, dnes si uz ani neviem predstavit, zeby nieco bezalo na fyzickom servery.