Statistiques

Statistiques jpp mar 11/10/2016 - 22:38

J'ai décidé de regrouper ici quelques résultats statistiques obtenus soit par analyse des "logs" du pare-feu soit plus récemment grâce à Ntop (actuellement 2.4) qui depuis la version 2.2 enregistre dans une base Mysql tous les élements de connexion.
Vous pouvez voir ici tout ce qui concerne Ntop et NtopNG.
Voir ici une mise à jour de septembre 2017.
Pour en revenir aux statistiques je me suis toujours amusé à essayer de savoir qui s'intéressait à mon petit système. Les analyses des résultats du firewall obligent à traiter les fichiers de Log et à traiter des tonnes de texte pour en tirer quelques résultats. Un script enregistre régulièrement ces données dans une base Mysql, mais seuls les évènements ayant "buté" sur le Firewall sont enregistrés.
NtopNG qui enregistre tous les flux réseau est encore plus précis puisqu'il ne loupe rien, pas la plus petite connexion qui lui échappe. L'invasion du port 23 (et 2323) n'a pas échappé à sa détection.
Les statistiques "anciennes" sont reportées dans la section "obsolete".

Origine scans 2019/2022

Origine scans 2019/2022 jpp ven 28/07/2023 - 23:01

Analyse sur 4 ans des origines de scans de ports. (En cours de réalisation)

Cette analyse a été réalisée à partir des archives de NtopNG sur les années de 2019 à 2022, elle concerne les réseaux et sous réseaux en ne retenant que les échanges ayant pour résultat zéro octets transmis. Ceci peut concerner le scan d’un port fermé ou être le résultat d’une connexion rejetée par le pare-feu.

Les données ont été extraites des tables cd NtopNG par année (environ 1 heure pour une année) puis stockées, toujours par année, dans une base Clickhouse pour exploitation, chaque année comporte plus de 20000 rangs.

Le tableau ci-dessous présente les résultats par réseau / années de 2019 à 2022 + un total des quatre années analysées. L’affichage est ici partiel pour voir l’ensemble du tableau (40 principaux réseaux d’origine) il suffit de cliquer ICI.  
 

Tableau nombre de connexions par réseau / année

Réseau  
 

2019

2020

2021

2022

Total

45

127614

680782

395367

177568

1381331

185

472940

410732

199090

143191

1225953

92

183047

148454

361913

50725

744139

194

0

259002

140492

54501

453995

89

48647

133481

177176

28607

387911

80

59955

214079

35433

60775

370242

193

37462

80447

126844

90183

334936

195

0

260603

65560

0

326163

192

0

64530

73939

95801

234270

167

0

23434

69539

127645

220618

81

185096

15577

0

13995

214668

91

0

21066

80677

104760

206503

94

35042

103459

32216

31135

201852

162

0

36785

60644

67256

164685

104

19392

35984

32116

55440

142932

51

11805

95836

21155

12143

140939

87

0

83418

23405

31975

138798

176

19335

61102

10697

45294

136428

212

0

75795

21566

31786

129147

78

17665

12753

15993

56747

103158

103

0

32713

33901

22814

89428

114

0

0

41011

44839

85850

5

24988

12904

10859

28336

77087

46

17659

18460

15228

21562

72909

52

17073

0

17523

33920

68516

198

20607

21165

0

22341

64113

85

45474

18124

0

0

63598

79

0

22898

27075

11575

61548

93

0

59626

0

0

59626

74

0

25059

33807

0

58866

17

16210

15394

12644

11792

56040

213

18685

23991

0

13112

55788

157

12277

11707

16488

14912

55384

173

0

0

22959

27429

50388

123

0

0

13599

36769

50368

172

13787

16634

0

15094

45515

146

0

12914

15387

15742

44043

209

0

13764

19583

10419

43766

216

29964

13689

0

0

43653

On remarque de fortes variations sur certains réseaux, probablement dues à un contrôle, ou absence de contrôle, du FAI responsable selon les années ?

Le réseau "45" fait très fort : 680000 hits en 2020 un peu plus de 1800 par jour !  
 

Pour un peu plus de détail j’ai extrait le détail des données par sous-réseau, par exemple pour le réseau « 45 » cela donne :  
 


Sous-réseau

2019

2020

2021

2022

Total

45.129

0

400745

13983

0

414728

45.143

0

89269

102802

44269

236340

45.146

0

27320

137920

0

165240

45.155

0

15790

75393

48033

139216

45.136

97783

23284

0

0

121067

45.134

0

21852

22726

11801

56379

45.140

0

33094

0

0

33094

45.141

0

17275

0

0

17275

45.227

14980

0

0

0

14980

45.145

0

13854

0

0

13854

45.61

0

0

0

12583

12583

45.93

0

0

0

10578

10578


 - Sous réseaux 185 


 
2019202020212022Total
185.17615887013392100292791
185.156516444269411175769295275390
185.14371508125580084066
185.390669440066944
185.17525697397180065415
185.15313308278850041193
185.19100173762197639352
185.2542681800026818
185.2092469900024699
185.401730700017307
185.2160164400016440
185.2360012334012334
185.1930110520011052
185.531067400010674

- Sous réseaux 92


 
2019202020212022Total
92.63238356650933861335608464565
92.118608085754000118348
92.1198064600080646
92.15401754314324031867
92.531293000012930

-  Sous réseaux 194 


 
2019202020212022Total
194.2602396401888249802308324
194.147001137210113721
194.310124040012404

-  Sous réseau du 89

 2019202020212022Total 
8989.2484394712504817049725252364744

Cliquer ici pour Voir tout le tableau "réseaux".


 

 

Le tableau réseau complet

Le tableau réseau complet drupadmin sam 29/07/2023 - 15:41

Tableau par réseau limité aux origines avec plus de 15000 hits sur une année.

Tableau nombre de connexions par réseau / année

 
2019202020212022Total
451276146807823953671775681381331
1854729404107321990901431911225953
9218304714845436191350725744139
194025900214049254501453995
894864713348117717628607387911
80599552140793543360775370242
193374628044712684490183334936
1950260603655600326163
1920645307393995801234270
16702343469539127645220618
8118509615577013995214668
9102106680677104760206503
94350421034593221631135201852
1620367856064467256164685
00201183102491940143082
10419392359843211655440142932
5111805958362115512143140939
870834182340531975138798
17619335611021069745294136428
2120757952156631786129147
7817665127531599356747103158
103032713339012281489428
11400410114483985850
52498812904108592833677087
461765918460152282156272909
52170730175233392068516
198206072116502234164113
8545474181240063598
79022898270751157561548
930596260059626
7402505933807058866
171621015394126441179256040
213186852399101311255788
1571227711707164881491255384
17300229592742950388
12300135993676950368
172137871663401509445515
146012914153871574244043
209013764195831041943766
21629964136890043653
7732971105190043490
3400151832784343026
159011707157891434541841
3500133052848941794
5401879502197840773
106014058131931322340474
4700186732047839151
6211752002668238434
178013213121221263637971
139014619120461106837733
6401447902151835997
3715249167290031978
6611394204480031842
103139000031390
4901065514456025111
12210931120340022965
12511787101380021925
4000106161029920915
1300002084020840
1410002051520515
1821929600019296
901910700019107
440001767317673
1110001699216992
430001694616946
830158580015858
1180001564015640

On peut remarquer là aussi de grosses variations d'une année sur l'autre, mais surtout dans les 10 premiers une certaine "constance" marquant probablement des FAI très permissifs.

La mode dans les attaques WEB

La mode dans les attaques WEB jpp sam 01/02/2020 - 13:54

Les attaques de serveurs WEB.
Les nouveautés de ces derniers mois :

  • 21 Février 2021 : les attaques liées à l'utilisation de Git pour la mainenance de l'arborescence des serveurs Web se multiplient voir article spécifique.
  • Septembre 2020 à Janvier 2021 : Attaque VXWORKS voir article spécifique.
  • Juin 2020 : La dernière attaque "à la mode " : GET /?q=user

Je ne sais pas encore à quoi est liée cette attaque ... mais j'en ai récupéré plus de 20 sur une seule journée !
Encore beaucoup de "2 accès de longueur 14 et 4 sans aucun header". Tiens je n'en ai plus vu depuis quelques mois (Mai 2021). et toujours les recherches de "/wp-login.php" prélude (si réussi) à diverses attaques.

Attaques "TYPE" :
Il existe une multitude d'attaques sur les sites Web depuis tous les "hits" sur /phpmyadmin, /myadmin, /pma/...... /wp-login
d'autres sont plus ciblées, par exemple /HNAP1 orientée vers certains routeurs ...
Mais il existe des modes, diffusion d'un nouveau script de recherche de vulnérabilités en général, on voit de telles attaques pendant des périodes plus ou moins longues et elles peuvent représenter un volume très important, les dernières en date concernent deux Url spécifiques :

  • .env, ça continue depuis des mois à faible débit toutefois.
  • /.git/HEAD ou /.git/config
  • Une nouvelle lubie (?) les URL commençant par "//", j'ai même vu "///",je ne sais pas ce que c'est censé faire, mais sur un serveur Apache les "//" sont convertis en "/" pour l'accès ce qui ne change donc rien.

".env" déjà rencontré quelques fois sur une longue période présente ces trois derniers jours une quantité plus de 10 fois supérieure aux autres attaques.
Il semble que ".env" soit utilisé par certains sites pour stocker des paramètres tels que les accès à la base de données ... si ces fichiers sont accessibles c'est la porte ouverte pour accéder aux données des utilisateurs ... et/ou pirater le site.
J'ai aussi vu des sites avec un suivi de version assuré par un gestionnaire de version, l'accès à HEAD doit pouvoir révéler des choses intéressantes sur le site.
Dans la plupart des cas il s'agit d'un non-respect des bonnes pratiques car ce type de fichier ne doit pas être "visible de l'extérieur" car contenant des données qui peuvent être sensibles : accès à la base, mot de passe administrateur ....

Liste d'URL d'attaques courantes :

  • /CHANGELOG.txt  ou LICENSE pour déterminer les logiciels et versions utilisés
  • /jmx-console   pour ceux qui laissent une console java accessible sur internet, c'est une invitation aux tentatives de brute-force
  • /myadmin et variantes phpmyadmin ... PhPMyadmin ... php-my-admin ... /pma
  • /db et variantes /dbadmin ... /admin
  • sans oublier /wp-admin et /wp-login
  • ni non plus les url contenant ../../../ pour essayer de "remonter" dans l'arborescence des fichiers du serveur et, par exemple d'accéder au Graal : le fichier /etc/passwd sur une machine Unix/Linux
  • Assez récemment on a vu apparaître la mode du // en début d'URL, je n'ai trouvé aucune information sur cette particularité.

J'arrête ici cette liste qui pourrait être longue ... mais qui dans beaucoup de cas cherche à exploiter des "erreurs" de configuration ou des imprudences telles que des couples user/mot de passe faibles voire très faibles ou a des valeurs par défaut, qui n'a jamais vu des accès administrateur "protégés" par admin/admin.
Une autre "attaque" mais je n'ai pas réussi à trouver à quel vulnérabilité/logiciel elle était destinée, c'est la réception de deux paquets HTTP sans signification particulière, le premier avec un contenu de 14 octets, le second de 4 octets. Quel esprit vicieux a pu inventer pareil scénario. J'en ai vu passer des dizaines en une semaine, puis, après une accalmie, c'est reparti. 

Depuis quelques jours (mai 2021) je trouve des recherches de /telescope .... Il y a toujours des nouveautés correspondant à des failles sur diverses applications.

N'oubliez pas d'effectuer les mises à jour de sécurité de tous vos logicieis ...

Attaques currentsetting.htm

Attaques currentsetting.htm jpp mer 11/11/2020 - 13:57

Novembre 2020 :
Depuis début novembre une nouvelle attaque est apparue, elle se manifeste par des accès qui présentent les caractéristiques suivantes :

  • Accès par IP
  • HTTP ou HTTPS
  • Pas de headers
  • Contenu = "GET /currentsetting.htm HTTP1/1"

Il semble que cette attaque soit dirigée contre des appareils Netgear, mais le terme "currentsettings" est peut-être utilisé dans d'autres logiciels.

Règle de détection pour Suricata  :
drop  tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"Web attack /currentsetting.htm"; flow:established,to_server; content:"/currentsetting.htm"; nocase; classtype:web-application-attack; sid:9005813; rev:1;metadata:created_at 2020-11-02, updated_at 2020-11-02;)

Règle de détection pour Modsecurity :
SecRule REQUEST_URI "@beginsWith /currentsetting.htm" "id:962424,phase:1,t:lowercase,t:removeWhitespace,t:htmlEntityDecode,deny,msg:'Web attack /currentsetting.htm', \
     severity:'CRITICAL' \
    setvar:'tx.msg=%{rule.msg}',status:406"


Il vous faudra bien entendu adapter les identifiants des règles à votre goût.

Attaques web utilisant Git

Attaques web utilisant Git jpp dim 21/02/2021 - 22:40

Fin février 2021 la fréquence des attaques fondées sur l'utilisation de "git" a augmenté de manière importante.
Il y a toujours eu quelques tentatives sur ce type d'URL mais le nombre était très marginal.
Depuis le 18/02/2021 
les attaques cherchant des renseignements liés à la maintenance des fichiers du serveur WEB se multiplient. La recherche concerne les sites dont le versionning est géré par git. Beaucoup de requêtes recherchent /.git/HEAD, leur nombre dépasse la vingtaine par jour sur les derniers jours, et cela concerne surtout le port 80. 
J'ai ajouté une règle pour Suricata concernant ces attaques :

drop tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB attack /.git/HEAD"; flow:established,to_server;  content:"/.git/HEAD"; nocase; http_uri; classtype:web-application-attack; sid:9005782; rev:1; metadata:created_at 2020-02-18, updated_at 2020-02-18;)
Et la même règle sans le "HEAD" car tous ne cherchent pas systématiquement .git/HEAD, il peut aussi s'agir de /.git/config ...
Pour contrer les futures attaques en HTTPS j'ai ajouté une règle pour Modsecurity :

SecRule REQUEST_URI "@beginsWith /.git/" "id:962303,phase:1,t:lowercase,t:removeWhitespace,t:htmlEntityDecode,deny,msg:'Web attack /.git/', \
severity:'CRITICAL' \
setvar:'tx.msg=%{rule.msg}',status:406"

Il semble donc imprudent d'utiliser Git pour gérer directement l'arborescence de son serveur Web. Il vaut donc beaucoup mieux gérer son arborescence Web dans une machine séparée, non accessible depuis Internet, on pourra ici utiliser sont outil préféré de versionning et recopier l'arborescence sur le "vrai" serveur Web après chaque train de modifications, la commande "scp" supporte la recopie de répertoires entiers ...

On est maintenant début 2022, presque un an après l'écriture de cet article et on constate toujours de nombreuses attaques cherchant des fichiers ".git" ou ".git/HEAD". Alors même que ces fichiers et répertoires devraient, au minimum, être cachés par un .htaccess ou carrément mis ailleurs, hors de portée ... du service web.

Octobre 2020 ...

Octobre 2020 ... jpp sam 07/11/2020 - 22:44

26 Janvier 2021 :
Cette attaque dure déjà depuis plus de 3 mois, du jamais vu.
Aujourd'hui un record des attaques "VXWORKS", 2093 "hits" entre 00:00 et 23:59, un gars a même insisté avec 831 hits ... Je n'avais encore jamais vu ça. Au fait il faut mettre à jour ma petite statistique accessible ci-dessous.

Octobre 2020 : voir quelques chiffres.
Très nombreux hits détectés par Suricata avec le message :
"ET EXPLOIT Possible VXWORKS Urgent11 RCE Attempt - Urgent Flag"
Sur les quatre dernières semaines cela représente un peu plus de 11000 hits sur mon adresse.
Ces attaques concernent principalement les port : 80,443,465 et 8080, parfois un peu de 3478.

La détection est assurée par les règles standard, et à jour, de Suricata.

Petite précision : pour ces attaques le "payload" est absent (longueur=0), toute l'astuce tient dans les flags TCP. 
Ces attaques visent la pile TCP de l'OS VXWORKS et d'autres qui sont utilisés par de très nombreux "devices" de par le monde, j'ai vu des articles citant des chiffres énormes de centaines de millions d'appareils de par le monde.
Des correctifs existent pour les versions récentes mais il existe, probablement, de très nombreux appareils utilisant des versions obsolètes et/ou qui ne sont plus "patchables". Parmi ces systèmes "à risque" on trouve des matériels de commande industrielle aussi bien que des appareils à usage médical, heureusement peu de ces appareils sont, en principe, reliés à Internet, mais avec la manie de tout connecter il est bien possible qu'un nombre certain soit plus ou moins accessible.

5 février 2021 :
Cette attaque a cessé aussi vite qu'elle avait commencé en moins de 24 heures (dernier jour le 29 janvier 2021) le nombre de hits est tombé complètement, le petit tableau ci-dessous résume la chute brutale du nombre de hits :

DateNombre de Hits
2021/01/241720
2021/01/25929
2021/01/262093
2021/01/27848
2021/01/28675
2021/01/293

Attaques : quelques chiffres

Attaques : quelques chiffres jpp mer 28/10/2020 - 13:24

Cette "attaque web" a commencé début octobre et a continué régulièrement jusqu'au 29/01/2021 elle s'est alors terminée brutalement. Ce fait peut laisser à penser à une organisation centralisée car un ensemble inorganisé ne pourrait agir de manière si concertée, s'agissait-il d'une sorte de botnet ? Il pourrait aussi s'agir d'une contre-mesure au niveau du réseau internet mais il est peu probable de pouvoir obtenir une "mise à jour" globale si rapide du réseau mondial.
J'en ai fait quelques tableaux le 05/02/2021 pour montrer son ampleur jusqu'au 29/01/2021 jour du point final de cette campagne :

  1. Tableau en nombre de hits par jour
  2. Tableau en nombre d'adresses IP participantes
Tableau par IP
Tableau en nombre de "Hits" par jour

On est monté à plus de 2000 hits par jour.

Tableau en nombre d'adresses IP
Tableau en nombre d'IP impliquées par jour

Les plus "gros" jours, aux environs du 22 octobre, on est monté à plus de 50 "agresseurs" différents pour près de 1500 hits.
J'ai compté plus de 350 hits pour une seule IP !
Aucune IP n'est présente deux fois, chez moi il suffit d'une fois pour que cette IP soit bannie, le "réservoir" de vilains semble donc inépuisable.
Autre remarque : un fort pourcentage de ces hits provient de machines virtuelles signées "Azure", merci Microsoft.

Stat 2019 sur ports

Stat 2019 sur ports jpp mar 30/07/2019 - 13:28

En regardant les rapports sur les nombreux "hits" sur le firewall ou dans les rapports IDS j'ai constaté la recrudescence de certains ports et une diminution pour d'autres. Afin de quantifier un peu cette impression je me suis penché sur les archives de NtopNG. Devant le volume j'ai limité mes ambitions à faire un inventaire des 10 "meilleurs" ports (les plus demandés par les "vilains") sur les six premiers mois de 2019 pour plus ample information.
Bien que je dispose de données archivées depuis mi 2016 j'ai décidé de me limiter au premier semestre 2019 car je réalise ceci sur mon portable (outil de vacances).
Cela représente quand même presque 28 millions de rangs dans la base Mysql. J'ai donc extrait les six mois de janvier à juin 2019 de la base archives et je les ai transférés dans le portable pour exploitation.
J'ai par ailleurs limité la recherche aux adresses IP figurant dans différentes "black lists" ce qui représente quand même environ 135000 "Black" adresses et #170000 hits sur le semestre pour les 10 ports  les plus fréquents ! Ceci parmi les 30000 ports utilisés entre 1 et 32000 les vilains ont de la constance.
Tableau des 10 ports les plus fréquentés :

Port NB hits
1900 41 935
23 32 226
445 26 227
8545 11 183
3389 9 513
22 9 352
81 7 024
5060 6 994
1433 6 305
8080 5 851
Total 156 610

Deux graphes représentant l'évolution par semaine sur le premier semestre 2019 :

Graphe à échelle linéaire :
Graphe (echelle linéaire) semaine par semaine

Graphe à échelle logarithmique :
Graphe à échelle logarithique

On constate aisément sur les graphes que le port 1900 bat tous les autres sauf quelques pointes du port 23 qui reste très vaillant ( à la recherche d'objets connectés mal protégés ?).
Le port 445 a subi une inflation importante à partir de début mars et il me semble qu'il reste actuellement très "demandé".
Le port 8545 (lié à des vols sur Ethereum ?) a présenté une pointe d'activité à la mi-février.

Le port 1433 (Lié à Sqlserver) a diminué de manière importante dès début mars et est passé de presque 1000 hits par semaine à moins d'une centaine sur le deuxième trimestre.
Pour les autres ports la demande semble à peu près constante.
Il semble donc y avoir un important effet de "mode" sur certains ports, peut-être la diffusion de failles de sécurité exploitables qui expliqueraient l'engouement des méchants pour ces ports.

Stat 2019 sur ports tableau détaillé

Stat 2019 sur ports tableau détaillé jpp mar 30/07/2019 - 13:32
 Ports avec les « Meilleurs » hits sur le premier trimestre 2019
WEEKP1900P23P445P8545P3389P22P81P5060P1433P8080
11430921533756273381629146684178
216581932640812329300716190819264
316501739694559292324707155857221
417191016695768350344584145921223
516781068660840329396120132815223
6167311045531226403328106175775232
716721056846799451338217210487231
816121094105457036235619117736193
916651015121433936045415812338251
1016851272119718248234114531931263
1117192116114825031429716731346225
1217001250121628335031525133755230
1316991341121634231230215135955211
1417091173113622034130815528762193
1516801149109821140936923040076277
1616721186111922841935411829864246
1717081237114921640937213332456247
181728980124327340634718334557220
1916761300123324945737742540253234
2016681911120128249838933540554253
2115251074111624848838716840959216
2214001416104825539330421033849209
2313981007106528437941819528455209
241396989111330930339125223439183
2514001448103127132241020424345211
26141543210094118245027424417208
TOTAL41935322262622711183951393527024699463055851
 156610         

Statistique sur les navigateurs

Statistique sur les navigateurs jpp mer 15/04/2020 - 23:57

Usage des navigateurs pour le premier trimestre 2020 :
Camembert sur l'usage des navigateurs

On constate une baisse de Firefox et même de Chrome, le seul en nette hausse est Opera.
Ces valeurs ne correspondent pas aux chiffres généraux et "officiels", les personnes qui fréquentent ce site sont donc une fraction"spéciale" de la population, bien différente de la population générale.

Usage des navigateurs pour l'été 2019 :

Camembert navigateurs été 2019

Usage des navigateurs pour 2018/12 à 2019/03 :
 

Graphique (camembert) des navigateurs en %

Pas beaucoup de changements entre Firefox et Chrome mais un peu plus de détail.

Un beau camembert de l'usage des navigateurs sur ce site du 2017/11/05 au 2017/12/04 :

Camembert % navigateurs

Scripts amusants

Scripts amusants jpp mer 10/08/2016 - 23:51

Je me suis aperçu que depuis quelques temps beaucoup de tentatives de connexion (par exemple sur le port 23) étaient originaires du Vietnam.
Sur mon pare-feu f'ai la possibilité de "bloquer" les IP d'un pays entier et le Vietnam a rejoint la Russie et la Chine dans la liste des pays bloqués.
J'ai voulu établir un petit palmarès des IP ayant tenté au moins une connexion, Ces adresses IP sont enregistrées par Ntop et un petit script personnel stocke les IP enrichies dans une table spécifique.
J'ai créé une table des pays "bloqués" au niveau du parefeu :

create table PAYS_BLOQUE
(CODPAYS        char(2)
)
engine MyISAM;
insert into PAYS_BLOQUE (CODPAYS) values ('CN');
insert into PAYS_BLOQUE (CODPAYS) values ('RU');
insert into PAYS_BLOQUE (CODPAYS) values ('VN');;
insert into PAYS_BLOQUE (CODPAYS) values ('HK');
insert into PAYS_BLOQUE (CODPAYS) values ('BR');
commit;

En combinant cette "nouvelle" table avec la table "IPV4_DOMAINE" par un ordre SQL amusant :

select xx.CODPAYS,xx.CTR,
        (case pb.CODPAYS
        when pb.CODPAYS is null  then    'BLOQUE'
        else '' end) BLOQUE
from
    (select CODPAYS,COUNT(*) CTR
    from IPV4_DOMAINE
    group by 1
    ) xx
left join PAYS_BLOQUE pb on (xx.CODPAYS = pb.CODPAYS )    
where xx.CTR > 150
order by 2 desc ;

on obtient le palmarès suivant :

+---------+------------------------+------+--------+
| CODPAYS | FR_NOM                 | CTR  | BLOQUE |
+---------+------------------------+------+--------+
| US      | États-Unis             | 2757 |        |
| CN      | Chine                  | 1317 | BLOQUE |
| VN      | Viet Nam               | 1279 | BLOQUE |
| BR      | Brésil                 | 1093 | BLOQUE |
| FR      | France                 |  828 |        |
| KR      | République de Corée    |  590 |        |
| TW      | Taïwan                 |  562 |        |
| RU      | Fédération de Russie   |  558 | BLOQUE |
| IN      | Inde                   |  434 |        |
| TR      | Turquie                |  321 |        |
| NL      | Pays-Bas               |  266 |        |
| CO      | Colombie               |  236 |        |
| RO      | Roumanie               |  223 |        |
| DE      | Allemagne              |  211 |        |
| PH      | Philippines            |  166 |        |
+---------+------------------------+------+--------+
15 rows in set, 4 warnings (1,93 sec)

Les pays bloqués sont parmi les leaders en nombre d'IP ayant tenté d'établir des connexions.
Plus de 1300 adresses chinoises , presque 1300 adresses vietnamiennes et plus de 1000 adresses brésiliennes ont tenté de se connecter et ont été rejetées par le parefeu.
J'ai controlé par ailleurs qu'aucune adresse de ces pays n'avait recu un octet en retour (sum(OUT_BYTES)) reste à zéro. On voit aussi dans ce tableau que les russes sont en baisse, ils se consacrent probablement à des activités plus "rentables" que de tenter de pénétrer les machines des autres.
Les brésiliens, comme les vietnamiens sont relativement nouveaux mais arrivent fort eux aussi.

Pour s'amuser un peu plus et voir quels ports sont les plus utilisés voir ici.
J'ai utilisé ici encore une nouvelle table pour avoir les noms des pays en clair :

desc PAYS;
+-----------+-------------+------+-----+---------+-------+
| Field     | Type        | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+-------+
| CODPAYS   | char(2)     | NO   | PRI |         |       |
| CODPAYS_3 | char(3)     | YES  |     | NULL    |       |
| ENG_NAME  | varchar(40) | YES  |     | NULL    |       |
| FR_NOM    | varchar(40) | YES  |     | NULL    |       |
+-----------+-------------+------+-----+---------+-------+

Cette table ("dump" Mysql) est disponible ici en téléchargement.

Statistiques : port 23 sur 16 mois

Statistiques : port 23 sur 16 mois jpp mer 29/03/2017 - 13:51

La "folie" du port 23 dure encore et toujours, la preuve ce graphe par date des "hits" sur les ports 23 et 2323 depuis le 2 août 2016 jusqu'au 1er novembre 2017.. Une remontée visible sur fin octobre 2017 est visible, se confirmera-t-elle ?

Graphique hits sur port 23 et 2323 de 2016/08/02 à 2017/03/28

Il semble néanmoins que la période de folie de fin 2016 soit légèrement passée, la baisse fin janvier/début février est due à un défaut d'enregistrement, comme celle de mi-septembre correspondant à des vacances en des lieux assez éloignés.
Ces chiffres sont obtenus à partir des données enregistrées par
NtopNG et concernent actuellement près de 340 000 adresses IP différentes et plus de 45 millions d'événements réseau. Oui la base commence à gonfler sérieusement et je ne fais plus ces statistiques sur la machine de "production".

Par pays (limité aux 25 "premiers") on voit que la Chine et le Brésil on nettement dépassé le Viet Nam depuis les résultats précédents, l'Inde effectue une belle remontée. En bas de peloton (non visible ici) on trouve Nauru, Anguilla et le Lesotho avec une IP et un paquet chacun.

Statistique par pays (limité au 25 principaux)

Stats IP des pirates 2020

Stats IP des pirates 2020 jpp sam 12/10/2019 - 13:35

Cette page est destinée à remplacer une page plus ancienne mais reste "en cours de modification" pour cause de manque de temps ... C'est un peu long de manipuler de gros paquets de données pour en extraire des données intéressantes/amusantes. 

Je me suis amusé à faire un petit comptage sur les adresses IP de "pirates" que j'ai détectés (scan de ports ou attaques WEB essentiellement). Il s'avère que certains sous-réseaux sont littéralement bourrés de ces individus.

Je me suis limité à compter sur les /24 le nombre d'adresses et le pourcentage que cela représente de ce sous-réseau ...
Note : certains pays sont éliminés d'office dans ce tableau : Chine, Russie, Brésil .... et je vais ajouter le pays dans le tableau.
Et voici les résultats, les 20 premiers sont :

Réseau /24 Nombre %
71.6.234.0 123 48,05 %
71.6.233.0 123 48,05 %
162.243.129.0 108 42,19 %
162.243.145.0 103 40,23 %
198.108.67.0 96 37,50 %
192.35.169.0 96 37,50 %
162.243.139.0 91 35,55 %
192.241.239.0 88 34,38 %
162.243.130.0 88 34,38 %
162.243.138.0 83 32,42 %
192.241.238.0 79 30,86 %
162.243.137.0 78 30,47 %
162.243.131.0 77 30,08 %
162.243.136.0 77 30,08 %
159.203.200.0 77 30,08 %
162.243.132.0 75 29,30 %
162.243.144.0 72 28,13 %
159.203.199.0 68 26,56 %
162.243.133.0 65 25,39 %
192.241.225.0 64 25,00 %

Il semble donc que certains FAI ne sont pas très "regardants".
Je n'ai pas osé mettre le nom des FAI ou entreprises car à part deux sociétés spécialisées dans le domaine des statistiques sur Internet les 18 autres proviennent du même FAI, d'ailleurs un des plus importants (le plus important ?) du monde.
Accès à la page "ancienne".

Stat : IP des pirates-old

Stat : IP des pirates-old jpp dim 18/08/2019 - 13:39

Le tableau suivant présente les principaux "nids" de pirates par sous-réseau (/16).
Certains pays ne sont pas présents (pour les IP/32) dans ce tableau car je les élimine impitoyablement dès l'entrée, ce pays sont principalement la Russie, la Chine, le Brésil, quelques pays d'Amérique du sud et quelques pays asiatiques. Les adresses IP utilisées proviennent de différentes listes de diffusion d'adresses douteuses plus ma propre liste.

« /8 » « /16 » NB ADDR %
108 62 2 051 3,13
216 151 792 1,21
173 234 770 1,17
54 36 542 ,83
216 152 512 ,78
77 247 426 ,65
107 170 375 ,57
66 249 374 ,57
165 22 348 ,53
178 128 316 ,48
68 183 314 ,48
162 243 314 ,48
206 189 287 ,44
134 209 281 ,43
159 65 281 ,43
128 199 280 ,43
96 47 279 ,43
178 137 277 ,42
139 28 268 ,41
95 141 260 ,40

La colonne "%" représente (le nombre d'adresses présentes / 65536) * 100.
On voir que les trois premières lignes montrent une utilisation de plusieurs % des adresses disponibles pas des "pirates". Le sous-réseau 108.62 est constitué de plus de 4% de "pirates" !
Le tableau est limité aux sous-réseaux ayant plus de 0.4% d'adresses réputées "malignes".

Attaques courantes 2020/2021

Attaques courantes 2020/2021 jpp jeu 14/10/2021 - 19:31

Ce tableau présente un récapitulatif des "ennuis" détectés par Suricata sur la dernière année.
On y remarque en tête les attaques liées à "VW Works",ce tableau ne comporte pas les détections sur le port 443 car Suricata ne peut interpréter les transmissions SSL/TLS.

On remarque aussi en deuxième position les détections correspondant, en général, à des attaques n'ayant pas donné de résultat car le service destinataire a répondu par un message d'erreur : style "Bad request" pour le port 80 ou coupute de la connexion paur un serveur SMTP.

Nombre
 
Description
66272
 
ET EXPLOIT Possible VXWORKS Urgent11 RCE Attempt - Urgent Flag
14520
 
SURICATA Applayer Detect protocol only one direction
7538
 
SURICATA TLS invalid record/traffic
7153
 
SURICATA SMTP invalid reply
2415
 
SMTP no server welcome message
1593
 
SURICATA STREAM reassembly overlap with different data
1590
 
SURICATA Applayer Wrong direction first Data
1301
 
SURICATA SMTP data command rejected
1244
 
WEB acces /.env
1186
 
SURICATA TCP invalid option length
972
 
ET EXPLOIT Possible Dovecot Memory Corruption Inbound (CVE-2019-11500)
944
 
SURICATA HTTP missing Host header
906
 
ET POLICY Observed Cloudflare DNS over HTTPS Domain (cloudflare-dns .com in TLS SNI), celui là est normal ici
834
 
ET DNS Query for .to TLD
775
 
GPL EXPLOIT ntpdx overflow attempt
744
 
SURICATA Applayer Mismatch protocol both directions
717
 
Web attack phpmyadmin
583
 
Web attack /user/login
558
 
GPL DNS zone transfer UDP
498
 
ET POLICY CURL User Agent
484
 
ET POLICY Credit Card Number Detected in Clear (16 digit)
481
 
Web Attack /wp-admin
449
 
ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent
419
 
ET EXPLOIT Possible CVE-2020-11910 anomalous ICMPv4 type 3,code 4 Path MTU Discovery
416
 
SURICATA TCP option invalid length
408
 
ET EXPLOIT Possible CVE-2016-2211 Symantec Cab Parsing Buffer Overflow
407
 
WEB Attack /plugin
399
 
ET POLICY SSLv3 Used in Session
380
 
Web Attack /wp-content
353
 
ET POLICY TLSv1.0 Used in Session

Ce tableau ne tient évidement pas compte de la folie "Log4j" ... qui n'a pas eu chez moi d'énormes répercussions. Suricata a bien epéré quelques tentatives mais pas une invasion.
 

Attaques web

Attaques web jpp jeu 21/02/2019 - 13:43

Après quelques semaines d'utilisation de Suricata en protection d'un serveur WEB j'ai compilé cette petite statistique sur les attaques les plus fréquentes sur le port 80 (Https est hors de portée de Suricata, mais Modsec est là pour le Https).
Tableau numéro 1 par pays (certains pays sont absents car bloqués au niveau du pare-feu : Chine, Russie ...).

Code Nom du pays Nbr hits
TH Thaïlande 591
US États-Unis 492
KR République de Corée 182
ES Espagne 170
TW Taïwan 154
MY Malaisie 144
FR France 115
CZ République Tchèque 113
HU Hongrie 102
DE Allemagne 69
IP NULL 32
IT Italie 31
BE Belgique 30
FI Finlande 27

Tableau numéro 2 par type d'attaque :

CTR Libellé
325 Web attack phpmyadmin
210 WEB attack /wp-login.php
134 WEB Attack /admin
78 Web attack /pma
77 WEB attack acces mysql
71 WEB Attack setup.php
67 WEB Attack /user/register
59 ET EXPLOIT HackingTrio UA (Hello, World)
55 WEB Attack /test
40 WEB Attack /muhstik
38 ET SCAN ZmEu Scanner User-Agent Inbound
35 WEB attack myadmin
35 Web Attack : /myadmin/script
35 Web attack /scripts/
30 Web Attack /admin/phpmy...
29 ET WEB_SPECIFIC_APPS Drupalgeddon2 <8.3.
29 Web attack /cmd
29 WEB Attack xmlrpc.php
29 WEB Attack /plugin
27 ET WEB_SPECIFIC_APPS [PT OPEN] Drupalged
26 WEB Attack '/web'
26 ET SCAN Possible Nmap User-Agent Observe
25 Web attack /s.php
24 WEB Attack ?q=user/password
21 WEB Attack '/xw'
21 Web Attack : /administrator
20 Web attack sur HNAP1
20 WEB Attack /shell
20 WEB attack /dbadmin
19 Web Attach /lala...
19 WEB Attack '/plugins/wea'
18 Web Attack : /pmamy..
18 WEB Attack /admin/pma
17 WEB Attack /phpadmin
16 Web attack /wordpress
15 Web Attack /wp-content
15 ET WEB_SERVER Exploit Suspected PHP Inje
15 WEB Attack /data
12 WEB Attack /vuln.php
12 WEB Attack alpengruss.it
11 WEB Attack '/w.php'
11 Web attack /sheep
11 WEB attack /db/..
11 Web attack /web/
11 WEB attack /mysqladmin
11 WEB Attack '/manager'

On voit ici que les attaques enregistrées sont des attaques "simples" faisant, en général, référence à des bugs logiciels (par exemple /wp-login.php), de mauvaises configurations ou l'installation de logiciels spécifiques. Il est par exemple très imprudent de laisser un "Phpmyadmin" accessible sur Internet, même si le répertoire principal est rebaptisé "pma".

Nombre IP par pays 11/2017

Nombre IP par pays 11/2017 jpp mer 01/11/2017 - 13:46

Note 2022 : depuis mon pare-feu bloque la plupart des adresses en provenance des pays trop "agressifs" et dont les sites ne m'intéressent pas, merci IP2location pour la liste des plages d'IP par pays et à "ipset" pour faire ce sale travail.

Une petite statistique sur l'origine des IP ayant eu au moins un contact d'août 2016 à ce jour (01/11/2017), liste établie sur plus de 410 000 IP différentes. Je précise que Chine,Russie,Vietnam et quelques autres sont impitoyablement rejetés par le pare-feu.

Code Pays Nombre IP
CN Chine 58 542
US États-Unis 53 232
BR Brésil 30 285
VN Viet Nam 23 657
RU Fédération de Russie 19 260
IN Inde 17 449
KR République de Corée 16 207
FR France 15 828
TW Taïwan 13 779
TR Turquie 13 436
MX Mexique 10 925
AR Argentine 9 821
UA Ukraine 8 374
IR République Islamique d\'Iran 6 345
GB Royaume-Uni 6 165
NL Pays-Bas 5 711
RO Roumanie 5 363
DE Allemagne 5 332
CO Colombie 5 276
IT Italie 4 761
IE Irlande 4 315
TH Thaïlande 4 228
PL Pologne 4 209
PK Pakistan 3 515
AU Australie 3 469
ES Espagne 2 749
ID Indonésie 2 617
CA Canada 2 477
CL Chili 2 352
SE Suède 2 146
HK Hong-Kong 2 035
EU EUROPE 1 999
PH Philippines 1 891
JP Japon 1 890
IL Israël 1 736
BG Bulgarie 1 717
MY Malaisie 1 466
EG Égypte 1 458
SG Singapour 1 434
EC Équateur 1 428

Statistiques sur les scans

Statistiques sur les scans jpp mer 21/04/2021 - 13:51

Quelques chiffres sur le scanning réseau.

Je conserve précieusement des archives en provenance de Ntopng sur plusieurs années : plus de 330 000 000 lignes) et j’ai eu envie de les exploiter un peu.

Par exemple les connexions sans réponse (colonne « OUT_BYTES » à zéro) marquent un certain nombre de scan bloqués par le pare-feu (action « drop ») ou d’autres actions bloquées à la source ( par exemple par Suricata) qui ne génèrent aucune réponse.
J’ai voulu voir s’il y avait une évolution significative sur les dernières années, en fait depuis depuis décembre 2017 (date mini dans mes archives …).

Le résultat est assez impressionnant en un mois (2020/11) plus de 2 600 000 connexions rejetées !

Graphe connexions "nulles"
Nombre de connexions "refusées"

La variation sur ces quelques années n’est pas très typique mais on note une variation importante avec des pointes passant les 2 000 000 de connexions sur 2018 (oct/nov) et 2020 (nov).

2021/04 n’est ici pas significatif car incomplet (test fait le 21/04/2021).
Aucune modification notable n’a été faite au niveau de la machine pare-feu et l’utilisation des machines « abritées » derrière a peu varié durant cette période.

De gros scanneurs

De gros scanneurs jpp mer 10/08/2022 - 00:17

Je conserve les traces (voir NTOPNG) de toutes les connexions et je me suis demandé quelles étaient les caractéristiques de  ceux qui passant leur vie à scanner le web.
J'ai donc fait un extrait les données : nombre de hits; nombre de ports différents, date du premier hit et date du dernier hit pour les entrées n'ayant pas donné lieu à réponse (port fermé).
Le résultat est comporte quelques chiffres surprenants :

  • Le plus "gros" scanneur a déclenché plus de 80000 hits sur 64408 ports en 25 jours soit une moyenne de 2576 ports par jour....
  • Un autre a scanné 65235 ports (tiens il en a oublié quelques-uns ?) en six jours seulement avec une moyenne de plus de 10000 ports par jour soit environ un port toutes les 7 secondes !
  • Un autre a "étalé" 31960 hits concernant 1092 ports sur 1406 jours  soit presque 4 ans soit une moyenne de 22 ports par jour seulement !
  • 36 adresses IP différentes on réalisé plus de 20000 hits

Voici le tableau correspondant :

Les plus gros scanneurs rencontrés sur 4 ans
IP Nombre de hits Nombre de ports Début Fin Nombre de jours
45.143.220.101 80 996 64 408 2020/03/22 22:03:49 2020/04/17 02:04:24 25
92.63.197.23 65 295 65 295 2021/09/17 22:09:39 2021/09/24 05:09:53 6
45.143.200.34 46 036 25 699 2021/04/09 23:04:37 2022/02/10 21:02:53 306
173.231.60.195 44 355 2 2021/12/09 06:12:06 2022/03/09 13:03:02 90
92.63.197.108 38 179 32 243 2021/08/22 13:08:04 2021/11/25 04:11:09 94
146.88.240.4 36 361 63 2019/04/11 04:04:05 2022/07/30 16:07:15 1206
92.63.197.112 36 060 32 081 2021/08/22 13:08:51 2021/11/25 10:11:34 94
92.63.197.110 35 671 29 999 2021/08/22 13:08:24 2022/07/10 12:07:55 321
212.70.149.69 35 319 1 2020/10/19 04:10:22 2020/12/18 12:12:19 60
10.128.175.2 33 844 1 2018/06/02 05:06:16 2020/07/01 12:07:01 760
176.113.115.246 33 618 32 906 2020/01/29 09:01:25 2020/05/09 20:05:01 101
212.70.149.68 32 400 1 2020/08/21 04:08:36 2020/10/16 20:10:35 56
185.176.27.2 32 322 22 565 2018/12/06 17:12:49 2020/08/12 23:08:46 615
92.154.95.236 31 960 1 092 2017/12/07 23:12:08 2021/12/13 13:12:54 1466
185.156.73.107 31 625 25 338 2021/06/19 09:06:14 2022/02/13 12:02:53 239
195.54.166.93 31 183 29 850 2020/01/15 21:01:51 2020/02/17 05:02:35 32
185.156.73.91 30 461 20 471 2020/10/04 03:10:37 2022/07/30 17:07:51 664
51.68.126.248 30 228 4 2020/02/25 22:02:19 2020/04/06 01:04:36 40
92.63.197.105 29 300 16 042 2021/05/16 17:05:56 2021/12/07 23:12:30 205
92.118.37.81 28 690 28 554 2019/03/15 01:03:36 2019/07/08 16:07:00 115
185.156.73.57 28 501 22 609 2019/12/19 17:12:39 2022/07/30 17:07:40 954
45.146.164.198 27 464 23 165 2021/03/16 00:03:47 2022/01/12 17:01:44 302
37.49.231.66 26 352 26 219 2018/08/03 19:08:24 2019/01/25 08:01:41 174
80.82.77.218 26 196 24 121 2020/03/17 01:03:40 2020/07/14 07:07:39 119
195.54.161.151 25 886 24 790 2021/02/06 14:02:56 2021/06/01 11:06:17 114
92.63.197.88 24 561 20 961 2020/05/29 12:05:49 2022/02/21 20:02:47 633
185.156.73.12 24 163 19 315 2021/01/30 22:01:59 2022/05/12 15:05:53 466
94.102.56.252 22 788 12 892 2018/09/07 15:09:40 2019/08/10 15:08:59 336
185.175.93.105 22 549 18 079 2019/07/15 11:07:55 2020/04/16 02:04:10 275
185.176.27.18 21 883 19 712 2019/06/04 19:06:24 2020/03/27 15:03:34 296
194.26.29.227 21 677 19 684 2020/04/23 21:04:52 2020/08/03 12:08:58 101
91.121.176.95 21 594 2 2016/08/03 07:08:04 2019/03/02 14:03:07 941
185.176.27.170 21 126 19 850 2019/03/10 13:03:32 2020/05/09 19:05:20 426
185.176.27.246 20 786 18 049 2018/12/28 12:12:28 2020/07/20 09:07:13 569
85.209.0.11 20 602 20 602 2019/07/02 11:07:22 2019/12/13 22:12:15 164
45.129.33.50 20 243 16 040 2020/08/08 21:08:59 2020/12/31 22:12:35 145
94.102.56.235 20 011 14 196 2018/05/29 17:05:10 2019/08/06 08:08:22 433

En prime l'ordre SQL pour la présentation des données, les 20 plus gros ont été extraits dans la table utilisée ici :

SELECT IP_V4, CTR, NBPORTS, DATE_FORMAT(FROM_UNIXTIME(DEBUT),"%Y/%m/%d %H:%m:%S") as DATE_DEB,
       DATE_FORMAT(FROM_UNIXTIME(FIN),"%Y/%m/%d %H:%m:%S") as DATE_FIN,
       TIMESTAMPDIFF(DAY,FROM_UNIXTIME(DEBUT),FROM_UNIXTIME(FIN)) as NBJOURS
FROM ntopng.GROS_SCANNEUR
order by CTR desc;

Avec MariaDB cet ordre a été exécuté en environ 28 minutes.

Scan de ports

Scan de ports jpp lun 12/02/2018 - 23:40

J'ai décidé de voir un peu quelles informations on peut tirer de l'enregistrement des flux réalisé par NTOPNG dans la base Mysql.
A ce jour un peu plus de 77 millions de rangs dont plus de 42 millions ont une origine externe à mon réseau, plus de 460000 adresses IP différentes figurent dans la base.
Les données prises en compte sont celles qui :
- proviennent d'une adresse extérieure
- utilisent un port < 30000
- n'utilisent pas un port donnant accès à un service web ou mail.
Première recherche :
Pays les plus fréquents.

On remarquera avec intérêt la cinquième place des Seychelles.
Deuxième recherche :
Ports les plus fréquents, sans différence entre UDP et TCP.

La liste complète fait plus de 17000 lignes ...
Le port 23 et son collègue 2323 écrasent nettement tous les autres, les ports 22 et 2222 suivent mais assez loin loin derrière.
Le port 1433 en troisième position indique que certains cherchent encore des machines SqlServer non patchées depuis des années ... quelques autres "services" utilisent aussi ce port dont le vieux W32 Spybot de 2003.
Le port 5060 est celui de SIP, y-en-a-t-il qui veulent téléphoner gratis ?
Les ports 3389 (Terminal Server) et 445 (SMB et certains virus) sont des ports typiquement Windows mais sont loin de présenter des valeurs élevées.

Troisième recherche :
Adresses IP les plus fréquentes.
La mention "BLACK" signale l'appartenance à un certain nombre de "black_lists".

Noter la quatrième place d'une adresse aux Seychelles et le fait que tous les "casse-pieds" ne sont pas répertoriés dans les black lists les plus courantes.
Quatrième recherche.
Comme la troisième en groupant sur le préfixe en /24.

On voit ici que le réseau "77.72.820/24" (indiqué GB par whois) ne contient pas moins de 17 adresses "malignes" et a réussi plus de 20000 "hits" au total, j'ai pu remarquer par ailleurs que l'adresse "abuse" de ce réseau ne réponds pas aux messages ce qui garantit la tranquillité des utilisateurs de ces adresses. Ce réseau figure par ailleurs dans toutes les bonnes black lists.
Le réseau "192.101.167.0/24" (indiqué CZ par whois) est très en dessous ! A peine 11 adresses abusives et 8300 hits.
Tous les emm... ne sont donc pas forcément basés dans des pays lointains ou disposant de régimes réputé totalitaires.