Publicado

GNU/Linux rpl nos sirve para buscar y modificar una cadena de texto en sus archivos. Es una utilería compatible con sistemas tipo UNIX y se encarga de buscar y reemplazar cadenas en archivos de texto, una ventaja importante es que trabaja recursivamente sobre directorios.

Lo primero verificar si nuestro sistema Linux cuenta con rpl

# whereis -b rpl

Sino instalarla:

# apt-get install rpl

Comandos:

$ rpl -i -- 'cadena-vieja 'cadena-nueva' nombreArchivo

Busca y reemplaza 'cadena-vieja' por 'cadenas-nueva' en el archivo “nombreArchivo”

$ rpl -Re 'cadena-vieja' 'cadena-nueva' -x '.php' ./

Busca en todos los archivos .php la cadena 'cadena-vieja' y la reemplaza por 'cadena-nueva' la revisión de los archivos se realiza en forma recursiva partiendo de la ubicación actual ( ./ ) y todos los directorios que estén debajo de ese árbol de archivos (hijos).

$ rpl -Refv 'cadena-vieja' 'cadena-nueva' -x'.php' -x'.cpp' ./

Busca en los archivos .php y .cpp la cadena 'cadena-vieja' y la reemplaza por 'cadena-nueva' a partir de la ubicación actual y en forma recursiva , pero además forza la sobreescritura ( f ) aún cuando el usuario no tenga los permisos de escritura sobre los archivos y muestra en pantalla ( v ) los resultados de las modificaciones “verbose”.

Para ver todas las opciones que puedes utilizar con el comando rpl teclea:

$ rpl -h
$ rpl --help

Autor

Publicado

GNU/Linux DebSecan efectúa una evaluación de la seguridad del sistema y relata las vulnerabilidades conocidas y asociadas a los paquetes instalados en el sistema, notificando al administrador (root) de los resultados.

# apt-get install debsecan

Para informes mas definidos, debe indicarse la versión Debian de nuestro sistema en el archivo /etc/default/debsecan:

#[...]

# For better reporting, specify the correct suite here, using the code
# name (that is, "sid" instead of "unstable").
SUITE=buster

#[...]

Debsecan puede configurarse para ser ejecutado diariamente a través de una tarea programada (cron). Sus resultados se envían por correo al administrador del sistema (root):

# debsecan-create-cron

La tarea programada durante la configuración enviará un correo al administrador con el resultado del análisis de seguridad.

Autor

Publicado

GNU/Linux https://www.fail2ban.org/wiki/index.php/Main_Page Fail2Ban es una aplicación que analiza continuamente los ficheros log y bloquea las direcciones Internet de donde se hayan originado varias tentativas fallidas de acceso con contraseña inválida. Fail2Ban es extremadamente eficaz en la prevención de ataques de fuerza bruta y ataques de denegación de servicio (DoS).

En la instalación de fail2ban activa el puerto ssh. Sin embargo, es posible monitorizar y proteger otros puertos.

# apt-get install fail2ban whois

La documentación de fail2ban recomienda se realice en un archivo con la extensión .local. Copie el archivo de la configuración original, con la extensión .conf:

# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

La configuración se efectuara, en el archivo /etc/fail2ban/jail.local.

Definimos cuáles son las direcciones que no estarán sujetas a restricciones (la dirección local y la red local), por cuánto tiempo estarán bloqueadas las direcciones de donde provengan las amenazas (1800 segundos (30 minutos)) y después de cuántas tentativas (4 tentativas permitidas). Esta configuración debe realizarse en el archivo /etc/fail2ban/jail.local:

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 172.18.50.0/24
bantime = 1800
maxretry = 4

# [...]

Definir correo que recibirá las alertas:

# [...]

#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = gerape@gnuco.org

# [...]

Debe configurarse la acción a realizar cuando se detecta un posible ataque. La dirección IP del atacante es bloqueada y un correo es enviado al administrador del sistema.

# [...]

#
# ACTIONS
#

# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to define
# action_* variables. Can be overriden globally or per
# section within jail.local file
banaction = iptables-multiport

# [...]

# Choose default action. To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g. action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_mwl)s

# [...]

Definir los parámetros del servicio que se pretende proteger. Para esto, se edita a partir de la linea JAILS del archivo /etc/fail2ban/jail.local:

# [...]

#
# JAILS
#

# [...]

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

# [...]

Reiniciamos el servicio:

# /etc/init.d/fail2ban restart

Durante cada reinicio del servicio fail2ban se envía un correo de notificación al administrador del sistema. En caso de una acción defensiva, el administrador también será notificado. Fail2Ban protege servidores correo, ftp, web, base datos y otros. Se debe editarse el archivo /etc/fail2ban/jail.local para modificar los servicios que se deseen proteger.

Autor

Publicado

GNU/Linux una breve introducción a los clusters de alta disponibilidad (High Availability(HA)). Es bastante normal tener alta disponibilidad para servicios que se consideran críticos dentro de una organización. En este caso concreto, pongamos que queremos implementar la alta disponibilidad el hecho de que uno de estos sistemas fallase dejaría la red aislada. Por lo tanto, es crítico tener el servicio en alta redundancia de forma que si un servidor falla, otro asume el servicio.
El software que hemos usado para tener alta disponibilidad se llama Pacemaker de Cluster Labs.
Conceptos
En nuestro caso tenemos dos servidores que ejecutan servicios críticos por lo tanto hay que configurarlos con el software de alta disponibilidad de forma que se organicen los servicios, se monitoricen y si hay algún problema, se pueda recuperar el servicio con el menor tiempo de fallo posible.
Activo/Activo vs. Activo/Pasivo
Los clústeres de servidores en alta disponibilidad se pueden organizar de forma que las dos máquinas den el servicio o que una, la activa, lo dé y la otra sólo entre a dar servicio si la primera falla. La manera de aprovechar mejor los recursos seria hacer que las dos máquinas ejecutasen el servicio, pero a veces no es posible ya que hay servicios que tienen estado y sólo permitirían ejecución en una máquina. De esta forma conseguimos que las dos máquinas estén ocupadas y aprovechamos un poco mejor los recursos.
Recursos
Tenemos dos servidores que, según el Pacemaker, reciben el nombre de nodos, para los servicios
Las IPs flotantes son direcciones que no están asignadas a una máquina sino que están conectadas al servicio, el servidor quien ejecuta el servicio sera quien tendrá la dirección flotante que el HA utilizara como dirección principal. Por lo tanto, reciben el nombre de flotantes porque pueden ir de una máquina a otra dependiendo de donde esté el servicio.
Las dos máquinas tienen que ser capaces de ejecutar los servicios. Si es el caso y deseamos replicar el servicio lo conseguimos con el comando rsync ejecutado cada cierto tiempo desde el cron.
Por lo tanto, identificamos como recursos las IPs flotantes más el software a ejecutar para ofrecer los servicios que necesitamos.
Prioridades
Con las prioridades podemos definir que un servicio se ejecute en una máquina en concreto cuando las dos están en marcha, lo que hace es definir mayor prioridad a un nodo para un determinado servicio o conjunto de servicios. Esto nos va muy bien para definir las alarmas y documentación de las máquinas ya que definimos una como primaria para un determinado servicio y la otra como secundaria.
Cuórum
Un clúster tiene cuórum cuando más de la mitad de los nodos del clúster están activos y han podido comunicarse satisfactoriamente. Así, si tenemos un clúster de 5 nodos, la red tiene un problema y 3 nodos quedan aislados de los otros 2, el miniclúster de 3 nodos seguirá sirviendo los servicios mientras que los otros 2 no lo harán, ya que no llegan al cuórum mínimo.
En nuestro caso, el tema del cuórum se trata diferente, ya que sólo tenemos dos servidores, por lo tanto el funcionamiento es distinto y el clúster podría llegar a funcionar con sólo un servidor activo y el otro caído.
Monitorización y Fencing
Los dos nodos del clúster están conectados a una red privada de forma que la comunicación es lo más directa posible y se van monitorizando para ver que todo funciona correctamente (tienen cuórum), cuando hay algún problema en la comunicación o un nodo detecta que el otro está malfuncionando (uno de los servicios críticos no está en marcha, no responde suficientemente rápido, hay problemas de disco, etc.) tiene que tomar la decisión de convertirse en nodo primario y ejecutar él los servicios críticos.
Se podría dar el caso que todos los servidores detectaran que hay algún problema y los dos decidieran a la vez que el otro está malfuncionando, asumiendo tanto la IP como el servicio a la vez, lo que provocaría un caos en la red, esta situación se conoce como split-brain. Para evitar esto tenemos el fencing.
El mecanismo de fencing que usamos se llama STONITH que significa “Shoot The Other Node In The Head”, que es una forma muy clara de explicar que un servidor “dispara una bala a la cabeza” del otro nodo, de forma que consigue pararlo para que no se dé el problema de que los dos asuman el servicio (split-brain). Una vez parado el otro servidor puede asumir tranquilamente todos los servicios y recursos del clúster.
Recuperación
Una vez se ha producido un problema, se ha ejecutado el fencing y tenemos el servicio reestablecido a pesar de que en un clúster degradado (ya que habría un servidor que se ha tenido que sacrificar) hace falta una intervención técnica para volver a recuperar la situación inicial. Es decir, poner en marcha el servidor sacrificado, ver qué problema tenía, solucionarlo y volver a poner el clúster en marcha.
De forma automática y gracias a las prioridades, una vez el clúster está en marcha se vuelve a establecer la configuración inicial, con un servidor primario tal como habíamos definido y el otro como secundario, en este caso uno tendría IP y servicios, mientras que el otro tendría la IP y servicio.
Hands On
Hacemos una configuración básica del fichero /etc/corosync/corosync.conf, donde ponemos los nodos del clúster, la red, protocolo para la comunicación, donde se hace el logging. El corosync sería el daemon que forma parte del software de alta disponibilidad que se encarga de la comunicación entre nodos.
cluster1 /root# cat /etc/corosync/corosync.conf
totem { version: 2 crypto_cipher: none crypto_hash: none clear_node_high_bit: yes interface { ringnumber: 0 bindnetaddr: Red IP interna mcastport: Puerto ttl: 1 } transport: udpu —> Significa que usamos UDP para la comunicación en lugar de multicast (al tener sólo dos
servidores ya nos va bien)
}
logging { —> Configuramos los logs hacia el SYSLOG fileline: off to_syslog: yes debug: off timestamp: on logger_subsys { subsys: QUORUM debug: off }
}
nodelist { —> La lista de nodos del clúster y ponemos las IPs privadas node { ring0_addr: 172.18.20.1 nodeid: 1 }
node { ring0_addr: 172.18.20.2 nodeid: 2 } } quorum { —> Al ser un clúster de dos nodos es necesario definir la opción two_node provider: corosync_votequorum two_node: 1 no-quorum-policy: ignore stonith-action: poweroff —> si hay un problema apagamos el servidor que está dando el problema }
Una vez tenemos la misma configuración en los dos servidores y hemos puesto en marcha el daemon de corosync, podemos usar la herramienta de línea de comandos crm para configurar recursos, prioridades, fencing en uno de los nodos, ya que con el corosync la configuración se aplicará a todos los nodos del clúster.
Para que el clúster esté funcionando correctamente hace falta que los nodos establezcan un cuórum, si hacemos crm status veremos que nos dice “partition with quorum”.
cluster1:/root # systemctl start corosync; systemctl start pacemaker
cluster1r:/root # crm status
Stack: corosync
Current DC: miserver (2) – partition with quorum
2 Nodes configured
0 Resources configured
Online: [ cluster1 cluster2 ]
Configuramos una IP flotante y un servicio: En este caso configuraría el servicio deseado pero otro servicio sería lo mismo. Lo que pone lsb:nombre_servicio quiere decir que el servidor tiene definido un servicio que se puede hacer start/stop que se llama nombre_servicio. Si no está este servicio, la configuración del clúster da un error.
miserver /root# crm configure
primitive ipservicio IPaddr2 params ip=172.18.20.1 cidr_netmask=24 op monitor interval=30s
primitive wol_relay lsb:wol_relay op monitor interval=15s
group servicio ipservicio servicio_relay
location cluster1 servicio 100: NODE1
location cluster2 servicio 50: NODE2
commit
STONITH: Se configura para NODE1 y también para NODE2
miserver /root#crm configure primitive shootNODE1 stonith:external/ipmi params hostname=“node1fencing”
ipaddr=“xxxx” userid=“fence” passwd=“XXX” interface=“lanplus” stonith-timeout=“30s” op monitor
interval=120s
miserver /root# crm configure location shootNODE1LOC shootNODE1 -inf: NODE1
Hacemos lo mismo para NODE2
Finalmente, con toda la configuración hecha y habiendo resuelto problemas que nos hayamos encontrado, el crm status tendría que dar algo así:
NODE1:/root # crm status
Stack: corosync
Current DC: NODE1 (2) – partition with quorum
2 Nodes configured
7 Resources configured
Online: [ cluster1 cluster 2 ]
shootNODE2 (stonith:extcluster2/ipmi): Started cluster1 Resource Group: servicio ipservicio (ocf::heartbeat:IPaddr2): Started cluster2 wol_relay (lsb:wol_relay): Started cluster2 Resource Group: servicio gwip (ocf::heartbeat:IPaddr2): Started cluster1 gw4ip (ocf::heartbeat:IPaddr2): Started cluster1 firewall (lsb:firewall_cluster): Started cluster1
Conclusión
Antes de usar Pacemaker usábamos un software que se llamaba Heartbeat (en realidad predecesor de Pacemaker).
Era mucho más sencillo de instalar y configurar pero faltaban muchas cosas que han mejorado en Pacemaker, el tema de orden y prioridades por ejemplo.
También es mejor la posibilidad de configuración con la herramienta crm que hace que se replique la configuración en todos los nodos del clúster.
En resumen, al principio usar Pacemaker parece una tarea más compleja, pero le vas viendo los beneficios y una vez te haces con la sintaxis es un software muy potente para gestionar la alta disponibilidad de servicios en Linux.
Configurar un cluster de alta disponibilidad activo/pasivo ofreciendo algún servicio que se quiera mantener en alta disponibilidad (ldap, http, https, etc.), el funcionamiento del software de HA (pacemaker y corosync) para ofrecer los servicios en HA, además esta configuración es la base de los clusters reales.
Instalacion y configuracion:
Utilizaremos como nodos del clúster los equipos cluster1 (172.18.20.1) y cluster2 (172.18.20.2), ambos con debian y como dirección IP virtual (la que usaremos como un recurso en alta disponibilidad) utilizaremos la 192.168.10.11.
En un cluster de HA siempre es recomendable que los nodos estén interconectados por interfaces dedicadas en otro segmento de red diferente del que se utiliza para ofrecer los recursos.
Instalación de pacemaker y corosync
En ambos nodos instalamos pacemaker y corosync:
cluster1:~# apt-get install pacemaker corosync
cluster2:~# apt-get install pacemaker corosync
Creamos en cluster1 la clave de autenticación de corosync y la copiamos a cluster2:
cluster1:~# corosync-keygen
cluster1:~# scp /etc/corosync/authkey patricio:/etc/corosync/authkey
cluster2:~# chmod 400 /etc/corosync/authkey
Editamos el fichero de configuración de corosync (/etc/corosync/corosync.conf) de ambos nodos y añadimos la red que se va a utilizar para controlar el latido entre los nodos (en nuestro caso va a ser la misma por la que se ofrecen los recursos, pero lo habitual sería que fuese una interfaz dedicada):
42
bindnetaddr: 172.18.20.0
Además para que corosync se inicie de forma automática al arrancar la máquina, marcamos a “yes” el parámetro START del fichero de configuración del demonio (/etc/default/corosync) en ambos nodos.
Reiniciamos corosync en los dos nodos
cluster1:~# service corosync restart
cluster2:~# service corosync restart
Si comprobamos el estado del cluster, podremos comprobar que inicialmente tenemos algo como:
root@cluster1:~# crm_mon
====
Last updated: Sun Feb 4 09:46:15 2018
Current DC: NONE
0 Nodes configured, unknown expected votes
0 Resources configured.
====
pero al cabo de unos instantes, pasamos al siguiente estado:
====
Last updated: Sun Feb 4 09:49:40 2018
Stack: openais
Current DC: bobesponja – partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
0 Resources configured.
====
Online: [ cluster1 cluster2 ]
Donde podemos comprobar que los dos nodos se han detectado, aunque todavía no hay ningún recurso configurado.
Configuración de la IP virtual como recurso
El recurso que vamos a configurar en este ejemplo va a ser una dirección IP 192.168.10.11, para ello en primer lugar desactivamos el mecanismo de STONITH (Shoot The Other Node In The Head), que se utiliza para parar un nodo que esté dando problemas y así evitar un comportamiento inadecuado del cluster:
cluster1:~# crm configure property stonith-enabled=false
Ahora configuramos el recurso de la IP virtual (172.18.20.1):
cluster1:~# crm configure primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip=“172.18.20.1” nic=“ens3” op monitor interval=“10s” meta is-managed=“true”
Al monitorizar ahora el cluster, veremos que aparece el recurso FAILOVER-ADDR asociado en este momento a cluster1:
====
Last updated: Sun Mar 4 09:15:33 2012
Stack: openais
Current DC: cluster1 – partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
====
Online: [ cluster1 cluster2 ]
FAILOVER-ADDR (ocf::heartbeat:IPaddr2): Started cluster1
Desde un equipo de la red 192.168.10.0/24 probamos a hacer ping a la 192.168.10.1 y verificamos la dirección MAC que responde (cluster1):
host:~$ ping -c 1 192.168.10.1
ping -c 1 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_req=1 ttl=64 time=0.735 ms
—- 192.168.10.1 ping statistics —-
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.735/0.735/0.735/0.000 ms
host:~$ ping -c 1 172.18.20.1
PING 172.18.20.1 (172.18.20.1) 56(84) bytes of data.
64 bytes from 172.18.20.1: icmp_req=1 ttl=64 time=1.35 ms
—- 172.18.20.1 ping statistics —-
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.352/1.352/1.352/0.000 ms
host:~$ ping -c 1 172.18.20.2
PING 172.18.20.2 (172.18.20.2) 56(84) bytes of data.
64 bytes from 172.18.20.2: icmp_req=1 ttl=64 time=0.667 ms
—- 172.18.20.2 ping statistics —-
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.667/0.667/0.667/0.000 ms
host:~$ cat /proc/net/arp
IP address HW type Flags HW address Mask Device
172.18.20.1 0×1 0×2 52:54:00:af:f8:9d * virbr1
192.168.10.1 0×1 0×2 52:54:00:af:f8:9d * virbr2
172.18.20.2 0×1 0×2 00:16:36:2d:70:4e * virbr1
Ahora probamos el funcionamiento del cluster apagando cluster1 y monitorizamos el cluster desde cluster2:
====
Last updated: Sun Mar 4 09:20:54 2012
Stack: openais
Current DC: patricio – partition WITHOUT quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
====
Online: [ cluster2 ]
OFFLINE: [ cluster1 ]
Sin embargo cluster1 no pasa a ofrecer el recurso directamente porque no hay quorum en el cluster. El quórum (quorum) es una propiedad que utiliza pacemaker para tomar las decisiones apropiadas mediante consultas consensuadas a todos los nodos, pero no tiene razón de ser en un cluster de solo dos nodos, ya que sólo habrá quorum cuando los dos nodos estén operativos, así que ignoramos las decisiones basadas en quórum:
cluster2:~# crm configure property no-quorum-policy=ignore
Podemos comprobar ahora como cluster2 pasa a ofrecer el recurso, aunque nos advierte que no ha habido quórum a la hora de tomar esa decisión:
====
Last updated: Sun Mar 4 09:29:58 2012
Stack: openais
Current DC: cluster2 – partition WITHOUT quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
====
Online: [ cluster2 ]
OFFLINE: [ cluster1 ]
FAILOVER-ADDR (ocf::heartbeat:IPaddr2): Started cluster2
Desde el equipo externo podemos comprobar que la dirección IP sigue respondiendo al ping, pero ahora está asociada a la dirección MAC de cluster2:
host:~$ ping -c 1 172.18.20.1
PING 172.18.20.1 (172.18.20.1) 56(84) bytes of data.
64 bytes from 172.18.20.1: icmp_req=1 ttl=64 time=1.83 ms
—- 172.18.20.1 ping statistics —-
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.835/1.835/1.835/0.000 ms
host:~$ cat /proc/net/arp
IP address HW type Flags HW address Mask Device
172.18.20.1 0×1 0×2 00:16:36:2d:70:4e * virbr1
172.18.20.2 0×1 0×2 00:16:36:2d:70:4e * virbr1
Si por último, volvemos a arrancar cluster1, éste volverá a ofrecer el recurso:
====
Last updated: Sun Mar 4 09:35:18 2012
Stack: openais
Current DC: cluster2 – partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
====
Online: [ cluster1 cluster2 ]
FAILOVER-ADDR (ocf::heartbeat:IPaddr2): Started cluster1

Autor

Publicado

GNU/Linux Scapy http://www.secdev.org/projects/scapy/ es un potente programa de manipulación de paquetes interactiva. Es capaz de forjar o decodificar paquetes de un gran número de protocolos, es una utilidad escrita en Python que nos servirá para crear y manipular paquetes, escanear, funciones de sniffer, creación de gráficas 2D / 3D / Pdf, passive OS fingerprinting, tracers gráficos. Además, podemos crear utilidades escritas en Python usando scapy. Posee funciones similares a ttlscan, nmap, hping, queso, p0f, xprobe, arping, arp-sk, ARPSpoof, firewalk.
Todo mediante línea de comandos, es integrable en Python, programable, versátil y flexible. Obtendremos solo los datos que queramos y todo lo complejo que deseemos. 1. apt-get install scapy
dhcpcanon – DCHP IPv4 client anonymity profile implementation
dhcpig – DHCP exhaustion script using scapy network library
python-scapy – Packet generator/sniffer and network scanner/discovery
python3-scapy – Packet crafting/sniffing/manipulation/visualization security tool
Nos instalara scapy y scapy3
Ejecutamos facilmente: 1. scapy
>>>
Denegacion de servicio
>>> send(IP(src=RandIP(‘78.0.0.0/16’), dst=’(IP)’)/TCP, dport=(puerto), loop=1, verbose=1)
Sniffer
>>> sniff(filter=”host 172.18.20.79″) File “
SyntaxError: invalid character in identifier
>>> sniff(filter=“host 172.18.19.79”)
^C
>>> sniff(filter=“host 172.18.19.79”)
^C
>>> sniff(filter=“icmp”, count=2)
^C
>>> sniff(filter=“icmp”, count=0)
^C
>>> sniff(iface=“wlp1s0”, filter=“tcp and port 80”, count=2)

>>> sniff(iface=“wlp1s0”, filter=“tcp and port 80”, count=2, prn=lambda x: x.summary)

>>> sniff(iface=“wlp1s0”, filter=“tcp and port 80”, count=2, prn=lambda x: x.show())
###[ Ethernet ]### dst= 52:54:00:4c:bb:65 src= 94:53:30:c5:47:f3 type= IPv4
###[ IP ]### version= 4 ihl= 5 tos= 0×0 len= 52 id= 30831 flags= DF frag= 0 ttl= 64 proto= tcp chksum= 0xd3bd src= 172.18.19.79 dst= 23.78.22.232 \options\
###[ TCP ]### sport= 53380 dport= http seq= 383643197 ack= 2109256274 dataofs= 8 reserved= 0 flags= A window= 237 chksum= 0xeebd urgptr= 0 options= [(‘NOP’, None), (‘NOP’, None), (‘Timestamp’, (2485683609, 1832873335))]
###[ Ethernet ]### dst= 94:53:30:c5:47:f3 src= 52:54:00:4c:bb:65 type= IPv4
###[ IP ]### version= 4 ihl= 5 tos= 0×0 len= 52 id= 56596 flags= DF frag= 0 ttl= 64 proto= tcp chksum= 0×6f18 src= 23.78.22.232 dst= 172.18.19.79 \options\
###[ TCP ]### sport= http dport= 53380 seq= 2109256274 ack= 383643198 dataofs= 8 reserved= 0 flags= A window= 235 chksum= 0xaa10 urgptr= 0 options= [(‘NOP’, None), (‘NOP’, None), (‘Timestamp’, (1832875838, 2485673608))]
Existe la manera de tener nuestros propios script en python para realizar lineas de comando en scapy.

Autor