# Blogs: PHP2Shell, serveru drošība un ārkārtas palīdzība

> Blogs par PHP2Shell un serveru drošību: situācija, hostings, atklāšana, nostiprināšana, droša izstrāde, vadība un lēmumu atbalsts.

Avots: https://phpsos.de/lv/blog/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

Situācijas vērtējums, instrukcijas administratoriem un lēmumu atbalsts vadībai. Sakārtots pēc tēmas, katrs raksts ar avotiem.

- [PHP2Shell: kas ir pierādīts un kas nav](https://phpsos.de/lv/blog/php2shell-was-belegt-ist/): PHP2Shell faktu pārbaude: kuri apgalvojumi nāk no primārajiem avotiem, kuri no mediju ziņojumiem un kurus apgalvojumus apstiprināt nevar.
- [Kāpēc PHP ievainojamība kļuva zināma pirms ielāpa](https://phpsos.de/lv/blog/php-luecke-vorzeitig-bekannt/): 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.
- [Iestādes atslēdz vietnes no tīkla: ko no tā mācīties uzņēmumiem](https://phpsos.de/lv/blog/behoerden-webseiten-offline/): 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.
- [BSI brīdinājuma līmenis oranžs: ko šis vērtējums nozīmē](https://phpsos.de/lv/blog/bsi-warnstufe-orange-erklaert/): 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.
- [Ko CERT-EU un CERT-Bund iesaka par PHP2Shell](https://phpsos.de/lv/blog/cert-eu-empfehlungen-php/): 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ē.
- [Cloudflare aizsardzības noteikumi pret PHP2Shell: ko tie dod un ko ne](https://phpsos.de/lv/blog/cloudflare-waf-php2shell/): 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.
- [22,6 miljoni eksponētu instanču: kā pareizi vērtēt skaitļus](https://phpsos.de/lv/blog/exponierte-instanzen-einordnen/): 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.
- [PHP2Shell piecās minūtēs: ziņojums vadībai](https://phpsos.de/lv/blog/php2shell-briefing-geschaeftsfuehrung/): PHP drošības ievainojamība PHP2Shell vienā lapā lēmumu pieņēmējiem: situācija, risks, pieci jautājumi IT un lēmumi šodienai.
- [PHP drošības ievainojamība vienkārši izskaidrota](https://phpsos.de/lv/blog/php-luecke-einfach-erklaert/): 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.
- [PHP2Shell: 15 hostinga klientu jautājumu](https://phpsos.de/lv/blog/fragen-von-hosting-kunden/): 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.
- [Kāpēc WordPress atjauninājums pret PHP2Shell nepalīdz](https://phpsos.de/lv/blog/warum-wordpress-update-nicht-hilft/): 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ā.
- [PHP2Shell un Log4Shell: kas ievainojamībām ir kopīgs](https://phpsos.de/lv/blog/php2shell-und-log4shell/): 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.
- [Masveida skenēšana pēc neielāpota PHP: kā norit automatizēti uzbrukumi](https://phpsos.de/lv/blog/automatisierte-massenscans/): 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ā.
- [Laika logs starp ielāpu un uzbrukumu](https://phpsos.de/lv/blog/zeitfenster-patch-angriff/): 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.
- [Pēc PHP2Shell: kāpēc papildu ziņojumi ir ticami](https://phpsos.de/lv/blog/weitere-php-meldungen/): PHP2Shell ar 21. oktobra ielāpu nav noslēgta. Kāpēc sekojoši ziņojumi ir gaidāmi un kā sagatavot savu komandu.
- [PHP2Shell: pirmās nedēļas situācijas aina](https://phpsos.de/lv/blog/lagebild-erste-woche/): 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.
- [Bīstami nepareizi padomi par PHP2Shell, kas pašlaik cirkulē](https://phpsos.de/lv/blog/gefaehrliche-falschtipps/): 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.
- [PHP versijas maiņa hostinga klienta sadaļā](https://phpsos.de/lv/blog/php-version-hosting-aendern/): 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.
- [Debian un Ubuntu: vai mana PHP pakotne ir ielāpota?](https://phpsos.de/lv/blog/debian-ubuntu-paket-gepatcht/): 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.
- [RHEL, AlmaLinux un Rocky Linux: PHP ielāpa pārbaude](https://phpsos.de/lv/blog/rhel-almalinux-rocky-php/): 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.
- [sury.org repozitorijs: PHP pakotnes no trešā avota](https://phpsos.de/lv/blog/sury-repository-php/): 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.
- [Remi repozitorijs: PHP uzturēšana aktuālā stāvoklī RHEL sistēmās](https://phpsos.de/lv/blog/remi-repository-php/): 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.
- [Kāpēc php -v pēc atjauninājuma rāda to pašu numuru](https://phpsos.de/lv/blog/php-v-zeigt-alte-nummer/): 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.
- [CVE numuru apliecināšana pakotnes changelog](https://phpsos.de/lv/blog/cve-im-changelog-nachweisen/): 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.
- [Hostinga sniedzēja maiņa pēc drošības incidenta: kam pievērst uzmanību?](https://phpsos.de/lv/blog/hoster-wechseln-nach-vorfall/): 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.
- [Vairākas PHP versijas vienā serverī: ielāpojiet katru atsevišķi](https://phpsos.de/lv/blog/mehrere-php-versionen-server/): 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ē.
- [Veco PHP versiju izslēgšana hostinga panelī](https://phpsos.de/lv/blog/alte-php-versionen-abschalten/): 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.
- [Plesk: PHP handler izpratne (FPM, FastCGI, Apache modulis)](https://phpsos.de/lv/blog/plesk-php-handler/): Kuru PHP handler Plesk izmanto vietnei, nosaka izolāciju, konfigurāciju un risku. Salīdzinājums, ņemot vērā PHP2Shell.
- [CloudLinux un alt-php: ko jāzina hostinga klientiem](https://phpsos.de/lv/blog/cloudlinux-alt-php/): 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.
- [PHP NAS, ugunsmūros un iekārtās: aizmirstās sistēmas](https://phpsos.de/lv/blog/php-auf-nas-und-appliances/): 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.
- [PHP mākoņa un PaaS sniedzējiem: kas ielāpo izpildes vidi?](https://phpsos.de/lv/blog/paas-php-laufzeit/): 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.
- [Oficiālie PHP Docker attēli: tagi, digest un pārbūve](https://phpsos.de/lv/blog/offizielle-php-docker-images/): 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.
- [CI/CD: PHP attēlu automātiska pārbūve](https://phpsos.de/lv/blog/php-images-in-ci-neu-bauen/): 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ā.
- [Ilgtermiņa atbalsts vecām PHP versijām: iespējas un robežas](https://phpsos.de/lv/blog/langzeitsupport-alte-php-versionen/): 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.
- [PHP atjaunināšana Windows sistēmā](https://phpsos.de/lv/blog/php-unter-windows-aktualisieren/): 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ā.
- [Brīdinājuma pazīme: tīmekļa serveris startē shell](https://phpsos.de/lv/blog/webserver-startet-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.
- [Aizdomīgu procesu atrašana Linux serveros](https://phpsos.de/lv/blog/verdaechtige-prozesse-linux/): Ļ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.
- [Slēpto cronjobs kā slēptās piekļuves atpazīšana](https://phpsos.de/lv/blog/cronjobs-als-hintertuer/): 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.
- [Nesen mainītu failu atrašana tīmekļa serverī](https://phpsos.de/lv/blog/geaenderte-dateien-finden/): 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.
- [PHP faili augšupielāžu mapē: atradumu pareiza izpratne](https://phpsos.de/lv/blog/php-dateien-im-upload-ordner/): 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.
- [Apmaskota PHP koda atpazīšana](https://phpsos.de/lv/blog/verschleierter-php-code/): 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.
- [Servera izejošo savienojumu pārbaude](https://phpsos.de/lv/blog/ausgehende-verbindungen-pruefen/): 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.
- [Svešu administratora kontu atrašana CMS un serverī](https://phpsos.de/lv/blog/fremde-admin-konten-finden/): 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.
- [Nezināmu SSH atslēgu atrašana un noņemšana](https://phpsos.de/lv/blog/ssh-schluessel-pruefen/): 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.
- [Kriptoieguves ļaunprogrammatūra tīmekļa serverī: pazīmes un rīcība](https://phpsos.de/lv/blog/kryptominer-auf-dem-server/): 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.
- [Serveris sūta surogātpastu: cēloņu atrašana](https://phpsos.de/lv/blog/server-verschickt-spam/): 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.
- [SEO surogātpasts un svešas lapas Google indeksā](https://phpsos.de/lv/blog/seo-spam-im-google-index/): 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.
- [Vietne pāradresē uz svešām lapām](https://phpsos.de/lv/blog/website-leitet-um/): 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.
- [Nodrošiniet pierādījumus, pirms pārinstalējat serveri](https://phpsos.de/lv/blog/beweise-sichern-vor-neuinstallation/): 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.
- [Incidenta laika līnijas izveide](https://phpsos.de/lv/blog/zeitleiste-eines-vorfalls/): 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.
- [CMS kodola failu salīdzināšana ar oriģinālu](https://phpsos.de/lv/blog/cms-kerndateien-vergleichen/): 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.
- [Datubāzes pārbaude, vai tajā nav ielikta koda](https://phpsos.de/lv/blog/datenbank-auf-schadcode-pruefen/): 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.
- [Ļaunprogrammatūras skeneri vietnēm: ko tie atrod un ko ne](https://phpsos.de/lv/blog/grenzen-von-malware-scannern/): 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.
- [PHP-FPM pūlu izolēšana katrai vietnei](https://phpsos.de/lv/blog/php-fpm-pools-isolieren/): 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.
- [memory_limit pareizi iestatīt](https://phpsos.de/lv/blog/memory-limit-richtig-setzen/): 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.
- [post_max_size un upload_max_filesize saprātīga ierobežošana](https://phpsos.de/lv/blog/post-max-size-upload-limits/): 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ā.
- [session.upload_progress izslēgšana: pareizi un pastāvīgi](https://phpsos.de/lv/blog/session-upload-progress-abschalten/): 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.
- [expose_php un Server galvenes: versiju norāžu slēpšana](https://phpsos.de/lv/blog/expose-php-versionsangaben/): 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.
- [display_errors off: kļūdu izvades izslēgšana produkcijā](https://phpsos.de/lv/blog/display-errors-produktion/): 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.
- [php_admin_value: iestatījumu bloķēšana pret pārrakstīšanu](https://phpsos.de/lv/blog/php-admin-value-sperren/): 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.
- [Atmiņas robežu iestatīšana ar systemd un cgroups](https://phpsos.de/lv/blog/speichergrenzen-systemd-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.
- [Nginx droša konfigurēšana PHP](https://phpsos.de/lv/blog/nginx-fuer-php-absichern/): 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.
- [Apache droša konfigurēšana PHP](https://phpsos.de/lv/blog/apache-fuer-php-absichern/): 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.
- [PHP izpildes aizliegšana augšupielāžu mapēs](https://phpsos.de/lv/blog/php-in-uploads-verbieten/): 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.
- [Augšupielādes pieprasījumu filtrēšana malā: iespējas un riski](https://phpsos.de/lv/blog/upload-anfragen-am-rand-filtern/): 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.
- [ModSecurity un OWASP Core Rule Set lietošana](https://phpsos.de/lv/blog/modsecurity-owasp-crs/): 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.
- [Fail2ban ieviešana tīmekļa serveriem](https://phpsos.de/lv/blog/fail2ban-fuer-webserver/): 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.
- [Ugunsmūris tīmekļa serveriem: atvērt tikai nepieciešamos portus](https://phpsos.de/lv/blog/firewall-fuer-webserver/): 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.
- [Automātiski drošības atjauninājumi Linux serveros](https://phpsos.de/lv/blog/automatische-sicherheitsupdates/): 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.
- [Least Privilege: tīmekļa servera lietotāja tiesības](https://phpsos.de/lv/blog/rechte-des-webserver-benutzers/): 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.
- [Admin sadaļu norobežošana ar IP, VPN vai papildu aizsardzību](https://phpsos.de/lv/blog/admin-bereiche-abschirmen/): 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.
- [TLS un HTTPS pareiza konfigurēšana](https://phpsos.de/lv/blog/tls-https-richtig-konfigurieren/): 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.
- [CIS Benchmarks un BSI moduļi tīmekļa serveriem](https://phpsos.de/lv/blog/cis-benchmarks-bsi-bausteine/): 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.
- [Paroļu droša glabāšana PHP: pareiza password_hash lietošana](https://phpsos.de/lv/blog/passwoerter-in-php-speichern/): 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.
- [CSRF aizsardzība PHP lietojumprogrammās](https://phpsos.de/lv/blog/csrf-schutz-php/): 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.
- [Ievades validēšana un filtrēšana PHP ar filter_var](https://phpsos.de/lv/blog/eingaben-validieren-php/): 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.
- [Command Injection novēršana PHP](https://phpsos.de/lv/blog/command-injection-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ā.
- [Server-Side Request Forgery (SSRF) novēršana PHP](https://phpsos.de/lv/blog/ssrf-in-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.
- [XML External Entities (XXE) novēršana PHP](https://phpsos.de/lv/blog/xxe-in-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.
- [Type Juggling PHP: brīvie salīdzinājumi kā drošības risks](https://phpsos.de/lv/blog/type-juggling-php/): 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.
- [Droši gadījuma skaitļi un tokeni PHP ar random_bytes](https://phpsos.de/lv/blog/sichere-tokens-php/): 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.
- [Piekļuves datu un .env failu pareiza aizsardzība](https://phpsos.de/lv/blog/env-dateien-schuetzen/): 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.
- [Publiska .git mape: nenovērtēta datu noplūde](https://phpsos.de/lv/blog/git-ordner-oeffentlich/): 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.
- [Rezerves kopiju faili tīmekļa saknē: .zip, .sql un .bak](https://phpsos.de/lv/blog/backup-dateien-im-webroot/): 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.
- [phpinfo() faili: kāpēc tiem jāpazūd](https://phpsos.de/lv/blog/phpinfo-dateien-entfernen/): 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.
- [Atkarību uzturēšana aktuālas: Composer, npm un spraudņi](https://phpsos.de/lv/blog/abhaengigkeiten-aktuell-halten/): 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.
- [Drošības koda pārskats PHP projektiem](https://phpsos.de/lv/blog/sicherheits-code-review-php/): 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.
- [Droša žurnālēšana: kļūdu protokolēšana bez datu noplūdes](https://phpsos.de/lv/blog/sicher-loggen-php/): Ž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.
- [REST API aizsardzība PHP](https://phpsos.de/lv/blog/rest-api-php-absichern/): 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.
- [IT pakalpojumu sniedzēju līgumi: skaidri noteikt drošības pienākumus](https://phpsos.de/lv/blog/dienstleistervertrag-sicherheit/): 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.
- [Datu apstrāde uzdevumā, ja pakalpojumu sniedzēji piekļūst serverim](https://phpsos.de/lv/blog/auftragsverarbeitung-serverzugriff/): 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.
- [Ievainojamību pārvaldība vidējiem uzņēmumiem](https://phpsos.de/lv/blog/schwachstellenmanagement-mittelstand/): 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.
- [Zināt, kas darbojas: visu tīmekļa vietņu un serveru inventārs](https://phpsos.de/lv/blog/inventar-websites-server/): 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.
- [Ielāpu pārvaldība kā process, nevis ugunsdzēsēju darbs](https://phpsos.de/lv/blog/patch-management-prozess/): 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.
- [Ārkārtas kontakti: kam un kad jāpaziņo?](https://phpsos.de/lv/blog/notfallkontakte-liste/): Ā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.
- [Ko izmaksā uzlauzts serveris: izmaksu posteņi](https://phpsos.de/lv/blog/kostenposten-eines-hacks/): 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.
- [Klientu informēšana pēc incidenta](https://phpsos.de/lv/blog/kunden-nach-vorfall-informieren/): 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.
- [Piegādes ķēde tīmeklī: aģentūra, hostings, spraudņu piegādātājs](https://phpsos.de/lv/blog/lieferkette-agentur-hoster/): 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.
- [Drošības izpratne administratoriem un redaktoriem: Security Awareness tīmekļa komandā](https://phpsos.de/lv/blog/sicherheitsbewusstsein-redaktion/): 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.
- [Ārkārtas vingrinājums pie galda: izspēlēt tīmekļa servera incidentu](https://phpsos.de/lv/blog/notfalluebung-am-tisch/): 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ī.
- [ISO 27001 un TISAX: kas skar tīmekļa serverus](https://phpsos.de/lv/blog/iso-27001-tisax-webserver/): 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.
- [VdS 10000: informācijas drošība maziem un vidējiem uzņēmumiem](https://phpsos.de/lv/blog/vds-10000-kmu/): 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.
- [Lessons Learned: kļūt labākiem pēc incidenta](https://phpsos.de/lv/blog/lessons-learned-nach-vorfall/): 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.
- [Ielāpot, atslēgt vai gaidīt? Lēmuma palīgs PHP nepilnības gadījumā](https://phpsos.de/lv/blog/patchen-abschalten-abwarten/): 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.
- [WAF vai atjauninājums: kāpēc vajadzīgi abi](https://phpsos.de/lv/blog/waf-oder-update/): 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.
- [Serveri uzstādīt no jauna vai tīrīt? Lēmums pēc inficēšanās](https://phpsos.de/lv/blog/neu-aufsetzen-oder-bereinigen/): 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.
- [Novērst pašiem vai pieaicināt pakalpojumu sniedzēju? Godīga svēršana](https://phpsos.de/lv/blog/selbst-beheben-oder-dienstleister/): 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.
- [IT drošības pakalpojumu sniedzēja izvēle: 12 jautājumi pirms pasūtījuma](https://phpsos.de/lv/blog/sicherheitsdienstleister-auswaehlen/): 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.
- [Pārvaldīts hostings vai pašu serveris? Drošības salīdzinājums](https://phpsos.de/lv/blog/managed-oder-eigener-server/): 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.
- [PHP jauninājums vai atpakaļportējums? Lēmums vecām sistēmām](https://phpsos.de/lv/blog/php-upgrade-oder-backport/): 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.
- [Pēc uzlaušanas mainīt CMS? Kad tas palīdz un kad ne](https://phpsos.de/lv/blog/cms-wechsel-nach-hack/): 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.
- [Statiskas vietnes: mazāk PHP, mazāka uzbrukuma virsma](https://phpsos.de/lv/blog/statische-website-alternative/): 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.
- [Pentests, Bug Bounty vai ievainojamību skenēšana? Piemērotas pārbaudes metodes izvēle](https://phpsos.de/lv/blog/pentest-bugbounty-scan/): 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.