Pientä Ddosin poikasta pukkaa

Aloittaja weatherc, lauantai, 26.11.2016, 19:32

« edellinen - seuraava »

0 Jäsenet ja 1 Vieras katselee tätä aihetta.

weatherc

No niin....
Kuten huomattu on DEDI ollut epävakaalla tuulella tänään..

Ongelmana tutkimisen kannalta on myös ollut se että se on bootannut itsensä ties kuinka monta kertaa kernel panicin seurauksena. Painikkien tiheys on vaan kasvanut siten että viimeiset olivat alle 10 minuutin välein..

Riitävästästi leokeja kun sai tutkattua niin tais löytyä ainakin yksi syypää...Joku hakkaa euweatherin index-sivua tahtiin 10-15 kertaa sekunnissa. Ei siinä mitään mutta
- hakkaaja on spoofattu näyttämään Google botilta. Niin rerefer kuin myös IP:t (jep, useampi IP) ovat Googlen *oikeita*.
- osoitten argumenteissa on randomi rivi jotta pääsee ohi Nginx:in cachen eli jokikinen pyytnö parsitaan PHP:llä.
- IP:tten blokkaaminen palomuurilla ei auttanut

Tilapäisratkaisuna joka auttoi ainakin hetken on että koko Googlen 66.249.76.xxx IP-range on nyt blokattu Nginxillä. Tämä koskee luonnollisesti myös sitä oikeaa Googlen bottia....

Tuollaista pukkaa:
Lainaa
66.249.76.120 - - [26/Nov/2016:17:22:18 +0100] "GET /index.php?PageSpeed=noscript&lang=setrrtttttttrrtrrrrr&lang=fi HTTP/1.1" 200 17538 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"


Mikä tuossa heti pisti silmään on tuo lang=setrrtttttttrrtrrrrr, oikea Google ei tuollaisia käytä


weatherc

Tilanne hallinnassa ainakin hetken, 1h 45min uptimea kasassa  ;)

Ongelma on/oli tuo "Ddos":aaja, tosin liikenne on kuitenkin liian vähäistä ettei sitä voi kutsua Ddosiksi mutta koska sivu on aika raskas niin on tulos mikä on eli se sai varsinkin Mysqlin juntturaan ja sen asetusten rajat paukkui. Heppu kun oli myös keksinyt miten kiertää Nginxin cachen jonka tarkoitus on nimenomaan estää että samaa sivua parsitaan alusta asti liian usein. Toinen seuraus oli todennäköisesti se että koska sivun parsiminen kestää kuitenkin "hetken" niin jäi sinne ajan mittaan liikaa kyselyjä jonoon jolloin koko hienous lopuksi kaatui.

Ratkaisu oli että sai kyseiset IP:t blokattua palomuurista käsin. Hakatkoon tiiliseinää ihan rauhassa :) Sivuvaikutuksena tässä tapauksessa tosin on se että meni myös Googlen oikea botti blokkiin koska tuo heppu on spoofannut itsenä niin että se näyttää Googlen botilta.

weatherc

Kuten pikkasen arvasinkin niin ongelma oli pikkasen monimutkaisempi kuin vain joku joka hakkaa jotain URL:ia...
Tietty syyn löytäminen onkin hankalempi koska logeissa ei tietenkään ollut mitään mitä viittaisikaan yllättävään rebootin syyhyn tai yhtä outoon 500 Internal server erroriin jossa vain osa Mysql:ä käyttävät skriptit toimivat.

Noh,
- Itse purkin softat päivitetty (eli se missä viuaalisofta Proxmox raksuttaa)
- Virtuaalit päivitetty
Tässä kohtaa alkoi purkkikin pysymään pystyssä

Jäljelle jäi tuo 500-errori joka loppujen lopuksi osoittautui Nginxin aikaansaamaksi. Sillä ei jostain syystä ollut oikeuksia kirjoittaa tmp-kansioihin. Kui se on sitten tähän asti toiminut??

PS. Google botin IP 66.249.76.* on edelleen pannassa mutta tuun jossain kohtaa koikelemaan sen pois päästämistä. Ei välttämättä vielä tänään kuitenkaan.

Jussa

Ilmeisesti ongelma ei vielä ratkennut täysin?

weatherc

Lainaus käyttäjältä: Jussa - maanantai, 28.11.2016, 10:25
Ilmeisesti ongelma ei vielä ratkennut täysin?

Ei niin sekä ilmestyi uusi ongelma ???

Se oli rebootannut itsensä noin 02:30 jonka jälkeen itse dedi käynnistyi ihan OK mutta virtuaalit eivät. Kuten jo tavaksi on tullut, logeissa ei ole mitään mitä antais edes pientä osvittaa rebootin syystä...Tämä ettei virtuaalit käynnisty boottauksen yhteydessä näyttää ilmestyneen sen jälkeen kun päivitin purkin softat.
Noh, siihen löytyi helppo ratkaisu, pieni häkkyrä joka tarkistaa että ovatko virtuaalit käynnissä ja käynnistää ne tarvittaessa. Häkkyrä on testattu toimivaksi parilla koe-rebootilla.

weatherc

Taas oli rebootti. Nyt kun osuin paikalle samaan aikaan ja ajankohtakin oli tiedossa kävin läpi kaikki purkin logit jotka löytys /var/log kansiosta. Muualta ei löytynyt mitään mutta mce-logista löysys seuraava jossa aikaleima osuu yhteen buutin kanssa:

Lainaa
mcelog: Family 6 Model 5e CPU: only decoding architectural errors
Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 0
TIME 1480355226 Mon Nov 28 18:47:06 2016
MCG status:
MCi status:
Uncorrected error
Error enabled
Processor context corrupt
MCA: Internal parity error
STATUS b200000000010005 MCGSTATUS 0
MCGCAP c0a APICID 0 SOCKETID 0
CPUID Vendor Intel Family 6 Model 94

Postia lähti Hetznerin suuntaan...

weatherc

Lainaus käyttäjältä: weatherc - maanantai, 28.11.2016, 20:12
Postia lähti Hetznerin suuntaan...

Vaihtoehdot jotka annettiin oli mitä arvasinkin, täysimääräinen hardware check jossa vaihtavat mahdolliset vialliset osat tai koko purkin raudan vaihto joko uusine SSD-lättyineen tai ilman.
Valinta osui näin alkuun tuohon hardware checkiin.

Tämä tarkoitta 10-14 tunnin downtimeä alkaen tänään 28.11 klo 23 Suomen aikaa.

kekke

#7
Lainaus käyttäjältä: weatherc - lauantai, 26.11.2016, 21:51
Tilanne hallinnassa ainakin hetken, 1h 45min uptimea kasassa  ;)

Ongelma on/oli tuo "Ddos":aaja, tosin liikenne on kuitenkin liian vähäistä ettei sitä voi kutsua Ddosiksi mutta koska sivu on aika raskas niin on tulos mikä on eli se sai varsinkin Mysqlin juntturaan ja sen asetusten rajat paukkui. Heppu kun oli myös keksinyt miten kiertää Nginxin cachen jonka tarkoitus on nimenomaan estää että samaa sivua parsitaan alusta asti liian usein. Toinen seuraus oli todennäköisesti se että koska sivun parsiminen kestää kuitenkin "hetken" niin jäi sinne ajan mittaan liikaa kyselyjä jonoon jolloin koko hienous lopuksi kaatui.

Ratkaisu oli että sai kyseiset IP:t blokattua palomuurista käsin. Hakatkoon tiiliseinää ihan rauhassa :) Sivuvaikutuksena tässä tapauksessa tosin on se että meni myös Googlen oikea botti blokkiin koska tuo heppu on spoofannut itsenä niin että se näyttää Googlen botilta.



Onkohan jollain heinä persiissä meitä "säämiehiä" kohtaan.
Oma muuri vimmaantui hälyttämään ja IDS on blokannut useita ntp ddosseja.
Näitä ei ole ennen mulla kotona kyllä näkynyt. Enkä kyllä aja ulospäin mitään NTP palveluakaan.
Saattaa tietysti olla täysin sattumaakin mutta saattaa tietysti olla ettei.


ohessa pari ipeetä --->



185.35.63.71
ET DOS Possible NTP DDoS Inbound Frequent Un-Authed MON_LIST Requests IMPL 0x02 -- 2016-11-29 03:30:52
185.35.63.75
ET DOS Possible NTP DDoS Inbound Frequent Un-Authed MON_LIST Requests IMPL 0x02 -- 2016-11-29 02:31:06

Näitä riittää, samasta segmentistä ovat kaikki. DNS ei tunne hosteja ja tracert pysähtyy
tohon nodeen ----> nagravision-sa.10gigabitethernet1-1.core1.zrh1.he.net



Edit*)*************************************************************************

Eiku eiku, kaivoin vähän lisää. Väärä hälyytys. Näillä on ja kuuluukin olla se heinä siellä.

inetnum:        185.35.62.0 - 185.35.63.255
descr: This IP network is used for Internet security research. Internet-scale port scanning activities are launched from this network.
org:            ORG-KSR3-RIPE
netname:        CH-KS-INNOVATION
country:        CH
organisation:   ORG-KSR3-RIPE
org-name:       Kudelski Security Innovation
address:        Kudelski Security
address:        Antoine Junod
address:        rte de Geneve 22-24
address:        1033 Cheseaux-sur-Lausanne
address:        Switzerland
abuse-c:        ACRO895-RIPE
mnt-ref:        MNT-KSNET
mnt-by:         MNT-KSNET

source:         RIPE  Filtered





t:k
-kekke-

****************************************************************
The reason why so few good books are written,
is that so few people who can write, know anything.
FinWX Masku-24
****************************************************************

weatherc

Ei tuota dediä hakaneeta voi kutsua oikeaksi Ddosiksi, liikenne 10 kyselyä ja noin 2 Kb/s...Vika oli ennemmin siinä että sivu jota se hakkasi ei ole siitä kevyemmästä päästä mitä tulee datan hakuun.

Rautatestit ohitse ja purkki palasi linjoille joskus 03:30 aikoihin eikä raudassa ole mitään vikaa. Vaikka se hyvä asia onkin niin se teki ongelman löytämisen asteen verran hankalammaksi...
Seuraavaksi taitaa mennä Proxmox-virtuaalisofta päivitykseen heitin enterprise-repon avulla.

weatherc

Vajaat 2 vrk uptimea nytten.
Muutos jonka tein Proxmoxiin on että muutin virtuaalien "CPU-type" arvoon "host" kun se oletuksena oli "kvm64".
Seurataan tilannetta....