Scan of the Month 30 - Analyse par Christophe GRENIER

Introduction

Le projet Honeynet propose régulièrement d'étudier des outils, des tactiques utilisées par des pirates lors d'intrusion pour démontrer la réalité de ces attaques, pour apprendre comment un pirate agit, pour s'en protéger et plus généralement pour améliorer les technologies et méthodes de collecte d'information. Dans ce but, des Honeypots ont été connectés sur Internet. Ces pots de miel permettent de collecter un maximum d'information sur les agissements des pirates.

Le challenge présenté dans cet article est assez ingrat, il s'agit d'analyser un mois de log d'un firewall. Malgré la possibilité pour les trois premiers de gagner le livre dédicacé de l'auteur du challenge, seules six personnes ont eu le courage de répondre à ce challenge. Pourtant, nous disposons tous de firewall!

Analyse

Pour commencer, récupérer sur le site de l'Honeynet le fichier de log et vérifions son intégrité.

[kmaster@christophe sotm30]$ tar xzf honeynet-Feb1_FebXX.log.gz
[kmaster@christophe sotm30]$ md5sum honeynet-Feb1_FebXX.log*
8c0070ef51f6f764fde0551fa60da11b  honeynet-Feb1_FebXX.log
e002b1013f18dd42e17be919c2870081  honeynet-Feb1_FebXX.log.gz
[kmaster@christophe sotm30]$ head -1 honeynet-Feb1_FebXX.log
Feb  1 00:00:02 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=192.150.249.87 DST=11.11.11.84 LEN=40 TOS=0x00 PREC=0x00 TTL=110 ID=12973 PROTO=TCP SPT=220 DPT=6129 WINDOW=16384 RES=0x00 SYN URGP=0
[kmaster@christophe sotm30]$ tail -1 honeynet-Feb1_FebXX.log
Feb 27 14:40:06 bridge kernel: OUTG CONN TCP: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.71 DST=220.210.69.62 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=50688 DF PROTO=TCP SPT=80 DPT=1325 WINDOW=6432 RES=0x00 ACK URGP=0

Les logs vont du 1 février 00:00:02 au 27 février, 14:40:06. Rien n'a été enregistré entre le mardi 10 14:47:18 et mercredi 11 10:03:32.

Feb 10 13:51:02 bridge kernel: eth0: 0 multicast blocks dropped.
Feb 10 13:51:03 bridge kernel: br0: port 2(eth0) entering disabled state
Feb 10 13:51:03 bridge kernel: eth1: 0 multicast blocks dropped.
Feb 10 13:51:03 bridge kernel: br0: port 1(eth1) entering disabled state
Feb 10 13:51:05 bridge kernel: br0: port 2(eth0) entering listening state
Feb 10 13:51:20 bridge kernel: br0: port 2(eth0) entering learning state
Feb 10 13:51:35 bridge kernel: br0: port 2(eth0) entering forwarding state
Feb 10 13:51:35 bridge kernel: br0: topology change detected, propagating
Feb 10 13:52:24 bridge kernel: br0: port 2(eth0) entering disabled state
Feb 10 13:52:24 bridge kernel: device eth0 left promiscuous mode
Feb 10 13:52:24 bridge kernel: br0: port 1(eth1) entering disabled state
Feb 10 13:52:24 bridge kernel: device eth1 left promiscuous mode
...
Feb 10 14:47:18 bridge kernel: INBLOCK: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:b0:d0:87:85:c3:08:00 SRC=11.11.11.69 DST=11.11.11.255 LEN=241 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=221
Feb 11 10:03:32 bridge kernel: INBLOCK: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:b0:d0:87:85:c3:08:00 SRC=11.11.11.67 DST=11.11.11.255 LEN=96 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=137 LEN=76
...
Feb 11 11:03:07 bridge kernel: device eth1 entered promiscuous mode
Feb 11 11:03:07 bridge kernel: device eth0 entered promiscuous mode
Feb 11 11:03:07 bridge kernel: br0: port 2(eth0) entering listening state
Feb 11 11:03:07 bridge kernel: br0: port 1(eth1) entering listening state
Feb 11 11:03:22 bridge kernel: br0: port 2(eth0) entering learning state
Feb 11 11:03:22 bridge kernel: br0: port 1(eth1) entering learning state
Feb 11 11:03:31 bridge kernel: Kernel logging (proc) stopped.
Feb 11 11:03:31 bridge kernel: Kernel log daemon terminating.
Feb 11 11:08:38 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=63.204.248.182 DST=11.11.11.90 LEN=48 TOS=0x00 PREC=0x00 TTL=113 ID=23614 DF PROTO=TCP SPT=3961 DPT=135 WINDOW=64800 RES=0x00 SYN URGP=0

Les adresses IP de l'honeynet ont été modifiées en 11.11.11.* et les serveurs DNS en 22.22.22.* et 23.23.23.*.
Tous les enregistrements sont de la machine bridge. Comme son nom l'indique et l'utilisation des devices br*, le firewall est en mode bridge (routage de niveau 2), on se trouve donc en présence d'un honeynet de seconde génération. En observant les interfaces d'entrée et de sortie du bridge (PHYSIN et PHYSOUT) et les adresses IP, nous apprenons que sur eth0 se trouve le routeur internet et éventuellement le réseau de production et sur eth1 les honeypots.

bridge	Drop TCP after 13 attempts	eth1	eth0	38
bridge	Drop udp after 20 attempts	eth1	eth0	7
bridge	INBLOCK	eth0	eth1	2
bridge	INBLOCK	eth1		185
bridge	INBOUND ICMP	eth0	eth1	19602
bridge	INBOUND TCP	eth0	eth1	244546
bridge	INBOUND UDP	eth0	eth1	18994
bridge	Legal Broadcast	eth1	eth0	3792
bridge	Legal DNS	eth1	eth0	18107
bridge	OUTG CONN OTHER	eth1	eth0	7
bridge	OUTG CONN TCP	eth1	eth0	1739
bridge	OUTG CONN UDP	eth1	eth0	485
all	other			20
total				307524

Les enregistrements du firewall sont commentés par

INBOUND ICMP, TCP, UDP, Other:
Tentative de connexion depuis Internet vers l'honeynet, autorisée par le bridge.
OUTG CONN TCP, UDP:
Tentative autorisée depuis l'honeynet.
Drop TCP, UDP after X
Tentative bloquée depuis l'honeynet.
Legal DNS:
Requetes DNS autorisées.
Legal Broadcast: Broadcast réseau autorisé lui aussi.

Quels sont les systèmes les plus attaqués

IP	Interface	Drop TCP after 13 attempts	Drop udp after 20 attempts	INBLOCK	INBOUND ICMP	INBOUND TCP	INBOUND UDP	Legal Broadcast	Legal DNS	OUTG CONN OTHER	OUTG CONN TCP	OUTG CONN UDP	Total
11.11.11.64	eth1	0	0	0	687	4420	652	0	0	0	0	0	5759
11.11.11.65	eth0	0	4	129	0	0	0	0	0	0	0	135	268
11.11.11.67	eth1	20	7	34	600	11387	994	3792	18107	7	370	485	35803
11.11.11.69	eth1	0	0	151	597	9715	795	0	0	0	42	0	11300
11.11.11.70	eth1	0	0	0	597	9884	805	0	0	0	0	0	11286
11.11.11.71	eth1	4	0	0	591	10248	814	0	0	0	676	0	12333
11.11.11.72	eth1	0	0	0	594	9298	880	0	0	0	51	0	10823
11.11.11.73	eth1	2	0	0	593	9518	804	0	0	0	76	0	10993
11.11.11.75	eth1	1	0	0	600	29301	829	0	0	0	97	0	30828
11.11.11.80	eth1	11	0	0	1190	12435	820	0	0	0	427	0	14883
11.11.11.81	eth1	0	0	0	593	8972	833	0	0	0	0	0	10398
11.11.11.82	eth1	0	0	0	594	9217	845	0	0	0	0	0	10656
11.11.11.83	eth1	0	0	0	594	8570	847	0	0	0	0	0	10011
11.11.11.84	eth1	0	0	0	584	7767	806	0	0	0	0	0	9157
11.11.11.85	eth1	0	0	0	590	8506	800	0	0	0	0	0	9896
11.11.11.87	eth1	0	0	0	585	10101	893	0	0	0	0	0	11579
11.11.11.89	eth1	0	0	0	582	8558	766	0	0	0	0	0	9906
11.11.11.90	eth1	0	0	0	1164	10596	763	0	0	0	0	0	12523
11.11.11.95	eth1	0	0	0	1230	8109	830	0	0	0	0	0	10169
11.11.11.100	eth1	0	0	1	1886	10645	772	0	0	0	0	0	13304
11.11.11.105	eth1	0	0	1	2350	10167	748	0	0	0	0	0	13266
11.11.11.110	eth1	0	0	0	2070	10181	658	0	0	0	0	0	12909
11.11.11.115	eth1	0	0	0	246	10161	681	0	0	0	0	0	11088
11.11.11.120	eth1	0	0	0	242	7449	673	0	0	0	0	0	8364
11.11.11.125	eth1	0	0	0	243	9341	686	0	0	0	0	0	10270
11.11.11.255	eth0	0	0	56	0	0	0	3792	0	0	0	0	3848
22.22.22.40	eth0	0	0	0	0	0	0	0	8998	0	0	0	8998
23.23.23.60	eth0	0	0	0	0	0	0	0	9109	0	0	0	9109

Quelques observations:

Les adresses 11.11.11.75, 11.11.11.80 et 11.11.11.67 reçoivent le plus de trafic entrant, ce sont les plus attaquées.
11.11.11.65 est l'adresse du routeur
Seule 11.11.11.67 effectue des résolutions DNS! Il y a deux possibilités:
- 11.11.11.67 est un serveur DNS et tout les honeypots l'utilisent.
- Il y a un seul serveur d'adresse IP principale 11.11.11.67 et de l'IP aliasing est utilisé.

[kmaster@christophe sotm30_bis]$ grep MAC= honeynet-Feb1_FebXX.log|cut -d= -f 3-6|sort -u
 MAC=00:02:b3:65:c9:71:00:b0:d0:87:85:c3:08:00 SRC=11.11.11.67 DST=11.11.11.65 LEN
 MAC=00:02:b3:65:c9:71:00:b0:d0:87:85:c3:08:00 SRC=11.11.11.69 DST=11.11.11.65 LEN
 MAC=ff:ff:ff:ff:ff:ff:00:b0:d0:87:85:c3:08:00 SRC=11.11.11.67 DST=11.11.11.255 LEN
 MAC=ff:ff:ff:ff:ff:ff:00:b0:d0:87:85:c3:08:00 SRC=11.11.11.69 DST=11.11.11.255 LEN

L'observation des adresses MAC nous apprend que 11.11.11.67 et 11.11.11.69 sont deux adresses IP utilisant la même interface réseau.

00:02:b3:65:c9:71 (Intel)	11.11.11.65
b0:d0:87:85:c3:08 (?)	11.11.11.67, 11.11.11.69

L'hypothèse de l'IP aliasing semble la bonne. En fait, cela a été confirmé depuis par l'organisateur de ce challenge qui dans son rapport indique aussi que le serveur est en Linux RedHat 7.x.

Internet	Routeur		   Bridge			Honeypot
				   Linux			Linux RedHat 7.x
				   Netfilter
				eth0  eth1 00:02:b3:65:c9:71    b0:d0:87:85:c3:08
  		 11.11.11.65	  				11.11.11.67
		 						IP Aliasing 
								69-73, 75, 80-85, 87, 89, 90, 95, 100, 105, 110,
								115, 120, 125

Quels ports sont ouverts sur chacun d'eux ?

Un port TCP ouvert renvoie un SYN ACK lorsqu'il reçoit une demande connexion SYN. Recherchons de tels paquets.

[kmaster@christophe sotm30_bis]$ grep "ACK SYN" honeynet-Feb1_FebXX.log|head -4
Feb  1 01:01:55 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=61.129.45.36 DST=11.11.11.69 LEN=44 TOS=0x00 PREC=0x00 TTL=107 ID=56257 PROTO=TCP SPT=80 DPT=6487 WINDOW=16616 RES=0x00 ACK SYN URGP=0
Feb  1 01:02:00 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=61.129.45.36 DST=11.11.11.69 LEN=44 TOS=0x00 PREC=0x00 TTL=107 ID=61373 PROTO=TCP SPT=80 DPT=6487 WINDOW=16616 RES=0x00 ACK SYN URGP=0
Feb  1 01:47:13 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=61.129.45.35 DST=11.11.11.72 LEN=48 TOS=0x00 PREC=0x00 TTL=107 ID=54719 PROTO=TCP SPT=80 DPT=21859 WINDOW=16616 RES=0x00 ACK SYN URGP=0
Feb  1 01:47:16 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=61.129.45.35 DST=11.11.11.72 LEN=48 TOS=0x00 PREC=0x00 TTL=107 ID=46972 PROTO=TCP SPT=80 DPT=21859 WINDOW=16616 RES=0x00 ACK SYN URGP=0
[kmaster@christophe sotm30_bis]$ grep "DST=61.129.45.35" honeynet-Feb1_FebXX.log
[kmaster@christophe sotm30_bis]$

Il semble donc que le port 80 (http) est ouvert sur le serveur 61.129.45.35, or il n'a jamais été contacté par le honeynet. Voici une capture d'écran de ethereal

Plusieurs hypothèses:

Le serveur web 61.129.45.35 a reçu un paquet forgé usurpant l'identité de 11.11.11.72 et y répond. Il serait par exemple la cible d'un scan de l'unique port 80 avec utilisation de leurre (cf nmap -D) ou bien la cible d'une attaque synflood avec IP spoofing.
Un pirate contrôle 61.129.45.35 et émet un paquet SYN ACK de façon à identifier si l'adresse 11.11.11.72 est utilisée, il attend la réponse RST.

Nous voila avec un mystère de plus et nous n'avons toujours pas trouvé quels étaient les ports ouverts.

Finalement, il sera possible de les identifier en recherchant dans les connections sortantes les enregistrements sans SYN, ni RST.

11.11.11.67	TCP	80(http)
		139(netbios-ssn)
		443(https)
	UDP	137(netbios-ns)
11.11.11.69	TCP	21(ftp)
		80(http)
		443(https)
11.11.11.71	TCP	21(ftp)
		80(http)
		443(https)
11.11.11.72	TCP	21(ftp)
		80(http)
		443(https)
11.11.11.73	TCP	21(ftp)
		80(http)
		139(netbios-ssn)
		443(https)
		3128(squid)
11.11.11.75	TCP	21(ftp)
		80(http)
		443(https)
11.11.11.80	TCP	21(ftp)
		80(http)
		139(netbios-ssn)
		443(https)

N'utilisant pas de notion de connection, il est plus difficile de trouver les ports UDP ouverts. En analysant les lignes contenant OUTG CONN UDP, on remarque qu'il y a seulement deux types de flux:

à destination du port UDP 514 du routeur 11.11.11.65
Il s'agit de message syslog.
venant du port UDP 137 de 11.11.11.67
Le port netbios-ns est donc ouvert sur ce serveur.

Pour résumé, l'honeynet combine donc des services HTTP, HTTPS, FTP, SMB, Squid répartis sur ces différentes adresses IP.

Pourquoi des machines avec des adresses IP proches sont attaquées différements ?

En évaluant la quantité de logs pour chaque adresse IP, on remarque que 11.11.11.75, 11.11.11.80 et 11.11.11.67 ont le plus de trafic entrant. Cela serait donc les plus attaquées.

En regardant plus en détail l'INBOUND TCP, 11.11.11.75 domine largement. Elle reçoit énormément de trafic HTTPS depuis 66.60.166.84. Ce service est pourtant présent sur 11.11.11.67, 69, 71-73, 80 mais c'est cette IP qui a été attaqué le plus.
Le trafic UDP est similaire pour chaque machine.
Le trafic ICMP présente lui aussi des inégalités, les adresses 11.11.11.105, 11.11.11.110, 11.11.11.100, 11.11.11.95, 11.11.11.80 et 11.11.11.90 reçoivent le plus de trafic, leur adresse est un multiple de 5 mais cela est un résultat de la configuration du honeypot. Cela est sans doute lié à la qualité des pseudo-générateurs aléatoires utilisés par les vers.

Clairement certaines IP sont plus visés que d'autres. Regardons cette évolution au cours du temps.

Quelles sont les tendances dans l'évolution des flux à destination de l'honeynet ?


	Le trafic TCP entrant augmente avec le temps, tandis que le trafic UDP stagne et le trafic ICMP décroît.

Est-ce que cela correspond aux statistiques relevés par DShield et d'autres sources ?

Les ports les plus attaqués sont similaires à ceux relevés sur DShield TOP Ports. Des tendances ont été calculés en utilisant la formule disponible sur http://isc.incidents.org/trends.html, mais le volume de donnée étant faible comparé à ce système collectant des informations du monde entier, l'erreur relative est donc importante et l'indicateur trend est finalement peu significatif.

INBOUND TCP

135	86565	Trend: -0.12	DCE endpoint resolution, Microsoft RPC services CAN-2003-0605 CAN-2003-0528 CAN-2003-0352
445(microsoft-ds)	46433	Trend: 0.47	Win2k+ Server Message Block
443(https)	26316	Trend: -19.11	Secure HTTP, 66.60.166.84 envoie des paquets vers 11.11.11.75 (et d'autres IP aussi) à destination de HTTPS (TCP 443) au environ de 17h le 7 février.
3127	25781	Trend: -0.37	W32/MyDoom, W32.Novarg.A backdoor
139(netbios-ssn)	14980	Trend: 0.83
80(http)	10384	Trend: -0.21	HTTP
6129	3427	Trend: 0.64	Dameware Remote Admin, un exploit est disponible sur internet pour les versions antérieurs à 3.71.0.0: DameWare Mini Remote Control Server Local SYSTEM Exploit
901(swat)	3097	Trend: -1.61	Samba Web Administration Tool, Witty worm
1433(ms-sql-s)	2745	Trend: 0.13	Microsoft-SQL-Server
17300	2146	Trend: -16.61	Kuang2 backdoor
1080(socks)	1916	Trend: -0.39	Proxy Server
3128(squid)	1529	Trend: 0.47	Proxy Server
4899	1412	Trend: -0.96	Radmin (www.radmin.com) remote PC control software
21(ftp)	1046	Trend: -1.20	FTP
27374(asp)	535	Trend: -15.22	Subseven Windows trojan
10080(amanda)	533	Trend: 0.82	Amanda Backup Util. C'est aussi un des nombreux ports que MyDoom.B essaye de contacter. Tech alert from us-cert
23(telnet)	401	Trend: 0.48	Telnet
20168	378	Trend: 0.36	lovgate virus remote control
111(sunrpc)	310	Trend: -14.67	Portmapper, rpcbind
389(ldap)	282	Trend: 0.65	Lightweight Directory Access Protocol
25(smtp)	267	Trend: 1.22	Looking for SMTP open relay ?
45295	249	Trend: -14.45	Firebird DB trojan
4000	224	Trend: -14.35	neoworx remote-anything slave remote control AOL ICQ instant messaging clent-server communication
31105	183	Trend: -1.53
12345	182	Trend: -14.14	NetBus backdoor trojan (En interne, cela peut être aussi Trend Micro Office Scan)
57	151	Trend: -13.95
3410	110	Trend: -13.64
22(ssh)	93	Trend: -13.47
455	83	Trend: -13.35	Dirt, Backdoor.SubSari15 trojan, Ce port a été scanné par 80.184.152.4.
34816	82	Trend: 1.91
Autre	890

Regardons l'évolution de certains d'entre eux.

135 Blaster, Welchia

Ce port est toujours très exploité mais on ne peut pas identifier ici le virus.
3127 MyDoom backdoor, Doomjuice worm

MyDoom ouvre une backdoor sur le port 3127. Sa variante MyDoom.C ou Doomjuice recherche cette backdoor pour ce propager. Elle a été découverte officiellement le 9 février. En effet, sa découverte coïncide avec le pic du 9 février.
6129 Dameware

Le 22 décembre a été publié une vulnérabilité de type buffer overflow sur Dameware. Le 23 janvier, un ver exploitant cette faille a fait son apparition. Certains doutaient que ce ver allait pouvoir se propager. On peut constater qu'il est bien présent même si le nombre d'attaque est faible.
901 Witty worm

Certaine version de la sonde RealSecure présente une vulnérabilité dans son code gérant ICQ. Le port TCP/901 est utilisé pour le monitoring des événements et est utilisé par le récent ver Witty pour détecter sa présence.
17300 Kuang

INBOUND UDP

137(netbios-ns)	8692	Trend: 0.60	NETBIOS Name Service
1434(ms-sql-m)	5905	Trend: -1.10	Microsoft-SQL-Monitor, CA-2003-04
1026	2366	Trend: -0.87
135	1525	Trend: -2.79	DCE endpoint resolution
1027	260	Trend: -15.53
1812(radius)	146	Trend: -0.04
111(sunrpc)	28	Trend: -13.30
31789	18	Trend: -12.86
53(domain)	17	Trend: -12.80

Le ver Slammer attaque le port UDP 1434 de MSSQL depuis plus d'un an et il est toujours là!

INBOUND ICMP

La totalité du trafic ICMP entrant est constitué de ICMP echo-request (ping). La taille des paquets ICMP est révélatrice du programme l'ayant généré.

[kmaster@christophe sotm30_bis]$ grep ICMP honeynet-Feb1_FebXX.log| ./stat_len.pl
LEN=28 count=100	Nmap ping (No data)
LEN=32 count=1
LEN=36 count=42
LEN=37 count=146
LEN=38 count=0		Linux Traceroute -I
LEN=52 count=48	
LEN=60 count=979	W2K ping, Cisco PIX ping
LEN=64 count=123
LEN=84 count=4		Linux 2.4 ping
LEN=92 count=18140	Nachi/Welchia worm, W2K traceroute
LEN=96 count=7
LEN=100 count=14	Cisco Catalyst ping

Le virus Nachi/Welchia utilise des pings ICMP dans son processus d'infection pour déterminer la présence de cible, il constitue la majorité du trafic ICMP. Les machines 63.123.38.103 (nombre 3928), 63.123.70.166 (nombre 3219) et 63.125.10.7 (host7.southern-charms.com, nombre 3087) ont générés la moitié de ce trafic.

Le virus est éliminé progressivement, mais là encore il sera sans doute toujours présent dans un an.

Quels types d'activité de reconnaissance peut-on détecter ? Dans quel but ?

La principale activité détectée par un firewall est le test de port. Les attaquants, humains ou non, sont à la recherche de port ouvert pour lequel il existe une vulnérabilité connue comme les failles

DCOM RPC (Première appartition dans le Microsoft Security Bulletin MS03-026) utilisant le port TCP 135.
WebDav (Microsoft Security Bulletin MS03-007) utilisant le port http d'IIS.
Workstation service buffer overrun vulnerability (Microsoft Security Bulletin MS03-049), TCP 445.
Locator service, TCP port 445 (Microsoft Security Bulletin MS03-001).
des backdoors (W32/MyDoom, W32.Novarg.A, Subseven, Firebird DB trojan)
des partages Windows sans mot de passe ou avec des mots de passe triviaux
la faille OpenSSL SSLv2 handshake (Exploité par le ver Slapper)
des relais de messagerie ouvert pour véhiculer du SPAM, des virus...
des proxy WEB ouverts pour des rechercher l'anonymas (Attaques par rebond, contournement de filtrage...)
des ftp avec des comptes anonymes pour stocker des warez

Les vers et les outils automatiques de piratage sont les principales sources de ce type d'activité.

Quels sont les différents types de scan que l'on peut remarqué ? Quels sont les outils à l'origine de ceux-ci

La majorité des scans ne ciblent qu'un port et parcourent les adresses IP de façon séquentielle:

Blaster scanne le port TCP 135 (Windows RPC service) par bloque de 20 adresses IP consécutives à la fois (Cf eeye Advisorie)
W32.Welchia.Worm tente d'exploiter lui aussi la faille RPC DCOM, mais aussi la faille WebDav (MS03-007) sur le port 80 des serveurs WEB IIS. Il scanne à travers des réseaux de classe B. (Cf w32.welchia.worm). La variant B exploite deux autres failles: Workstation service buffer overrun vulnerability et Locator service vulnerability, toujours sur le port TCP 445.
D'autres attaquants comme 66.60.166.84 vont scanner pour du HTTPS (TCP 443). Dans le cas présent, c'est une attaque par force brute contre la faille OpenSSL handshake (CAN-2002-0656).

Pas mal de vers ont été identifiés dans cet article. Il y a eu 100 pings Nmap, c'est à dire au final très peu de personnes:

[kmaster@christophe sotm30_bis]$ grep ICMP honeynet-Feb1_FebXX.log|grep "LEN=28"| ./stat_by.pl "SRC="
SRC=203.69.14.162(203.69.14.162) count=47
SRC=217.81.50.100(pD9513264.dip.t-dialin.net) count=41
SRC=217.84.102.194(pD95466C2.dip.t-dialin.net) count=6
SRC=161.58.176.160(161.58.176.160) count=5
SRC=203.125.225.247(203.125.225.247) count=1

Le deuxième attaquant a combiné des pings Nmap (Ping sans donnée, taille 28) avec des pings TCP sur le port 80 à la recherche du port 139. C'est pas très efficace comme méthode. En dehors de celui-ci, les autres attaquants utilisant Nmap n'ont fait que du ping.

Il n'y a eu qu'un seul traceroute:

grep "TTL=1 " honeynet-Feb1_FebXX.log
Feb  3 13:43:51 bridge kernel: OUTG CONN OTHER: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=224.0.0.2 LEN=32
TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
Feb  3 13:45:06 bridge kernel: OUTG CONN OTHER: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=224.0.1.1 LEN=32
TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
Feb  3 13:45:11 bridge kernel: OUTG CONN OTHER: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=224.0.1.1 LEN=32
TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
Feb  3 13:45:11 bridge kernel: OUTG CONN OTHER: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=224.0.1.1 LEN=32
TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
Feb  8 11:02:10 bridge kernel: INBOUND ICMP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=161.58.176.160 DST=11.11.11.75 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=55782 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=19298
Feb  8 11:02:11 bridge kernel: INBOUND ICMP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=161.58.176.160 DST=11.11.11.75 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=55910 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=22370
Feb  8 11:02:13 bridge kernel: INBOUND ICMP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=161.58.176.160 DST=11.11.11.75 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=55966 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=25442
Feb 19 12:11:00 bridge kernel: OUTG CONN OTHER: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=224.0.1.1 LEN=32
TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
Feb 19 12:11:01 bridge kernel: OUTG CONN OTHER: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=224.0.1.1 LEN=32
TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
Feb 19 12:11:04 bridge kernel: OUTG CONN OTHER: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=224.0.1.1 LEN=32
TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

Mais on remarque aussi la présence du protocole 2, il s'agit d'IGMP. L'honeypot est sans doute mal configuré.

Voici un exemple où le pirate scanne une plage d'adresse IP puis se connecte sur les machines où ce port est ouvert.

[kmaster@christophe sotm30_bis]$ grep 80.116.93.36 honeynet-Feb1_FebXX.log|grep 11.11.11.69
Feb  1 09:05:35 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=80.116.93.36 DST=11.11.11.69 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=4456 DF PROTO=TCP SPT=23665 DPT=21 WINDOW=512 RES=0x00 SYN URGP=0
Feb  1 09:05:46 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=80.116.93.36 DST=11.11.11.69 LEN=48 TOS=0x00 PREC=0x00 TTL=113 ID=31181 DF PROTO=TCP SPT=3203 DPT=21 WINDOW=16384 RES=0x00 SYN URGP=0
Feb  1 09:08:17 bridge kernel: OUTG CONN TCP: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.69 DST=80.116.93.36 LEN=107 TOS=0x00 PREC=0x00 TTL=64 ID=33374 DF PROTO=TCP SPT=21 DPT=3203 WINDOW=5840 RES=0x00 ACK PSH URGP=0
Feb  1 09:08:17 bridge kernel: OUTG CONN TCP: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.69 DST=80.116.93.36 LEN=77 TOS=0x00 PREC=0x00 TTL=64 ID=33375 DF PROTO=TCP SPT=21 DPT=3203 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
Feb  1 09:08:17 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=80.116.93.36 DST=11.11.11.69 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=38495 PROTO=TCP SPT=3203 DPT=21 WINDOW=0 RES=0x00 RST URGP=0

80.116.93.36 scanne la plage d'adresse IP en envoyant des SYN pour détecter les ports 21. Un serveur FTP est présent sur 11.11.11.69, celui-ci renvoie donc un SYN ACK (réponse non visible dans les logs de firewall). Alors le pirate se connecte sur le serveur, cette fois-ci le paquet SYN fait 48 octets et non plus 40.

Y a t-il des scans lents ?

src
66.60.166.84	084.166-60-66-fuji-dsl.static.surewest.net	21829
66.186.83.178	Timmins-Cabl-66-186-83-178.vianet.ca	10197
127.0.0.1	localhost	6394
63.13.135.27	2Cust27.VR2.NYC4.broadband.uu.net	5533
63.123.70.166	63.123.70.166	3897
63.125.10.7	host7.southern-charms.com	3727
63.126.133.117	63.126.133.117	2423
67.123.234.132	adsl-67-123-234-132.dsl.anhm01.pacbell.net	2334
63.126.133.8	63.126.133.8	1963
194.128.177.225	mailhost.omt.co.uk	1960
69.55.143.53	xdsl-69-55-143-53.sofnet.net	1809
61.48.11.170	61.48.11.170	1805
218.103.70.82	n218103070082.netvigator.com	1592
63.126.190.227	63.126.190.227	1411
83.30.20.8	li8.neoplus.adsl.tpnet.pl	1296
208.61.160.83	adsl-61-160-83.mco.bellsouth.net	1178
68.237.49.113	pool-68-237-49-113.ny325.east.verizon.net	1077
63.126.133.131	63.126.133.131	1020
217.81.50.100	pD9513264.dip.t-dialin.net	1013
61.120.200.227	hq-mail.autobytel-japan.com	888
83.26.23.92	kn92.neoplus.adsl.tpnet.pl	712
200.203.174.67	200.203.174.67	678
200.203.174.125	200.203.174.125	625
192.168.0.1	192.168.0.1	591
192.168.0.9	192.168.0.9	591
65.94.22.107	MTL-ppp-149514.qc.sympatico.ca	552
63.122.75.30	cable2-30.heathrowcable.net	545
67.68.37.235	Toronto-HSE-ppp3733490.sympatico.ca	537
206.130.246.2	gateway.ssw.ca	514
63.126.133.122	63.126.133.122	503
Other	37352

Et oui! La machine 63.126.133.117 semble étirer un scan sur tout le mois:

Feb 1 13:48:44, il teste les ports TCP 135 et 445 de 11.11.11.72
Feb 1 15:41:14, même chose sur 11.11.11.90
Feb 1 18:13:46, 11.11.11.75
Feb 1 20:11:49, 11.11.11.89
et ainsi de suite

Le 3 février 16:13:17, 5 février 21:48:39, 12 février 22:25:07, 18 février 23:10:38, il revient à ces premiers amours et scanne à nouveau le serveur 11.11.11.72. Il s'agit sans doute d'un ver.

src
63.13.135.27	2Cust27.VR2.NYC4.broadband.uu.net	2588
64.156.39.12	dialup-64.156.39.12.Dial1.Denver1.Level3.net	1602
63.126.25.230	63.126.25.230	574
68.237.49.113	pool-68-237-49-113.ny325.east.verizon.net	507
66.52.249.70	66-52-249-70.sttl.dial.netzero.com	337
202.108.249.51	202.108.249.51	267
210.13.22.79	210.13.22.79	193
202.96.86.37	202.96.86.37	173
203.200.213.182	203.200.213.182	168
168.160.224.144	168.160.224.144	144
202.108.249.21	202.108.249.21	137
221.3.141.40	221.3.141.40	113
61.237.17.55	61.237.17.55	87
221.11.4.8	221.11.4.8	83
148.243.211.25	na-148-243-211-25.na.avantel.net.mx	77
63.199.242.48	adsl-63-199-242-48.dsl.sndg02.pacbell.net	73
81.201.196.125	bar-196-E125.rhone.ch	72
81.128.70.195	host81-128-70-195.in-addr.btopenworld.com	69
202.129.40.27	202.129.40.27	66
148.243.211.247	na-148-243-211-247.na.avantel.net.mx	66
68.125.63.65	adsl-68-125-63-65.dsl.pltn13.pacbell.net	60
64.231.161.3	HSE-Hamilton-ppp291545.sympatico.ca	60
148.243.211.6	na-148-243-211-6.na.avantel.net.mx	56
63.80.79.40	63.80.79.40	53
202.97.179.115	202.97.179.115	50
63.226.20.35	lkmdslppp35.phnx.uswest.net	48
4.43.215.143	lsanca1-ar58-4-43-215-143.lsanca1.dsl-verizon.net	48
69.44.153.38	69.44.153.38	48
221.11.4.9	221.11.4.9	46
66.52.249.71	66-52-249-71.sttl.dial.netzero.com	46
Other	5575

Le même phénomêne peut être observer pour le protocole UDP. Prenons le cas de 64.156.39.12, machine scannant le port UDP 135.

[kmaster@christophe sotm30_bis]$ grep 64.156.39.12 honeynet-Feb1_FebXX.log|grep DPT=135|cut -d: -f1-2|uniq
Feb  1 10:07
Feb  1 10:09
Feb  1 22:41
Feb  2 02:36
Feb  2 05:48
Feb  3 04:28
Feb  3 15:01
Feb  4 09:23
Feb  5 00:27
Feb  5 03:09
Feb  5 22:10
Feb  6 07:39
Feb  6 08:02
Feb  7 00:33
Feb  7 10:03
Feb  7 10:24
Feb  7 22:47
...

Il s'agit là encore, sans trop de doute, d'un ver qui revient à l'attaque.

Quels autres bruits peut-on observer sur Internet ?

En dehors des vers Internet, il y a aussi des SPAMS netbios visant le port TCP 445 pour envoyer des popups.

Quel trafic anormal peut-on observer ?

Il y a plusieurs choses étonnantes:

Du trafic utilisant des adresses privés (RFC 1918)
Par exemple, les adresses 10.10.228.18, 172.16.3.74 se retrouvent dans les logs, elles sont la conséquence d'IP spoofing. Cela signifie aussi que le provider n'a pas pris la peine de mettre en place des protections anti-IP spooging (ex: route path check ou net.ipv4.conf.all.rp_filter = 1 sur un Linux), ni même de configurer des ACL sur ces routeurs pour filtrer les adresses privés

Pire, on retrouve aussi des paquets venant de 127.0.0.1!

[kmaster@christophe sotm30_bis]$ grep 127.0.0.1 honeynet-Feb1_FebXX.log|head -3
Feb 16 08:08:09 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=127.0.0.1 DST=11.11.11.82 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=21925 PROTO=TCP SPT=80 DPT=1537 WINDOW=0 RES=0x00 ACK RST URGP=0
Feb 16 08:08:22 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=127.0.0.1 DST=11.11.11.72 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=23190 PROTO=TCP SPT=80 DPT=1866 WINDOW=0 RES=0x00 ACK RST URGP=0
Feb 16 08:08:34 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=127.0.0.1 DST=11.11.11.85 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=24295 PROTO=TCP SPT=80 DPT=1271 WINDOW=0 RES=0x00 ACK RST URGP=0

Des messages syslog sont envoyés sur le routeur 11.11.11.65. Un routeur n'est pas destiné à traiter ce genre d'information, c'est plutot une source de message. En pratique, un sniffer capture ses paquets.
Le honeynet utilise des adresses IP comprises dans le réseau 11.11.11.64/26. Or le broadcast est en 11.11.11.255, on remarque aussi des paquets à destination de 11.11.11.64. Le masque de sous-réseau est donc mal configuré sur le honeypot.
Des messages IGMP sont émis par le honeypot. Ils n'ont pas de raison d'être, encore un petit problème de configuration.

Quelles sont les tendances dans l'évolution des flux venant de l'honeynet ?

Le trafic UDP n'est composé que de messages syslog et de requêtes Netbios. Il ne présente pas d'intérêt. Pour le trafic TCP sortant, ne conservons que les requêtes SYN sortantes dont on élimine les requêtes vers TCP 113 (auth/ident). Il ne reste que les flux générés depuis l'honeynet:

02-07 1
02-08 40
02-09 1

Est-ce que l'honeypot a été compromis ?

L'honeypot a été compromis, cela ne fait aucun doute, il y a des requêtes sortantes autre que vers le port auth/ident (TCP 113).

Feb  7 16:28:50 TCP eth1 -> eth0 11.11.11.67:1308 -> 209.63.57.10:http	http://www1.0catch.com
Feb  8 06:52:55 TCP eth1 -> eth0 11.11.11.67:1309 -> 62.211.66.12:http	http://www.xoom.it, http://members.xoom.virgilio.it

Feb  8 06:54:47 TCP eth1 -> eth0 11.11.11.67:1311 -> 209.63.57.10:http	http://www1.0catch.com
Feb  8 07:09:20 TCP eth1 -> eth0 11.11.11.67:1315 -> 209.63.57.10:ftp	ftp://www1.0catch.com
Feb  8 07:14:07 TCP eth1 -> eth0 11.11.11.67:1323 -> 193.230.153.133:ftp	ftp://www.as.ro	ftp://www.i-need-ftp.as.ro ftp://www.lugojteam.as.ro
Feb  8 07:34:30 TCP eth1 -> eth0 11.11.11.67:1742 -> 207.66.155.21:http	Bondo and Remer BONDO-REMER (NET-207-66-155-16-1)

Feb  8 10:50:11 TCP eth1 -> eth0 11.11.11.67:1757 -> 64.161.61.115:1291	adsl-64-161-61-115.dsl.snlo01.pacbell.net
Feb  8 10:56:35 TCP eth1 -> eth0 11.11.11.67:1759 -> 207.66.155.21:http	Bondo and Remer
Feb  8 10:57:25 TCP eth1 -> eth0 11.11.11.67:1760 -> 195.27.176.155:http	http://master.openssl.org

Feb  8 11:46:51 TCP eth1 -> eth0 11.11.11.67:1764 -> 207.66.155.21:http	Bondo and Remer
Feb  8 12:01:03 TCP eth1 -> eth0 11.11.11.67:1774 -> 216.254.0.38:ftp	rpmfind.speakeasy.net
Feb  8 12:08:49 TCP eth1 -> eth0 11.11.11.67:1778 -> 62.211.66.12:http	http://www.xoom.it
Feb  8 12:10:27 TCP eth1 -> eth0 11.11.11.67:1779 -> 207.66.155.21:http	Bondo and Remer
Feb  8 12:15:14 TCP eth1 -> eth0 11.11.11.67:1783 -> 66.187.232.40:ftp	ftp://updates.redhat.com
Feb  8 12:19:41 TCP eth1 -> eth0 11.11.11.67:1787 -> 195.27.176.155:http	http://master.openssl.org
Feb  8 12:36:41 TCP eth1 -> eth0 11.11.11.67:1794 -> 207.66.155.21:http	Bondo and Remer

Feb  8 13:46:48 TCP eth1 -> eth0 11.11.11.67:1796 -> 64.161.61.115:1051	adsl-64-161-61-115.dsl.snlo01.pacbell.net

Feb  9 12:06:02 TCP eth1 -> eth0 11.11.11.67:1845 -> 64.161.61.115:3184	adsl-64-161-61-115.dsl.snlo01.pacbell.net

Les hébergeurs Xoom et as.ro ont déjà été utilisés par des pirates pour stocker des exploits et des backdoors comme on a pu le constater lors du SOTM29. L'honeypot est sous RedHat et le pirate tente de télécharger les correctifs sur le site de RedHat ftp://updates.redhat.com ainsi que le site d'OpenSSL master.openssl.org. Cette pratique est courante, le pirate comble par brèche par laquelle il est entré afin qu'aucun autre pirate ne profite de la machine.

Feb  7 16:28:15 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=61.120.200.227 DST=11.11.11.95 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=41971 DF PROTO=TCP SPT=44480 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Feb  7 16:28:23 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=61.120.200.227 DST=11.11.11.95 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=55856 DF PROTO=TCP SPT=44482 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Feb  7 16:28:49 bridge kernel: OUTG CONN UDP: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=11.11.11.65 LEN=93
TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4713 DPT=514 LEN=73
Feb  7 16:28:50 bridge kernel: OUTG CONN TCP: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=11.11.11.67 DST=209.63.57.10 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4123 DF PROTO=TCP SPT=1308 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

L'honeypot a été compromis le 7 février sans doute par la faille OpenSSL SSLv2 handshake par la machine 61.120.200.227 (hq-mail.autobytel-japan.com). On remarque l'émission de message syslog juste avant la connection web sortante.

D'autres messages syslog peuvent être observer:

Feb  3 13:39:13 -> Feb  3 13:48:49
Feb  7 16:26:05 -> Feb  7 16:29:19
Feb  8 06:49:53 -> Feb  8 07:34:54
Feb  8 10:50:12 -> Feb  8 10:59:39
Feb  8 11:43:30 -> Feb  8 12:37:15
Feb 10 14:00:28 -> Feb 10 14:31:03
Feb 11 10:31:07 -> Feb 11 10:31:20 
Feb 11 11:02:31 -> Feb 11 11:02:49
Feb 11 12:26:36 -> Feb 11 12:30:20
Feb 19 12:11:35 -> Feb 19 12:12:16
Feb 20 13:07:58 -> Feb 20 13:08:09

En dehors des messages du 7 et 8 février que l'on peut associer à l'intrusion, on ignore malheureusement la teneur de ces messages.

OS Fingerprinting des attaquants

Feb  1 00:00:32 bridge kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0
PHYSOUT=eth1 SRC=211.168.230.94 DST=11.11.11.69 LEN=48 TOS=0x00 PREC=0x00
TTL=110 ID=7203 DF PROTO=TCP SPT=1207 DPT=135 WINDOW=16384 RES=0x00 SYN URGP=0

Lorsque l'attaquant tente une connexion, paquet TCP avec le flag SYN, diverses informations sont enregistrées par le firewall:

SRC, l'adresse IP à partir de laquelle est lancé la connexion
LEN, la taille du paquet IP
TTL, le time to live décrémenté à chaque routeur, je suppose que le TTL initial était la puissance de 2 supérieure
DF, option interdisant la fragmentation
WINDOW, la taille de la fenêtre TCP, c'est à dire la taille des données pouvant être envoyés sans ACK Remarque, le fenêtre est souvent exprimé en multiple du MTU ou de MSS.

Plus d'informations auraient pu être enregistrées avec l'option iptables --log-tcp-options. Cependant ces empreintes sont suffisantes pour distinguer plusieurs systèmes d'exploitation. Pour cela, j'ai utilisé la base de signature de p0f, un outils de prise d'empreinte passif.

Signature	Nombre	Système d'exploitation
%8192:128:1:48	80644	Windows:98 (15), Windows:2000 SP2+, XP SP1 (seldom 98 4.10.2222)
S44:128:1:48	39233	Windows:XP Pro SP1, 2000 SP3
S4:64:1:60	27747	Linux:2.4 (Google crawlbot), Linux:2.4/2.6, Linux:2.5/2.6 (sometimes 2.4) (2), Linux:2.5 (sometimes 2.4) (4), FortiNet:FortiGate 50
*:128:1:48	25063	-Windows:XP/2000 while downloading (leak!), @Windows:98, @Windows:XP/2000
65535:128:1:48	23876	Windows:2000 SP4, XP SP1
S6:128:1:48	19343	Windows:XP, 2000 SP2+
32767:128:1:52	2255	Windows:98 (10)
16384:128:0:40	1598
8192:128:1:44	1468	Windows:NT 4.0 (older)
64512:128:1:48	980	Windows:XP SP1, 2000 SP3 (2)
*:128:1:64	793	@Windows:XP/2000 (RFC1323), @Windows:XP (RFC1323, w+)
*:128:1:52	721	@Windows:XP/2000 (RFC1323 no tstamp)
S22:64:1:60	638	Linux:2.2 (1)
32767:128:1:48	611	Windows:XP SP1, 2000 SP4 (3)

Si des logs caparables étaient obtenus d'un firewall en production, quelles sources ou groupes d'IP seraient à considérer comme la plus grande menace potentielle

L'analyse de log permettrait de déduire quels sont les flux de communications autorisés. Au besoin, il faudrait revoir totalement la politique de sécurité afin d'interdire par défaut tout flux entrant ou sortant et n'ouvrir que le strict nécessaire. Ainsi les flux bloqués par le firewall venant de réseau interne ou de DMZ sont révélateurs soit de mauvaise configuration, soit de la présence d'un hacker cherchant à rebondir sur d'autres systèmes.

Christophe GRENIER
Consultant Sécurité chez Global Secure
Site perso: http://www.cgsecurity.org
Email perso: grenier@cgsecurity.org

Liens internet:
ISC Incidents trends
DShield TOP Ports
w32.welchia.worm
Tech alert about MyDoom
CAN-2003-0605 CAN-2003-0528 CAN-2003-0352 eeye Advisorie à propos de la faille Windows RPC, RPC DCOM
CAN-2002-0656 bug d'OpenSSL SSLv2 handshake
GenII Honeynet
SOTM29, le challenge précédent

Christophe GRENIER
Consultant Sécurité chez Global Secure
Site perso: http://www.cgsecurity.org
Email perso: grenier@cgsecurity.org