Ju
@ju@nugole.it
Nuovo profilo, nuova istanza (mia!), nuovo software (snac - e come dargli torto).
Che dire: mi ri-presento.
Ho scoperto che è meglio chiarire subito le cose: non sono una persona buona.
Non sono neanche una persona cattiva, credo.
Sono, cerco di essere, una persona [piena di contraddizioni però] razionale.
Mi interessano un sacco di cose, l'universo scibile in realtà.
In genere parlo di: poesia, politica, gatti, storia, giardinaggio, uncinetto, montagne, informatica, fantasy, fantascienza... non necessariamente in quest'ordine. Va un po' a periodi.
Mi capita spesso di mettere in discussione opinioni comunemente accettate, questo in genere mi rende antipaticə.
Non sopporto gli slogan.
Non sopporto chi imbroglia sulle premesse di un ragionamento per farlo apparire sensato.
Non sopporto i fanatismi e i fanatici.
Non è normale che sia pieno di sta roba vero?
Perchè l'impressione che ho io è che qualcuno stia cercando allegramente (e da qualche settimana) di collegarsi come root e l'unico motivo per cui non ci riesce è che la password di root è furba.
(E no, io non mi collego mai come root. Perchè sono paranoic...ehm...come sopra.)
May 08 09:29:56 Aster sshd[77607]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=104.244.77.50 user=root
May 08 09:29:58 Aster sshd[77607]: Failed password for root from 104.244.77.50 port 56454 ssh2
May 08 09:29:58 Aster sshd[77607]: Connection closed by authenticating user root 104.244.77.50 port 56454 [preauth]
May 08 09:29:59 Aster sshd[77609]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=104.244.77.50 user=root
May 08 09:29:59 Aster sshd[77611]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=104.244.77.50 user=root
Prova a ripetere l'attacco su quell'IP (fa giri strani in Lussemburgo).
@ju Ovviamente non è una cosa buona.
Quanto all'essere normale... purtroppo succede sempre.
Il firewall dovrebbe permettere accesso solo a chi dovrebbe avere accesso, ma se hai un IP dinamico diventa più difficile. Però potresti comunque restringerlo ai range del tuo provider, se riesci a trovarli.
Una cosa per evitare di riempire i log è di mettere ssh su un port diverso da 22. Almeno ci mettono un po' di più a trovarlo (qui il problema è diminuito di circa 10 mila volte facendo così).
@ju E ultimo ma di certo non meno importante (se non l'hai già fatto)...
Metti ssh solo con chiavi, e impedisci accesso con password. E naturalmente tieni le chiavi private ben sicure.
@ju In /etc/ssh/sshd_config o uno dei file che include:
PasswordAuthentication no
poi controllare che senza chiave non permetta login (per esempio:
ssh -i /dev/null HOST
che quindi non può offrire chiavi)
@ju ... ma dato che hai ancora quel laptop che non è diventato un router, non c'è bisogno di dire di provare prima lì, vero? Prima di chiuderti fuori dal server.
Intanto ho:
ristretto l'uso di root: passwd --lock root, non importa, non uso root. Sudo va bene.
modificato /etc/security/access.conf bloccando l'accesso a root.
Implementato il blocco dell'utente dopo 3 tentativi sbagliati con la password (anche root.)
Adesso cambio la porta ssh...speriamo che non mi chiudo fuori... -.-"
(Sul server, di default è installato ufw.)
@ju Per cambiare porta di ssh:
1. essere sul server e attenzione a non scollegarsi
2. cambiare "Port 22" in qualcos'altro
3. far ripartire il servizio ssh
4. collegarsi da un terminale diverso usando il nuovo port
5. se tutto funziona, puoi anche mettere due righe in ~/.ssh/config per indicare il nuovo port di default
@ju Ah e ovviamente cambiare ufw perché permetta accesso dal nuovo port. Siccome non uso ufw non so come si fa, ma comunque dovrebbe esserci della documentazione (e non essere inutile come quella di aruba)
@ju Probabilmente però non legge sshd_config ma /etc/services - che dice "ssh 22/tcp" e se lo cambi potrebbe tornare ad essere 22 dopo un'aggiornamento.
È più sicuro mettere il numero nel firewall.
Ceno.
Poi torno.
@ju Ora mi sento in colpa...
@ju Perché non ho pensato a una procedura che rendesse impossibile chiudersi fuori.
@ju Quando cambi il port su sshd... cambi anche quello che usa il cliente?
Altrimenti sì ti viene "connection refused"...
ssh -p NUMERO (eccetera)
@ju No.
A meno che systemd nella sua infinita [CW] non abbia evitato di far ripartire sshd...
Comunque "netstat -tnl" dovrebbe dire qualcosa tipo:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
oppure qualcosa di diverso invece del ":22" nella terza colonna.
Comunque: ho cenato, ho procacciato una birretta, mi metto al lavoro e creo le chiavi.
Fatto :D
E non mi sono chiusə fuori dal server!
Ora ho un utente solo, con la sua chiave, che può accedere al server.
Root non può accedere e comunque è ristretto.
Dici che devo comunque provare a cambiare la porta?
@ju Non è necessario.
Ma comunque un'occhiata ai log non fa male.
Se un IP continuasse a tornare... c'è sempre la possibilità di bloccarlo
[oppure guardare fail2ban]
@ju Strano che non siano prostitute olandesi.
"Accepted publickey for (il mio utente) from (il mio ip) port (porta alta) ssh2:"
@ju No, questa è la porta del cliente. Che sarà sempre una porta alta. Appena connesso, "netstat -tn" sul server mostrerà sia il 22 ("local address") che la porta alta ("remote address"). Oppure "echo $SSH_CONNECTION" che mostra 4 campi: IP cliente, porta cliente, IP server, porta server(22)
ok...uhm...ci sono un tot di connessioni...
cp 0 0 ip_server:443 20.101.35.60:44996 ESTABLISHED
tcp 0 0 ip_server:22 24.237.119.118:49222 SYN_RECV
tcp 0 0 ip_server:22 61.160.119.116:14565 SYN_RECV
tcp 0 0 ip_server:22 106.246.89.70:40273 SYN_RECV
tcp 0 316 ip_server:22 mio_ip:63624 ESTABLISHED
tcp 0 0 ip_server:443 mio_ip:63807 ESTABLISHED
tcp 0 0 ip_server:443 mio_ip:63806 ESTABLISHED
tcp 0 0 ip_server:22 218.22.11.106:48718 SYN_RECV
non credo di dovermi preoccupare di quelle sulla porta 443 che dovrebbero riguardare snac?
devo preoccuparmi di SYN_RECV?
@ju SYN_RECV vuol dire che hanno cercato di aprire una connessione su port 22 ma senza poi far nulla.
Probabilmente scan con nmap o equivalente per vedere che port sono aperti.
Questi di solito non vanno nel log perché non arrivano fino ad avere una connessione aperta ("ESTABLISHED") quindi sshd non lo sa e non può riportare un tentativo di usare una password.
@ju Penso per il momento si erano stufati a causa del "connection refused" temporaneo...
@ju Ah e per il port 443 - quell'IP che inizia per 20 è sociale.network, penso che sia una connessione benigna di qualcunə che ti segue...
@ju Se dovessero raggiungere il livello di "grande rottura" ci sono altre cose che si possono fare, anche senza cambiare port 22 con qualche altro numero.
Per esempio "port knocking" (dove il firewall accetta solo connessioni da IP che hanno esibito un'attività ben distinguibile per esempio SYN_SENT to altri port in una sequenza predeterminata e che tu conosci e il tuo cliente ssh può essere configurato per inviare, ma altri non dovrebbero conoscere).
nel frattempo sto guardando ufw ...che però più che un firewall semplice mi sembra anche un firewall troppo semplice. Quasi quasi lo cambio con iptables.
Ci penso.