Tulevan IP osoitteen estäminen

[angle]

Sattumalta huomasin reitittimen lokista jotain poikkeavaa.

Jul 5 09:07:43 dropbear[589]: Child connection from 197.3.7.157:54544
Jul 5 09:07:47 dropbear[589]: Login attempt for nonexistent user from 197.3.7.157:54544
Jul 5 09:07:48 dropbear[589]: Exit before auth: Exited normally

Noita siis useampia aina parin tunnin välein ja eri portteihin kohdistuneena. Yrittääköhän joku skannata mun SSH palvelun porttia? Tai jotain muuta? Mulla on myös VPN serveri päällä reitittimessä.

Netin syövereistä löytyi jotain ohjeita tulevan IP osoitteen estämiseksi iptables komentojen avulla.

Kun mun reitittimeen saa lisättyä noita iptables komentoja niin lisäsinkin jo seuraavan rivin sinne.

iptables -A INPUT -s 197.3.7.157 -j DROP

Mahtaakohan tuo tehdä tehtävänsä?

 

[bindi]

- Vaihda SSH:n portti pois defaultista
- root login pois (tosin ei varmaan mahdollista reititinympäristössä)
- salasanalogin pois (public key authentication tilalle)
- mieti tarvitsetko edes SSH:ta reitittimeesi etänä?

 

[Tataz]

Noinhan se menee, mutta ei se maksa vaivaa yksittäisiä IP-osoitteita estellä. Kaikkia julkiseen verkkoon kytkettyjä laitteita käydään automatisoidusti koputtelemassa koko ajan eikä siitä kannata huolissaan. Toki kannattaa pitää palomuuri päällä ja avata portit vain niille palveluille, joita tarvitsee.

Joo koputteluja tulee ja sinnikkäästi samoista IP-osoitteista yritetään kirjautua. Login perusteella viimeisen 12 tunnin aikana fail2ban on bannannut 42 eri IP-osoitetta. Suurin sallittu kirjautumisyritysten määrä on 6 kappaletta, jonka jälkeen seuraa 30 minuutin banni.

Spoileri

cat fail2ban.log | grep Ban | cut -d' ' -f5-8 | sort | uniq -u
[ssh] Ban 109.63.212.69
[ssh] Ban 111.59.163.35
[ssh] Ban 117.64.82.139
[ssh] Ban 123.52.244.190
[ssh] Ban 12.87.106.234
[ssh] Ban 148.63.179.217
[ssh] Ban 150.255.123.185
[ssh] Ban 153.37.119.243
[ssh] Ban 158.174.74.224
[ssh] Ban 180.175.89.243
[ssh] Ban 183.159.192.150
[ssh] Ban 183.187.250.177
[ssh] Ban 185.143.223.136
[ssh] Ban 188.255.196.58
[ssh] Ban 190.178.40.135
[ssh] Ban 190.6.177.22
[ssh] Ban 211.198.6.96
[ssh] Ban 213.57.26.237
[ssh] Ban 218.108.74.250
[ssh] Ban 218.92.0.133
[ssh] Ban 218.92.0.138
[ssh] Ban 218.92.0.140
[ssh] Ban 218.92.0.144
[ssh] Ban 218.92.0.154
[ssh] Ban 218.92.0.167
[ssh] Ban 218.92.0.172
[ssh] Ban 27.15.189.73
[ssh] Ban 27.5.162.246
[ssh] Ban 36.33.216.194
[ssh] Ban 37.139.107.228
[ssh] Ban 37.187.159.53
[ssh] Ban 5.138.142.187
[ssh] Ban 54.39.145.59
[ssh] Ban 62.102.148.67
[ssh] Ban 69.158.249.72
[ssh] Ban 70.162.88.248
[ssh] Ban 78.188.13.253
[ssh] Ban 84.53.198.98
[ssh] Ban 91.121.156.98
[ssh] Ban 95.83.37.67
[ssh] Ban 95.84.206.21
[ssh] Ban 98.235.133.140

Edit:
Katsoin millaisillä käyttäjänimillä perinteisen rootin lisäksi yritetään kirjautua.
Failed password for invalid user 111 Failed password for invalid user 123321 F - Pastebin.com

SSH ei logita kokeiltuja salasanoja, mutta SSH:n saa logittamaan salasatkin, jos tekee muutoksia lähdekoodiin.

Edit2:
Otin useammalta päivältä bannattuja IP-osoitteita ja tein niistä heat mapin ( Heatmaps ).

 

[dot1q]

Jännä juttu että Kiinassa punane täplä. Melkein yllättää mut. Täytyykin liipasta Pfsenseen China -> Mun muuri nullroute päälle. En mä sieltä mitään tartte. Hyvää keskustelua, 5/5.

 

[angle]

Kiitoksia kommenteista. SSH:n portin olen jo aiemmin vaihtanut pois oletuksesta. SSH:ta silloin tällöin tulee käytettyä. Salasanasuojaus ja brute force esto käytössä.

 

[telcoM]

iptables -A INPUT -s 197.3.7.157 -j DROP

Mahtaakohan tuo tehdä tehtävänsä?

Tuossa on sellainen juttu, että iptables-sääntöjen järjestyksellä on väliä: ensimmäinen täsmäävä sääntö ratkaisee paketin kohtalon. Tuo komento lisää säännön listan loppupäähän.

Jotta tietäisi onko tuolla toivottu vaikutus vai ei, pitäisi nähdä koko INPUT-sääntölista tuon lisäyksen jälkeen.
Siinäkin on pieni knoppi: pelkkä "iptables -L" ei näytä onko jokin sääntö sidottu vaikuttamaan vain tiettyyn verkkoliitäntään vai ei, joten olisi parempi käyttää vaikka "iptables -L -vn"-listausta josta näkyy kaikki oleellinen, tai sitten "iptables -S"-komentoa joka listaa säännöt iptables-komennolle annettavien optioiden muodossa.

Jos aiempana on esim. sääntö joka päästää porttiin 54544 saapuvan liikenteen läpi lähtö-IP:stä riippumatta tyyliin "iptables -A INPUT -p tcp --dport 54544 -j ACCEPT", silloin tuon säännön lisäämisellä sääntölistan loppuun ei ole mitään vaikutusta portin 54544 liikenteeseen. Sääntö pitäisi tällöin lisätä listan alkuun, eli

iptables -I INPUT 1 -s 197.3.7.157 -j DROP

lisää tuon säännön nimenomaisesti INPUT-listan ensimmäiseksi säännöksi.

SSH:n siirtäminen pois oletusportista toki vähentää skannailuyrityksiä jonkin verran, mutta nykyisin se ei enää tehoa niin hyvin kuin joskus aikaisemmin, koska bottiverkkoon kaapatut koneet ym. yhä useammin skannaavat kaikki portit läpi ja löytävät sen SSH-portin kuitenkin.

Siksi suosittelisin että jos pidät SSH:ta auki ulkomaailmaan päin. kannattaisi SSH-palvelun asetuksissa kieltää salasana-autentikoinnin käyttö kokonaan ja käyttää sen sijaan SSH-avainautentikointia jos suinkin mahdollista. Silloinkin SSH-palvelu saattaa tarjota sisään yrittäjälle mahdollisuuden salasanan syöttämiseen, mutta mikään salasana ei tällöin tule kelpaamaan vaan salasanapyyntö esitetään vain jotta saadaan tunkeutuja tuhlaamaan aikaansa toivottomaan salasanojen arvailuun. Lisäksi tällöin SSH-palvelinpää voi tietoisesti... hidastaa... vastausten... lähettämistä, jotta tunkeutujalle näyttää siltä kuin kohdekone olisi heikkotehoinen ja/tai kovassa kuormassa, vaikka palvelinpää oikeastaan vastaa tuollaiselle uunotettavalle vasta sitten kun kaikki muu tärkeämpi on tehty ja sattuu huvittamaan.

Yksittäisten IP-estojen tekeminen käsipelillä ei pitemmän päälle maksa vaivaa: kun estät yhden osoitteen, joku toinen saman bottiverkon kone jatkaa todennäköisesti kohta kolkuttelua. Jos noista on oikeasti vaivaa, tarvittaisiin joku fail2ban-tyyppinen systeemi joka automaattisesti bannaa joksikin aikaa IP-osoitteen josta on tullut yli X epäonnistunutta yritystä tietyn ajan sisällä, ja (haluttaessa) purkaa bannin automaattisesti kun kolkuttelun loppumisesta on kulunut tarpeeksi aikaa.

 

[Tataz]

Siksi suosittelisin että jos pidät SSH:ta auki ulkomaailmaan päin. kannattaisi SSH-palvelun asetuksissa kieltää salasana-autentikoinnin käyttö kokonaan ja käyttää sen sijaan SSH-avainautentikointia jos suinkin mahdollista. Silloinkin SSH-palvelu saattaa tarjota sisään yrittäjälle mahdollisuuden salasanan syöttämiseen, mutta mikään salasana ei tällöin tule kelpaamaan vaan salasanapyyntö esitetään vain jotta saadaan tunkeutuja tuhlaamaan aikaansa toivottomaan salasanojen arvailuun. Lisäksi tällöin SSH-palvelinpää voi tietoisesti... hidastaa... vastausten... lähettämistä, jotta tunkeutujalle näyttää siltä kuin kohdekone olisi heikkotehoinen ja/tai kovassa kuormassa, vaikka palvelinpää oikeastaan vastaa tuollaiselle uunotettavalle vasta sitten kun kaikki muu tärkeämpi on tehty ja sattuu huvittamaan.

Muokkasin Debianissa tiedostoa /etc/pam.d/sshd . Lisäsin asetuksiin rivin

auth  optional  pam_faildelay.so  delay=5000000

Tämä tuottaa väärän salasanan jälkeen 5 sekunnin viiveen.
How to Provide login delay in ssh

 

[angle]

No koitinpa saattaa käyttöön tätä avaintiedosto tunnistusta tässä minun Asus N56U reitittimessä, padavan firmiksellä. Taitaa olla vähän puginen firmis tämän osalta kun web liittymän kautta julkinen avain ei jää muistiin vaan piti tehdä tämän ohjeen avulla. Näin avain ilmestyi myös web hallintasivulle. Puttyyn en tehnyt muita muutoksia kuin lisäsin polun siihen avain tiedostoon. Ja sen puttyn pageant ohjelman laitoin taustalle ja sinne vielä avaintiedoston fraasilla avattu avain.

Putty herjaa
No supported authentication methods available (server sent: publickey)

Puttyä en nyt kauheammin tunne, että teinkö oikein? vai mahtaako serverin puolella olla sittenkin jotain väärin?

Muoks. Hetikin selvisi. Julkinen avain oli kopioitu siitä puttygen luomasta julkinen avain tiedostosta. Sillä ei toiminut. Mutta kun kopioin avaimen suoraan puttygen ohjelmasta pelkkänä tekstinä serveriin niin alkoi toimia.