Archivi tag: udp

Traffico TCP sulla porta 0

Sicurezza, , , , , , , , , ,

Qualche giorno fa Nagios mi ha segnalato un allarme di sicurezza che mi ha lasciato alquato basito:

When a syslog message is generated by the device a SEC info IPACCESSLOGP list 102 denied tcp 77.223.136.170(0) - 95.245.162.62(0), 1 packet 9:5:46:40.62

In soldoni, l’ACL attiva sull’interfaccia dialer (WAN) del mio router ha “scartato” un segmento TCP proveniente dall’IP 77.223.136.170 (porta 0) e diretto al mio (vecchio) IP pubblico (ovvero 95.245.162.62, porta 0).

Ora, è sufficiente avere un minimo di dimestichezza con lo stack TCP/IP per capire che l’anomalia sta proprio nella porta sorgente ed in quella di destinazione. Infatti, la porta 0 è riservata ed il suo impiego può avvenire per i motivi (leciti) più disparati.

Ad esempio, nel caso in cui il pacchetto IP (formato da header + payload) superi la MTU del link che deve attraversare, esso subirà un processo specifico, denominato “frammentazione”.

In particolare, essendo l’header TCP parte del payload IP (per via dell’incapsulamento – vedi immagine sottostante), ciascun frammento potrebbe contenere la suddetta intestazione per intero o solo parzialmente. Nel primo caso, l’header TCP originario si troverebbe soltanto nel primo frammento, mentre tutti gli altri conterrebbero la sola intestazione IP (dotata di ID specifico del frammento, offset per la ricostruzione del traffico in fase di ricezione – dimensione e bit MF – More Fragment – pari a 0 o 1 a seconda che si tratti dell’ultimo frammento o meno).

encaps

Più in generale, la porta TCP/UDP pari a 0 potrebbe stare a significare, molto semplicemente, assenza di layer 4 (basti pensare al protocollo ICMP).

Per quanto riguarda, invece, l’uso malevolo della porta 0, possiamo distinguere 3 macro-tipologie di casi:

1) Attacchi di tipo fingerprint. Essi si basano sul presupposto che spesso e volentieri le ACL non possono essere definite in modo tale da droppare esplicitamente il traffico in ingresso sulla porta 0 (TCP o UDP), ergo puntare ad essa è un modo abbastanza efficace (ma non infallibile) per ottenere info sulla tipologia di router oggetto di interesse (OS fingerprint – leggete questo per ulteriori dettagli);

2) Attacchi volti ad “aggirare” le ACL. Ad esempio, forzando la frammentazione del pacchetto IP ed agendo sul campo offset,  si potrebbe riuscire, in teoria, a sovrascrivere parte dell’intestazione TCP originaria (che punta ad una porta di destinazione “lecitamente” raggiungibile dall’esterno, come potrebbe essere la 25 per il protocollo SMTP) con una porta non accessibile dall’esterno (ad esempio la 23 per il protocollo Telnet). Per ulteriori dettagli su tale tipologia di attacco (denominato tiny overlapping fragment attack) leggete questo.

3) Attacchi di tipo DoS/DDoS. Forzando la frammentazione dei pacchetti IP sottostanti al layer 4 (TCP/UDP) si potrebbe riuscire a “sovraccaricare” il router di destinazione, soprattutto per via dell’overhead dovuto all’attività di “ricostruzione” del traffico. Inoltre, puntando ad una porta non lecita, ad esempio la 0, lo si costringerebbe ad inviare dei messaggi ICMP Port Unreachable (se abilitati sull’interfaccia), sovraccaricandolo ulteriormente.

Della casistica appena illustrata credo che l’allarme ricada, molto banalmente, negli attacchi di tipo fingerprint. Ovviamente ho alzato il livello di attenzione per evitare “brutte” sorprese in futuro.

Vi terrò comunque aggiornati.

Aggiornamento 1

A quanto pare si è trattato proprio di un portscan/fingerprint. Infatti, dopo circa 5 giorni dallo scan sulla porta TCP 0, ho registrato il seguente traffico:

Jan 25 15:29:15 192.168.2.1 1738: 001735: Jan 25 15:29:14.483 UTC: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 77.223.136.170(443) -> 79.31.118.x(43616), 1 packet
Jan 25 15:29:17 192.168.2.1 1739: 001736: Jan 25 15:29:15.988 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 77.223.136.170(256) -> 79.31.118.x(43617), 1 packet
Jan 25 15:29:18 192.168.2.1 1740: 001737: Jan 25 15:29:17.200 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 77.223.136.170(111) -> 79.31.118.x(43617), 1 packet
Jan 25 15:29:19 192.168.2.1 1741: 001738: Jan 25 15:29:18.204 UTC: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 77.223.136.170(1106) -> 79.31.118.x(43616), 1 packet
Jan 25 15:29:20 192.168.2.1 1742: 001739: Jan 25 15:29:19.204 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 77.223.136.170(700) -> 79.31.118.x(43617), 1 packet
Jan 25 15:29:20 192.168.2.1 1743: 001740: Jan 25 15:29:20.208 UTC: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 77.223.136.170(3493) -> 79.31.118.x(43616), 1 packet
Jan 25 15:29:22 192.168.2.1 1744: 001741: Jan 25 15:29:21.213 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 77.223.136.170(726) -> 79.31.118.x(43617), 1 packet
Jan 25 15:29:24 192.168.2.1 1746: 001743: Jan 25 15:29:23.365 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 77.223.136.170(777) -> 79.31.118.x(43618), 1 packet
Jan 25 15:29:26 192.168.2.1 1747: 001744: Jan 25 15:29:25.046 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 77.223.136.170(111) -> 79.31.118.x(43618), 1 packet

Aggiornamento 2

In data 26 Gennaio ho ricevuto un altro pacchetto da/verso la suddetta porta:

When a syslog message is generated by the device a SEC info IPACCESSLOGP list 101 denied tcp 23.236.147.202(0) - 79.31.118.x(0), 1 packet 0:14:52:02.45

Vediamo se tra qualche giorno il nuovo IP sorgente utilizzerà lo stesso ordine di port probing del suo predecessore.

Aggiornamento 3

Come volevasi dimostrare, a distanza di qualche ora è arrivato il port probing vero e proprio:

Jan 27 18:36:33 192.168.2.1 19380: 019433: Jan 27 18:36:32.479 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 23.236.147.202(139) -> 79.31.118.x(46096), 1 packet
Jan 27 18:36:35 192.168.2.1 19381: 019434: Jan 27 18:36:34.475 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 23.236.147.202(1002) -> 79.31.118.x(46097), 1 packet
Jan 27 18:36:36 192.168.2.1 19382: 019435: Jan 27 18:36:35.500 UTC: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 23.236.147.202(2701) -> 79.31.118.x(46095), 1 packet
Jan 27 18:36:36 192.168.2.1 19383: 019436: Jan 27 18:36:36.500 UTC: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 23.236.147.202(11967) -> 79.31.118.x(46095), 1 packet
Jan 27 18:36:38 192.168.2.1 19384: 019437: Jan 27 18:36:37.552 UTC: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 23.236.147.202(1494) -> 79.31.118.x(46095), 1 packet
Jan 27 18:36:39 192.168.2.1 19385: 019438: Jan 27 18:36:38.556 UTC: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 23.236.147.202(8021) -> 79.31.118.x(46095), 1 packet
Jan 27 18:36:43 192.168.2.1 19387: 019440: Jan 27 18:36:42.353 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 23.236.147.202(139) -> 79.31.118.x(46097), 1 packet
Jan 27 18:36:48 192.168.2.1 19388: 019441: Jan 27 18:36:47.154 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 23.236.147.202(139) -> 79.31.118.x(46095), 1 packet

Anche in questo caso le porte oggetto dell’attacco sono quelle > 1023. Ho quindi fatto qualche modifica all’ACL configurata sulla dia0 del mio router, sostituendo la regola:

access-list 101 permit tcp any gt 1023 any log

con:

access-list 101 permit tcp any gt 1023 any established log

in modo tale da consentire il traffico proveniente dalle porte > 1023 solo se si riferiscono a delle connessioni già esistenti.

Aggiornamento 4

Sono riuscito a ricreare parzialmente la suddetta tipologia di traffico, utilizzando un apposito tool denominato hping, il quale è in grado di forgiare dei pacchetti RAW/TCP/UDP/ICMP da impiegare durante le operazioni di OS fingerprint e non solo.

Ad esempio, mediante il comando:

[root@linuxbox ~]# hping3 -S -V <mio indirizzo IP>

sono riuscito a generare una sfilza di pacchetti TCP recanti i classici 40 byte di header, payload 0 e flag SYN settata a 1, la cui destinazione proprio è la famigerata porta 0.

Di seguito riporto il tracciato tcpdump da locale (grazie al quale si può notare che la porta sorgente è una porta alta, ovvero maggiore di 1023, e che la porta di destinazione è sempre la 0):

09:41:14.967184 IP 192.168.1.1.1232 > 79.31.118.x.0: Flags [S], seq 2094000106, win 512, length 0
09:41:15.967305 IP 192.168.1.1.1233 > 79.31.118.x.0: Flags [S], seq 517260399, win 512, length 0
09:41:16.967425 IP 192.168.1.1.1234 > 79.31.118.x.0: Flags [S], seq 399923675, win 512, length 0
09:41:17.967477 IP 192.168.1.1.1235 > 79.31.118.x.0: Flags [S], seq 725026004, win 512, length 0
09:41:18.967573 IP 192.168.1.1.rmtcfg > 79.31.118.x.0: Flags [S], seq 1830159741, win 512, length 0
09:41:19.967638 IP 192.168.1.1.1237 > 79.31.118.x.0: Flags [S], seq 342672970, win 512, length 0

Mentre il log generato dal mio router è il seguente:

Apr  3 09:39:35 192.168.2.1 108805: 108943: Apr  3 08:39:34.979 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 95.254.89.x(1232) -> 79.31.118.x(0), 1 packet
Apr  3 09:39:37 192.168.2.1 108807: 108945: Apr  3 08:39:36.979 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 95.254.89.x(1233) -> 79.31.118.x(0), 1 packet
Apr  3 09:39:39 192.168.2.1 108808: 108946: Apr  3 08:39:38.980 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 95.254.89.x(1234) -> 79.31.118.x(0), 1 packet
Apr  3 09:39:41 192.168.2.1 108809: 108947: Apr  3 08:39:40.980 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 95.254.89.x(1235) -> 79.31.118.x(0), 1 packet
Apr  3 09:39:43 192.168.2.1 108810: 108948: Apr  3 08:39:42.981 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 95.254.89.x(1236) -> 79.31.118.x(0), 1 packet
Apr  3 09:39:45 192.168.2.1 108811: 108949: Apr  3 08:39:44.977 UTC: %SEC-6-IPACCESSLOGP: list 101 denied tcp 95.254.89.x(1237) -> 79.31.118.x(0), 1 packet

Invece, forzando a 0 la porta sorgente del suddetto traffico (e mantenendola tale per tutta la durata del test – opzione -k) attraverso il comando:

[root@linuxbox ~]# hping3 -S -VV -s 0 -k <mio indirizzo IP>

sono riuscito ad intercettarlo localmente come dimostrato dal seguente tracciato:

10:32:21.495218 IP 192.168.1.1.0 > 79.31.118.x.0: Flags [S], seq 1600061111, win 512, length 0
10:32:22.495334 IP 192.168.1.1.0 > 79.31.118.x.0: Flags [S], seq 965785080, win 512, length 0
10:32:23.495411 IP 192.168.1.1.0 > 79.31.118.x.0: Flags [S], seq 677172521, win 512, length 0
10:32:24.495492 IP 192.168.1.1.0 > 79.31.118.x.0: Flags [S], seq 473418678, win 512, length 0

ma è stato successivamente scartato dal router sorgente, ergo non è mai giunto a destinazione.

Nei prossimi giorni proverò a ripetere il test utilizzando il router di un vendor differente.

Tracert e traceroute messi a confronto

Networking, , , , , , , ,

I comandi tracert (di casa Microsoft) e traceroute (di casa *nix) vengono utilizzati per enumerare gli hop (dispositivi di rete di livello 3, solitamente router) che attraversa un pacchetto fino a giungere a destinazione.

Ad esempio, se volessi individuare il percorso intrapreso da un pacchetto verso una data destinazione, posso lanciare il comando:

C:\Users\eldo>tracert 4.2.2.2

Traccia instradamento verso b.resolvers.Level3.net [4.2.2.2]
su un massimo di 30 punti di passaggio:

  1     3 ms     1 ms     2 ms  192.168.*.*
  2     *        *        *     Richiesta scaduta.
  3    14 ms    18 ms    17 ms  151.6.185.105
  4    32 ms    33 ms    31 ms  151.6.5.15
  5   124 ms   208 ms   218 ms  151.6.1.89
  6    45 ms    45 ms    45 ms  151.6.0.174
  7   117 ms   216 ms    51 ms  212.73.241.161
  8    52 ms    53 ms    54 ms  ae-14-14.ebr1.Frankfurt1.Level3.net [4.69.142.19]
4]
  9    59 ms    54 ms    55 ms  ae-61-61.csw1.Frankfurt1.Level3.net [4.69.140.2]

 10     *        *        *     Richiesta scaduta.
 11    55 ms    54 ms    54 ms  b.resolvers.Level3.net [4.2.2.2]

Traccia completata.

Gli hop non identificati (quelli caratterizzati dall’errore Richiesta Scaduta), non consentono un deteterminato tipo di traffico, nella fattispecie quello ICMP.

Infatti, il comando tracert basa il suo funzionamento sul suddetto protocollo.

Discorso diverso riguarda, invece, il comando traceroute:

 1  vodafone.station (10.*.*.*)  1.269 ms  1.247 ms  1.224 ms
 2  * * *
 3  * * *
 4  83.224.40.185 (83.224.40.185)  76.238 ms  76.338 ms  77.658 ms
 5  85.205.14.105 (85.205.14.105)  88.192 ms  81.755 ms  82.662 ms
 6  212.73.241.21 (212.73.241.21)  120.408 ms  102.599 ms  102.517 ms
 7  ae-0-11.bar2.Milan1.Level3.net (4.69.142.190)  72.483 ms  70.973 ms  69.436 ms
 8  ae-14-14.ebr1.Frankfurt1.Level3.net (4.69.142.194)  77.455 ms  76.717 ms  76.729 ms
 9  ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2)  77.707 ms ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6)  79.677 ms ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2)  77.714 ms
10  * * *
11  b.resolvers.Level3.net (4.2.2.2)  76.517 ms  77.154 ms  76.688 ms

tracert,traceroute,hop,icmp,ttl,windows,unix,linux,udp

Esso, infatti, basa il proprio funzionamento sul protocollo UDP (porta compresa tra 33434 e 33454). Esiste comunque un’opzione per fare in modo che il suddetto comando utilizzi il protocollo ICMP, ovvero -I:

nightfly@nightbox:~$ sudo traceroute -I 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 60 byte packets
 1  vodafone.station (10.1.1.1)  6.259 ms  6.270 ms  6.272 ms
 2  * * *
 3  * * *
 4  83.224.40.185 (83.224.40.185)  75.660 ms  76.495 ms  77.516 ms
 5  85.205.14.105 (85.205.14.105)  84.951 ms  85.111 ms  85.128 ms
 6  212.73.241.21 (212.73.241.21)  81.020 ms  68.027 ms  68.200 ms
 7  ae-0-11.bar2.Milan1.Level3.net (4.69.142.190)  74.880 ms  68.066 ms  68.426 ms
 8  ae-14-14.ebr1.Frankfurt1.Level3.net (4.69.142.194)  77.336 ms  76.738 ms  79.799 ms
 9  ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6)  78.400 ms  78.500 ms  90.106 ms
10  ae-2-70.edge5.Frankfurt1.Level3.net (4.69.154.73)  78.688 ms  76.939 ms  76.813 ms
11  b.resolvers.Level3.net (4.2.2.2)  76.679 ms  76.707 ms  76.957 ms

Come potete notare, in quest’ultimo caso il decimo hop ha risposto, proprio perchè su di esso è consentito il traffico ICMP e non quello UDP.

Traceroute come footprinting

Il comando traceroute può essere utilizzato con finalità di footprinting. Ad esempio, se un dato hop non risponde nè al protocollo ICMP nè a quello UDP su una porta alta (compresa nel range che ho riportato in precedenza), si può specificare una determinata porta di destinazione mediante la flag -p. Supponendo che sull’host sia attivo un demone DNS, il comando da utilizzare potrebbe essere il seguente:

nightfly@nightbox:~$ sudo traceroute -p 53 10.1.2.14

Alla prossima.

Le crew di smanettoni dell’est

Sicurezza, , , , , , ,

Per quanto riguarda i portscan, psad è veramente una manna dal cielo. Tale applicativo non fa altro che rimanere in “ascolto” sul server in attesa di intercettare eventuali pacchetti inviati ad un range di porte più o meno esteso.

crew,portscan,udp,well known ports,nmap -su,whois,est europa,pbx

Questa mattina, grazie al suddetto tool, ho ricevuto una caterva di email del tipo:

=-=-=-=-=-=-=-=-=-=-=-= Mon Aug 20 11:56:55 2012 =-=-=-=-=-=-=-=-=-=-=-=

 Danger level: [2] (out of 5)

 Scanned UDP ports: [17565: 1 packets, Nmap: -sU]
 iptables chain: INPUT (prefix "Generic log entry:"), 1 packets

 Source: 188.237.169.123
 DNS: host-static-188-237-169-123.moldtelecom.md

 Destination: 10.*.*.*
 DNS: [No reverse dns info available]

 Overall scan start: Mon Aug 20 08:59:05 2012
 Total email alerts: 9
 Complete UDP range: [1024-17565]
 Syslog hostname: *

 Global stats: chain: interface: TCP: UDP: ICMP:
 INPUT eth1 0 19 0

[+] Whois Information:
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '188.237.168.0 - 188.237.175.255'

inetnum: 188.237.168.0 - 188.237.175.255
netname: MOLDTELECOM-NET
descr: JSC "Moldtelecom" S.A.
descr: Chisinau, Moldova
country: MD
admin-c: MLA32-RIPE
tech-c: MLA32-RIPE
status: ASSIGNED PA
remarks: INFRA-AW
remarks: MaxFiber Users, IPMPLS Moldova
mnt-by: MOLDTELECOM-MNT
source: RIPE # Filtered

role: Moldtelecom LIR Adminstrators
remarks:
address: JSC "Moldtelecom" S.A.
address: 10, Stefan cel Mare ave.
address: Chisinau, Moldova
address: MD-2001
phone: +373 22570565
fax-no: +373 22542601
remarks:
admin-c: VSM13-RIPE
tech-c: NM2546-RIPE
nic-hdl: MLA32-RIPE
abuse-mailbox: cert.mtc@moldtelecom.md
remarks:
mnt-by: MOLDTELECOM-MNT
source: RIPE # Filtered

% Information related to '188.237.128.0/18AS8926'

route: 188.237.128.0/18
descr: JSC "Moldtelecom" S.A.
descr: 10, Stefan cel Mare ave.,
descr: MD-2001, Chisinau, Moldova
origin: AS8926
mnt-by: MOLDTELECOM-MNT
source: RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.19.5 (WHOIS2)

=-=-=-=-=-=-=-=-=-=-=-= Mon Aug 20 11:56:55 2012 =-=-=-=-=-=-=-=-=-=-=-=

=-=-=-=-=-=-=-=-=-=-=-= Mon Aug 20 11:59:31 2012 =-=-=-=-=-=-=-=-=-=-=-=

 Danger level: [2] (out of 5)

 Scanned UDP ports: [17565: 1 packets, Nmap: -sU]
 iptables chain: INPUT (prefix "Generic log entry:"), 1 packets

 Source: 176.102.218.106
 DNS: [No reverse dns info available]

 Destination: 10.*.*.*
 DNS: [No reverse dns info available]

 Overall scan start: Mon Aug 20 10:03:03 2012
 Total email alerts: 15
 Complete UDP range: [1024-17565]
 Syslog hostname: *

 Global stats: chain: interface: TCP: UDP: ICMP:
 INPUT eth1 0 32 0

[+] Whois Information:
#
# Query terms are ambiguous. The query is assumed to be:
# "n 176.102.218.106"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=176.102.218.106?showDetails=true&showARIN=false&ext=netref2
#

NetRange: 176.0.0.0 - 176.255.255.255
CIDR: 176.0.0.0/8
OriginAS:
NetName: RIPE-176
NetHandle: NET-176-0-0-0-0
Parent:
NetType: Allocated to RIPE NCC
Comment: These addresses have been further assigned to users in
Comment: the RIPE NCC region. Contact information can be found in
Comment: the RIPE database at http://www.ripe.net/whois
RegDate: 1993-05-01
Updated: 2010-05-18
Ref: http://whois.arin.net/rest/net/NET-176-0-0-0-0

OrgName: RIPE Network Coordination Centre
OrgId: RIPE
Address: P.O. Box 10096
City: Amsterdam
StateProv:
PostalCode: 1001EB
Country: NL
RegDate:
Updated: 2011-09-24
Ref: http://whois.arin.net/rest/org/RIPE

ReferralServer: whois://whois.ripe.net:43

OrgAbuseHandle: RNO29-ARIN
OrgAbuseName: RIPE NCC Operations
OrgAbusePhone: +31 20 535 4444
OrgAbuseEmail: hostmaster@ripe.net
OrgAbuseRef: http://whois.arin.net/rest/poc/RNO29-ARIN

OrgTechHandle: RNO29-ARIN
OrgTechName: RIPE NCC Operations
OrgTechPhone: +31 20 535 4444
OrgTechEmail: hostmaster@ripe.net
OrgTechRef: http://whois.arin.net/rest/poc/RNO29-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 whois.ripe.net:43.

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '176.102.192.0 - 176.102.223.255'

inetnum: 176.102.192.0 - 176.102.223.255
netname: FOBOS-NET
descr: Center for Information Technologies "Fobos" Ltd.
country: UA
org: ORG-FOBO2-RIPE
admin-c: AP7848-RIPE
tech-c: AP7848-RIPE
status: ASSIGNED PI
mnt-by: RIPE-NCC-END-MNT
mnt-lower: RIPE-NCC-END-MNT
mnt-by: KUTS-MNT
mnt-routes: KUTS-MNT
mnt-domains: KUTS-MNT
source: RIPE # Filtered

organisation: ORG-FOBO2-RIPE
org-name: Center for Information Technologies "Fobos" Ltd.
org-type: OTHER
address: 39800, Ukraine, Poltavsky reg. Komsomolsk, Lenina str., 40
mnt-ref: vissado-mnt
mnt-by: vissado-mnt
source: RIPE # Filtered

person: Andrew Philonenko
address: Lenina str., 41/185
address: Poltava reg
address: 39800 Komsomolsk, Ukraine
phone: +380633131008
fax-no: +380534830742
nic-hdl: AP7848-RIPE
mnt-by: KUTS-MNT
source: RIPE # Filtered

% Information related to '176.102.192.0/19AS39822'

route: 176.102.192.0/19
descr: FobosRoute
origin: AS39822
mnt-by: KUTS-MNT
source: RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.19.5 (WHOIS3)

=-=-=-=-=-=-=-=-=-=-=-= Mon Aug 20 11:59:31 2012 =-=-=-=-=-=-=-=-=-=-=-=

e ancora:

=-=-=-=-=-=-=-=-=-=-=-= Mon Aug 20 11:45:10 2012 =-=-=-=-=-=-=-=-=-=-=-=

 Danger level: [2] (out of 5)

 Scanned UDP ports: [17565: 1 packets, Nmap: -sU]
 iptables chain: INPUT (prefix "Generic log entry:"), 1 packets

 Source: 178.238.218.219
 DNS: [No reverse dns info available]

 Destination: 10.*.*.*
 DNS: [No reverse dns info available]

 Overall scan start: Mon Aug 20 08:59:30 2012
 Total email alerts: 5
 Complete UDP range: [1024-17565]
 Syslog hostname: *

 Global stats: chain: interface: TCP: UDP: ICMP:
 INPUT eth1 0 15 0

[+] Whois Information:
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '178.238.218.0 - 178.238.218.255'

inetnum: 178.238.218.0 - 178.238.218.255
netname: EUROLINK
descr: Eurolink Bt.
country: HU
admin-c: LB1142-RIPE
tech-c: LB1142-RIPE
status: ASSIGNED PA
mnt-by: DENINET-MNT
source: RIPE # Filtered

person: Lorant Budavari
address: WLA Interservices Ltd.
address: Margit u. 114.
address: Budapest, 1165
address: Hungary
phone: +36 1 9994294
fax-no: +36 1 4020274
nic-hdl: LB1142-RIPE
source: RIPE # Filtered
mnt-by: DENINET-MNT

% Information related to '178.238.218.0/24AS33947'

route: 178.238.218.0/24
descr: WLA Interservices Ltd.
mnt-by: WLA-NET-MNT
origin: AS33947
mnt-by: DENINET-MNT
source: RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.19.5 (WHOIS1)

=-=-=-=-=-=-=-=-=-=-=-= Mon Aug 20 11:45:10 2012 =-=-=-=-=-=-=-=-=-=-=-=

In soldoni, trattasi di 3 indirizzi IP dell’est Europa, ovvero:

1) 188.237.169.123 (Moldavo);
2) 176.102.218.106 (Ucraino);
3) 178.238.218.219 (Ungherese).

I suddetti portscan hanno come target il protocollo di trasporto UDP e le porte ad esso associate (non well-known, ovvero superiori alla 1023).

Il protocollo UDP viene utilizzato soprattutto nell’ambito del traffico audio/video e dell’instant messaging, poichè, non prevedendo meccanismi di controllo e ritrasmissione, consente elevate velocità di trasferimento.

Ma perchè prendere di mira proprio il suddetto protocollo? Bhè, suppongo per via del fatto che molti PBX VOIP software sono dei veri colabrodo… e che tali PBX usino proprio l’UDP per il trasporto.

La soluzione? 3 regolette da aggiungere alla chain INPUT di netfilter:

sudo iptables -A INPUT -i eth1 -s 188.237.169.123 -j DROP
sudo iptables -A INPUT -i eth1 -s 176.102.218.106 -j DROP
sudo iptables -A INPUT -i eth1 -s 178.238.218.219 -j DROP

Notate che ho parlato di crew, in quanto gli IP sorgenti dell’attacco non presentano servizi pubblicati all’esterno (a parte uno che è in ascolto sulla porta http/https, ma manca la index) e che si tratta molto probabilmente di semplici linee ADSL (un po’ come la nostra Alice). Infine, ad avallare la mia ipotesi vi è anche il fatto che non esistono nomi dominio associati agli IP in questione (a parte l’hostname ADSL).

In definitiva, mailare il loro ISP sarebbe completamente inutile, quindi non vi è (almeno per il momento) soluzione definitiva a questa piaga. Dunque lasciamo fare a psad il suo sporco lavoro ed interveniamo a tempo debito con qualche regola su netfilter.

A presto.