Blogs: PHP2Shell, serveru drošība un ārkārtas palīdzība
Situācijas vērtējums, instrukcijas administratoriem un lēmumu atbalsts vadībai. Sakārtots pēc tēmas, katrs raksts ar avotiem.
Situācija un vērtējums
17 raksti
PHP2Shell: kas ir pierādīts un kas nav
PHP2Shell faktu pārbaude: kuri apgalvojumi nāk no primārajiem avotiem, kuri no mediju ziņojumiem un kurus apgalvojumus apstiprināt nevar.
Lasīt tālāk →002Kāpēc PHP ievainojamība kļuva zināma pirms ielāpa
Saskaņā ar ziņojumiem dati par PHP2Shell kļuva publiski pirms embargo beigām. Skaidrojam norisi un ko tas nozīmē jūsu ielāpu plānošanai.
Lasīt tālāk →003Iestādes atslēdz vietnes no tīkla: ko no tā mācīties uzņēmumiem
Maincas pilsēta, Hesenes zemes valdība un BKA vietnes atslēdza piesardzības nolūkā. Ko uzņēmumi no tā var mācīties savam lēmumam.
Lasīt tālāk →004BSI brīdinājuma līmenis oranžs: ko šis vērtējums nozīmē
BSI PHP2Shell vērtē ar 3 / oranžs. Ko skala norāda un ko ne, un kā uzņēmumi šo vērtējumu pārvērš lēmumos.
Lasīt tālāk →005Ko CERT-EU un CERT-Bund iesaka par PHP2Shell
Oficiālās iestādes ir vienisprātis: nekavējoties ielāpot, citādi izolēt. Salīdzinām ieteikumus un rādām, kā izolēšana izskatās praksē.
Lasīt tālāk →006Cloudflare aizsardzības noteikumi pret PHP2Shell: ko tie dod un ko ne
Cloudflare savlaicīgi ieviesa aizsardzības noteikumus pret PHP2Shell. Kāpēc tas palīdz, kāpēc tas tomēr neaizstāj PHP atjauninājumu un kādi iestatījumi jāpārbauda.
Lasīt tālāk →00722,6 miljoni eksponētu instanču: kā pareizi vērtēt skaitļus
Unit 42, CybelAngel un citi min ļoti atšķirīgus skaitļus par PHP2Shell. Skaidrojam, kas tika skaitīts un kurš skaitlis jums patiešām ir svarīgs.
Lasīt tālāk →008PHP2Shell piecās minūtēs: ziņojums vadībai
PHP drošības ievainojamība PHP2Shell vienā lapā lēmumu pieņēmējiem: situācija, risks, pieci jautājumi IT un lēmumi šodienai.
Lasīt tālāk →009PHP drošības ievainojamība vienkārši izskaidrota
PHP2Shell ne-tehniķiem: ar ikdienas attēliem, nelielu vārdnīcu un trim tipiskiem izejas stāvokļiem, ko jums kā vietnes operatoram darīt.
Lasīt tālāk →010PHP2Shell: 15 hostinga klientu jautājumu
Jūsu vietne atrodas pie hostinga sniedzēja, un vēlaties zināt, kas jums PHP2Shell gadījumā jādara pašam? Šeit 15 biežākie jautājumi ar īsām atbildēm.
Lasīt tālāk →011Kāpēc WordPress atjauninājums pret PHP2Shell nepalīdz
Daudzi operatori pēc virsrakstiem atjaunināja WordPress un jūtas droši. Kāpēc PHP2Shell gadījumā tas neko nedod un kas ir svarīgs tā vietā.
Lasīt tālāk →012PHP2Shell un Log4Shell: kas ievainojamībām ir kopīgs
Daudzi PHP2Shell salīdzina ar Log4Shell no 2021. gada. Ko salīdzinājums dod, kur tas klibo un kādas toreizējās mācības palīdz šodien.
Lasīt tālāk →013Masveida skenēšana pēc neielāpota PHP: kā norit automatizēti uzbrukumi
Pēc PHP2Shell uzbrucēji internetu automatizēti pārmeklē, meklējot ievainojamus serverus. Kā tas norit, kāpēc lielums nav svarīgs un kas jūs aizsargā.
Lasīt tālāk →014Laika logs starp ielāpu un uzbrukumu
PHP2Shell gadījumā uzbrukuma mēģinājumi bija jau pirms ielāpa. Skaidrojam laika loga fāzes, kā izmērīt savu logu un kā to saīsināt.
Lasīt tālāk →015Pēc PHP2Shell: kāpēc papildu ziņojumi ir ticami
PHP2Shell ar 21. oktobra ielāpu nav noslēgta. Kāpēc sekojoši ziņojumi ir gaidāmi un kā sagatavot savu komandu.
Lasīt tālāk →016PHP2Shell: pirmās nedēļas situācijas aina
Nedēļu pēc pirmā novērotā uzbrukuma mēģinājuma: stāvoklis ar ielāpiem, iestāžu brīdinājumiem, uzbrukumiem un atslēgšanām, tīri sadalīts pa avotiem.
Lasīt tālāk →017Bīstami nepareizi padomi par PHP2Shell, kas pašlaik cirkulē
Bloķēt sīkdatnes, slēpt kļūdu ziņojumus, atjaunināt tikai CMS: deviņi padomi par PHP2Shell, kas rada viltus drošību, un kas patiešām ir svarīgs.
Lasīt tālāk →Hostings un distributīvi
18 raksti
PHP versijas maiņa hostinga klienta sadaļā
Kā hostinga sniedzēja klienta sadaļā pārslēgt PHP versiju, kuru versiju izvēlēties un ko pārbaudīt pirms un pēc.
Lasīt tālāk →019Debian un Ubuntu: vai mana PHP pakotne ir ielāpota?
Kuras PHP pakotnes Debian un Ubuntu ir izlabojuši pret PHP2Shell, kā precīzi salīdzināt instalēto stāvokli un kāpēc apliecinājums neizdodas.
Lasīt tālāk →020RHEL, AlmaLinux un Rocky Linux: PHP ielāpa pārbaude
Ko Red Hat ir publicējis par PHP2Shell, kā RHEL un tā atvasinājumos apliecināt pakotnes stāvokli un kāpēc ar pārlādi nepietiek.
Lasīt tālāk →021sury.org repozitorijs: PHP pakotnes no trešā avota
Daudzi Debian un Ubuntu serveri PHP saņem no sury repozitorija. Ko tas nozīmē atjauninājumiem, apliecinājumiem un vecām PHP versijām pēc PHP2Shell.
Lasīt tālāk →022Remi repozitorijs: PHP uzturēšana aktuālā stāvoklī RHEL sistēmās
Remi piegādā aktuālas PHP versijas RHEL saimei, kā moduli vai paralēli instalējamas. Tā pārbaudāt stāvokli pēc PHP2Shell un izvairāties no aizmirstiem atzariem.
Lasīt tālāk →023Kāpēc php -v pēc atjauninājuma rāda to pašu numuru
Atjauninājums izpildīts, taču php -v ziņo veco versiju. Parasti tas ir backport, nevis kļūda. Tā nošķirat nekaitīgo no īstām problēmām.
Lasīt tālāk →024CVE numuru apliecināšana pakotnes changelog
Kam PHP ielāps jāpierāda vadībai, pārbaudītājiem vai apdrošinātājiem, ar versijas numuru nepietiek. Šādi changelog ieraksts kļūst par pierādījumu.
Lasīt tālāk →025Hostinga sniedzēja maiņa pēc drošības incidenta: kam pievērst uzmanību?
Pēc incidenta vēlme pēc jauna hostinga sniedzēja ir saprotama. Lai pārcelšanās neaizvestu līdzi arī uzbrucēju, svarīga ir secība un izvēle.
Lasīt tālāk →026Vairākas PHP versijas vienā serverī: ielāpojiet katru atsevišķi
Daudzos serveros blakus darbojas trīs, četras vai vairāk PHP instalācijas. Pēc PHP2Shell katra jāatrod, jāatjaunina un jāpārstartē.
Lasīt tālāk →027Veco PHP versiju izslēgšana hostinga panelī
PHP2Shell ir labs iemesls atbrīvoties no vecām PHP versijām. Rīkojieties trīs fāzēs, lai neviena vietne un neviens cronjob nenokristu nemanīts.
Lasīt tālāk →028Plesk: PHP handler izpratne (FPM, FastCGI, Apache modulis)
Kuru PHP handler Plesk izmanto vietnei, nosaka izolāciju, konfigurāciju un risku. Salīdzinājums, ņemot vērā PHP2Shell.
Lasīt tālāk →029CloudLinux un alt-php: ko jāzina hostinga klientiem
CloudLinux serveros vietnes bieži darbojas ar savām alt-php pakotnēm. Katrai no šīm versijām vajadzīgs savs ielāps, un to var ieviest tikai servera operators.
Lasīt tālāk →030PHP NAS, ugunsmūros un iekārtās: aizmirstās sistēmas
PHP izmanto ne tikai tīmekļa serveri. Skarti var būt arī NAS sistēmas, ugunsmūri un speciālās ierīces ar tīmekļa saskarni. Ielāpot tur parasti var tikai ražotājs, sasniedzamību regulējat jūs paši.
Lasīt tālāk →031PHP mākoņa un PaaS sniedzējiem: kas ielāpo izpildes vidi?
Platformas pakalpojumos PHP ielāps ir atkarīgs no darbības modeļa. Izšķirošā ir izpildes vide, kas patiešām piegādā saturu, nevis lokālā vide vai lietojumprogrammas kods.
Lasīt tālāk →032Oficiālie PHP Docker attēli: tagi, digest un pārbūve
Oficiālā PHP attēla tags ir rādītājs, kas laika gaitā pārvietojas uz jauniem stāvokļiem. Kas saprot tagu, variantu un digest, izvēlas pareizo attēlu un var pierādīt ielāpa stāvokli.
Lasīt tālāk →033CI/CD: PHP attēlu automātiska pārbūve
Attēls noveco arī bez koda izmaiņām. Ar laika grafika būvējumiem, versijas pārbaudi un izvietošanu pēc digest PHP ielāpi uzticami nonāk produkcijā.
Lasīt tālāk →034Ilgtermiņa atbalsts vecām PHP versijām: iespējas un robežas
Kas nevar uzreiz pāriet no PHP 8.1 vai vecākas versijas, ilgtermiņa atbalstu atrod pie distributīviem, trešo pušu sniedzējiem un komerciāliem pakalpojumiem. Ko šie ceļi sniedz, ko vajag rakstiski un kur ir robežas.
Lasīt tālāk →035PHP atjaunināšana Windows sistēmā
Windows sistēmā automātiska PHP atjauninājuma nav. Kas izvēlas pareizo variantu, pārbauda lejupielādi un pārstartē visus procesus, PHP2Shell ielāpu tīri nogādā katrā datorā.
Lasīt tālāk →Atklāšana un forensika
18 raksti
Brīdinājuma pazīme: tīmekļa serveris startē shell
Ja PHP-FPM vai tīmekļa servera process startē shell, tā ir viena no spēcīgākajām ielaušanās brīdinājuma pazīmēm. Kā pārbaudīt procesu koku, novērtēt izņēmumus un modeli uzraudzīt pastāvīgi.
Lasīt tālāk →037Aizdomīgu procesu atrašana Linux serveros
Ļaunprātīgi procesi maskējas ar nekaitīgiem nosaukumiem, darbojas no pagaidu mapēm vai no izdzēstiem failiem. Ar dažām lasošām komandām atradīsiet novirzes un tās novērtēsiet.
Lasīt tālāk →038Slēpto cronjobs kā slēptās piekļuves atpazīšana
Uzbrucēji izmanto ieplānotus uzdevumus, lai pēc attīrīšanas atgrieztos. Kā pilnībā pārbaudīt crontab, cron direktorijus, systemd taimerus un at uzdevumus un atpazīt aizdomīgus ierakstus.
Lasīt tālāk →039Nesen mainītu failu atrašana tīmekļa serverī
Pēc iespējamas ielaušanās svarīgi ir tas, kas serverī mainījies. Kā meklēt pēc laika logiem, pareizi izmantot mtime un ctime un salīdzināt ar pakotnēm, Git un rezerves kopijām.
Lasīt tālāk →040PHP faili augšupielāžu mapē: atradumu pareiza izpratne
PHP fails augšupielāžu mapē gandrīz vienmēr ir trauksmes signāls, bet ne katrs ir ļaunprātīgs kods. Kā novērtēt atradumu, neiznīcinot pēdas, un noskaidrot, vai kāds to ir izsaucis.
Lasīt tālāk →041Apmaskota PHP koda atpazīšana
Nelasāms PHP kods ar eval un base64_decode ir klasiska ievadīta ļaunprātīga koda pazīme. Kādus modeļus meklēt, kā tos droši atrast un kad apmaskošana ir likumīga.
Lasīt tālāk →042Servera izejošo savienojumu pārbaude
Tīmekļa serveris galvenokārt atbild uz pieprasījumiem. Ja tas pats veido savienojumus ar nezināmiem mērķiem, tas var nozīmēt uzbrucēju vadību vai datu aizplūdi. Kā pārbaudīt un ierobežot izejošo satiksmi.
Lasīt tālāk →043Svešu administratora kontu atrašana CMS un serverī
Nezināms administrators bieži ir vienkāršākā slēptā piekļuve. Kā meklēt svešus kontus līmenis pa līmenim, arī tādus, ko saskarne slēpj.
Lasīt tālāk →044Nezināmu SSH atslēgu atrašana un noņemšana
Ievadīta SSH atslēga uzbrucējiem atver durvis, pat ja visas paroles ir nomainītas. Kā atrast katru authorized_keys failu un pārbaudīt katru ierakstu.
Lasīt tālāk →045Kriptoieguves ļaunprogrammatūra tīmekļa serverī: pazīmes un rīcība
Pastāvīgi pilns CPU, kaut gan apmeklētāju nav vairāk: tas var būt kriptoieguves ļaunprogrammatūra. Kā pārbaudīt slodzi, atrast procesu un tā pārstartēšanas mehānismus un rīkoties sakārtoti.
Lasīt tālāk →046Serveris sūta surogātpastu: cēloņu atrašana
Nepiegādājami e-pasti, bloķēšanas saraksti, sūdzības: ja jūsu pašu serveris sūta surogātpastu, aiz tā parasti ir skripts vai nolaupīta pastkaste. Kā atrast avotu.
Lasīt tālāk →047SEO surogātpasts un svešas lapas Google indeksā
Pēkšņi zem jūsu domēna rangojas lapas par zālēm vai viltotām precēm. Kā noskaidrot, no kurienes nāk SEO surogātpasts, un panākt tā izņemšanu no indeksa.
Lasīt tālāk →048Vietne pāradresē uz svešām lapām
Apmeklētāji nonāk loterijās vai aizdomīgos veikalos, bet jūs paši neredzat nekā? Kā atrast slāni, kurā slēpjas pāradresācija, un to novērst.
Lasīt tālāk →049Nodrošiniet pierādījumus, pirms pārinstalējat serveri
Pārbūve novērš uzbrucēju, bet arī visas pēdas. Kas pirms tam velta stundu pierādījumu nodrošināšanai, vēlāk var pateikt, kas noticis.
Lasīt tālāk →050Incidenta laika līnijas izveide
Kad ieradās uzbrucējs, ko viņš darīja, kad tas tika pamanīts? Sakārtota laika līnija atbild uz šiem jautājumiem un ir pamats ziņojumiem, apdrošināšanai un pārskatam.
Lasīt tālāk →051CMS kodola failu salīdzināšana ar oriģinālu
Salīdzinājums ar tīru oriģinālu parāda katru mainīto failu neatkarīgi no tā, vai skeneris to pazīst. Kā izveidot salīdzināšanu WordPress, Composer projektiem un sistēmas pakotnēm.
Lasīt tālāk →052Datubāzes pārbaude, vai tajā nav ielikta koda
Kas pārbauda tikai failus, tam paslīd garām puse. Kā lasāmā režīmā un uz kopijas pārmeklēt datubāzes saturu, iestatījumus, trigerus un kontus, meklējot ielikto kodu.
Lasīt tālāk →053Ļaunprogrammatūras skeneri vietnēm: ko tie atrod un ko ne
Skeneris neko nepaziņo, tātad viss kārtībā? Ne vienmēr. Kādi vietņu skeneru veidi pastāv, ko katrs redz un ko principā nespēj redzēt.
Lasīt tālāk →Nostiprināšana un konfigurācija
20 raksti
PHP-FPM pūlu izolēšana katrai vietnei
Savs pūls katrai vietnei ir sākums, nevis beigas. Kā pārbaudīt esošos pūlus un nostiprināt sockets, paplašinājumus, statusa lapas, resursus un žurnālus.
Lasīt tālāk →055memory_limit pareizi iestatīt
memory_limit ierobežo atmiņu katram PHP pieprasījumam. Pēc PHP2Shell php.net pagaidām iesaka pretējo. Kas spēkā ikdienas darbībā, pārejas posmā un pēc atjauninājuma.
Lasīt tālāk →056post_max_size un upload_max_filesize saprātīga ierobežošana
Augšupielādes robežas darbojas trijās vietās: tīmekļa serverī, PHP un lietojumprogrammā. Kā iestatīt vērtības saskaņoti, arī ar php.net pārejas vērtībām PHP2Shell gadījumā.
Lasīt tālāk →057session.upload_progress izslēgšana: pareizi un pastāvīgi
Aizsardzība pret CVE-2026-115560 un viens no PHP2Shell pārejas pasākumiem ir iestatāms ātri. Lai tas noturētos, tam jābūt pareizajā vietā, nobloķētam un pēc katra atjauninājuma jāpārbauda.
Lasīt tālāk →058expose_php un Server galvenes: versiju norāžu slēpšana
PHP, Nginx un Apache pēc noklusējuma katrā atbildē min savu versijas numuru. Tas neaizsargā pret uzbrukumiem, bet skeneriem sniedz ērtu mērķu sarakstu. Kā to izslēgt un tomēr saglabāt pārskatu.
Lasīt tālāk →059display_errors off: kļūdu izvades izslēgšana produkcijā
Redzami PHP kļūdu ziņojumi atklāj ceļus, datubāzu nosaukumus un versijas. Kā tos izslēgt PHP, ietvarā un tīmekļa serverī, nepazaudējot kļūdas no redzesloka.
Lasīt tālāk →060php_admin_value: iestatījumu bloķēšana pret pārrakstīšanu
Drošības iestatījumam maz jēgas, ja lietojumprogramma to ar vienu koda rindiņu atkal maina. Ar php_admin_value un php_admin_flag jūs PHP-FPM un Apache vērtības nosakāt saistoši.
Lasīt tālāk →061Atmiņas robežu iestatīšana ar systemd un cgroups
php.net kā PHP2Shell pārejas pasākumu iesaka memory_limit=-1 un atmiņas robežu ārpus PHP. Kā šo robežu iestatīt ar systemd un cgroups, lai viens worker nenorautu līdzi visu pakalpojumu.
Lasīt tālāk →062Nginx droša konfigurēšana PHP
Lielākā daļa ievainojamību Nginx uzstādījumos PHP slēpjas nevis Nginx, bet dažās PHP location rindiņās. Kā konfigurēt nodošanu PHP-FPM tā, lai tiktu izpildīti tikai vēlamie skripti.
Lasīt tālāk →063Apache droša konfigurēšana PHP
Apache ir elastīgs, un tieši tas to dara jutīgu pret nepareizu konfigurāciju. Kā pieslēgt PHP caur PHP-FPM, aizvērt .htaccess kā slēpto piekļuvi un droši iestatīt svarīgākās kodola opcijas.
Lasīt tālāk →064PHP izpildes aizliegšana augšupielāžu mapēs
Webshell vajag divas lietas: mapi, kurā to var ierakstīt, un serveri, kas to izpilda. Kā atņemt otro, un to visās rakstāmajās mapēs, ne tikai uploads.
Lasīt tālāk →065Augšupielādes pieprasījumu filtrēšana malā: iespējas un riski
Speciālisti iesaka līdz PHP ielāpošanai starpniekserverī bloķēt augšupielādes pieprasījumus ārpus īstiem augšupielādes ceļiem. Tas var palīdzēt, bet var arī paralizēt veidlapas un pasūtījumus. Kā rīkoties kontrolēti.
Lasīt tālāk →066ModSecurity un OWASP Core Rule Set lietošana
Sava Web Application Firewall ar ModSecurity un OWASP Core Rule Set ir bezmaksas un jaudīga, bet ne pašplūsmā. Kā izvēlēties dzinēju, sākt bez atteicēm un noregulēt noteikumus.
Lasīt tālāk →067Fail2ban ieviešana tīmekļa serveriem
Fail2ban bloķē adreses, kas žurnālos atkārtoti izceļas. Tīmekļa serveriem tam ir gatavi filtri, un ar dažām rindiņām pievienojami savi. Kā to ieviest, neizslēdzot ne sevi, ne savus klientus.
Lasīt tālāk →068Ugunsmūris tīmekļa serveriem: atvērt tikai nepieciešamos portus
Tīmekļa serverim uz āru parasti vajag tikai divus portus. Tomēr daudzos serveros internetā klausās datubāzes, PHP-FPM vai pārvaldības saskarnes. Kā atrast atvērtos pakalpojumus un aizvērt nevajadzīgos.
Lasīt tālāk →069Automātiski drošības atjauninājumi Linux serveros
Saskaņā ar ziņojumiem distributīvi PHP backport dažkārt piegādāja jau 2026. gada 21. oktobrī, ielāpu publicēšanas dienā. Kas lietoja automātiskus drošības atjauninājumus, tam tie bija serverī ātri. Lai tie darbotos, vajadzīgas pārstartēšanas, trešo pušu avoti un kontrole.
Lasīt tālāk →070Least Privilege: tīmekļa servera lietotāja tiesības
Ievadīts kods darbojas ar tīmekļa servera lietotāja tiesībām. Ko šis konts drīkst, nosaka, cik tālu tiek uzbrucējs. Lūk, kā ierobežot shell, sudo, cron, datubāzi un failu sistēmu līdz nepieciešamajam.
Lasīt tālāk →071Admin sadaļu norobežošana ar IP, VPN vai papildu aizsardzību
Kāpēc vietnes aizmugurei nav jābūt pieejamai visai pasaulei un kā to norobežot ar IP atļaušanu, VPN vai priekšā ieslēgtu pieteikšanos, neizslēdzot sevi pašu.
Lasīt tālāk →072TLS un HTTPS pareiza konfigurēšana
Kādas TLS versijas un šifrēšanas komplektus (cipher suites) tīmekļa serverim šodien jāpiedāvā, uz ko balstās ieteikumi un kā pārbaudīt Nginx, Apache un izejošos PHP savienojumus.
Lasīt tālāk →073CIS Benchmarks un BSI moduļi tīmekļa serveriem
Kādi nostiprināšanas standarti pastāv Linux tīmekļa serveriem, ar ko CIS Benchmarks atšķiras no IT-Grundschutz moduļiem un kā no tiem izveidot pārbaudāmu prasību kopu jūsu PHP serveriem.
Lasīt tālāk →Droša izstrāde
16 raksti
Paroļu droša glabāšana PHP: pareiza password_hash lietošana
Kā izstrādātāji PHP glabā paroles ar password_hash un password_verify, izvēlas piemērotu metodi un nomaina vecos MD5 vai SHA-1 jaucējkodus, nepieprasot paroles atiestatīšanu visiem lietotājiem.
Lasīt tālāk →075CSRF aizsardzība PHP lietojumprogrammās
Kā izstrādātāji PHP lietojumprogrammās novērš Cross-Site Request Forgery: tokeni katram mainošam pieprasījumam, izcelsmes pārbaude galvenē un SameSite sīkdatnes kā papildu slānis.
Lasīt tālāk →076Ievades validēšana un filtrēšana PHP ar filter_var
Kā izstrādātāji PHP pārbauda ievadi ar filter_var, filter_input_array un atļauju sarakstiem, kuri filtri ir novecojuši un kāpēc validēšana neaizstāj Prepared Statements un izvades kodēšanu.
Lasīt tālāk →077Command Injection novēršana PHP
Kā izstrādātāji PHP novērš Command Injection: sistēmas komandas aizstāt ar PHP funkcijām, lietot proc_open bez shell, pārbaudīt argumentus un atrast bīstamās vietas esošajā kodā.
Lasīt tālāk →078Server-Side Request Forgery (SSRF) novēršana PHP
Kā izstrādātāji novērš, ka PHP lietojumprogramma svešu personu uzdevumā vaicā iekšējās sistēmas: atļauju saraksti, protokolu ierobežojums, atrisinātās adreses pārbaude un tīkla robežas.
Lasīt tālāk →079XML External Entities (XXE) novēršana PHP
Kā izstrādātāji PHP droši apstrādā XML: libxml noklusējuma uzvedība, riskantas opcijas, piemēram, LIBXML_NOENT, aizsardzība ar entity loader un LIBXML_NO_XXE, kā arī tipiskas slēptas XML ieejas.
Lasīt tālāk →080Type Juggling PHP: brīvie salīdzinājumi kā drošības risks
Kāpēc brīvie salīdzinājumi ar == PHP var radīt drošības nepilnības, ko mainīja PHP 8.0 un kā salīdzinājumus pieteikšanās, tokenu un atļauju pārbaudēs uzrakstīt noturīgi.
Lasīt tālāk →081Droši gadījuma skaitļi un tokeni PHP ar random_bytes
Kā izstrādātāji PHP veido tokenus paroles atiestatīšanas saitēm, API atslēgām un vienreizējiem kodiem: kriptogrāfiski droši avoti, pietiekams garums, glabāšana kā jaucējkods un ierobežota derīgums.
Lasīt tālāk →082Piekļuves datu un .env failu pareiza aizsardzība
Kā aizsargāt datubāzu paroles, API atslēgas un citus noslēpumus PHP projektos: .env faili ārpus tīmekļa saknes, bloķēšana tīmekļa serverī, šauras tiesības un sakārtota nomaiņa pēc incidenta.
Lasīt tālāk →083Publiska .git mape: nenovērtēta datu noplūde
Kāpēc ar Git izvietota tīmekļa sakne var atklāt visu pirmkodu kopā ar vēsturi, kā to pārbaudīt, nekavējoties bloķēt un izvietošanu ilgstoši uzbūvēt bez .git mapes.
Lasīt tālāk →084Rezerves kopiju faili tīmekļa saknē: .zip, .sql un .bak
Kāpēc datubāzu izmetumi, arhīvi un rezerves kopijas publiskajā direktorijā ir viena no biežākajām datu noplūdēm, kā tās atrast, bloķēt un noskaidrot, vai tās tika atvērtas.
Lasīt tālāk →085phpinfo() faili: kāpēc tiem jāpazūd
Pēc PHP2Shell daudzi administratori ātri izveido info.php. Kāpēc šādi faili ir datu noplūde, kā tos atrast un kuri pārbaudes ceļi ir labāki.
Lasīt tālāk →086Atkarību uzturēšana aktuālas: Composer, npm un spraudņi
Projekts sastāv no trim pakotņu pasaulēm: Composer, npm un CMS spraudņi. Kā visas trīs uzturēt aktuālas ar fiksētu ritmu, skaidru atbildību un testiem.
Lasīt tālāk →087Drošības koda pārskats PHP projektiem
Kā komandas mērķtiecīgi caurskata savu PHP kodu uz drošības nepilnībām: pārskatu veidi, kritiskās funkcijas, lietderīgi rīki un pārbaudes saraksts.
Lasīt tālāk →088Droša žurnālēšana: kļūdu protokolēšana bez datu noplūdes
Žurnāli palīdz kļūdu meklēšanā un forensikā, bet ātri paši kļūst par datu noplūdi. Ko PHP lietojumprogrammām vajadzētu protokolēt, ko nekad un kā žurnālus aizsargāt.
Lasīt tālāk →089REST API aizsardzība PHP
Saskarnes bieži ir sliktāk aizsargātas nekā vietne to priekšā. Svarīgākie noteikumi REST API PHP, sākot no objekta atļaujas līdz ātruma ierobežojumam.
Lasīt tālāk →Vadība un tiesības
14 raksti
IT pakalpojumu sniedzēju līgumi: skaidri noteikt drošības pienākumus
PHP2Shell parādīja, cik bieži nav skaidrs, kam jāielāpo. Kādi drošības pienākumi pieder līgumiem ar aģentūru, hostinga un IT pakalpojumu sniedzēju.
Lasīt tālāk →091Datu apstrāde uzdevumā, ja pakalpojumu sniedzēji piekļūst serverim
Kas ārējiem ļauj piekļūt serveriem ar klientu datiem, tam parasti vajadzīgs AVV. Ko prasa VDAR 28. pants un kā ārkārtas gadījumā piekļuves organizēt atbilstoši datu aizsardzībai.
Lasīt tālāk →092Ievainojamību pārvaldība vidējiem uzņēmumiem
Neviens vidējs uzņēmums nevar nekavējoties apstrādāt katru ziņojumu. Vienkāršs cikls no uzskaites, novērtēšanas, lēmuma un apliecinājuma nodrošina, ka svarīgākais notiek pirmais.
Lasīt tālāk →093Zināt, kas darbojas: visu tīmekļa vietņu un serveru inventārs
Daudzi pie PHP2Shell paklupa nevis uz ielāpa, bet uz jautājuma, kur vispār darbojas PHP. Lūk, kā izveidot visu tīmekļa vietņu un serveru inventāru.
Lasīt tālāk →094Ielāpu pārvaldība kā process, nevis ugunsdzēsēju darbs
Kas ielāpus uzstāda tikai tad, kad deg, ārkārtas situācijā zaudē laiku. Kā ielāpu pārvaldības process ar noteiktām klasēm, logiem un apliecinājumiem savieno rutīnu un ārkārtas gadījumu.
Lasīt tālāk →095Ārkārtas kontakti: kam un kad jāpaziņo?
Ārkārtas situācijā svarīgi, ko var sasniegt un kad. Kā izveidot IT ārkārtas kontaktu sarakstu ar aktivizētājiem, aizvietotājiem un datiem, kas vajadzīgi katram zvanam.
Lasīt tālāk →096Ko izmaksā uzlauzts serveris: izmaksu posteņi
Uzlauzts tīmekļa serveris rada vairāk izmaksu nekā remonts. Kādi izmaksu posteņi rodas un kā ar saviem skaitļiem pamatot profilakses budžetu.
Lasīt tālāk →097Klientu informēšana pēc incidenta
Vai tas ir pienākums vai brīvprātīgi: kā pēc incidenta izlemt, kuri jāinformē, kuri kanāli ir droši un kā sagatavots klientu apkalpošanas dienests.
Lasīt tālāk →098Piegādes ķēde tīmeklī: aģentūra, hostings, spraudņu piegādātājs
PHP2Shell parādīja, cik daudz posmu ir starp ielāpu un jūsu vietni. Kā pazīt savas vietnes piegādes ķēdi, nodrošināt to un uzņemt atsevišķu posmu atteici.
Lasīt tālāk →099Drošības izpratne administratoriem un redaktoriem: Security Awareness tīmekļa komandā
Kas uztur vietnes, ikdienā lemj par drošību, bieži to nemanot. Kā apmācīt administratorus un redaktorus atbilstoši lomai un bez slaidu kaudzes.
Lasīt tālāk →100Ārkārtas vingrinājums pie galda: izspēlēt tīmekļa servera incidentu
Vingrinājums pie galda izmaksā vienu pēcpusdienu un parāda, vai jūsu ārkārtas rīcības plāns iztur. Šeit atradīsiet gatavu scenāriju incidentam PHP tīmekļa serverī.
Lasīt tālāk →101ISO 27001 un TISAX: kas skar tīmekļa serverus
Kas darbina ISMS pēc ISO 27001 vai kam ir TISAX etiķete, tam jāņem vērā arī tīmekļa serveri. Šeit lasāms, kuras prasības tie skar un kādi apliecinājumi pēc PHP2Shell ir svarīgi.
Lasīt tālāk →102VdS 10000: informācijas drošība maziem un vidējiem uzņēmumiem
VdS 10000 ir viegls ietvars informācijas drošībai vidējos uzņēmumos. Ko tā prasa, kas jauns 2025. gadā un ko tas nozīmē vietnēm un tīmekļa serveriem.
Lasīt tālāk →103Lessons Learned: kļūt labākiem pēc incidenta
Pēc incidenta ir pirms nākamā. Strukturēta pēcsanāksme bez vainīgo meklēšanas padara sliktu nedēļu par izmērāmu progresu.
Lasīt tālāk →Lēmumu atbalsts
10 raksti
Ielāpot, atslēgt vai gaidīt? Lēmuma palīgs PHP nepilnības gadījumā
Kritiskas PHP nepilnības gadījumā atbildīgajiem jālemj ātri. Šis palīgs sakārto trīs variantus, nosauc kritērijus un parāda, kad gaidīšana ir pieļaujama.
Lasīt tālāk →105WAF vai atjauninājums: kāpēc vajadzīgi abi
Tīmekļa lietojumprogrammu ugunsmūris var pārtvert uzbrukumus, bet neaizver nepilnību PHP interpretatorā. Kad WAF palīdz, kur tas beidzas un kā abus saprātīgi apvienot.
Lasīt tālāk →106Serveri uzstādīt no jauna vai tīrīt? Lēmums pēc inficēšanās
Pēc ielaušanās ir divi ceļi: serveri iztīrīt vai pārbūvēt. Kuri kritēriji izšķir un kāpēc secība ir svarīgāka par izvēli.
Lasīt tālāk →107Novērst pašiem vai pieaicināt pakalpojumu sniedzēju? Godīga svēršana
Ne katrai drošības situācijai vajadzīga ārēja palīdzība. Ar šiem kritērijiem un īsu pašpārbaudi izlemsiet, vai jūsu komanda PHP2Shell tiek galā viena vai vajadzīgs atbalsts.
Lasīt tālāk →108IT drošības pakalpojumu sniedzēja izvēle: 12 jautājumi pirms pasūtījuma
Laika spiedienā atrast labu drošības pakalpojumu sniedzēju ir grūti. Šie divpadsmit jautājumi palīdz lietišķi salīdzināt piedāvājumus, neuzķeroties uz reklāmas solījumiem.
Lasīt tālāk →109Pārvaldīts hostings vai pašu serveris? Drošības salīdzinājums
PHP2Shell bija stresa tests katram darbības modelim. Salīdzinājums parāda, kad drošāks ir pārvaldīts hostings, kad pašu serveris un kuri jauktie varianti sevi pierāda.
Lasīt tālāk →110PHP jauninājums vai atpakaļportējums? Lēmums vecām sistēmām
Vecām PHP versijām pēc PHP2Shell ir vairāki ceļi: distribūcijas atpakaļportējums, trešais avots, pirmkoda ielāps, ilgtermiņa atbalsts vai jauninājums. Ko katrs ceļš spēj un cik ilgi tas iztur.
Lasīt tālāk →111Pēc uzlaušanas mainīt CMS? Kad tas palīdz un kad ne
Pēc ielaušanās uzticība CMS bieži ir zudusi. Taču jauna sistēma reti atrisina patieso cēloni. Kad maiņa ir lietderīga un kā tā izdodas tīri.
Lasīt tālāk →112Statiskas vietnes: mazāk PHP, mazāka uzbrukuma virsma
Statiska vietne piegādā gatavus HTML failus un serverī neprasa PHP. Tas ievērojami samazina uzbrukuma virsmu, taču nes līdzi savas robežas un pienākumus.
Lasīt tālāk →113Pentests, Bug Bounty vai ievainojamību skenēšana? Piemērotas pārbaudes metodes izvēle
Skenēšana, penetrācijas tests un Bug Bounty pārbauda vietnes pilnīgi atšķirīgi. Ko katra metode spēj, kur tā zaudē un kāda secība der jūsu uzņēmumam.
Lasīt tālāk →Katra stunda ir svarīga. Rakstiet mums tūlīt.
Īsi aprakstiet sistēmu, PHP versiju un novēroto. Mēs sazināsimies, noskaidrosim situāciju un strādāsim attālināti, līdz incidents ir slēgts un dokumentēts.