internetin uhat ja vaikutus omille sivuille

[einari]

Periaatteessa palveluntarjoajan pitäisi suojata riittävästi asiakkaan kotisivut ja plogit murtautumisyrityksiltä, mutta käytännössä se ei mene niin. Sen sain itse havaita 16.11.2023 kun muutamassa tunnissa 2240  kirjautumisyritystä sivuilleni tapahtui, Limit login attemps varoitti brute force-hyökkäyksen mahdollisuudesta. Onneksi salasana oli riittävän vahva, noin 20 merkkinen jonka murtamiseen menee yhdeltä koneelta noin 8 vuotta.. mutta kun kyseisessä hyökkäyksessä hyökkääjä valjastaa "kaapatut" ip-osoitteet toteuttamaan hyökkäystä niin matemaattisesti ajatellen 8 ip-osoitetta tekee vuoden.. 365 päivän.. 8670 tunnin jne... 

Tuosta voisi päätellä että ensisijaisesti salasanan vahvuus on merkitsevä, tokihan kaksivaiheinen tunnistautuminen olisi lisäturva.. mutta onneksi on apuohjelmia siihen ja kaikenlaiseen häirintään kuten spammeihin.

Kun kaikki paljastui minulle niin palveluntarjoajan suunnalla xml-rcp esto oli pudonnut pois, syysksi arvelivat jotain lisäosaa, mutten oikein usko siihen.. lienee heidän virhe. Niinpä laitoin kyseisen suojauksen päälle xml-rcp secure lisäosalla, sen jälkeen hyökkäykset loppuivat, mietin kuitenkin asiaa ja päädyin asentamaan Ninja Firewall- lisäosan joka poimi bothit pois ja kun rest-apin eston laitoin niin huomsi miten kirjautumisyritykset jatkuivat.. tosin sillä rest.apin estolla on haittansakin, toistaiseksi toimii ok sivut.. eikä minusta sivuni tarvi antaa admin.ajax tai index.apiin kenenkään tulla...

En kuitenkaan ollut tyytyväinen tilanteeseen koska en voinut itse määritellä sitä kellä on lupa tai ei, löysin clean talk ohjelmiston ja tuntuu oikein hyvältä.. ajattelin pistää ninja firewallin tauolle ja katsoa miten käy..
se asentuu myös muihinkin kuin wordpressiin... 

Kai ne ninja ja cleantalk yhdessä poistelevat mikä ensiksi saa uhat haaviin??   

Kuva ohjauspaneelista

[khyron]

Periaatteessa palveluntarjoajan pitäisi suojata riittävästi asiakkaan kotisivut ja plogit murtautumisyrityksiltä, mutta käytännössä se ei mene niin.

Ei se myöskään voi mennä niin, tai ehkä jossain ihan perus sivuissa missä on pelkästään staattista sisältöä. Joku managed servicekin on jo hankala jos asiakas pääsee edes jotain konffaamaan. Sit jos asiakas ite pääsee asentelemaan valmissoftia, tai asentelemaan jopa omia tuotoksiaan missä on mitä sattuu haavoittuvuuksia niin aika mahdoton olis palveluntarjojan niitä valvoa. Korkeintaan voisi ajaa jonkun skannerin mikä tiedottaa asiakas haavoittuvuuksista, mutta sekin vaatisi että asiakas tekee niille jotain.

[einari]

Ei se myöskään voi mennä niin, tai ehkä jossain ihan perus sivuissa missä on pelkästään staattista sisältöä. Joku managed servicekin on jo hankala jos asiakas pääsee edes jotain konffaamaan. Sit jos asiakas ite pääsee asentelemaan valmissoftia, tai asentelemaan jopa omia tuotoksiaan missä on mitä sattuu haavoittuvuuksia niin aika mahdoton olis palveluntarjojan niitä valvoa. Korkeintaan voisi ajaa jonkun skannerin mikä tiedottaa asiakas haavoittuvuuksista, mutta sekin vaatisi että asiakas tekee niille jotain.

Kyllä olet oikeassakin, mutta kun kyseessä on palveluntarjoajan hallinnoima ja isännöimä wordpress-kotisivutila niin pitäisi oletuksena oleva XML-RCP.PHP pysyä disabloituna varsinkin kun on tiedossa kyseisen takaportin antama mahdollisuus murtaa Admin-salasana ja sitä kautta valjastaa ip-osoite brute force tai palvelunestohyökkäykseen..  Noiden muiden kanssa kyllä pärjää, tosin ei houkuttele myöskään spam-listoille päätyminen..  Tuossa eilinen raportti, alibaba spammailee... ja babbar.eu on jatkuvasti pommittamassa...

[khyron]

No toi on toki vähän epäilyttävää jos managed serviceen tulee turvattomia plugineja yllättäen ja pyytämättä päälle.

[weatherc]

Periaatteessa palveluntarjoajan pitäisi suojata riittävästi asiakkaan kotisivut ja plogit murtautumisyrityksiltä, mutta käytännössä se ei mene niin.

Ei se mene niin. Asiakas on täysin itse vastuussa purkille asentamistaan palikoista ja niiden mahdollista aiheuttamista vahingoista. Aina.
Turvallisuutta ja Wordpressiä ei myöskään voi käyttää samassa lauseessa.
Tämä mm koska se on niin suosittu että myös sen kaikki haavoituvuudet ovat hyvin tiedossa. Ja niitähän riittää.
Jos palveluntarjoaja on itse laittanut jotain plugarieta päälle niin se on heidän onglemansa, ei sun. Jos ovat turvattomia, niin kertonee pikemmin palveluntarjoajan tasosta/osaamisesta. Halvalla kun ei saa hyvää näissäkään jutuissa.

Kannatta myös lukaista palveluntarjoajan tiedoista että mitä se managed oikeasti tarkoittaa ja sisältää. Niissä tarjoaja todennäköisesti viertää vastuun lähes kaikesta asiakkaalle loppupeleissä.

Toisaalta, fakta on vaan myös se, että on purkki/sivsto mikä tahansa niin voi niihin kohdistua isotkin määrät kirjautumisyrityksiä. Tämä mm siksi että purkin ip-numero on voinut olla käytössä ties missä aikasemmin ennen nykyistä käyttöä (törmätty mm siihen että jokun dedi-version ip oli blokattu osassa välityspalvelimia, eli liikenne ei kulkenut). Ei niitä mikään palomuuri tms estä mutta pitää ne kurissa.
Esim dedille niitä tulee satoja päivässä. Mutta sitä varten on Brute Force Monitor ja LFD olemassa
 

[J.Jäntti]

Täällä vastaavat yritykset pysähtyvät omaan palomuuriin sellaisenaan, johtuen toki siitä että FinWX:ää ja sen palveluita pyöritetään konesalin sijaan ns. on-premises tyyliin. Kaikki kontrolli itsellä tuo toki lisähommaa, kuten laitteiston toiminnan seuraamista ja ylläpitoa, mutta sepä onkin tässä oman ammattitaidon ylläpitämisen kannalta vain hyväksi ja hyödyksi.