Este es el comando sc_filterpolicy que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.
PROGRAMA:
NOMBRE
sc_filterpolicy - controlador scamper para probar sistemas para una política de filtrado congruente
SINOPSIS
sc_filterpolicy [-D] [-a fichero de entrada] [-l archivo de registro] [-o archivo de salida] [-O opciones]
[-p puerto-correteador] [-t tipo de host] [-T compruébalo] [-U correteador-unix]
sc_filterpolicy [-r archivo de datos]
DESCRIPCIÓN
La pestaña sc_filterpolicy La utilidad proporciona la capacidad de conectarse a un corretear(1) instancia
y use esa instancia para probar sistemas para políticas de filtrado congruentes. Las pruebas de utilidad
cada sistema especificado en el archivo de entrada probando la accesibilidad de la aplicación con ICMP,
Sondas UDP y TCP, utilizando tanto IPv4 como IPv6 cuando corresponda. Cada sistema en la entrada
el archivo debe tener varias direcciones IP especificadas; el controlador prueba cada dirección IP en cada
sistema de uno en uno para evitar que el sistema remoto limite la velocidad de respuesta.
sc_filterpolicy obtiene velocidad probando sistemas en paralelo, aunque puede parecer que
operar lentamente porque no se informa ningún progreso hasta que todas las direcciones que pertenecen a un dispositivo
han sido probados uno a la vez.
Las aplicaciones soportadas por sc_filterpolicy para probar la política de filtrado son:
- ICMP: probar la capacidad de respuesta a los paquetes de solicitud de eco ICMP. Clasificamos la dirección IP como
responde a las solicitudes de eco ICMP si envía una respuesta de eco ICMP.
- NetBIOS: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 139 (el puerto NetBIOS).
Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- MSSQL: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 1433 (el Microsoft SQL
puerto predeterminado del servidor). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- FTP: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 21 (el puerto predeterminado para FTP
conexiones de control). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- SSH: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 22 (el puerto predeterminado para SSH).
Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- telnet: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 23 (el puerto predeterminado para
telnet). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- MySQL: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 3306 (el puerto predeterminado para
MySQL). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- PDR: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 3389 (el puerto predeterminado para
RDP). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- HTTPS: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 443 (el puerto predeterminado para
HTTPS). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- SMB: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 445 (el puerto predeterminado para
SMB). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- HTTP: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 80 (el puerto predeterminado para
HTTP). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- BGP: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 179 (el puerto predeterminado para
BGP). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
- NTP: probar la capacidad de respuesta a los paquetes UDP enviados al puerto 123 (el puerto predeterminado para NTP)
con una carga útil de solicitud de versión NTP. Clasificamos la dirección IP como receptiva si
envía una respuesta UDP.
- DNS: probar la capacidad de respuesta a los paquetes UDP enviados al puerto 53 (el puerto predeterminado para DNS) con
una consulta para www.google.com. Clasificamos las direcciones IP como receptivas si envía un
Respuesta UDP.
- SNMP: probar la capacidad de respuesta a los paquetes UDP enviados al puerto 161 (el puerto predeterminado para SNMP)
con un get para sysDescr a través de la comunidad pública utilizando el protocolo SNMPv2c. Nosotros
clasifique las direcciones IP como receptivas si envía una respuesta UDP.
- VCN: probar la capacidad de respuesta a los paquetes TCP SYN enviados al puerto 5900 (el puerto predeterminado para
VNC). Clasificamos la dirección IP como receptiva si envía un SYN / ACK.
Las opciones admitidas por sc_filterpolicy son los siguientes:
-? imprime una lista de opciones de la línea de comandos y una sinopsis de cada una.
-a fichero de entrada
especifica el nombre del archivo de entrada que consta de una secuencia de sistemas
prueba. Consulte la sección de ejemplos para ver ejemplos de formato de archivo de entrada.
-D con esta opción establecida, sc_filterpolicy se desprenderá y se convertirá en un demonio.
-l archivo de registro
especifica el nombre de un archivo para registrar la salida del progreso sc_filterpolicy generado
en tiempo de ejecución.
-o archivo de salida
especifica el nombre del archivo que se va a escribir. El archivo de salida utilizará el verrugas(5)
formato.
-O opciones
permite el comportamiento de sc_filterpolicy para ser adaptado aún más. Las elecciones actuales
para esta opción son:
- impaciente: ordenar los sistemas que se encuentran en el archivo de entrada de modo que aquellos con el
la mayoría de las direcciones se sondean primero, de modo que el sondeo se complete tan rápido como
posible.
- incongruente: solo informan los sistemas que se infiere que tienen una incongruencia
política de filtrado.
- rastro: probar las direcciones encontradas en el archivo de entrada usando traceroute, en lugar de
que ping.
- tuplas: indica que el archivo de entrada está formateado como tuplas, en lugar de filas.
Consulte la sección de ejemplos para obtener más información.
-p puerto-correteador
especifica el puerto en el host local donde corretear(1) acepta la toma de control
conexiones.
-r archivo de datos
especifica el nombre de un archivo de datos de política de filtro recopilado previamente, en verrugas(5)
formato, para leer y analizar.
-t clase de sonda
especifica la clase de sondas a enviar para cada dirección IP en el archivo de entrada. los
Las opciones actuales para esta opción son:
- enrutador: prueba ICMP, SSH, Telnet, HTTPS, HTTP, BGP, NTP, DNS y SNMP.
- servidor: prueba ICMP, FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB, HTTP, NTP, DNS,
y SNMP.
- todo: prueba ICMP, NetBIOS, MSSQL, FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB, VNC,
HTTP, BGP, NTP, DNS y SNMP.
-T compruébalo
especifica ajustes al programa de pruebas de los tipos de aplicaciones admitidos.
Anteponer una aplicación con + hace que el tipo de aplicación se agregue a la prueba
programar, y anteponer una aplicación con - hace que el tipo de aplicación sea
eliminado del programa de pruebas.
-U correteador-unix
especifica el socket de dominio Unix en el host local donde corretear(1) está aceptando
Conexiones de toma de control.
EJEMPLOS
sc_filterpolicy requiere de un corretear(1) instancia escuchando en un puerto o socket de dominio Unix para
comandos para recopilar datos:
correteador -P 31337
comenzará un corretear(1) instancia escuchando en el puerto 31337 en la interfaz de bucle invertido. Usar
sc_filterpolicy para probar la política de filtrado de un conjunto de enrutadores especificados en un archivo llamado
routers.txt y formateado como filas de la siguiente manera:
foo.example.com 192.0.2.1 2001: DB8 :: 1
bar.ejemplo.com 192.0.2.2 2001: DB8 :: 2
el siguiente comando probará la capacidad de respuesta de estos enrutadores a ICMP, SSH, Telnet,
Sondas HTTPS, HTTP, BGP, NTP, DNS y SNMP, que registran datos sin procesar en example-routers.warts:
sc_filterpolicy -p 31337 -a routers.txt -t router -o ejemplo-routers.warts
Incluir el nombre de cada dispositivo en el archivo de entrada es opcional.
El siguiente comando solo probará la capacidad de respuesta de los enrutadores a SSH:
sc_filterpolicy -p 31337 -a routers.txt -T + ssh -o ejemplo-ssh.warts
Para utilizar sc_filterpolicy para probar la política de filtrado de un conjunto de servidores especificados en un archivo
llamado servers.txt y formateado como tuplas de la siguiente manera:
db.ejemplo.com 192.0.2.3
db.ejemplo.com 2001 :: DB8 :: 3
corp.ejemplo.com 192.0.2.4
corp.example.com 2001 :: DB8 :: 4
el siguiente comando probará la capacidad de respuesta de estos servidores a ICMP, FTP, SSH, Telnet,
Sondas MySQL, RDP, HTTPS, SMB, HTTP, NTP, DNS y SNMP, que registran datos sin procesar en ejemplos
servidores.warts:
sc_filterpolicy -p 31337 -a servers.txt -t server -o example-servers.warts -O tuplas
En un archivo de entrada formateado como tuplas, el nombre (o un identificador) de cada dispositivo es
obligatorio, y se utiliza para garantizar que solo se envíe una sonda a un dispositivo a la vez, y para
recopile las respuestas de diferentes direcciones en el mismo dispositivo para informar.
Una vez que se hayan recopilado los datos brutos, sc_filterpolicy se puede utilizar para analizar los datos recopilados.
Para el archivo example-routers.warts, el siguiente comando descarga un resumen de los datos
recopilados para cada enrutador:
sc_filterpolicy -r ejemplo-routers.warts
:
: eH
: Yo l THS
: CS n TTBNDN
: MS y PTGTNM
: PH t SPPPSP
========================================
192.0.2.1: OOOOO
2001: DB8 :: 1: OOOOO
192.0.2.2: BUEY
2001: DB8 :: 2: OO
El primer enrutador responde (O) para las sondas ICMP, SSH, HTTP, DNS y SNMP en todos
direcciones. El segundo enrutador responde (O) a las sondas ICMP en ambas direcciones.
no responde (X) a SSH en la dirección IPv4, pero responde (O) a SSH en IPv6
dirección y posiblemente representa una política de filtrado que es incongruente y requiere
atención. Tenga en cuenta que las celdas vacías en la tabla representan un enrutador que no respondió
(X) a ese protocolo para todas las direcciones probadas; las celdas se dejan vacías para permitir que el usuario
centrarse en servicios de aplicaciones abiertos e incongruentes.
El comando:
sc_filterpolicy -O incongruente -r ejemplo-routers.warts
solo mostrará enrutadores con una política de filtrado incongruente.
Utilice sc_filterpolicy en línea utilizando los servicios de onworks.net
