SC_FILTERPOLICY(1)

💖 sc_filterpolicy — the scamper driver bestie 💖

okay so real talk: this is sc_filterpolicy(1), a General Commands Manual page, and it's the scamper driver that tests systems for congruent filtering policy. yes ma'am. let's get into it 🦋

---

✨ SYNOPSIS ✨

sc_filterpolicy [-D] [-a input-file] [-l log-file] [-o output-file]
                [-O options] [-p scamper-port] [-t host-type] [-T test]
                [-U scamper-unix]

sc_filterpolicy [-r data-file]

---

🌸 DESCRIPTION 🌸

so the whole vibe of sc_filterpolicy is: it connects to a running scamper(1) instance and uses that instance to test systems for congruent filtering policy. that's the mission. that's the assignment. 🫶

it tests every system you put in the input file by probing for application reachability with ICMP, UDP, and TCP probes, using both IPv4 and IPv6 where applicable. and listen — each system in the input file should have multiple IP addresses specified. the driver probes each IP address on each system one at a time to avoid causing the remote system to rate-limit responses. no cap, one at a time, it's a whole thing.

sc_filterpolicy gets its speed by probing systems in parallel, but ngl it might look like it's operating slowly, because no progress is reported until all addresses belonging to a device have been tested one at a time. it's not slacking, it's just being polite to the network. 😭

the applications supported by sc_filterpolicy to test filtering policy are:

• ICMP — test responsiveness to ICMP echo request packets. we classify the IP address as responsive to ICMP echo requests if it sends an ICMP echo reply.
• NetBIOS — test responsiveness to TCP SYN packets sent to port 139 (the NetBIOS port). we classify the IP address as responsive if it sends a SYN/ACK.
• MSSQL — test responsiveness to TCP SYN packets sent to port 1433 (the Microsoft SQL server default port). we classify the IP address as responsive if it sends a SYN/ACK.
• FTP — test responsiveness to TCP SYN packets sent to port 21 (the default port for FTP control connections). we classify the IP address as responsive if it sends a SYN/ACK.
• SSH — test responsiveness to TCP SYN packets sent to port 22 (the default port for SSH). we classify the IP address as responsive if it sends a SYN/ACK.
• Telnet — test responsiveness to TCP SYN packets sent to port 23 (the default port for telnet). we classify the IP address as responsive if it sends a SYN/ACK.
• MySQL — test responsiveness to TCP SYN packets sent to port 3306 (the default port for MySQL). we classify the IP address as responsive if it sends a SYN/ACK.
• RDP — test responsiveness to TCP SYN packets sent to port 3389 (the default port for RDP). we classify the IP address as responsive if it sends a SYN/ACK.
• HTTPS — test responsiveness to TCP SYN packets sent to port 443 (the default port for HTTPS). we classify the IP address as responsive if it sends a SYN/ACK.
• SMB — test responsiveness to TCP SYN packets sent to port 445 (the default port for SMB). we classify the IP address as responsive if it sends a SYN/ACK.
• HTTP — test responsiveness to TCP SYN packets sent to port 80 (the default port for HTTP). we classify the IP address as responsive if it sends a SYN/ACK.
• BGP — test responsiveness to TCP SYN packets sent to port 179 (the default port for BGP). we classify the IP address as responsive if it sends a SYN/ACK.
• NTP — test responsiveness to UDP packets sent to port 123 (the default port for NTP) with an NTP version request payload. we classify the IP address as responsive if it sends a UDP response.
• DNS — test responsiveness to UDP packets sent to port 53 (the default port for DNS) with a query for www.google.com. we classify the IP address as responsive if it sends a UDP response.
• SNMP — test responsiveness to UDP packets sent to port 161 (the default port for SNMP) with a get for sysDescr via the public community using the SNMPv2c protocol. we classify the IP address as responsive if it sends a UDP response.
• VNC — test responsiveness to TCP SYN packets sent to port 5900 (the default port for VNC). we classify the IP address as responsive if it sends a SYN/ACK.

---

👑 OPTIONS 👑

the options supported by sc_filterpolicy are as follows, and yes we're going through every single one:

• -? — prints a list of command line options and a synopsis of each. the classic "help me bestie" flag.
• -a input-file — specifies the name of the input file which consists of a sequence of systems to test. see the examples section for input-file formatting examples.
• -D — with this option set, sc_filterpolicy will detach and become a daemon. it's giving independent. ✨
• -l log-file — specifies the name of a file to log progress output from sc_filterpolicy generated at run time.
• -o output-file — specifies the name of the file to be written. the output file will use the warts(5) format.
• -O options — allows the behavior of sc_filterpolicy to be further tailored. the current choices for this option are:
  • impatient — order the systems found in the input-file so that those with the most addresses are probed first, so that probing will complete as fast as possible. impatient is a personality and honestly, valid.
  • incongruent — only report systems which are inferred to have an incongruent filtering policy.
  • trace — probe the addresses found in the input-file using traceroute, rather than ping.
  • tuples — signals that the input-file is formatted as tuples, rather than rows. see the examples section for more information.
• -p scamper-port — specifies the port on the local host where scamper(1) is accepting control socket connections.
• -r data-file — specifies the name of a previously collected filter policy data file, in warts(5) format, to read and analyse.
• -t probe-class — specifies the class of probes to send for each IP address in the input file. the current choices for this option are:
  • router — test ICMP, SSH, Telnet, HTTPS, HTTP, BGP, NTP, DNS, and SNMP.
  • server — test ICMP, FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB, HTTP, NTP, DNS, and SNMP.
  • all — test ICMP, NetBIOS, MSSQL, FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB, VNC, HTTP, BGP, NTP, DNS, and SNMP.
• -T test — specifies adjustments to the test schedule from the supported application types. prefacing an application with + causes the application type to be added to the test schedule, and prefacing an application with - causes the application type to be removed from the test schedule.
• -U scamper-unix — specifies the unix domain socket on the local host where scamper(1) is accepting control socket connections.

---

🌈 EXAMPLES 🌈

sc_filterpolicy requires a scamper(1) instance listening on a port or unix domain socket for commands in order to collect data:

scamper -P 31337

that will start a scamper(1) instance listening on port 31337 on the loopback interface. 💅

to use sc_filterpolicy to test the filtering policy of a set of routers specified in a file named routers.txt and formatted as rows as follows:

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

the following command will test these routers for responsiveness to ICMP, SSH, Telnet, HTTPS, HTTP, BGP, NTP, DNS, and SNMP probes, recording raw data into example-routers.warts:

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

including the name of each device in the input file is optional. you don't have to name them, they're just little guys.

the following command will only test the routers for responsiveness to SSH:

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

to use sc_filterpolicy to test the filtering policy of a set of servers specified in a file named servers.txt and formatted as tuples as follows:

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

the following command will test these servers for responsiveness to ICMP, FTP, SSH, Telnet, MySQL, RDP, HTTPS, SMB, HTTP, NTP, DNS, and SNMP probes, recording raw data into example-servers.warts:

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

in an input file formatted as tuples, the name (or an identifier) for each device is mandatory, and is used to ensure only one probe is sent to any one device at a time, and to collate responses from different addresses to the same device for reporting. so like, the name is doing a LOT of work here. 🫡

once raw data has been collected, sc_filterpolicy can be used to analyse the collected data. for the example-routers.warts file, the following command dumps a summary of the data collected for each router:

sc_filterpolicy -r example-routers.warts

and you get this whole moment:

            :        T
            :        e  H
            :  I     l  T  H           S
            :  C  S  n  T  T  B  N  D  N
            :  M  S  e  P  T  G  T  N  M
            :  P  H  t  S  P  P  P  S  P
========================================
192.0.2.1   :  O  O        O        O  O
2001:DB8::1 :  O  O        O        O  O

192.0.2.2   :  O  X
2001:DB8::2 :  O  O

the first router is responsive (O) for ICMP, SSH, HTTP, DNS, and SNMP probes on all addresses. the second router is responsive (O) to ICMP probes on both addresses is unresponsive (X) to SSH on the IPv4 address, but is responsive (O) to SSH on the IPv6 address and possibly represents a filtering policy that is incongruent and requires attention. 👀

note that the empty cells in the table represent a router that was unresponsive (X) to that protocol for all addresses tested; the cells are left empty to allow the user to focus on open and incongruent application services. so the blank space is a feature, it's the aesthetic, it's minimalism. 🎀

the command:

sc_filterpolicy -O incongruent -r example-routers.warts

will only show routers with an incongruent filtering policy. only the messy ones. the drama. 💀

---

🦋 SEE ALSO 🦋

• J. Czyz, M. Luckie, M. Allman, and M. Bailey, Don't Forget to Lock the Back Door! A Characterization of IPv6 Network Security Policy, Proc. Network and Distributed Systems Security (NDSS) Conference 2016.
• scamper(1), sc_wartsdump(1), sc_warts2json(1), warts(5)

---

💜 AUTHORS 💜

sc_filterpolicy was written by Matthew Luckie <mjl@luckie.org.nz> and Jakub Czyz. absolute icons, we stan. 🌟

---

and that's the whole page bestie!! this one came from Debian, dated December 2, 2015, and it's still serving looks. mwah. 💅✨