1SC_FILTERPOLICY(1) BSD General Commands Manual SC_FILTERPOLICY(1)
2
4 sc_filterpolicy — scamper driver to test systems for congruent filtering
5 policy
6
8 sc_filterpolicy [-D] [-a input-file] [-l log-file] [-o output-file]
9 [-O options] [-p scamper-port] [-t host-type] [-T test]
10 [-U scamper-unix]
11 sc_filterpolicy [-r data-file]
13
15 The sc_filterpolicy utility provides the ability to connect to a running
16 scamper(1) instance and use that instance to test systems for congruent
17 filtering policy. The utility tests each system specified in the input
18 file by probing for application reachability with ICMP, UDP, and TCP
19 probes, using both IPv4 and IPv6 where applicable. Each system in the
20 input file should have multiple IP addresses specified; the driver probes
21 each IP address on each system one at a time to avoid causing the remote
22 system to rate-limit responses. sc_filterpolicy obtains speed by probing
23 systems in parallel, though it may appear to operate slowly because no
24 progress is reported until all addresses belonging to a device have been
25 tested one at a time.
26 The applications supported by sc_filterpolicy to test filtering policy
28 are:
29 - ICMP: test responsiveness to ICMP echo request packets. We classify
30 the IP address as responsive to ICMP echo requests if it sends an
31 ICMP echo reply.
32 - NetBIOS: test responsiveness to TCP SYN packets sent to port 139
33 (the NetBIOS port). We classify the IP address as responsive if it
34 sends a SYN/ACK.
35 - MSSQL: test responsiveness to TCP SYN packets sent to port 1433 (the
36 Microsoft SQL server default port). We classify the IP address as
37 responsive if it sends a SYN/ACK.
38 - FTP: test responsiveness to TCP SYN packets sent to port 21 (the
39 default port for FTP control connections). We classify the IP
40 address as responsive if it sends a SYN/ACK.
41 - SSH: test responsiveness to TCP SYN packets sent to port 22 (the
42 default port for SSH). We classify the IP address as responsive if
43 it sends a SYN/ACK.
44 - Telnet: test responsiveness to TCP SYN packets sent to port 23 (the
45 default port for telnet). We classify the IP address as responsive
46 if it sends a SYN/ACK.
47 - MySQL: test responsiveness to TCP SYN packets sent to port 3306 (the
48 default port for MySQL). We classify the IP address as responsive
49 if it sends a SYN/ACK.
50 - RDP: test responsiveness to TCP SYN packets sent to port 3389 (the
51 default port for RDP). We classify the IP address as responsive if
52 it sends a SYN/ACK.
53 - HTTPS: test responsiveness to TCP SYN packets sent to port 443 (the
54 default port for HTTPS). We classify the IP address as responsive
55 if it sends a SYN/ACK.
56 - SMB: test responsiveness to TCP SYN packets sent to port 445 (the
57 default port for SMB). We classify the IP address as responsive if
58 it sends a SYN/ACK.
59 - HTTP: test responsiveness to TCP SYN packets sent to port 80 (the
60 default port for HTTP). We classify the IP address as responsive if
61 it sends a SYN/ACK.
62 - BGP: test responsiveness to TCP SYN packets sent to port 179 (the
63 default port for BGP). We classify the IP address as responsive if
64 it sends a SYN/ACK.
65 - NTP: test responsiveness to UDP packets sent to port 123 (the
66 default port for NTP) with an NTP version request payload. We clas‐
67 sify the IP address as responsive if it sends a UDP response.
68 - DNS: test responsiveness to UDP packets sent to port 53 (the default
69 port for DNS) with a query for www.google.com. We classify the IP
70 address as responsive if it sends a UDP response.
71 - SNMP: test responsiveness to UDP packets sent to port 161 (the
72 default port for SNMP) with a get for sysDescr via the public commu‐
73 nity using the SNMPv2c protocol. We classify the IP address as
74 responsive if it sends a UDP response.
75 - VNC: test responsiveness to TCP SYN packets sent to port 5900 (the
76 default port for VNC). We classify the IP address as responsive if
77 it sends a SYN/ACK.
78 The options supported by sc_filterpolicy are as follows:
80 -? prints a list of command line options and a synopsis of each.
82 -a input-file
84 specifies the name of the input file which consists of a sequence
85 of systems to test. See the examples section for input-file for‐
86 matting examples.
87 -D with this option set, sc_filterpolicy will detach and become a
89 daemon.
90 -l log-file
92 specifies the name of a file to log progress output from
93 sc_filterpolicy generated at run time.
94 -o output-file
96 specifies the name of the file to be written. The output file
97 will use the warts(5) format.
98 -O options
100 allows the behavior of sc_filterpolicy to be further tailored.
101 The current choices for this option are:
102 - impatient: order the systems found in the input-file so that
103 those with the most addresses are probed first, so that
104 probing will complete as fast as possible.
105 - incongruent: only report systems which are inferred to have
106 an incongruent filtering policy.
107 - trace: probe the addresses found in the input-file using
108 traceroute, rather than ping.
109 - tuples: signals that the input-file is formatted as tuples,
110 rather than rows. See the examples section for more infor‐
111 mation.
112 -p scamper-port
114 specifies the port on the local host where scamper(1) is accept‐
115 ing control socket connections.
116 -r data-file
118 specifies the name of a previously collected filter policy data
119 file, in warts(5) format, to read and analyse.
120 -t probe-class
122 specifies the class of probes to send for each IP address in the
123 input file. The current choices for this option are:
124 - router: test ICMP, SSH, Telnet, HTTPS, HTTP, BGP, NTP, DNS,
125 and SNMP.
126 - server: test ICMP, FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB,
127 HTTP, NTP, DNS, and SNMP.
128 - all: test ICMP, NetBIOS, MSSQL, FTP, SSH, Telnet, MySQL,
129 RDP, HTTPS, SMB, VNC, HTTP, BGP, NTP, DNS, and SNMP.
130 -T test
132 specifies adjustments to the test schedule from the supported
133 application types. Prefacing an application with + causes the
134 application type to be added to the test schedule, and prefacing
135 an application with - causes the application type to be removed
136 from the test schedule.
137 -U scamper-unix
139 specifies the unix domain socket on the local host where
140 scamper(1) is accepting control socket connections.
141
143 sc_filterpolicy requires a scamper(1) instance listening on a port or
144 unix domain socket for commands in order to collect data:
145 scamper -P 31337
147 will start a scamper(1) instance listening on port 31337 on the loopback
149 interface. To use sc_filterpolicy to test the filtering policy of a set
150 of routers specified in a file named routers.txt and formatted as rows as
151 follows:
152 foo.example.com 192.0.2.1 2001:DB8::1
154 bar.example.com 192.0.2.2 2001:DB8::2
155 the following command will test these routers for responsiveness to ICMP,
157 SSH, Telnet, HTTPS, HTTP, BGP, NTP, DNS, and SNMP probes, recording raw
158 data into example-routers.warts:
159 sc_filterpolicy -p 31337 -a routers.txt -t router -o example-routers.warts
161 Including the name of each device in the input file is optional.
163 The following command will only test the routers for responsiveness to
165 SSH:
166 sc_filterpolicy -p 31337 -a routers.txt -T +ssh -o example-ssh.warts
168 To use sc_filterpolicy to test the filtering policy of a set of servers
170 specified in a file named servers.txt and formatted as tuples as follows:
171 db.example.com 192.0.2.3
173 db.example.com 2001::DB8::3
174 corp.example.com 192.0.2.4
175 corp.example.com 2001::DB8::4
176 the following command will test these servers for responsiveness to ICMP,
178 FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB, HTTP, NTP, DNS, and SNMP
179 probes, recording raw data into example-servers.warts:
180 sc_filterpolicy -p 31337 -a servers.txt -t server -o example-servers.warts -O tuples
182 In an input file formatted as tuples, the name (or an identifier) for
184 each device is mandatory, and is used to ensure only one probe is sent to
185 any one device at a time, and to collate responses from different
186 addresses to the same device for reporting.
187 Once raw data has been collected, sc_filterpolicy can be used to analyse
189 the collected data. For the example-routers.warts file, the following
190 command dumps a summary of the data collected for each router:
191 sc_filterpolicy -r example-routers.warts
193 : T
195 : e H
196 : I l T H S
197 : C S n T T B N D N
198 : M S e P T G T N M
199 : P H t S P P P S P
200 ========================================
201 192.0.2.1 : O O O O O
202 2001:DB8::1 : O O O O O
203 192.0.2.2 : O X
205 2001:DB8::2 : O O
206 The first router is responsive (O) for ICMP, SSH, HTTP, DNS, and SNMP
208 probes on all addresses. The second router is responsive (O) to ICMP
209 probes on both addresses is unresponsive (X) to SSH on the IPv4 address,
210 but is responsive (O) to SSH on the IPv6 address and possibly represents
211 a filtering policy that is incongruent and requires attention. Note that
212 the empty cells in the table represent a router that was unresponsive (X)
213 to that protocol for all addresses tested; the cells are left empty to
214 allow the user to focus on open and incongruent application services.
215 The command:
217 sc_filterpolicy -O incongruent -r example-routers.warts
219 will only show routers with an incongruent filtering policy.
221
223 J. Czyz, M. Luckie, M. Allman, and M. Bailey, Don't Forget to Lock the
224 Back Door! A Characterization of IPv6 Network Security Policy, Proc.
225 Network and Distributed Systems Security (NDSS) Conference 2016.
226 scamper(1), sc_wartsdump(1), sc_warts2json(1), warts(5)
227
229 sc_filterpolicy was written by Matthew Luckie <mjl@luckie.org.nz> and
230 Jakub Czyz.
231BSD December 2, 2015 BSD