{"id":7059,"date":"2025-09-17T16:44:04","date_gmt":"2025-09-17T14:44:04","guid":{"rendered":"https:\/\/www.hostingtg.com\/blog\/?p=7059"},"modified":"2025-09-17T16:44:07","modified_gmt":"2025-09-17T14:44:07","slug":"comprobar-puertos-abiertos","status":"publish","type":"post","link":"https:\/\/www.hostingtg.com\/blog\/comprobar-puertos-abiertos\/","title":{"rendered":"C\u00f3mo comprobar puertos abiertos en Linux: local, red y firewall"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Antes de nada: abierto \u2260 expuesto (y por qu\u00e9 te puede enga\u00f1ar la prueba)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hablar de \u201cpuertos abiertos\u201d como si fuera una lista fija se queda corto. Un puerto <em>listening<\/em> en el sistema no siempre est\u00e1 expuesto hacia fuera. Por ejemplo, puedo tener un servicio escuchando en <code>127.0.0.1:8080<\/code>; para el host est\u00e1 <strong>abierto<\/strong>, pero desde Internet es invisible. En mi experiencia, los falsos positivos y negativos suelen venir de aqu\u00ed:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Loopback<\/strong>: servicios que s\u00f3lo escuchan en <code>127.0.0.1<\/code> o <code>::1<\/code>.<\/li>\n\n\n\n<li><strong>IPv6 vs IPv4<\/strong>: si el servicio escucha s\u00f3lo en IPv6 y escaneas en IPv4, parecer\u00e1 \u201ccerrado\u201d. A la inversa, igual.<\/li>\n\n\n\n<li><strong>Firewall\/NAT\/per\u00edmetro<\/strong>: el host escucha, pero un firewall (local o perimetral), un <em>Security Group<\/em> en la nube o el router filtra o redirige.<\/li>\n\n\n\n<li><strong>Rutas y pol\u00edticas<\/strong>: zonas de <code>firewalld<\/code>, pol\u00edticas <code>DROP<\/code>, listas por interfaz o reglas por estado de conexi\u00f3n.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Mi regla de oro: mirar el problema desde tres \u00e1ngulos \u2014<strong>dentro del host<\/strong>, <strong>desde fuera de la red<\/strong> y <strong>en el firewall\/per\u00edmetro<\/strong>\u2014 y cuadrar la foto con evidencias de los tres.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Desde dentro del host: identifica qu\u00e9 escucha realmente (<code>ss<\/code>, <code>lsof<\/code>)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando quiero rapidez y detalle, prefiero <code>ss<\/code> frente a <code>netstat<\/code>. <code>ss<\/code> es m\u00e1s \u00e1gil, filtra mejor y muestra el <em>owner<\/em> del socket sin dolores.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><code>ss -lntup<\/code>: lectura r\u00e1pida y filtros \u00fatiles<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Lista puertos <strong>TCP<\/strong> en escucha, sin <em>reverse <a href=\"https:\/\/www.hostingtg.com\/blog\/google-dns\/\" target=\"_blank\" data-type=\"link\" data-id=\"https:\/\/www.hostingtg.com\/blog\/google-dns\/\" rel=\"noreferrer noopener\">DNS<\/a><\/em>, con procesos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -lntup\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Par\u00e1metros clave:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>-l<\/code> (listening), <code>-n<\/code> (no resolver), <code>-t<\/code> (TCP), <code>-u<\/code> (UDP), <code>-p<\/code> (proceso).<\/li>\n\n\n\n<li><code>-4<\/code> \/ <code>-6<\/code> para separar IPv4\/IPv6.<\/li>\n\n\n\n<li>Filtros muy pr\u00e1cticos:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code># Filtrar por puerto 22\nsudo ss -ltnp '( sport = :22 )'\n\n# Ver solo IPv6 en escucha\nsudo ss -ltn6\n\n# Ver UDP \"en escucha\" (recordatorio: UDP no establece sesi\u00f3n)\nsudo ss -lnup\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Combinado con <code>lsof<\/code> para ver ficheros y sockets:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -iTCP -sTCP:LISTEN -P -n\nsudo lsof -iUDP -P -n | head\n<\/code><\/pre>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">En mi caso, antes de tocar reglas, <strong>corro <code>ss<\/code><\/strong> y confirmo que realmente hay algo escuchando. Evita perseguir \u201cfantasmas\u201d de firewall cuando en realidad no hay servicio.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Diferencias pr\u00e1cticas <code>ss<\/code> vs <code>netstat<\/code><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>netstat<\/code> (paquete <code>net-tools<\/code>) est\u00e1 deprecado en muchas distros; funciona, pero <code>ss<\/code> (en <code>iproute2<\/code>) ofrece filtros modernos, mejor rendimiento y m\u00e1s detalle por socket. Si tu documentaci\u00f3n antigua menciona <code>netstat -tulpn<\/code>, trad\u00facelo mentalmente a <code>ss -lntup<\/code>.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">Consejo: si trabajas con contenedores o <em>namespaces<\/em>, aseg\u00farate de auditar el <strong>namespace correcto<\/strong>:<\/p>\n<\/blockquote>\n\n\n\n<pre class=\"wp-block-code\"><code># Ver sockets de red del contenedor (usa el PID del proceso principal)\nsudo nsenter -t &lt;PID&gt; -n ss -lntup\n\n# O con netns nominal\nsudo ip netns exec &lt;ns&gt; ss -lntup\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Desde fuera de la red: valida exposici\u00f3n real con <code>nmap<\/code> (TCP\/UDP)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Para confirmar qu\u00e9 es <strong>alcanzable de verdad<\/strong>, me voy a otra m\u00e1quina y paso <code>nmap<\/code>. Esto evita autoenga\u00f1os del tipo \u201caqu\u00ed lo veo abierto, as\u00ed que desde fuera debe estarlo\u201d.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Estados <code>open\/closed\/filtered<\/code> y falsos negativos<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>open<\/strong>: una aplicaci\u00f3n responde al puerto.<\/li>\n\n\n\n<li><strong>closed<\/strong>: ning\u00fan servicio escuchando; el host <strong>responde<\/strong> con rechazo (p. ej., RST).<\/li>\n\n\n\n<li><strong>filtered<\/strong>: un firewall filtra; no hay respuesta concluyente (p\u00e9rdida de paquetes, ICMP bloqueado\u2026).<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Si un host \u201cno responde al ping\u201d, puede ser normal; usa <code>-Pn<\/code> para escanear igualmente. Para <strong>IPv6<\/strong>, a\u00f1ade <code>-6<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Ejemplos: rango completo, servicio concreto y UDP<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Escaneo TCP de todos los puertos (r\u00e1pido y \u00fatil):<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>nmap -p- -sS -Pn --reason 198.51.100.10\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Detecci\u00f3n de servicio\/versi\u00f3n en puertos t\u00edpicos:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>nmap -p 22,80,443 -sS -sV --reason 198.51.100.10\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">UDP (m\u00e1s lento y propenso a \u201copen|filtered\u201d):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo nmap -sU --top-ports 200 --reason 198.51.100.10\n# O focalizado:\nsudo nmap -sU -p 53,123,161 --reason 198.51.100.10\n<\/code><\/pre>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">En mi pr\u00e1ctica, combino <code>-sS<\/code> (TCP) y <code>-sU<\/code> (UDP) cuando necesito la foto completa y pruebo tambi\u00e9n <code>-6<\/code> para evitar falsos negativos si el servicio s\u00f3lo escucha en IPv6.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Firewall y per\u00edmetro: <code>ufw<\/code>, <code>firewalld<\/code>\/<code>nftables<\/code> para cuadrar la foto<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Un <em>check<\/em> local dice \u201cescucha\u201d, <code>nmap<\/code> desde fuera dice \u201cclosed\/filtered\u201d\u2026 toca revisar la <strong>pol\u00edtica de firewall<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><code>ufw<\/code> (Ubuntu\/Debian)<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ufw status verbose\nsudo ufw allow 22\/tcp\nsudo ufw delete allow 8080\/tcp\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ojo con el perfil IPv6 (fichero <code>\/etc\/ufw\/ufw.conf<\/code>, <code>IPV6=yes<\/code>) y con reglas por aplicaci\u00f3n (<code>\/etc\/ufw\/applications.d\/<\/code>).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><code>firewalld<\/code> (RHEL\/Fedora) sobre <code>nftables<\/code><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code># Zona activa y su interfaz\nsudo firewall-cmd --get-active-zones\nsudo firewall-cmd --zone=public --list-all\n\n# Abrir puerto en runtime y despu\u00e9s hacerlo permanente\nsudo firewall-cmd --zone=public --add-port=8080\/tcp\nsudo firewall-cmd --zone=public --add-port=8080\/tcp --permanent\nsudo firewall-cmd --reload\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Trampa t\u00edpica<\/strong>: abrir en la zona equivocada o tener la interfaz en otra zona.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><code>nftables<\/code> (reglas finas)<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo nft list ruleset\n# Ejemplo de permitir SSH\nsudo nft add rule inet filter input tcp dport 22 ct state new accept\n<\/code><\/pre>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">Cuando \u201ccuadro la foto\u201d, reviso <code>ufw<\/code>\/<code>firewalld<\/code>\/<code>nft<\/code> porque un DROP silencioso convierte puertos abiertos en \u201cfiltered\u201d a ojos de <code>nmap<\/code>.<\/p>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Per\u00edmetro\/Nube<\/strong>: no olvides <em>Security Groups<\/em> (AWS, Azure, GCP), ACLs, WAF y el router ISP. Puedes tener todo OK en el host y seguir bloqueado fuera.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Casos que confunden: loopback, IPv6, contenedores y puertos ef\u00edmeros<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Loopback<\/strong>: servicios locales (dashboards, Prometheus, etc.) oyen en <code>127.0.0.1<\/code> por seguridad. Para exponerlos, cambia <em>bind address<\/em> a <code>0.0.0.0<\/code>\/<code>::<\/code> <strong>y<\/strong> abre en firewall.<\/li>\n\n\n\n<li><strong>S\u00f3lo IPv6<\/strong>: si ves <code>:::443<\/code> en <code>ss<\/code> y <code>nmap<\/code> (IPv4) marca \u201cclosed\u201d, prueba <code>nmap -6<\/code>.<\/li>\n\n\n\n<li><strong>Contenedores\/Namespaces<\/strong>: Docker publica puertos con DNAT; el contenedor puede escuchar en <code>0.0.0.0:80<\/code> <strong>dentro<\/strong> pero no estar mapeado hacia el host. Verifica con:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>docker ps\ndocker inspect &lt;container&gt; | jq '.&#91;0].HostConfig.PortBindings'\nss -lntup | grep -E 'docker|containerd'\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En Kubernetes, mira <code>Service<\/code>\/<code>Ingress<\/code> y <em>NetworkPolicy<\/em>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Puertos ef\u00edmeros<\/strong>: son puertos cliente (rango <code>ip_local_port_range<\/code>) que ver\u00e1s en estados <code>ESTAB<\/code>\/<code>TIME-WAIT<\/code>; no son \u201cservidores en escucha\u201d pero confunden si filtras mal:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat \/proc\/sys\/net\/ipv4\/ip_local_port_range\ncat \/proc\/sys\/net\/ipv6\/ip_local_port_range 2&gt;\/dev\/null || echo \"usa el mismo rango que IPv4\"\n<\/code><\/pre>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">Yo suelo recordar: \u201clas herramientas <strong>muestran \u00e1ngulos distintos<\/strong> del mismo problema\u201d; s\u00f3lo cruzando host + red + firewall saco la verdad.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Checklist r\u00e1pida: comandos y pasos en 60 segundos<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Local<\/strong>: <code>sudo ss -lntup<\/code> \u2192 \u00bfexiste el puerto? \u00bfen IPv4\/IPv6? \u00bfen qu\u00e9 <em>bind<\/em>?<\/li>\n\n\n\n<li><strong>Red<\/strong>: desde otra m\u00e1quina \u2192 <code>nmap -p- -sS -Pn --reason &lt;tu_IP&gt;<\/code> y, si toca, <code>-6<\/code> y\/o <code>-sU<\/code>.<\/li>\n\n\n\n<li><strong>Firewall<\/strong>:\n<ul class=\"wp-block-list\">\n<li>Ubuntu: <code>sudo ufw status verbose<\/code><\/li>\n\n\n\n<li>RHEL\/Fedora: <code>sudo firewall-cmd --get-active-zones &amp;&amp; --list-all<\/code><\/li>\n\n\n\n<li>General: <code>sudo nft list ruleset<\/code><\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Per\u00edmetro\/Nube<\/strong>: revisa SG\/ACL\/WAF\/router.<\/li>\n\n\n\n<li><strong>Reprueba<\/strong>: vuelve a lanzar <code>nmap<\/code> y valida.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Errores comunes y c\u00f3mo evitarlos<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Escanear IPv4 cuando el servicio s\u00f3lo escucha en IPv6. <strong>Soluci\u00f3n<\/strong>: <code>nmap -6<\/code>.<\/li>\n\n\n\n<li>Abrir el puerto en la <strong>zona equivocada<\/strong> de <code>firewalld<\/code>. <strong>Soluci\u00f3n<\/strong>: confirma interfaz&#x2194;zona.<\/li>\n\n\n\n<li>Confiar en <code>netstat<\/code> y obviar <code>ss<\/code>. <strong>Soluci\u00f3n<\/strong>: adopta <code>ss<\/code> y sus filtros.<\/li>\n\n\n\n<li>Olvidar el <strong>per\u00edmetro<\/strong> (NAT\/SG). <strong>Soluci\u00f3n<\/strong>: diagrama simple del flujo y valida hop a hop.<\/li>\n\n\n\n<li>Interpretar <strong>UDP<\/strong> como \u201ccerrado\u201d cuando es \u201cfiltered\u201d. <strong>Soluci\u00f3n<\/strong>: usa <code>--reason<\/code>, prueba puertos concretos y paciencia.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Sobre Comprobar puertos abiertos<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Comprobar puertos abiertos <strong>de verdad<\/strong> significa mirar el sistema desde tres perspectivas: <strong>dentro del host<\/strong>, <strong>desde fuera<\/strong> y <strong>en el firewall\/per\u00edmetro<\/strong>. En mi pr\u00e1ctica, <code>ss<\/code> me da la realidad local con rapidez; <code>nmap<\/code> (desde otra m\u00e1quina) me dice qu\u00e9 es realmente <strong>alcanzable<\/strong>; y el repaso a <code>ufw<\/code>\/<code>firewalld<\/code>\/<code>nftables<\/code> me permite cuadrar la foto, incluyendo IPv6, contenedores y puertos ef\u00edmeros. Con ese tri\u00e1ngulo, los \u201cmisterios\u201d desaparecen.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">FAQs<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\u00bf<code>ss<\/code> o <code>netstat<\/code>?<\/strong><br><code>ss<\/code> es m\u00e1s moderno, r\u00e1pido y con mejores filtros. \u00dasalo por defecto; deja <code>netstat<\/code> para sistemas antiguos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\u00bfPor qu\u00e9 <code>nmap<\/code> dice \u201cfiltered\u201d?<\/strong><br>Porque no recibe respuestas concluyentes: hay firewall\/NAT. Revisa reglas y usa <code>--reason<\/code>\/<code>-Pn<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\u00bfC\u00f3mo verifico IPv6?<\/strong><br>Aseg\u00farate de que el servicio escucha en <code>::<\/code>\/<code>[::1]<\/code>, usa <code>ss -6<\/code> y escanea con <code>nmap -6<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\u00bfQu\u00e9 pasa con puertos ef\u00edmeros y NAT?<\/strong><br>Los ef\u00edmeros son puertos cliente temporales; no confundir con <em>listening<\/em>. Con NAT, valida tanto la IP interna como la p\u00fablica y las reglas de <em>port forwarding<\/em>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\u00bfC\u00f3mo pruebo UDP de forma fiable?<\/strong><br>Es m\u00e1s dif\u00edcil: combina <code>nmap -sU<\/code> con pruebas de aplicaci\u00f3n (p. ej., consultas DNS a 53\/UDP) y observa <code>open|filtered<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Opini\u00f3n Personal<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Hablar de \u201ccomprobar puertos abiertos\u201d como si fuera una checklist es enga\u00f1arse. Un puerto en <em>listening<\/em> no siempre est\u00e1 expuesto y ah\u00ed se pierden horas. Mi postura es clara: si no lo puedes alcanzar <strong>desde fuera<\/strong>, no existe para el usuario. Por eso empiezo dentro del host con <code>ss<\/code> (m\u00e1s r\u00e1pido y preciso que <code><a href=\"https:\/\/www.hostingtg.com\/blog\/netstat\/\" target=\"_blank\" data-type=\"link\" data-id=\"https:\/\/www.hostingtg.com\/blog\/netstat\/\" rel=\"noreferrer noopener\">netstat<\/a><\/code>) para saber qu\u00e9 <strong>realmente<\/strong> escucha, separo IPv4\/IPv6 y verifico procesos. Despu\u00e9s, desde otra m\u00e1quina, valido con <code>nmap<\/code> (TCP y, cuando toca, UDP) para distinguir entre <em>open<\/em>, <em>closed<\/em> y <em>filtered<\/em>. Y cierro el tri\u00e1ngulo mirando el <strong>firewall<\/strong>: <code>ufw<\/code>, <code>firewalld<\/code>\/<code>nftables<\/code> o la pol\u00edtica del per\u00edmetro en la nube.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo impopular: muchos fallos no son \u201cdel puerto\u201d, son de <strong>alcance<\/strong>. Contenedores sin <em>port mapping<\/em>, servicios atados a <code>127.0.0.1<\/code>, reglas en la zona equivocada, o el cl\u00e1sico \u201csolo escucha en IPv6\u201d. Tambi\u00e9n veo confusiones con <strong>puertos ef\u00edmeros<\/strong>: son clientes, no servicios; no deber\u00edan salir en tu inventario de exposici\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mi criterio operativo es simple y me ha ahorrado tickets: <strong>host \u2192 red \u2192 firewall<\/strong>, en ese orden, y repetir. Cada cambio, un escaneo. Cada apertura, documentada. Menos adivinar, m\u00e1s evidencias. \u00bfResultado? Menos sustos, m\u00e1s tiempo para lo importante.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ahora te leo: \u00bfc\u00f3mo compruebas t\u00fa los puertos en Linux? \u00bf<code>ss<\/code> o <code>netstat<\/code>? \u00bfQu\u00e9 te ha roto m\u00e1s la cabeza: IPv6, UDP o contenedores? D\u00e9jame tus comentarios abajo y enriquezcamos la gu\u00eda con tus casos reales.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Antes de nada: abierto \u2260 expuesto (y por qu\u00e9 te puede enga\u00f1ar la prueba) Hablar de \u201cpuertos abiertos\u201d como si fuera una lista fija se queda corto. Un puerto listening en el sistema no siempre est\u00e1 expuesto hacia fuera. Por ejemplo, puedo tener un servicio escuchando en 127.0.0.1:8080; para el host est\u00e1 abierto, pero desde [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":7061,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_aifi_custom_prompt":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[952],"tags":[1097,1094,898,785,779,1101,888],"class_list":["post-7059","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guias","tag-almalinux","tag-centos","tag-debian","tag-kernel","tag-linux","tag-puertos","tag-ubuntu"],"_links":{"self":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7059","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/comments?post=7059"}],"version-history":[{"count":2,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7059\/revisions"}],"predecessor-version":[{"id":7062,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7059\/revisions\/7062"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media\/7061"}],"wp:attachment":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media?parent=7059"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/categories?post=7059"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/tags?post=7059"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}