sc_filterpolicy - Online nel cloud

PROGRAMMA:

NOME

sc_filterpolicy — driver scamper per testare i sistemi per una politica di filtraggio congruente

SINOSSI

sc_filterpolicy [-D] [-a file di input] [-l file di log] [-o file di uscita] [-O Opzioni]
[-p porto di scappatella] [-t tipo di host] [-T test] [-U scamper-unix]

sc_filterpolicy [-r file di dati]

DESCRIZIONE

. sc_filterpolicy utility fornisce la possibilità di connettersi a un'esecuzione correre(1) istanza
e utilizzare tale istanza per testare i sistemi per una politica di filtraggio congruente. L'utilità testa
ogni sistema specificato nel file di input verificando la raggiungibilità dell'applicazione con ICMP,
Sonde UDP e TCP, utilizzando sia IPv4 che IPv6, ove applicabile. Ogni sistema nell'input
il file dovrebbe avere più indirizzi IP specificati; il driver sonda ogni indirizzo IP su ogni
sistema uno alla volta per evitare che il sistema remoto limiti la velocità delle risposte.
sc_filterpolicy ottiene velocità sondando i sistemi in parallelo, anche se può sembrare
operare lentamente perché non viene segnalato alcun progresso finché tutti gli indirizzi appartenenti a un dispositivo
sono stati testati uno alla volta.

Le applicazioni supportate da sc_filterpolicy per testare la politica di filtraggio sono:
- ICMP: test di reattività ai pacchetti di richiesta di eco ICMP. Classifichiamo l'indirizzo IP come
risponde alle richieste di eco ICMP se invia una risposta di eco ICMP.
- NetBIOS: testare la reattività ai pacchetti TCP SYN inviati alla porta 139 (la porta NetBIOS).
Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- MSSQL: testare la reattività ai pacchetti TCP SYN inviati alla porta 1433 (Microsoft SQL
porta predefinita del server). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- FTP: testare la reattività ai pacchetti TCP SYN inviati alla porta 21 (la porta predefinita per FTP
connessioni di controllo). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- SSH: testare la reattività ai pacchetti TCP SYN inviati alla porta 22 (la porta predefinita per SSH).
Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- Telnet: testare la reattività ai pacchetti TCP SYN inviati alla porta 23 (la porta predefinita per
telnet). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- MySQL: testare la reattività ai pacchetti TCP SYN inviati alla porta 3306 (la porta predefinita per
MySQL). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- PSR: testare la reattività ai pacchetti TCP SYN inviati alla porta 3389 (la porta predefinita per
RDP). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- HTTPS: testare la reattività ai pacchetti TCP SYN inviati alla porta 443 (la porta predefinita per
HTTPS). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- PMI: testare la reattività ai pacchetti TCP SYN inviati alla porta 445 (la porta predefinita per
SMB). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- HTTP: testare la reattività ai pacchetti TCP SYN inviati alla porta 80 (la porta predefinita per
HTTP). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- BGP: testare la reattività ai pacchetti TCP SYN inviati alla porta 179 (la porta predefinita per
BGP). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.
- PNT: testare la reattività ai pacchetti UDP inviati alla porta 123 (la porta predefinita per NTP)
con un payload di richiesta di versione NTP. Classifichiamo l'indirizzo IP come reattivo se
invia una risposta UDP.
- DNS: testare la reattività ai pacchetti UDP inviati alla porta 53 (la porta predefinita per DNS) con
una query per www.google.com. Classifichiamo l'indirizzo IP come reattivo se invia un
Risposta UDP.
- SNMP: testare la reattività ai pacchetti UDP inviati alla porta 161 (la porta predefinita per SNMP)
con un get per sysDescr tramite la comunità pubblica utilizzando il protocollo SNMPv2c. Noi
classificare l'indirizzo IP come reattivo se invia una risposta UDP.
- VNC: testare la reattività ai pacchetti TCP SYN inviati alla porta 5900 (la porta predefinita per
VNC). Classifichiamo l'indirizzo IP come reattivo se invia un SYN/ACK.

Le opzioni supportate da sc_filterpolicy sono come segue:

-? stampa un elenco di opzioni della riga di comando e una sinossi di ciascuna.

-a file di input
specifica il nome del file di input che consiste in una sequenza di sistemi da
test. Vedere la sezione esempi per esempi di formattazione del file di input.

-D con questa opzione impostata, sc_filterpolicy si staccherà e diventerà un demone.

-l file di log
specifica il nome di un file da cui registrare l'output di avanzamento sc_filterpolicy generato
in fase di esecuzione.

-o file di uscita
specifica il nome del file da scrivere. Il file di output utilizzerà il verruche(5)
formato.

-O Opzioni
consente il comportamento di sc_filterpolicy da personalizzare ulteriormente. Le scelte attuali
per questa opzione sono:
- impaziente: ordinare i sistemi trovati nel file di input in modo che quelli con il
la maggior parte degli indirizzi vengono sondati per primi, in modo che il sondaggio venga completato il più velocemente possibile
possibile.
- incongruente: segnalare solo i sistemi che si suppone abbiano un'incongruenza
politica di filtraggio.
- traccia: sondare gli indirizzi trovati nel file di input utilizzando traceroute, piuttosto
rispetto al ping.
- tuple: segnala che il file di input è formattato come tuple, anziché come righe.
Per maggiori informazioni, consultare la sezione degli esempi.

-p porto di scappatella
specifica la porta sull'host locale dove correre(1) accetta presa di controllo
connessioni.

-r file di dati
specifica il nome di un file di dati di criteri di filtro raccolti in precedenza, in verruche(5)
formato, da leggere e analizzare.

-t classe sonda
specifica la classe di sonde da inviare per ogni indirizzo IP nel file di input.
le scelte attuali per questa opzione sono:
- router: testare ICMP, SSH, Telnet, HTTPS, HTTP, BGP, NTP, DNS e SNMP.
- Server: prova ICMP, FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB, HTTP, NTP, DNS,
e SNMP.
- tutto: prova ICMP, NetBIOS, MSSQL, FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB, VNC,
HTTP, BGP, NTP, DNS e SNMP.

-T test
specifica le modifiche alla pianificazione dei test in base ai tipi di applicazione supportati.
Anteporre un'applicazione con + fa sì che il tipo di applicazione venga aggiunto al test
pianificare e anteporre un'applicazione con - fa sì che il tipo di applicazione sia
rimosso dal programma di prova.

-U scamper-unix
specifica il socket di dominio Unix sull'host locale dove correre(1) sta accettando
connessioni delle prese di controllo.

ESEMPI

sc_filterpolicy richiede a correre(1) istanza in ascolto su una porta o socket di dominio Unix per
comandi per raccogliere dati:

scappare -P 31337

inizierà un correre(1) istanza in ascolto sulla porta 31337 sull'interfaccia loopback. Per utilizzare
sc_filterpolicy per testare la politica di filtraggio di un insieme di router specificati in un file denominato
routers.txt e formattato come righe come segue:

foo.esempio.com 192.0.2.1 2001:DB8::1
bar.esempio.com 192.0.2.2 2001:DB8::2

il seguente comando testerà la reattività di questi router a ICMP, SSH, Telnet,
Sonde HTTPS, HTTP, BGP, NTP, DNS e SNMP, che registrano dati grezzi in example-routers.warts:

sc_filterpolicy -p 31337 -a routers.txt -t router -o example-routers.warts

L'inserimento del nome di ciascun dispositivo nel file di input è facoltativo.

Il seguente comando testerà solo la reattività dei router a SSH:

sc_filterpolicy -p 31337 -a routers.txt -T +ssh -o example-ssh.warts

Per utilizzare sc_filterpolicy per testare la politica di filtraggio di un insieme di server specificati in un file
denominato servers.txt e formattato come tuple come segue:

db.esempio.com 192.0.2.3
db.example.com 2001::DB8::3
corp.example.com 192.0.2.4
corp.example.com 2001::DB8::4

il seguente comando testerà la reattività di questi server a ICMP, FTP, SSH, Telnet,
Sonde MySQL, RDP, HTTPS, SMB, HTTP, NTP, DNS e SNMP, registrazione di dati grezzi in esempi
server.verruche:

sc_filterpolicy -p 31337 -a servers.txt -t server -o example-servers.warts -O tuples

In un file di input formattato come tuple, il nome (o un identificatore) per ciascun dispositivo è
obbligatorio e viene utilizzato per garantire che venga inviata una sola sonda a un dispositivo alla volta e per
raccogliere le risposte provenienti da indirizzi diversi sullo stesso dispositivo per la segnalazione.

Una volta raccolti i dati grezzi, sc_filterpolicy può essere utilizzato per analizzare i dati raccolti.
Per il file example-routers.warts, il seguente comando scarica un riepilogo dei dati
raccolti per ogni router:

sc_filterpolicy -r esempio-routers.warts

: T
: e H
: Io questo
: CS n TTBNDN
: MS e PTGTNM
: PH t SPPPSP
========================================
192.0.2.1 : OOOOO
2001:DB8::1 : OOOOO

192.0.2.2 : BUE
2001:DB8::2 : OO

Il primo router è reattivo (O) per le sonde ICMP, SSH, HTTP, DNS e SNMP su tutti
indirizzi. Il secondo router è reattivo (O) alle sonde ICMP su entrambi gli indirizzi è
non risponde (X) a SSH sull'indirizzo IPv4, ma risponde (O) a SSH sull'indirizzo IPv6
indirizzo e probabilmente rappresenta una politica di filtraggio che è incongruente e richiede
attenzione. Nota che le celle vuote nella tabella rappresentano un router che non rispondeva
(X) a quel protocollo per tutti gli indirizzi testati; le celle vengono lasciate vuote per consentire all'utente di
concentrarsi su servizi applicativi aperti e incongruenti.

Il comando:

sc_filterpolicy -O incongruent -r example-routers.warts

mostrerà solo i router con una politica di filtraggio incongruente.

Utilizzare sc_filterpolicy online utilizzando i servizi onworks.net