Archivi tag: ssh

Script kiddie 0 – 1 Nazareno

Sicurezza, , , , , ,

In questo post vi ho parlato del lamer che si ostinava a bombardare i miei server sulla porta SSH standard. Essendo che la maggior parte degli attacchi proveniva da IP appartenenti a KoreaNET, ho deciso di impostare delle opportune ACL direttamente sul router.

Il tizio, però, accortosi di quanto accaduto, ha cominciato ad utilizzare altre shell su provider diversi, soprattutto africani. Poichè non ho intenzione di blacklistare tutto il mondo, ho pensato di correre ai ripari in modo diverso.

Per prima cosa, analizzando il fail auth.log ho notato che tutti i tentativi di accesso venivano effettuati utilizzando come username root:

Jul 31 11:31:20 nightbox sshd[26506]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.132.225.70  user=root

Jul 31 11:31:22 nightbox sshd[26508]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=14.45.203.1  user=root

Jul 31 11:31:22 nightbox sshd[26511]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=41.236.232.32  user=root

Ho quindi disabilitato l’accesso root, agendo direttamente sul file sshd_config presente in /etc/ssh:

PermitRootLogin no

Adesso potrà provare tutti i dizionari che vuole, ma ogni tentativo di login come root gli risponderà picche.

Inoltre, poichè mi secca ricevere miliardi di mail da fail2ban perchè questo tizio ha deciso che il suo nuovo hobby è bombardare i range di IP italiani (tra cui quelli dei miei server) ho messo in ascolto il servizio SSH su una porta non standard (compresa tra 1024 e 65535). Non credo sia tanto skillato da fare un nmap per individuare la nuova porta su cui SSH è in listening.

Vi terrò comunque aggiornati sugli ulteriori sviluppi.

A presto.

Attacco bruteforce SSH su range di IP italiani

Sicurezza, , , , , ,

Da circa una settimana fail2ban mi segnala tutta una serie di attacchi bruteforce diretti al servizio SSH in ascolto sui miei server. Questi attacchi si verificano sempre agli stessi orari, ovvero verso le 11 di mattina e verso le 23 di sera. Inoltre, provengono da diversi indirizzi IP, soprattutto coreani, il che mi fa sospettare che vengano pilotati da uno dei tanti lamer di turno in possesso di una piccola botnet composta da zombie.

Facendo un nmap su 3 dei PC da cui proviene l’attacco, ho notato la presenza della porta 20000 TCP aperta, la quale accetta connessioni SSH in ingresso mediante scambio delle chiavi. Ecco come il lamerozzo pilota la sua botnet…

Interesting ports on 222.117.21.18:
Not shown: 992 closed ports
PORT      STATE    SERVICE
111/tcp   open     rpcbind
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
445/tcp   filtered microsoft-ds
1234/tcp  open     hotline
2869/tcp  filtered unknown
4444/tcp  filtered krb524
20000/tcp open     unknown

Ma come fare per contrastare questi attacchi? Semplice, basta impostare delle opportune ACL deirettamente sul router (sempre che il vostro router sia Cisco).

Nella fattispecie, ecco l’ACL che sto utilizzando:

access-list 101 deny ip host 127.0.0.1 any log
access-list 101 deny ip host 255.255.255.255 any log
access-list 101 deny ip 10.0.0.0 0.255.255.255 any log
access-list 101 deny ip 172.16.0.0 0.15.255.255 any log
access-list 101 deny ip 224.0.0.0 15.255.255.255 any log
access-list 101 permit icmp any any echo-reply 
access-list 101 deny icmp any any 
access-list 101 deny ip 121.128.0.0 0.31.255.255 any log 
access-list 101 deny ip 121.160.0.0 0.31.255.255 any log 
access-list 101 deny ip 118.32.0.0 0.31.255.255 any log 
access-list 101 deny ip 59.0.0.0 0.31.255.255 any log 
access-list 101 deny ip 61.76.0.0 0.3.255.255 any log
access-list 101 deny ip 119.192.0.0 0.31.255.255 any log 
access-list 101 deny ip 61.72.0.0 0.3.255.255 any log 
access-list 101 deny ip 221.144.0.0 0.15.255.255 any log 
access-list 101 deny ip 222.96.0.0 0.15.255.255 any log 
access-list 101 deny ip 115.0.0.0 0.15.255.255 any log
access-list 101 deny ip 220.92.0.0 0.3.255.255 any log 
access-list 101 deny ip 221.163.0.0 0.15.255.255 any log
access-list 101 deny ip 220.116.0.0 0.15.255.255 any log  
access-list 101 deny ip 112.160.0.0 0.31.255.255 any log
access-list 101 deny ip 175.192.0.0 0.63.255.255 any log
access-list 101 permit ip any any

Per lo più si tratta di blocchi di indirizzi /11, /12, /13 e /14. E’ stato facile per me individuare la wildcard da utilizzare nelle regole dell’ACL poichè fail2ban fornisce il CIDR degli indirizzi, riportandolo nelle mail di notifica:

# ENGLISH

KRNIC is not an ISP but a National Internet Registry similar to APNIC.

[ Network Information ]

IPv4 Address : 115.0.0.0 - 115.23.255.255 (/12+/13)

Service Name : KORNET

Organization Name : Korea Telecom

Organization ID : ORG1600

Address : 206, Jungja-dong, Bundang-gu, Sungnam-ci

Zip Code : 463-711

Registration Date : 20080703

ecc.

Adesso il lamer potrà sfruttare PC connessi ad altri provider, ma non quelli di KORNET.

A presto.

Script per il backup giornaliero di un database remoto

SO: Linux, , , , , , ,

Visto che la ridondanza non è mai troppa (Murphy vi dice qualcosa?), ho pensato di realizzare uno scrip per effettuare il backup di un database hostato su un server remoto.

shell

Ecco lo scrip (basato su expect):

#!/usr/bin/expect -f
set date [exec date +%d_%m_%y]
set password1 "<pass1>"
set password2 "<pass2>"
set database "<nomedb>"
spawn ssh user@hostname
expect "*?assword:*"
send "$passwordr"
send "r"
expect ":~$"
send "mysqldump $database -u root -ppassvostrodb > $database_$date.plr"
send "$database_$date.pl user@hostname:/home/userr"
expect "*?assword:*"
send "$password2r"
send "r"
expect ":~$"
send "rm database_*r"
expect eof

Lo scrip in questione si collega via SSH al server remoto, esegue un dump del database per poi copiarlo tramite SCP sul mio server.

Affinchè tale scrip venga eseguito giornalmente (per la precisione ogni sera alle 22) è necessario editare il file /etc/crontab aggiungendo la seguente direttiva:

00 22   * * * user  cd /home/user/ && ./backupremotedb > /dev/null 2>&1

Per ulteriori info contattatemi.

A presto.

SSH: Cannot determine realm for numeric host address. Problema risolto

learning log, , , ,

Recentemente, tentando di installare alcune regole IPTABLES direttamente sul firewall mediante SCP, ho riscontrato la presenza del seguente messaggio di errore:

debug: Next authentication method: gssapi-with-mic
debug: An invalid name was supplied
Cannot determine realm for numeric host address

debug: An invalid name was supplied
Cannot determine realm for numeric host address

debug: An invalid name was supplied
Cannot determine realm for numeric host address
ssh.jpg

Uhm, evidentemente il problema sta proprio nel metodo di autenticazione, ovvero nel gssapi-with-mic.

Cosa fare dunque? Bhè, semplice… disabilitare tale metodo di autenticazione. Apro quindi in scrittura il file ssh_config presente nella directory /etc/ssh

nightfly@nightbox:~$ sudo nano /etc/ssh/ssh_config

e modifico la direttiva associata a GSSAPIAuthentication da yes a no.

Salvo il file ed il problema è stato risolto.

A presto.

SSH Bombing

Sicurezza, , ,

Premesso che sui server che gestisco gli attacchi di tipo bruteforce sono all’ordine del giorno, oggi fail2ban ha cominciato ad imprecare in modo alquanto insistente.

Ma cosa ci sarà da strillare così tanto? Do un’occhiata ai file di log e mi accorgo che da ben 12 ore, un certo indirizzo IP sta provando a forzare il servizio SSH in ascolto sulle mie macchine.

Uhm, vediamo un po’ cosa dice il mio amico fail2ban:

Hi,           

The IP 174.132.*.* has just been banned by Fail2Ban after 6 attempts against ssh.                 
Here are more information about 174.132.*.*:           
#     
# Query terms are ambiguous.  The query is assumed to be:     
#     "n 174.132.*.*"     
#     
# Use "?" to get help.     
#           
#     
# The following results may also be obtained via:     
# http://whois.arin.net/rest/nets;q=174.132.*.*?showDetails=true&showARIN=false     
# NetRange:       174.132.0.0 - 174.133.255.255     
  CIDR:           174.132.0.0/15     
  OriginAS:       AS36420, AS30315, AS13749, AS21844     
  NetName:        NETBLK-THEPLANET-BLK-15     
  NetHandle:      NET-174-132-0-0-1     
  Parent:         NET-174-0-0-0-0     
  NetType:        Direct Allocation     
  RegDate:        2008-06-17     
  Updated:        2008-06-17     
  Ref:            http://whois.arin.net/rest/net/NET-174-132-0-0-1                 
  OrgName:        ThePlanet.com Internet Services, Inc.     
  OrgId:          TPCM     
  Address:        315 Capitol     
  Address:        Suite 205     
  City:           Houston     
  StateProv:      TX     
  PostalCode:     77002     
  Country:        US     
  RegDate:        1999-08-31     
  Updated:        2010-10-13     
  Ref:            http://whois.arin.net/rest/org/TPCM           
  ReferralServer: rwhois://rwhois.theplanet.com:4321           
  OrgNOCHandle: THEPL-ARIN     
  OrgNOCName:   The Planet NOC     
  OrgNOCPhone:  +1-281-822-4204      
  OrgNOCEmail:  noc@theplanet.com     
  OrgNOCRef:    http://whois.arin.net/rest/poc/THEPL-ARIN          
  OrgTechHandle: TECHN33-ARIN     
  OrgTechName:   Technical Support     
  OrgTechPhone:  +1-214-782-7800      
  OrgTechEmail:  admins@theplanet.com     
  OrgTechRef:    http://whois.arin.net/rest/poc/TECHN33-ARIN           
  OrgAbuseHandle: ABUSE271-ARIN     
  OrgAbuseName:   The Planet Abuse     
  OrgAbusePhone:  +1-281-714-3560      
  OrgAbuseEmail:  abuse@theplanet.com     
  OrgAbuseRef:    http://whois.arin.net/rest/poc/ABUSE271-ARIN           
  RTechHandle: TECHN33-ARIN     
  RTechName:   Technical Support     
  RTechPhone:  +1-214-782-7800      
  RTechEmail:  admins@theplanet.com     
  RTechRef:    http://whois.arin.net/rest/poc/TECHN33-ARIN           
  RAbuseHandle: ABUSE271-ARIN     
  RAbuseName:   The Planet Abuse     
  RAbusePhone:  +1-281-714-3560      
  RAbuseEmail:  abuse@theplanet.com     
  RAbuseRef:    http://whois.arin.net/rest/poc/ABUSE271-ARIN           
  RNOCHandle: THEPL-ARIN     
  RNOCName:   The Planet NOC     
  RNOCPhone:  +1-281-822-4204      
  RNOCEmail:  noc@theplanet.com     
  RNOCRef:    http://whois.arin.net/rest/poc/THEPL-ARIN           
#     
# ARIN WHOIS data and services are subject to the Terms of Use     
# available at: https://www.arin.net/whois_tou.html     
# Found a referral to rwhois.theplanet.com:4321.           
%rwhois V-1.5:003eff:00 whois.theplanet.com (by Network Solutions, Inc. V-1.5.9.5)     
Network:Class-Name:network     
network:ID:NETBLK-THEPLANET-BLK-15     
network:Auth-Area:174.132.0.0/15     
network:Network-Name:TPIS-BLK-174-132-*-0     
network:IP-Network:174.132.*.*/29     
network:IP-Network-Block:174.132.*.* - 174.132.*.*     
network:Organization-Name:Mike Dillard     
network:Organization-City:Austin    
network:Organization-State:TX     
network:Organization-Zip:78701     
network:Organization-Country:USA     
network:Description-Usage:customer     
network:Server-Pri:ns1.theplanet.com     
network:Server-Sec:ns2.theplanet.com     
network:Tech-Contact;I:abuse@theplanet.com     
network:Admin-Contact;I:abuse@theplanet.com     
network:Created:20090204     
network:Updated:20090216           
%ok           

Regards,           

Fail2Ban

Ah che bello… finalmente un attacco che non proviene dal classico cinese smanettone. Ehm, però qui c’è qualcosa che non mi quadra (leggasi server farm), proviamo a fare un piccolo nmap su quell’indirizzo, va:

nightfly@nightbox:~$ sudo proxychains nmap -sS 174.132.*.*     
[sudo] password for nightfly:     
ProxyChains-3.1 (http://proxychains.sf.net)           

Starting Nmap 5.00 ( http://nmap.org ) at 2011-04-12 20:20 CEST     
Interesting ports on **.ae.**ae.static.theplanet.com (174.132.*.*):     
Not shown: 983 closed ports     

PORT     STATE SERVICE     
21/tcp   open  ftp     
22/tcp   open  ssh     
25/tcp   open  smtp     
53/tcp   open  domain     
80/tcp   open  http     
106/tcp  open  pop3pw     
110/tcp  open  pop3     
111/tcp  open  rpcbind     
143/tcp  open  imap     
443/tcp  open  https     
465/tcp  open  smtps     
993/tcp  open  imaps     
995/tcp  open  pop3s     
1040/tcp open  netsaint     
1311/tcp open  rxmon     
3306/tcp open  mysql     
8443/tcp open  https-alt
Ecco, c’è solo qualche servizio in ascolto… e tra questi vi è anche il mitico Plesk! Chissà cosa accadrebbe se…

hacked.png

Vabbè ecco un’altra testa di ponte. Piccola mailina all’abuse e fine dei giochi.      

Bye.





	

	
	

		
			



							


	

		
				

			Sancho: configurazione per l’accesso da remoto ad mldonkey via SSH
		

		
		

			p2p, , , , 					

	


		

		
Sancho, interfaccia grafica multipiattaforma per mldonkey, presenta tutta una serie di caratteristiche più che interessanti, le quali consentono una facile gestione e personalizzazione del demone p2p in questione. A mio avviso, la possibilità di gestire il core da remoto mediante una connessione SSH è sicuramente una delle feature più intriganti. Vediamo dunque come configurare il nostro client per la connessione ad mldonkey da remoto, prendendo in considerazione a tal scopo lo screenshot sottostante:




sancho.png








Nel campo di input che ho marcato con la lettera A occorre inserire l’indirizzo locale del server su cui mldonkey è in ascolto (ad esempio 127.0.0.1). Nei campi username e password sottostanti dovrete immettere le credenziali di accesso al core mldonkey.




Nel campo di input contrassegnato con B è necessario inserire l’IP pubblico del server su cui è attivo il core. A tal proposito, poichè spesso si ha a che fare con IP dinamici, vi consiglio di tirar su un hostname basato su DNS dinamico, usufruendo del servizio gratuito messo a disposizione da dyndns.


Nel campo C inserite lo username che utilizzate per accedere via SSH al server. Ovviamente, dovrà essere inserita anche la password nel campo immediatamente sottostante.


Cliccate infine sul pulsante Make current selection the default e successivamente su Finish. Adesso siete pronti a collegarvi mediante Sancho al core in ascolto su un server remoto.




A presto.







	

	
	

		
			



							


	

		
				

			Abilitare SSH su switch Cisco Catalyst 3750
		

		
		

			Networking, , , , 					

	


		

		
Prima di introdurre questa mini-guida, occorre precisare che non tutte le IOS Cisco supportano SSH. Nella fattispecie, quelle abilitate a ricevere connessioni mendiante Secure SHell riportano la dicitura K9 nell’ambito del filename.


Ma veniamo a noi. Per prima cosa, occorre creare la chiave RSA da utilizzare come fingerprint. Per fare ciò basta digitare il comando:


Switch(config)# crypto key generate rsa general-keys label ssh-fingerprint


Dopodichè digitiamo:


Switch(config)# ip ssh version 2


in modo da abilitare sul dispositivo la versione 2 del protocollo SSH (più robusta della 1).


Adesso definiamo username e password di accesso:


Switch(config)# username <vostro username> password <vostra password>


A questo punto disabilitiamo l’accesso telnet e consentiamo solo quello ssh usando il comando transport input (e già che ci siamo aggiungiamo username e password appena creati come credenziali per il login):


 Switch(config)# line vty 0 15
 Switch(config)# login local
 Switch(config-line)# transport input ssh
 Switch(config-line)# end


Infine salviamo la configurazione:


Switch# copy run start


ed il gioco è fatto.


A presto.





	

	
	

		
			



							


	

		
				

			SSH: autenticazione mediante scambio delle chiavi
		

		
		

			SO: Linux, , , , 					

	


		

		
Il protocollo SSH (acronimo si Secure SHell), viene utilizzato per stabilire una connessione cifrata con determinati host, in modo da ottenere accesso alla loro interfaccia a linea di comando (CLI).


Ora, l’accesso vero e proprio alla macchina remota può evvenire seguendo diverse strade, ad esempio mediante l’inserimento di opportune credenziali di accesso (username e password) oppure mediante uno scambio di chiavi (pubbliche). Quest’ultima modalità di accesso risulta estremamente utile quando un determinato host deve connettersi via SSH ad un altro in modo automatizzato (ad esempio attraverso un cronjob schedulato). Un caso molto diffuso riguarda l’upload via SCP dei log relativi ai vari dispositivi di rete direttamente sul logserver.


Vediamo ora come predisporre i nostri dispositivi per lo scambio automatico delle chiavi. Per prima cosa occorre generare, su ciascun host, una coppia di chiavi pubblica/privata (RSA a 2048 bit). E’ possibile fare ciò mediante il comando:


nightfly@nightbox:~$ ssh-keygen


Durante la procedura di generazione delle chiavi è buona norma utilizzare una passphrase non vuota. Essa verrà adoperata per criptare la nostra chiave privata.




In particolare, la chiave pubblica verrà salvata all’interno del file id_rsa.pub nella direcotory nascosta .ssh presente nella home del nostro utente.


A questo punto connettiamoci all’host remoto via SSH in modo da aggiungere il suo fingerprint all’interno dei file known_hosts, anch’esso posizionato nella dir .ssh. Tale procedura si rende necessaria in quanto SSH prevede l’identificazione dell’host remoto e l’aggiunta esplicita (mediante popup di conferma) del suo fingerprint tra gli host fidati.


Una volta identificato l’host remoto occorre generare una coppia di chiavi anche su di esso. Il comando è del tutto identico a quello utilizzato sul notro PC.


Ora possiamo procedere con copia/incolla della nostra chiave pubblica sull’host remoto, salvandola all’interno del file authorized_keys, dopo averlo creato mediante il comando:


nightfly@nightbox:~/.ssh$ touch authorized_keys


e dopo avergli assegnato i permessi 600:


nightfly@nightbox:~/.ssh$ chmod 600 authorized_keys


Tale procedura va eseguita anche sul nostro PC, nel caso in cui dovesse essere il logserver ad effettuare una richiesta di connessione verso di noi. Ovviamente, in tal caso, all’interno del nostro file authorized_keys andrà copiata la chiave pubblica del server.


Attenzione: condizione necessaria affinchè tutto funzioni è che l’utente del nostro PC (che lancia la connessione SSH) e quello del logserver per il quale è stato definito il file authorized_key coincidano.




A presto.


PS: Grazie a Max per i prezioni suggerimenti.







	

	
	

		
			



							


	

		
				

			mldonkey: download di un link da remoto
		

		
		

			SO: Linux, , , 					

	


		

		
Mettiamo il caso che si voglia scaricare un file mediante mldonkey, ma che la macchina su cui gira tale applicativo sia raggiungibile solo da remoto. Mettiamo inoltre il caso che tale macchina accetti esclusivamente connessioni cifrate via SSH. Come fare dunque per lanciare un download? La risposta è semplice.


Per prima cosa sarà necessario lanciare una sessione SSH verso la macchina di destinazione, utilizzando ad esempio PuTTY (potete scaricarlo da qui, è gratuito).


A questo punto lanciamo un nmap e verifichiamo che la porta 4000 sia in ascolto su localhost:


nightfly@nightbox:~$ nmap localhost | grep 4000


Dovremmo ottenere un output del tipo:


4000/tcp open  remoteanything


Lanciamo quindi il comando:


nightfly@nightbox:~$ telnet localhost 4000


e visualizzaremo un prompt del tipo:


Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Welcome to MLDonkey 3.0.1
Welcome on mldonkey command-line

Use ? for help

MLdonkey command-line:
>


A questo punto siamo dentro la console dei comandi di mldonkey. Autentichiamoci digitando:


auth <username> <password>


e successivamente lanciamo il download di un link (e2k, ftp, torrent e così via) mediante il comando:


dllink <link>


Verifichiamo infine che il download sia effettivamente attivo scrivendo in console:


vd


Ecco fatto, il download è in esecuzione sulla macchina remota. A presto.