Ver puertos abiertos en Linux

How to check if port is in use in

To check the listening ports and applications on Linux:

1. Open a terminal application i.e. shell prompt.
2. Run any one of the following command on Linux to see open ports:
   sudo lsof -i -P -n | grep LISTEN
sudo netstat -tulpn | grep LISTEN
sudo ss -tulpn | grep LISTEN
sudo lsof -i:22 ## see a specific port such as 22 ##
sudo nmap -sTU -O IP-address-Here
3. For the latest version of Linux use the ss command. For example, ss -tulw

Let us see commands and its output in details.

Option #1: lsof command

The syntax is:
$ sudo lsof -i -P -n
$ sudo lsof -i -P -n | grep LISTEN
$ doas lsof -i -P -n | grep LISTEN ### [OpenBSD] ###
Sample outputs:

Fig.01: Check the listening ports and applications with lsof commandConsider the last line from above outputs:

sshd    85379     root    3u  IPv4 0xffff80000039e000      0t0  TCP 10.86.128.138:22 (LISTEN)

• sshd is the name of the application.
• 10.86.128.138 is the IP address to which sshd application bind to (LISTEN)
• 22 is the TCP port that is being used (LISTEN)
• 85379 is the process ID of the sshd process

Option #2: netstat command

You can check the listening ports and applications with netstat as follows.

Linux netstat syntax

Run netstat command along with grep command to filter out port in LISTEN state:
$ netstat -tulpn | grep LISTEN
The netstat command deprecated for some time on Linux. Therefore, you need to use the ss command as follows:
sudo ss -tulw
sudo ss -tulwn
sudo ss -tulwn | grep LISTEN


Where, ss command options are as follows:

• -t : Show only TCP sockets on Linux
• -u : Display only UDP sockets on Linux
• -l : Show listening sockets. For example, TCP port 22 is opened by SSHD server.
• -p : List process name that opened sockets
• -n : Don’t resolve service names i.e. don’t use DNS

Option #3: nmap command

The syntax is:
$ sudo nmap -sT -O localhost
$ sudo nmap -sU -O 192.168.2.13 ##[ list open UDP ports ]##
$ sudo nmap -sT -O 192.168.2.13 ##[ list open TCP ports ]##
Sample outputs:

Fig.02: Determines which ports are listening for TCP connections using nmapYou can combine TCP/UDP scan in a single command:
$ sudo nmap -sTU -O 192.168.2.13

A note about Windows users

You can check port usage from Windows operating system using following command:
netstat -bano | more
netstat -bano | grep LISTENING
netstat -bano | findstr /R /C:"[LISTEING]"

---

Fuente:
https://www.cyberciti.biz/faq/unix-linux-check-if-port-is-in-use-command/

Nuevos comandos de red en Linux

El comando ifconfig (perteneciente al paquete net-tools)  es un comando con bastante tiempo a sus espaldas y, aunque sigue presente en muchas distribuciones de Linux, está destinado a desaparecer y a ser sustituido por la mejorada aplicación iproute2 suite (apareció en 2011). Así está ocurriendo ya en las ultimas versiones de las principales distribuciones, como Debian 9.

Para aprender a manejar este nuevo comando recomiendo estos artículos:

• CÓMO USAR DEL COMANDO IP (IPROUTE2 SUITE) EN LUGAR DE IFCONFIG EN LINUX
• Suite IpRoute2 uso básico para gestión de la red
• Enrutamiento avanzado con iproute2

 

Recursos:

• Guía de referencia rápida: rh_ip_command_cheatsheet_1214_jcs_print

 

Midiendo el ancho de banda de red con IPerf3

Esta prueba se puede hacer con algunos routers (como los del fabricante Ubiquiti) y dispositivos de red, a parte de PCs.

En el servidor ejecutamos en una terminal:

$iperf3 -s

En los clientes:

iperf 3 -c <IP_Servidor>

 

Zeroshell – Una solución ideal para la empresa.

Zeroshell es una distribución Linux para servidores y dispositivos integrados destinados a proporcionar los servicios de red principal de una LAN, administrándose desde una interfaz web muy sencilla de utilizar.

Puede proporcionar los siguientes servicios:

• DHCP.
• DNS.
• NTP.
• Firewall.
• VLAN.
• VPN.
• RADIUS.
• LDAP.
• Portal Cautivo

Por tanto, es una solución de las más completas del mercado, siendo su mayor ventaja la facilidad de uso, y que está basado en software libre. Una maravilla. Podemos instalarlo en cualquier equipo incluso aquellos con poca potencia.

Comandos básicos en Postfix para manejar la cola de correo

Para aquellos que se estén iniciando en el mundo del MTA Postfix, ahí van unos  comandos útiles para el manejo de la cola de correo:

mailq (Mostrar la cola de correo por pantalla)
postsuper -d numero (eliminar el mensaje)
postsuper -d ALL (eliminar todos los mensajes)
postsuper -r Number (Encolar de nuevo el mensaje)
postsuper -r ALL (Encolar de nuevo todos los mensajes)
postqueue -p (Mostrar la cola de correo por pantalla). Equivalente a mailq
postqueue -f (Hacer un flush de la cola de correo, intentar enviar todos los correos)

---

Fuente original: http://rm-rf.es/comandos-basicos-en-postfix-para-manejar-la-cola-de-correo/

Configurar Postfix para usar un servidor SMTP remoto usando un puerto alternativo

On one of my local Ubuntu workstations at home, I sometimes have the need to send mail out using mailutils/mailx inside of scripts or on the command line. I also don’t necessarily want/need to set up an entire mail server on my workstation. In addition, Verizon FiOS doesn’t take too kindly to this for purposes of preventing malicious activity, SPAM, etc. They actually block outbound connections on the default SMTP port (25).

If you’re using Ubuntu 14.04 LTS, it comes with Postfix by default. If you’re using a different version or flavor, chances are you’ve got Sendmail or Exim installed. These instructions assume you’ve uninstalled whatever MTA came with your system, and that you want to use Postfix (far superior to its counterparts in my eyes).

First, it’s easiest to install postfix and Cyrus SASL packages from your operating system’s repository. If you’re compiling from source, be sure to make Postfix with the -DUSE_SASL_AUTH flag for SASL support and -DUSE_TLS for TLS support.

# apt-get install postfix libsasl2-2 -y

Next, edit the main Postfix configuration file @ /etc/postfix/main.cf to include the following:

# Set this to your server's fully qualified domain name.
# If you don't have a internet domain name,
# use the default or your email addy's domain - it'll keep
# postfix from generating warnings all the time in the logs
mydomain = local.domain
myhostname = host.local.domain

# Set this to your email provider’s smtp server.
# A lot of ISP’s (ie. Verizon) block the default port 25
# to prevent spamming. So in this case we’ll use port 587.
relayhost = your.smtp.host:587

smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_type = cyrus
smtp_sasl_auth_enable = yes

# optional: necessary if email provider uses load balancing and
# forwards emails to another smtp server
# for delivery (ie: smtp.yahoo.com –> smtp.phx.1.yahoo.com)
# No necesario usar con el servidor smtp del Instituto
#smtp_cname_overrides_servername = no

# optional: necessary if email provider
# requires passwords sent in clear text
# Necesario para que funcione con el servidor smtp del Instituto
smtp_sasl_security_options = noanonymous

Note: Your remote SMTP host must be configured to listen on the alternate port you specify in relayhost=

Next, you need to configure authentication with SASL, so edit /etc/postfix/sasl_passwd and provide the credentials in this format:

your.smtp.host:587 username:password

Note: The host and port must match identically to relayhost= in main.cf

Generate a postfix .db file from the previous file

# postmap hash:/etc/postfix/sasl_passwd

For security, you’ll want to make sure the sasl_passwd and sasl_passwd.db files are not readable:

# chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

That’s it, restart the postfix service and test sending email.

# service postfix restart
# echo testing | mail some@address.com


Si el comando anterior no envia el email y falla es porque no usa la cuenta del servidor remoto. Para solucionarlo y forzar a que use la cuenta del servidor ejecutar el comando email así:

$echo «body of your email» | mail -s «This is a Subject» -r «email@desdequeenviar» email@destinatario

If you did everything correctly, you’ll see your local host connect to the remote host and send the message. If something went wrong, you’ll want to start digging through logs to figure out why.

---

Fuente original: Configure Postfix to use a remote SMTP relay server via alternate port

---

Otras fuentes relacionadas:

• How To Relay Postfix mails via smtp.gmail.com on Ubuntu 14.04.1
• Mailgun: How to configure SMTP relay for postfix on Ubuntu
• https://websetnet.com/es/configure-postfix-to-use-gmail-smtp-on-ubuntu/
• https://www.linode.com/docs/email/postfix/postfix-smtp-debian7

Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget)

No sé qué le pasa últimamente a mi router Zyxel 660HW en su función de switch de red para conectar los diferentes ordenadores de casa. Mientras que el ancho de banda de red que debería de permitir para la comunicación entre los ordenadores debería de ser cercano a los teóricos 100 Mbps, hay veces que no hace falta esforzarse mucho para ver que realmente es muy inferior, hasta llegar a ver cosas como esta usando Samba entre un sistema con Ubuntu y otro con Debian:

Sin saber realmente por qué me está ocurriendo esto, este problema me sirve para hablar del IPerf, una pequeña utilidad que nos sirve para medir el ancho de banda efectivo entre dos sistemas de la red usando TCP o UDP. Como está disponible para Windows, y para los diferentes sistemas UNIX (en Debian y Ubuntu existe un paquete en la distribución estándar), podemos usarla entre dos nodos cualquiera conectados a una red para ver el ancho de banda real que, tras quitar las cabeceras y los retardos que introducen los dispositivos de red intermedios, nos queda.

En un extremo la ejecutaremos en modo servidor, con la opción -s:

debian $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.2 port 5001 connected with 192.168.1.3 port 53490
[  4]  0.0-10.3 sec    116 MBytes  94.1 Mbits/sec

En el otro extremo, en modo cliente, con la opción -c. Por defecto, ambos extremos usan el puerto 5001:

ubuntu $ iperf -c debian
------------------------------------------------------------
Client connecting to debian, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.3 port 53490 connected with 192.168.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec    116 MBytes  96.3 Mbits/sec

Vemos que, de una red de 100 Mbps salen 94-96 Mbps. No está mal.

Por defecto, es el cliente es el que manda datos al servidor durante 10 segundos (a menos que usemos el parámetro -t en el cliente). Curiosamente, si hago la prueba al revés, para que el ordenador con Debian mande al ordenador con Ubuntu, obtengo algo menos de velocidad:

ubuntu $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.3 port 5001 connected with 192.168.1.2 port 35792
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec    104 MBytes  87.1 Mbits/sec

debian $ iperf -c ubuntu
------------------------------------------------------------
Client connecting to ulises, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 35792 connected with 192.168.1.3 port 5001
[  3]  0.0-10.0 sec    104 MBytes  87.2 Mbits/sec

Pero en realidad, tales números sólo los obtengo cuando no está ocurriendo nada más en la red. La realidad es que si el router está trabajando en otras cosas, los números que puedo obtener son bastante peores. Definitivamente, mi router/switch no tiene bastante potencia para mover varios flujos de datos a la vez a 100 Mbps entre sus diferentes interfaces:

debian $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.2 port 5001 connected with 192.168.1.3 port 43429
[  4]  0.0-10.4 sec  38.9 MBytes  31.3 Mbits/sec

ubuntu $ iperf -c debian
------------------------------------------------------------
Client connecting to debian, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.3 port 43429 connected with 192.168.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  38.9 MBytes  32.0 Mbits/sec

Pero lo que es el colmo es lo que estoy viendo estos últimos días, que se traduce en la captura de la copia de datos con Samba del principio de la entrada:

ubuntu $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  5] local 192.168.1.3 port 5001 connected with 192.168.1.2 port 36886
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.2 sec  2.38 MBytes  1.96 Mbits/sec

debian $ iperf -c ubuntu
------------------------------------------------------------
Client connecting to ubuntu, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 36886 connected with 192.168.1.3 port 5001
[  3]  0.0-10.2 sec  2.38 MBytes  1.96 Mbits/sec

¡Menos de 2 Mbps! En los aproximadamente 4 años que llevo con este router, nunca me había hecho estas cosas. Sí que estaba acostrumbrado a no mover datos entre ordenadores a más de unos 4MB/seg (los 32 Mbps que salían anteriormente). Eso era lo normal, y me parecía razonablemente aceptable, pero ahora, de vez en cuando le da por hacer esto y no se arregla hasta que lo reinicio y sólo por un rato. ¿Será problema de hardware? ¿Será problema de software? ¿Ha llegado la hora de cambiar el router?

Por cierto, si necesitamos medir el ancho de banda y no tenemos el más versátil IPerf a mano, siempre podemos recurrir a un clásico scp, pero tendremos que tener en cuenta la carga adicional en encriptar y desencriptar los datos en ambos extremos:

debian $ scp linux-2.6.25.5.tar.bz2 vicente@ubuntu:/tmp/
linux-2.6.25.5.tar.bz2                        100%   46MB   3.6MB/s   00:13

También podemos usar un netcat con un dd o con un pv para que nos midan la velocidad de transferencia:

debian $ cat linux-2.6.25.5.tar.bz2 | nc -q 0 ubuntu 2222

ubuntu $ nc -lp 2222 | dd of=/dev/null
68980+31407 records in
94901+1 records out
48589640 bytes (49 MB) copied, 6.28166 s, 7.7 MB/s

debian $ cat linux-2.6.25.5.tar.bz2 | nc -q 0 ubuntu 2222

$ nc -lp 2222 | pv > /dev/null
46.3MB 0:00:06 [7.43MB/s] [     <=>                                           ]

Si en uno de los sitemas tenemos un servidor web, el wget también nos dará estadísticas de velocidad de transferencia:

$ wget http://debian/linux-2.6.25.5.tar.bz2
--2008-12-12 20:17:58--  http://debian/linux-2.6.25.5.tar.bz2
Resolving debian... 192.168.1.2
Connecting to debian |192.168.1.2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 48589640 (46M) [application/x-tar]
Saving to: `linux-2.6.25.5.tar.bz2'

97% [====================================>  ] 47,195,808   418K/s  eta 4s

ubuntu $ wget http://debian/linux-2.6.25.5.tar.bz2
--2008-12-12 20:20:38--  http://debian/linux-2.6.25.5.tar.bz2
Resolving debian... 192.168.1.2
Connecting to debian |192.168.1.2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 48589640 (46M) [application/x-tar]
Saving to: `linux-2.6.25.5.tar.bz2.2'

100%[======================================>] 48,589,640  10.5M/s   in 4.4s    

2008-12-12 20:20:42 (10.4 MB/s) - `linux-2.6.25.5.tar.bz2' saved [48589640/48589640]

¿Se nota que entre las dos ejecuciones he reiniciado el router? ¡Qué diferencia! ¡De 418 KB/s a 10.5 MB/s!.

---

Fuente y autoría: http://www.vicente-navarro.com/blog/2008/12/13/midiendo-el-ancho-de-banda-de-red-con-iperf-y-con-scp-netcat-wget/

Manual fundamental sobre WakeOnLAN

Hoy en día hay mucha gente que tiene en casa un ordenador conectado a Internet casi siempre encendido y al que se puede acceder desde cualquier lugar, normalmente por SSH en sistemas UNIX (aunque también hay servidores SSH para sistemas Windows, son menos frecuentes, porque las posibilidades que tenemos en la shell de Windows son muy limitadas) y por VNC o RDP en Windows. En muchos casos, es bastante normal que además de ese ordenador siempre encendido se tenga algún otro que sólo se enciende cuando se está en casa.

Pero hay veces que, estando lejos, nos puede interesar encender ese otro ordenador de forma remota porque necesitamos un fichero que tenemos en él o necesitamos hacer algo en él. Para esas situaciones, lo mejor es tener el Wake on LAN (WoL) preparado en esa máquina y las utilidades necesarias para activarlo en la máquina que no solemos apagar.

El WoL es posible en los PCs actuales gracias a las fuentes de alimentación ATX que, cuando el ordenador está apagado, siguen alimentando a ciertas partes de la placa base permitiendo asimismo el Wake on Ring y la posibilidad de arancar el PC sólo pulsando una tecla del teclado o que se encienda a una determinada hora.

Requisitos Hardware

Para que una tarjeta de red pueda hacer un WoL, es necesario que la tarjeta bien soporte el estándar PCI 2.2, bien sea unida con un cable a un conector específico de la placa base:

En las placas base más modernas, con uno o más interfaces de red ya integrados en la propia placa, no necesitamos hacer nada a nivel de hardware para que el WoL funcione.