AI botnetai: kaip pasikeitė serverių atakos 2025–2026 metais.
AI botnetai: kaip pasikeitė serverių atakos 2025–2026 metais.
sysadmin 2024 metais tipinė WordPress ataka atrodė taip: keli IP adresai daužo wp-login.php su tuo pačiu user agent, ta pačia slaptažodžių kauke, nuspėjamais intervalais tarp užklausų. fail2ban užblokuodavo per minutę, nginx grąžindavo 429, ataka baigdavosi.
2025 metų pabaigoje vaizdas pasikeitė. Cloudflare Bot Traffic Report 2026 duomenimis, 94% visų prisijungimo bandymų WordPress svetainėse — botai. Tačiau tai nebėra skriptai su fiksuotu slaptažodžių sąrašu. Tai sistemos kurios mokosi iš klaidų realiuoju laiku: keičia user agent po kiekvieno blokavimo, variuoja intervalus tarp užklausų kad nepatektų po rate limiting, atakuoja vienu metu per xmlrpc.php, wp-login.php ir REST API — koordinuotai, iš skirtingų taškų visame pasaulyje.
Tyrinėtojų duomenimis, 35% botnet operacijų 2025 metais naudojo mašininio mokymosi algoritmus aptikimo sistemoms apeiti. Tai jau nebe masinis perrinkimas — tai adaptyvi ataka.
KAIP VEIKIA AI BOTNETAS
Klasikinis botnetas — tai užkrėstų įrenginių armija, kiekvienas vykdantis vieną instrukciją: daužyk šį URL, su šiais parametrais, tokiu dažniu. Instrukcija ateina iš C2 serverio (command and control), viskas nuspėjama.
AI botnetas veikia kitaip. Kiekvienas mazgas ne tik vykdo instrukciją — jis analizuoja serverio atsakymą ir nusprendžia ką daryti toliau. Gavo 403? Pakeisti user agent. Gavo 429? Sumažinti dažnį 40% ir palaukti. Gavo peradresavimą? Sekti jį ir bandyti dar kartą. Trijų sekundžių neatsakė? Persijungti į kitą endpoint.
Realus pavyzdys: RondoDox botnetas, dokumentuotas The Hacker News 2026 m. sausį. Sistema per devynis mėnesius praėjo tris evoliucijos fazes: rankinis skenavimas 2025 m. kovą-balandį → masinis kasdieninis WordPress, Drupal ir IoT įrenginių zondavimas balandį-birželį → kas valandinis automatizuotas diegimas nuo liepos iki gruodžio 2025. Per devynis mėnesius botnetas išmoko rasti pažeidžiamybes ir jas išnaudoti greičiau nei dauguma komandų spėja įdiegti pataisas.
Patchstack 2026 metų ataskaitos duomenimis: medianinis laikas nuo viešo pažeidžiamumo atskleidimo iki aktyvaus išnaudojimo — 5 valandos. Ne dienų. Valandų.
KUO AI BOTNETAS SKIRIASI NUO ĮPRASTO
Tapatybės rotacija
Senas botnetas naudojo vieną IP kol jis buvo užblokuotas. AI botnetas keičia IP adresus, user agent, užklausų antraštes ir net TLS fingerprint pagal išmoktą grafiką — taip kad kiekviena užklausa atrodytų kaip nauja naršyklė iš naujos šalies.
Patikrinti savo serverį dėl tokios veiklos:
# Populiariausi user agent per paskutines 24 valandas
grep "POST /wp-login.php" /var/log/nginx/access.log | \
awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20
# Dešimtys skirtingų realistiškų user agent iš skirtingų IP = AI botneto požymisDaugiavektorė koordinacija
Vietoj smūgio į vieną tašką — vienu metu atakuojami keli endpoint. Kol fail2ban blokuoja IP už smūgius į wp-login.php, kitas botneto mazgas tyliai bando slaptažodžius per xmlrpc.php iš kito IP. Tada persijungia į REST API. Tikslas — rasti neapsaugotą įėjimo tašką.
# Peržiūrėti atakas per visus WordPress endpoint vienu metu
# Išvestis: IP adresas | užklausų skaičius | atakuotų endpoint sąrašas
grep -E "wp-login|xmlrpc|wp-json" /var/log/nginx/access.log | \
awk '{print $1, $7}' | sort | \
awk '{count[$1]++; endpoints[$1]=endpoints[$1]" "$2} END {for(ip in count) if(count[ip]>5) print ip, count[ip], endpoints[ip]}' | \
sort -k2 -rn | head -20Išvesties pavyzdys:
185.220.101.42 23 /wp-login.php /xmlrpc.php /wp-login.php /xmlrpc.php
94.102.49.11 17 /wp-json/wp/v2/users /wp-login.php /xmlrpc.phpPirma eilutė — IP pakaitomis atakuoja wp-login.php ir xmlrpc.php, klasikinė daugiavektorė ataka. Antra — pradėjo žvalgyba per wp-json, tada perėjo prie brutalios jėgos. Jei matai vieną IP keliuose endpoint — tai ne atsitiktinumas.
ML slaptažodžių laužymas
Tokie įrankiai kaip PassGAN — neuroninis tinklas apmokytas ant 15,68 milijono slaptažodžių iš RockYou duomenų rinkinio — iš karto sulaužo 50% dažniausių slaptažodžių. Septynių simbolių slaptažodis iš raidžių, skaitmenų ir specialių simbolių — per šešias minutes ant vartotojo GPU. Tradicinis žodyno brutalios jėgos metodas tokio greičio nepasiekia.
Payload pasirinkimas pagal aukos profilį
Pažangūs botnetai nustato tikslinio tipo ir automatiškai pasirenka payload: korporatyviniam serveriui — ransomware, medicinos svetainei — duomenų eksfiltracija, silpnam VPS — kriptomaineris. SiliconAngle duomenimis, kai kurie botnetai nustato pelningiausią atakos scenarijų dar prieš pagrindinę fazę.
KĄ TAI REIŠKIA ADMINISTRATORIUI
Seni metodai veikia prasčiau. Keli konkretūs pavyzdžiai:
IP pagrindu veikiantis blokavimas — fail2ban blokuoja IP po N nesėkmingų bandymų. AI botnetas daro N-1 bandymų iš kiekvieno IP ir pereina prie kito. Jei botnete 10 000 mazgų ir fail2ban riba — 5 bandymai, botnetas gali padaryti 49 999 bandymus kol pirmasis IP bus užblokuotas.
Rate limiting pagal IP — ta pati problema. Limitas 10 užklausų per minutę iš vieno IP? Botnetas naudoja 100 IP ir daro po vieną užklausą per minutę iš kiekvieno. Limitas nesuveikia.
User agent filtravimas — nenaudingas prieš botnetus kurie rotavuoja realistiškus user agent iš realių naršyklių.
Kas realmente veikia 2026 metais:
KAIP APSISAUGOTI
1. Elgesio analizė vietoj IP blokavimo
Vietoj „blokuoti IP po 5 nesėkmių” — analizuoti elgesio šablonus. Vienas IP darantis po vieną bandymą? Įtartina. Šimtas IP atakuojančių vienu metu su tiksliai 60 sekundžių pauzėmis? Per sinchronizuota žmonėms.
Cloudflare Bot Management ir Cloudflare WAF su managed rules tai daro automatiškai. Nginx be Cloudflare — derinti subnet lygio rate limiting su žurnalų analize:
# Rasti /24 potinklius su anomalia veikla per paskutinę valandą
awk -v d="$(date -d '1 hour ago' '+%d/%b/%Y:%H:%M')" '$0 > d' \
/var/log/nginx/access.log | \
grep "POST /wp-login.php" | \
awk '{print $1}' | \
sed 's/\.[0-9]*$/\.0\/24/' | \
sort | uniq -c | sort -rn | head -20
# Jei vienas potinklis rodo šimtus užklausų — blokuoti jį visą nftables2. Challenge pagrindu veikianti apsauga
Cloudflare Turnstile arba CAPTCHA wp-login.php — botas negali praeiti challenge be JavaScript ir realios naršyklės aplinkos. Tai atpjauna daugumą paprastų botų. Pažangūs AI botnetai naudoja headless naršykles, tačiau tai kainuoja atakaujančiajam nepalyginamai brangiau.
3. Uždaryti visus vektorius išskyrus vieną
Jei xmlrpc.php uždarytas, wp-json users endpoint uždarytas, lieka tik wp-login.php — tai sukoncentruoja ataką vienoje vietoje ir supaprastina stebėjimą. Kuo mažesnis atakos paviršius, tuo lengviau aptikti anomalijas.
# Išsamus nginx blokavimas
location = /xmlrpc.php {
deny all; # Blokuoti visas užklausas — grąžina 403 Forbidden
access_log off; # Nerašyti į žurnalą — netaršyti disko botų užklausomis
}
location ~* ^/wp-json/wp/v2/users {
deny all;
access_log off;
}
# limit_req_zone — rate limiting zona, skelbiama http{} bloke
# $binary_remote_addr — raktas: kliento IP dvejetainiu formatu (4 baitai, taupo atmintį)
# zone=wplogin:10m — zonos pavadinimas ir atminties dydis (10 MB ≈ 160 000 IP adresų)
# rate=1r/m — maksimaliai 1 užklausa per minutę iš vieno IP
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=1r/m;
location = /wp-login.php {
# burst=3 — leisti eilę iki 3 užklausų viršijant limitą (teisėtiems vartotojams)
# nodelay — eilėje nelaikyti užklausų, iš karto grąžinti 503 jei limitas viršytas
limit_req zone=wplogin burst=3 nodelay;
fastcgi_pass unix:/run/php/php8.3-fpm.sock; # Perduoti užklausą PHP-FPM per Unix socket
include fastcgi_params; # Įtraukti standartinius FastCGI parametrus
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # Kelias į PHP failą
}Svarbus niuansas: limit_req_zone skelbiamas http{} bloke nginx.conf, o ne server{} viduje. Įdėjus į server{} — nginx nepasileis su klaida „limit_req_zone” is not allowed here.
Patikrinti konfigūraciją ir perkrauti:
nginx -t && systemctl reload nginx4. Anomalijų stebėjimas realiuoju laiku
AI botnetai atsiskleidžia ne atskirais IP adresais, o šablonais. Stebėti reikia ne „kiek užklausų iš šio IP” o „kaip atrodo srautas apskritai”:
# Unikalių IP atakuojančių wp-login per paskutines 5 minutes skaičius
awk -v d="$(date -d '5 minutes ago' '+%d/%b/%Y:%H:%M')" \
'$0 > d && /POST \/wp-login.php/' /var/log/nginx/access.log | \
awk '{print $1}' | sort -u | wc -l
# Daugiau nei 20 unikalių IP per 5 minutes = koordinuota ataka5. Application Passwords ir 2FA
Net jei botnetas gavo teisingą prisijungimo vardą per wp-json — Application Passwords (WordPress 5.6+) ir dviejų faktorių autentifikacija daro slaptažodžių brutalios jėgos ataką beprasmę. Tai pigiausia apsauga su didžiausiu efektu.
6. nftables — blokavimas prieš nginx
nginx ir PHP — tai jau grandinės pabaiga. Iki tol kol užklausa pasiekia wp-login.php, serveris jau išnaudojo išteklius TCP ryšiui, TLS rankos paspaudimui ir HTTP antraščių apdorojimui. nftables pjauna srautą branduolio lygmeniu — prieš nginx, prieš PHP, prieš viską.
Blokuoti konkretų IP rankiniu būdu:
nft add element inet filter blocklist { 185.220.101.42 }
# Patikrinti kad pridėtas
nft list set inet filter blocklistBlokuoti visą potinklį kai iš jo ateina koordinuota ataka:
nft add element inet filter blocklist { 185.220.101.0/24 }Automatizuoti blokavimą pagal nginx žurnalus — skriptas kuris paima populiariausius atakuojančius potinklius ir prideda juos į nftables:
#!/bin/bash
# Rasti potinklius su daugiau nei 50 užklausų į wp-login per paskutinę valandą
awk -v d="$(date -d '1 hour ago' '+%d/%b/%Y:%H:%M')" '$0 > d' \
/var/log/nginx/access.log | \
grep "POST /wp-login.php" | \
awk '{print $1}' | \
sed 's/\.[0-9]*$/\.0\/24/' | \
sort | uniq -c | sort -rn | \
awk '$1 > 50 {print $2}' | \
while read -r subnet; do
nft add element inet filter blocklist { $subnet }
echo "Blocked: $subnet"
doneRate limiting nftables lygmeniu — apriboti naujų TCP ryšių skaičių į 80 ir 443 portus iš vieno IP. Teisingas būdas per meter — per-IP skaitiklis be išankstinio atminties paskirstymo kiekvienam adresui:
# Pridėti į chain input{} sekciją nftables konfigūracijoje
# Meter skaičiuoja naujus ryšius per IP, viršijus limitą — drop
tcp dport { 80, 443 } ct state new \
meter http_limit { ip saddr limit rate over 20/second } dropJei reikia pridėti viršijusius limitą į blocklist su automatišku galiojimo pabaiga. Pastaba: limit rate be meter yra globalus viso srauto limitas, ne per-IP. Per-IP naudok meter iš ankstesnio bloko. Šis variantas naudingas bendrai SYN flood apsaugai:
# Pirma paskelbti dinaminį set su timeout table sekcijoje:
# set blocklist {
# type ipv4_addr
# flags dynamic, timeout
# timeout 1h
# }
# Tada taisyklė chain input{}:
tcp dport { 80, 443 } ct state new \
limit rate over 20/second \
add @blocklist { ip saddr } dropSkirtumas nuo nginx rate limiting esminis: nginx skaičiuoja užklausas HTTP lygmeniu — ryšys jau užmegztas. nftables skaičiuoja TCP SYN paketus — ryšys dar neatidarytas. Tai reiškia kad DDoS atakos su tūkstančiais ryšių metu nftables apsaugo nginx nuo perkrovos, o ne atvirkščiai.
fail2ban su nftables backend automatizuoja visą procesą — sukonfigūravus jail wp-login.php, jis automatiškai prideda IP į nftables set viršijus ribą:
# Patikrinti kad fail2ban naudoja nftables
fail2ban-client get sshd banaction
# Turėtų rodyti: nftables-multiport arba nftables-allports
# WordPress jail statusas
fail2ban-client status nginx-wploginREALŪS SKAIČIAI 2025–2026
Iš viešai prieinamų ataskaitų:
- 94% WordPress prisijungimo bandymų — botai (Cloudflare Bot Traffic Report 2026)
- 35% botnet operacijų naudojo ML aptikimui apeiti 2025 metais
- Medianinis laikas nuo pažeidžiamumo atskleidimo iki išnaudojimo: 5 valandos (Patchstack 2026)
- 11 334 nauji pažeidžiamumai WordPress ekosistemoje 2025 metais, 42% augimas per metus (Patchstack 2026)
- 91% pažeidžiamumų — papildiniuose, ne WordPress branduolyje
Paskutinis skaičius svarbus: papildinių atnaujinimas tą dieną kai išleidžiama pataisa — tai jau nebe rekomendacija, tai minimalus standartas.
KAIP SUPRASTI KAD TAI AI BOTNETAS O NE PAPRASTAS
Paprastas botnetas palieka grubius pėdsakus: tie patys user agent, tas pats potinklis, nuspėjami intervalai. AI botnetas atrodo kitaip — ir tai matoma žurnaluose.
Požymis 1: skirtingi user agent atakuoja tą patį endpoint.
# Kiek unikalių user agent atakavo wp-login per paskutinę valandą?
grep "POST /wp-login.php" /var/log/nginx/access.log | \
awk -F'"' '{print $6}' | sort -u | wc -l
# Paprastas botnetas: 1-3 unikalūs UA
# AI botnetas: 20-50+ skirtingų realistiškų UAPožymis 2: atakos srautas paskirstytas netolygiai laike, bet be akivaizdžių šablonų.
# Peržiūrėti užklausų pasiskirstymą pagal minutes
grep "POST /wp-login.php" /var/log/nginx/access.log | \
awk '{print $4}' | cut -d: -f1,2,3 | sort | uniq -c
# Paprastas botnetas: lygūs intervalai (kas sekundę, kas 5 sekundes)
# AI botnetas: nereguliarios intervalai, imituojantys žmogųPožymis 3: ataka vienu metu nukreipta į kelis endpoint iš skirtingų IP.
# Unikalių IP atakuojančių skirtingus endpoint skaičius
grep -E "wp-login|xmlrpc|wp-json" /var/log/nginx/access.log | \
awk '{print $1}' | sort -u | wc -l
# 50+ unikalių IP atakuoja skirtingus taškus = koordinuotas botnetasPožymis 4: užklausų kiekis nesuveikia rate limiting, bet atakuojančių IP skaičius akivaizdžiai nenormalus.
Jei viską tai matai vienu metu — tai AI botnetas. Atskiras IP blokavimas nepadės.
KĄ DARYTI JEI ATAKA JAU VYKSTA
Žingsnis po žingsnio planas kai svetainė jau atakuojama ir reikia veikti greitai.
1 žingsnis — įvertinti mastą:
# Kiek wp-login užklausų paskutinėse 1000 žurnalo eilučių?
tail -n 1000 /var/log/nginx/access.log | grep -c "wp-login"
# Stebėti srautą realiuoju laiku (Ctrl+C išeiti):
tail -f /var/log/nginx/access.log | grep "wp-login"
# Kiek unikalių IP per paskutines 10 minučių?
awk -v d="$(date -d '10 minutes ago' '+%d/%b/%Y:%H:%M')" \
'$0 > d' /var/log/nginx/access.log | \
grep "wp-login" | awk '{print $1}' | sort -u | wc -l2 žingsnis — nedelsiant įjungti Cloudflare Under Attack Mode jei svetainė už Cloudflare:
Valdymo skydelyje: Security → Settings → Security Level → I’m Under Attack. Cloudflare prideda JS challenge visiems lankytojams. Botai atfiltruojami akimirksniu, teisėti vartotojai praeina per 5 sekundes.
3 žingsnis — laikinai blokuoti wp-login.php per nginx visiems išskyrus savo IP:
# Laikinas blokavimas nginx — pridėti į server{}
location = /wp-login.php {
allow TAVO_IP;
deny all;
}nginx -t && systemctl reload nginx4 žingsnis — leisti fail2ban surinkti likusius:
# Patikrinti kas jau užblokuota
fail2ban-client status nginx-wplogin
# Rankiniu būdu užblokuoti potinklį
fail2ban-client set nginx-wplogin banip 185.220.101.0/245 žingsnis — po stabilizavimo atlikti analizę: iš kur atėjo ataka, kokie endpoint buvo atakuojami, ką praleido apsauga.
KAIP NUSTATYTI ĮSPĖJIMUS IKI SVETAINĖ KRENTA
Ataką geriau aptikti likus 10 minučių iki kritimo nei po jo. Keli būdai.
Paprastas įspėjimas per bash + systemd timer — suveikia kai unikalių atakuojančių IP skaičius viršija ribą:
#!/bin/bash
# /usr/local/bin/check-wp-attack.sh
THRESHOLD=30
COUNT=$(awk -v d="$(date -d '5 minutes ago' '+%d/%b/%Y:%H:%M')" \
'$0 > d && /POST \/wp-login.php/' /var/log/nginx/access.log | \
awk '{print $1}' | sort -u | wc -l)
if [ "$COUNT" -gt "$THRESHOLD" ]; then
echo "ALERT: $COUNT unique IPs attacking wp-login.php in last 5 min" | \
mail -s "WordPress attack detected: $(hostname)" [email protected]
fiPaleisti per systemd timer kas 5 minutes:
# /etc/systemd/system/wp-attack-check.service
[Unit]
Description=Check for WordPress brute force attack
[Service]
Type=oneshot
ExecStart=/usr/local/bin/check-wp-attack.sh# /etc/systemd/system/wp-attack-check.timer
[Unit]
Description=Run WordPress attack check every 5 minutes
[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
[Install]
WantedBy=timers.targetsystemctl enable --now wp-attack-check.timer
systemctl list-timers | grep wp-attackNaudojant Cloudflare — sukonfigūruoti įspėjimus Security → Notifications → Under Attack Mode Activation ir Custom Firewall Rules Triggered.
HONEYPOT IR GEO-BLOKAVIMAS
Honeypot — spąstai botams
Idėja paprasta: sukurti URL kurį niekada neužklausia teisėtas vartotojas, tačiau kurį botai randa skenuodami. Bet kokia užklausa į jį — automatiškai botas.
Sukurti honeypot endpoint nginx:
location = /wp-admin/install.php {
# Teisėtas vartotojas niekada neužklausia šio veikiančioje svetainėje
# Bet kokia užklausa = botas
access_log /var/log/nginx/honeypot.log;
return 403;
}
# Pastaba: nginx location blokai nematcho query string.
# Norint blokuoti ?action=register, naudoti if server{} kontekste:
# if ($arg_action = "register") {
# access_log /var/log/nginx/honeypot.log;
# return 403;
# }Automatiškai drausti visus kas beldžiasi į honeypot per fail2ban:
# /etc/fail2ban/filter.d/nginx-honeypot.conf
[Definition]
failregex = ^<HOST> - - \[.*\] "(GET|POST) /(wp-admin/install\.php|wp-login\.php\?action=register).* HTTP/.*" \d+
ignoreregex =# /etc/fail2ban/jail.d/nginx-honeypot.conf
[nginx-honeypot]
enabled = true
port = http,https
filter = nginx-honeypot
logpath = /var/log/nginx/honeypot.log
maxretry = 1
bantime = 604800 # 7 dienų
action = nftables-multiport[name=honeypot, port="80,443", protocol=tcp]Viena užklausa — iš karto 7 dienų draudimas. Teisėtas vartotojas ten niekada nenueis.
Geo-blokavimas per nftables
Jei svetainė veikia konkrečiame regione — srautas iš kitų regionų gali būti atpjautas branduolio lygmeniu. Lietuvių kalba rašomam tinklaraščiui nėra priežasties priimti ryšius iš Brazilijos ar Indonezijos 3 valandą nakties.
Per Cloudflare — paprasčiausias būdas: Security → WAF → Tools → IP Access Rules → Block country.
Per nftables su IP sąrašais iš ipdeny.com:
# Atsisiųsti IP blokavimo sąrašą (pvz., Kinija)
wget -q http://www.ipdeny.com/ipblocks/data/aggregated/cn-aggregated.zone \
-O /etc/nftables/geo-block-cn.txt
# Sukurti set ir pridėti taisyklę
nft add set inet filter geo_block { type ipv4_addr\; flags interval\; }
nft add rule inet filter input ip saddr @geo_block drop
# Įkelti IP adresus į set
while read -r cidr; do
nft add element inet filter geo_block { $cidr }
done < /etc/nftables/geo-block-cn.txtSvarbu: geo-blokavimas yra grubus įrankis. Jis taip pat blokuoja teisėtus vartotojus iš užblokuotų regionų. Naudok tik kai esi tikras kad svetainės auditorija geografiškai ribota.
Kodėl WordPress yra pagrindinis AI botnetų taikinys
Ne todėl kad WordPress mažiau saugus nei kitos TVS. Dėl masto: W3Techs duomenimis, daugiau nei 43% visų interneto svetainių veikia ant WordPress. Vienas botnetas su vienu taisyklių rinkiniu vienu metu atakuoja milijonus potencialių taikinių.
Matematika paprasta: botneto nuoma kainuoja dešimtis dolerių per dieną, o pažeistas serveris su gera domeno reputacija tamsiojo interneto rinkose kainuoja nuo 500 iki kelių tūkstančių dolerių. WordPress ataka atsipirka greitai.
Antras veiksnys: nuspėjama struktūra. Kiekviena WordPress svetainė turi tuos pačius endpoint — wp-login.php, xmlrpc.php, wp-json, wp-admin. Botnetas žino kur ieškoti be jokios išankstinės žvalgybos.
KUR VISA TAI EINA
Tai kas vyksta dabar — tik pradžia. Kelios tendencijos kurios jau matomos ir toliau stiprės.
Atakos be žmogaus dalyvavimo
Šiandien AI botnetai vis dar valdomi žmonių — kažkas paleidžia kampaniją, nustato tikslus, analizuoja rezultatus. Kitas žingsnis — visiškai autonominės sistemos kurios savarankiškai pasirenka tikslus, adaptuoja taktiką ir monetizuoja prieigą. Pirmieji požymiai jau yra: RondoDox per devynis mėnesius perėjo nuo rankinio skenavimo iki kas valandinio automatizuoto diegimo be matomo operatorių dalyvavimo.
AI prieš AI
Tai jau vyksta. Cloudflare Bot Management, Wordfence, Imperva — visi naudoja mašininį mokymąsi anomalijoms aptikti. Užpuolikai žino apie šias sistemas ir apmokyti savo botus apeiti būtent jas. Atsiranda ginklavimosi varžybos kur abi pusės iteruoja greičiau nei žmonės spėja analizuoti.
Darktrace State of AI Cybersecurity 2025 ataskaitos duomenimis, 78% informacijos saugumo direktorių pranešė kad AI atakos reikšmingai veikia jų organizacijas. Tuo pačiu daugiau nei 60% teigė kad jaučiasi pasiruošę apsiginti — 15% augimas lyginant su 2024 metais. Tačiau nepakankamos žinios apie AI ir personalo trūkumas išlieka pagrindiniais barjerais.
Ribos tarp boto ir žmogaus išblukimas
Headless naršyklės su AI gali imituoti žmogaus elgesį — pelės judėjimą, pauzes tarp paspaudimų, slinkimą, realistinį puslapio skaitymo laiką. CAPTCHA kuri 2020 metais sustabdydavo 99% botų, 2026 metais sustabdo žymiai mažiau. Cloudflare Turnstile ir panašios sistemos persikėlė nuo „įrodyk kad esi žmogus” į visos sesijos elgesio analizę — tačiau užpuolikai adaptuojasi ir prie to.
Ką tai reiškia administratoriui
Profesija keičiasi. Anksčiau pakakdavo sukonfigūruoti taisykles — fail2ban uždraus, nftables blokuos, ir galima ramiai miegoti. Dabar taisyklės statiškos, o atakos dinaminės. Vis daugiau laiko eina ne konfigūruojant apsaugą, o analizuojant šablonus, interpretuojant anomalijas, suprantant užpuoliko logiką.
Geros naujienos: apsaugos įrankiai taip pat tampa protingesni. Cloudflare, Wordfence Premium, Imunify360 — tai jau ne tik taisyklės, o adaptyvinės sistemos. Administratoriaus vaidmuo pereina nuo „parašyti taisyklę” prie „teisingai sukonfigūruoti ir interpretuoti ką AI apsauga randa.”
Blogos naujienos: įėjimo barjeras užpuolikams mažėja. Anksčiau sudėtingai koordinuotai atakai reikėjo žinių ir išteklių. Dabar pakanka išsinuomoti paruoštą AI botnetą kaip paslaugą — tokie pasiūlymai jau egzistuoja tamsiojo interneto rinkose.
Internetas tampa vieta kur didžiąją dalį srauto generuoja mašinos, atakuojančias mašinas gina mašinos, o žmonės vis labiau atsiduria operatorių ir analitikų vaidmenyje — o ne kasdienių užduočių vykdytojų.
IŠVADA
AI botnetai nepakeitė atakų tikslų — wp-login.php, xmlrpc.php, REST API, nepataisyti papildiniai. Jie pakeitė greitį ir adaptyvumą. Tai kas anksčiau buvo blokuojama per minutę dabar gali nepastebimai veikti valandas.
Gera žinia: bazinė higiena vis dar veikia. Uždarytas xmlrpc.php, uždarytas wp-json users endpoint, rate limiting wp-login.php, atnaujinti papildiniai ir 2FA — ne stebuklingas sprendimas, bet pakankamai kad svetainė išeitų iš „lengvo taikinio” kategorijos.
Botai atakuoja viską iš eilės. Tikslas nėra tapti nepažeidžiamam — tikslas tapti pakankamai sunkiu taikiniu kad botnetas persijungtų į kitą svetainę eilėje.
Jei jums patiko straipsnis, galite paremti autorių.
