Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 Re : Réseau » Du pentest sur la banquise » 25-06-2020 11:05:39

Juste un mot en passant pour préciser que le projet n'est pas abandonné, mais, je refonds totalement la plateforme de virtualisation (dont la cible du «pentest») pour cause d'espace disque insuffisant.

Je reprends donc dans quelques jours le temps de prévoir et mettre en place un serveur un peu plus cohérent.

#2 Re : Réseau » Du pentest sur la banquise » 18-06-2020 12:54:48

@--gilles--

Je n'avais pas vu ton post, je ne le lis que maintenant. Oui, les arnaques sur internet sont monnaie courantes (de plus en plus j'ai l'impression). Et malheureusement les victimes sont bien souvent mal informées et mal conseillées. Au delà de la classique arnaque à la carte bancaires (dont les frais sont généralement remboursés par les banques), des méthodes «originales» sont de plus en plus souvent mises en œuvre.

Je ne saurais trop te conseiller d'insister auprès de ton ami pour qu'il porte plainte (et change de système d'exploitation au passage).

#3 Re : Réseau » Du pentest sur la banquise » 18-06-2020 11:26:54

Salut,

Une crise de sciatique m'ayant empêchée de toucher un clavier pendant quelques jours, je reprends donc ce fil là où je l'avais laissé: la reconnaissance

La reconnaissance

Cette première partie sera très courte puisque n'ayant qu'un intérêt très limité dans le contexte de la protection d'un vps/home serveur. En effet il n'y a qu'une seule machine donc assez peu de travail à ce niveau.

Pour la forme je présente donc les résultats de ce que peut donner spiderfoot sur un NDD. J'ai testé 2 outils de ce type Spiderfoot et datasploit, mais le second repose exclusivement sur python2, qui, on ne le rappellera jamais assez doit être abandonné vu qu'il n'est plus maintenu depuis janvier de cette année. Je ne le présenterai donc pas…

Spiderfoot
Un logiciel d'OSINT (open source Intelligence) automatise les recherches pour la reconnaissance de noms de domaine. Il en existe beaucoup, j'ai choisi celui-là pour deux raisons principales: Il est open source. Et il ne s'appuie PAS sur python 2.

Il dispose d'énormément de modules pour tout un tas de tests différents. Il s'appuie essentiellement sur des services extérieurs tels que : https://www.projecthoneypot.org/ ou https://www.shodan.io/, qui, demandent généralement une inscription (gratuite) à leur service. Je ne les utiliserais pas ici.

Il peut être utilisé via une web UI en l'installant sur un serveur ou directement en ligne de commande. En l'occurrence je l'utilise uniquement en CLI pour des tests rapides. Sa documentation est disponible ici: https://www.spiderfoot.net/documentation/

Indisponible dans les dépôts Debian, j'ai choisi de l'installer depuis le dépôt git:

git clone https://github.com/smicallef/spiderfoot.git


cd spiderfoot



La liste des modules utilisables est visualisée via:

./sf.py -M



Puis, tentons une recherche DNS (via le module sfp_dnsresolve) sur notre nom de domaine préféré… (j'utilise debian-facile.org uniquement parce que une reconnaissance DNS sur mon home serveur n'aurait pas de sens, il n'y a aucun NDD associé).

./sf.py -m sfp_dnsresolve -s debian-facile.org -q




SpiderFoot UI                   Internet Name                                   debian-facile.org                                          
sfp_dnsresolve                  Domain Name                                     debian-facile.org                                          
sfp_dnsresolve                  IPv6 Address                                    2a00:5880:1401:11::1:1                                      
sfp_dnsresolve                  Internet Name                                   stolon.debian-facile.org                                    
sfp_dnsresolve                  IPv6 Address                                    2a00:5880:1401:11::1:1                                      
sfp_dnsresolve                  IP Address                                      89.234.146.138                                              
sfp_dnsresolve                  Internet Name                                   stolon.debian-facile.org                                    
SpiderFoot UI                   Domain Name                                     debian-facile.org                                          
 



L'option -m permet de nommer le module qu'on souhaite utiliser. L'option -s permet de spécifier un NDD. L'option -q permet une lecture directe des informations sans les écrire dans un fichier de log, ainsi que que de ne pas afficher les erreurs. Les differentes options sont disponible via :

./sf.py --help



Au delà des informations qu'aurait pu donner un whois, il fait également apparaitre les domaines associés à debian-facile.org (en l'occurence stolon notre hébergeur, vive lui !).

Une recherche un peu plus complète via le module sfp_dnsgrep (disponible seul ici: https://github.com/erbbysam/DNSGrep) permettra surement de trouver des informations supplémentaires:

./sf.py -m sfp_dnsgrep -s debian-facile.org -q



sfp_dnsgrep                     Internet Name                                   ns1.debian-facile.org
sfp_dnsgrep                     Internet Name                                   ns2.debian-facile.org
sfp_dnsgrep                     Internet Name                                   vps174967.debian-facile.org
sfp_dnsgrep                     Internet Name                                   df-paulla.debian-facile.org
sfp_dnsgrep                     Internet Name                                   collab.debian-facile.org
sfp_dnsgrep                     Internet Name                                   paste.debian-facile.org
sfp_dnsgrep                     Internet Name                                   newdf.debian-facile.org
sfp_dnsgrep                     Internet Name                                   search.debian-facile.org
sfp_dnsgrep                     Internet Name                                   wiki.debian-facile.org
sfp_dnsgrep                     Internet Name                                   mail.debian-facile.org
sfp_dnsgrep                     Internet Name                                   webmail.debian-facile.org
sfp_dnsgrep                     Internet Name                                   forum.debian-facile.org
sfp_dnsgrep                     Internet Name                                   vm.debian-facile.org
sfp_dnsgrep                     Internet Name                                   adhesion.debian-facile.org
sfp_dnsgrep                     Internet Name                                   stolon.debian-facile.org
sfp_dnsgrep                     Internet Name                                   ftp.debian-facile.org
sfp_dnsgrep                     Internet Name                                   smtp.debian-facile.org
sfp_dnsgrep                     Internet Name                                   http.debian-facile.org
sfp_dnsgrep                     Internet Name                                   images.debian-facile.org
sfp_dnsgrep                     Internet Name                                   planet.debian-facile.org
sfp_dnsgrep                     Internet Name - Unresolved                      git.debian-facile.org
sfp_dnsgrep                     Internet Name                                   dev.debian-facile.org
sfp_dnsgrep                     Internet Name                                   wiki-dev.debian-facile.org
sfp_dnsgrep                     Internet Name                                   forum-dev.debian-facile.org
sfp_dnsgrep                     Internet Name                                   www.debian-facile.org
sfp_dnsgrep                     Internet Name                                   stolon.debian-facile.org
 



Si maintenant on veut par exemple savoir quel serveur web est utilisé, une recherche via le module sfp_urlscan pourra donner quelques indications:

./sf.py -m sfp_urlscan -s debian-facile.org -q



sfp_urlscan                     Linked URL - Internal                         http://www.debian-facile.org/
sfp_urlscan                     Physical Location                               FR
sfp_urlscan                     Internet Name                                    dev.debian-facile.org
sfp_urlscan                     Physical Location                               FR
sfp_urlscan                     BGP AS Membership                         16276
sfp_urlscan                     Web Server                                        Apache
 



Tiens, nous avons désormais l'information recherchée: le serveur web en fonction est un Apache. Il est (à priori) situé en France.

Bien que peu intéressante dans un contexte de sécurisation d'un vps/home serveur, ce type d'informations peut être utile par la suite, dans une phase de recherche de potentiels attaquants. Il permet notamment de vérifier si certaines ips et/ou nom de domaine ont étés répertoriés comme «domaines malicieux» auprès de sites spécialisés les référençant.

#4 Re : Réseau » Du pentest sur la banquise » 12-06-2020 20:34:33

Pour ce qui me concerne en complement des classique dig et whois, je vais commencer par regarder vers :

https://github.com/DataSploit/datasploit
et
https://github.com/smicallef/spiderfoot

Je dirai que ça devrait sans problème occuper mon temps imparti à cette expérience pour demain.

Je fais des retours dès que j'en ai.

#5 Re : Réseau » Du pentest sur la banquise » 12-06-2020 12:08:30

Bonjour à toutes et tous,

Aujourd'hui première vrai journée d'attaque sur ce pentest de noob. La première étape sera de créer une VM (Debian Sid) pour pouvoir installer les softs nécessaires sans risquer de salir mes installations de postes de travail. Dans la foulée, quelques softs permettant de se lancer dans la première étape (reconnaissance), seront testés.

#6 Re : Réseau » Du pentest sur la banquise » 12-06-2020 00:22:04

À priori et à l'exception d'une journée ou deux par semaine mon but actuel sera de consacrer entre une et deux heures quotidiennes à cette expérience. Donc même si la route est assez longue il devrait y avoir de la nouvelle matière de manière assez réguliere (peut-être pas quotidiennement non-plus, mais…).

#7 Re : Système » freeze fréquent du système » 11-06-2020 15:57:25

Salut,

Pourrais-tu nous apporter quelques précisions sur le contexte dans lequel surviennent ces freezes. Charge CPU importante ? La RAM est totalement utilisée ? Un petit coup de htop entre deux freezes peut, peut-être nous éclairer sur ton problème.

#8 Re : Réseau » Du pentest sur la banquise » 11-06-2020 11:40:23

Comme je le précise dans le premier post, il n'est pas question (dans un premier temps en tout cas) d'utiliser autre chose que Debian et les logiciels présents dans les dépôts. Mon opinion sur Kali est très simple: Rarement utile, cette distro est généralement mal utilisée et donne souvent une fausse impression de maitrise du sujet. Globalement nuisible pour l'apprentissage (surtout sans encadrement).

#9 Re : Réseau » Du pentest sur la banquise » 11-06-2020 11:05:52

Pentest sur la banquise

1. Méthodologie

Avant de se lancer il va s'agir de définir un périmètre pour le test d'intrusion. Dans mon cas il va s'agir d'une VM Debian 10 comportant des services web. Il aurait pû s'agir de tout ou d'une partie du réseau, mais dans un souci de simplification une seule machine sera l'objet du test.

Le pentest est généralement divisé en 3 grands scénarios:

— Blackbox: Le pentest en blackbox est une simulation d'attaque en «conditions réelles» avec un pentesteur se mettant dans la peau du cracker/pirate. Dans ce scénario il ne dispose d'aucune information sur la cible (ou alors très peu). L'audit sera long et ne permettra pas de se concentrer sur les éléments supposés sensibles de la cible.

— Whitebox: À l'inverse le pentest en whitebox se pratique en connaissance totale des configurations de la cible. Il permet des audits plus rapides et un approfondissement de la détection des vulnérabilités potentielles.

— Greybox: Methodologie intermediaire, dans laquelle le pentesteur dispose d'un nombre réduit d'information. Elle permet de bénéficier des avantages des deux premiers scénarios. Typiquement, il s'agit de simuler à la fois une attaque classique en blackbox, ainsi qu'une attaque venu d'un user légitime, possédant des droits utilisateurs.

Dans le cas qui nous occupe, (le pentest étant réalisé par le propriétaire de la/des machine(s)), les différentes méthodologies seront simulées afin de tenter d'avoir un aperçu plus complet des failles potentielles.

2. Étapes du pentest

  2.1 Reconnaissance
  2.2 Cartographie du réseau et des services
  2.3 Recherche des vulnérabilités
  2.4 Exploitation de la/des vulnérabilité(s)
  2.5 Élévation de privilèges
  2.6 Maintien des accès
  2.7 Propagation et/ou déplacements latéraux
  2.8 Nettoyage
  2.9 Documentation des vulnérabilité(s)

Ces différentes étapes seront détaillées au fur et à mesure de l'avancée du projet.

Beaucoup d'outils différents existent pour effectuer un pentest. Certains très automatisés, d'autres beaucoup moins. Si vos connaissances vous amènent à en connaitre d'autres que ceux qui seront cités ici n'hésitez pas à les présenter.

#10 Réseau » Du pentest sur la banquise » 11-06-2020 10:22:53

framend
Réponses : 14
Bonjour à toutes et à tous,

J'ouvre ce sujet pour commenter au fur et à mesure mon projet de pentesting (sur mon propre réseau, bien sûr)… On peut lire beaucoup de chose sur le sujet sur le ouébe, mais, faut bien avouer qu'il s'agit rarement de sujets très accessibles. Donc voilà, tentative de vulgarisation, démocratisation (partielle) de l'infosec toussa… Je ne suis pas du tout un spécialiste de la chose, mais j'espère justement pouvoir progresser afin de mettre le plus possible mes machines à l'abri des malandrins.

Le sujet est trèèèèèès vaste et trèèèèèès technique, but même pas peur !

Le but final sera d'apprendre à tester des apps, des réseaux et tout ceci dans la plus totale légalité. Je ne vise pas l'apprentissage de compétences exhaustives à un niveau professionnel, mais bel et bien de pouvoir sécuriser nos VPS et autres serveurs auto-hébergés. Tant qu'il le sera possible il ne sera fait usage que de logiciels présents dans les dépôts (Debian). Pas de Kali-linux, BlackArch ou je ne sais quelle distro dédiée. Le sujet étant vaste et mon temps limité, ça va probablement être assez long, mais qu'importe.

Je commence donc aujourd'hui en annonçant une méthodologie, en listant quelques outils et en ajoutant quelques liens vers de la documentation.

#11 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 08-06-2020 11:35:09

Petit retour pour annoncer une page de wiki: https://debian-facile.org/atelier:chant … ec-libvirt

Elle est encore a fignoler (notemment pour la partie NAT), mais est d'ores et déjà fonctionnelle.

#12 Re : Autres » [DÉBAT?] mutt, neomutt, pourquoi en 2020 ? » 21-05-2020 16:56:12

Salut, j'ai rédigé le premier des deux tutos et j'utilise plusieurs boite dorénavant sur mutt. Elles sont appellées avec des Hooks sur des dossiers contenant des configs individuelles.

Le hook en question est réalisé ainsi:

folder-hook 'account.com.foo' 'source ~/chemin/vers/<fichier_conf_du_compte>'


Puis mappé via une macro à F2 :

macro index <f2> '<sync-mailbox><enter-command>source ~/chemin/vers/<fichier_conf_du_compte><enter><change-folder>!<enter>'


Le fichier de config individuel de la boite mail prend la forme habituelle d'une config imap. Je n'utilise pas gmail mais des configs sont visibles sur le web, ça à l'air faisable.

#13 Re : Vos sites et projets perso » [Blog] Get rich or dev tryin' » 20-05-2020 09:55:40

for php in getrichordevtryin:
     print('\o/ Wéééééééé')

#14 Re : Matériel » monter un disque dur sans ecrire de mot de passe+sans root » 10-05-2020 07:11:08

Juste en passant diig je vois ton prompt là… «root@debian:/home/ju» et je ne peux m'empêcher de me dire que tu passes root via «su» ce qui expliquerait que la commande systemctl ne soit pas trouvée.

Depuis Buster on passe root via «su -» ou «su -l» ou «su --login» l'explication est ici : https://debian-facile.org/viewtopic.php?id=24901

Utiliser sudo en root c'est pas top du tout…

#15 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 07-05-2020 19:05:31

Bon la bataille fût rude mais la victoire n'en est que plus savoureuse. Le problème de fond était le manque de documentation de ma part comme indiqué dans le titre: Il s'avère que ce guest a été créé sur le mode par default de libvirt: le NAT. Or, il ne correspond pas à mes besoins du tout…

J'ai donc refais une VM en mode bridge ce qui a rempli toutes mes espérances. L'exploration des fonctions de NAT de libvirt attendra un peu, il faut d'abord que je joue avec ce guest tout neuf.

Une page de wiki est dans les tuyaux, peut-être même avec une partie NAT qui sait…

Un grand merci à Béta-Pictoris pour son aide. Je completerais ce sujet au passage.

#16 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 18:49:13

Bon…

Si je change l'adresse mac et l'ip dans le profil « default » de kvm et que je tente de le relancer via :


virsh net-start default
error: Failed to start network default
error: internal error: Network is already in use by interface enp0s7  
 


Donc à priori pas comme ça que je peux la changer.

To be continued…

#17 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 17:41:41

En effet, quelque chose d'un peu étrange dans la config de la vm:


framend-4d10~
>_virsh -c qemu:///system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # net-list
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

virsh # net-edit default
<network>
  <name>default</name>
  <uuid>f53f0fd1-0ab2-4562-82b6-0e1670300528</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:57:a0:93'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
    ┆ <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>
 



Or, ip a dans la vm renvoie une adresse MAC différente:



2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:0f:10:f5 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp1s0
       valid_lft 86365sec preferred_lft 86365sec
    inet6 fec0::5054:ff:fe0f:10f5/64 scope site dynamic mngtmpaddr
       valid_lft 86367sec preferred_lft 14367sec
    inet6 fe80::5054:ff:fe0f:10f5/64 scope link
       valid_lft forever preferred_lft forever
 


Je vais tenter d'harmoniser tout ça…

#18 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 17:34:47

le but pour moi est de tenter d'éviter virt-manager (l'host est un serveur headless). Mais je pense que c'est une bonne piste…

#19 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 16:58:59

Bon après désactivation du bridge br0 dans /etc/network/interfaces et remise d'enp0s7 en dhcp, sinon pas de réseau sur l'host, le retour d'ip a est le suivant:



2: enp0s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1c:25:02:43:50 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic enp0s7
       valid_lft 863542sec preferred_lft 863542sec
    inet6 2a01:e0a:37f:93a0:21c:25ff:fe02:4350/64 scope global dynamic mngtmpaddr
       valid_lft 85943sec preferred_lft 85943sec
    inet6 fe80::21c:25ff:fe02:4350/64 scope link
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:57:a0:93 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:57:a0:93 brd ff:ff:ff:ff:ff:ff
 


La vm possède tout autant cette ip étrange…
Et la connectivité est inchangée… ssh de C vers A, ok
Mais ssh vers B unreacheable que ce soit depuis A ou C, et ce, sur 192.168.122.1 ou sur 10.0.2.15

Je séche…

#20 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 16:34:01

La grande question que je me pose c'est pourquoi dhcp me renvoie cette addresse étrange sur la vm :



Listening on LPF/enp1s0/52:54:00:0f:10:f5
Sending on   LPF/enp1s0/52:54:00:0f:10:f5
Sending on   Socket/fallback
DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5                              
DHCPOFFER of 10.0.2.15 from 10.0.2.2
DHCPREQUEST for 10.0.2.15 on enp1s0 to 255.255.255.255 port 67                            
DHCPACK of 10.0.2.15 from 10.0.2.2
bound to 10.0.2.15 -- renewal in 36254 seconds.                                            
 

#21 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 16:32:48

Retiré les lignes concernant le bridge de /etc/network/interfaces. Puis,


systemctl restart networking.service
 


Et relancé le bridge virbr0 de virsh.
Du coup ip a renvoie:



2: enp0s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 00:1c:25:02:43:50 brd ff:ff:ff:ff:ff:ff
8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:1c:25:02:43:50 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic br0
       valid_lft 862471sec preferred_lft 862471sec
    inet6 2a01:e0a:37f:93a0:21c:25ff:fe02:4350/64 scope global dynamic mngtmpaddr
       valid_lft 86064sec preferred_lft 86064sec
    inet6 fe80::21c:25ff:fe02:4350/64 scope link
       valid_lft forever preferred_lft forever
9: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:57:a0:93 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
10: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:57:a0:93 brd ff:ff:ff:ff:ff:ff

 


Mais pas plus de vm en ssh sur 192.168.122.1 hmm

brctl show, quand à lui renvoie:


bridge name     bridge id               STP enabled     interfaces
br0             8000.001c25024350       no              enp0s7
virbr0          8000.52540057a093       yes             virbr0-nic
 



Je présume donc qu'un reboot de l'host devrait aider à « éteindre » le bridge br0.

#22 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 16:11:26

Le bridge créé via virsh éteint, sa mention à bien disparu du retour d'ip (dans l'host), par contre un fois la vm relancée j'ai encore cette ip locale bizarre (10.0.2.15) sur la vm. scratchhead.gif

Pas plus de ping ni de ssh.

Je vais du coup tenter l'inverse: retirer le bridge br0 de /etc/network/interfaces et relancer celui de virsh…

#23 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 15:59:01

C'est ce que je me disais, un bridge de trop…
DHCP est activé dans la vm via /etc/network/interfaces, oui.

#24 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 15:30:42

La vm arrêtée et relancée renvoie la même ip : 10.0.2.15 intouchable via ssh. Par contre ce coup là je pingue l'hôte.

#25 Re : Réseau » [Resolu] Problème probable d'ICC sur un bridge réseau pour une VM kvm » 04-05-2020 15:17:59

Par contre dans la vm invitée, après un :


systemctl restart networking.service
 


Le retour d'ip a qui était :



2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group defaul
t qlen 1000                                                                                
    link/ether 52:54:00:0f:10:f5 brd ff:ff:ff:ff:ff:ff                                    
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp1s0                          

 


Est devenu:



2: enp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 100
0                                            
    link/ether 52:54:00:0f:10:f5 brd ff:ff:ff:ff:ff:ff                      

 



Donc plus de réseau dans la vm. Peut-être son interface doit-elle être passée aussi en « manual » ?

Un petit:


ifup enp1s0
 


La relance sans problème, elle récupère une ip : 10.0.2.15. Qui est intouchable via ping ou ssh.

Pied de page des forums

Propulsé par FluxBB