Access Control Lists and Rule Order

An access control list, or ACL, is what a firewall reads to decide what gets through. It is a numbered set of rules. Each rule says which way the traffic is going, what to look for in it, and what to do when it's found. The firewall starts at the top and works down, and the first rule that fits the traffic is the one it obeys. Everything below that rule is never read for that traffic.

Three young men, Josiah White, Dalton Norman, and Paras Jha, a Rutgers student, wrote a program in 2016 that they called Mirai. It searched the internet for devices such as security cameras, video recorders, and home routers that would accept a remote login through Telnet, an old service that sends everything, passwords included, unencrypted. Then it tried a short list of the usernames and passwords the devices had shipped with, which their owners had never changed, and on some devices could not change. Every device it got into joined a botnet that the three could order to flood any target with traffic.

The program's code holds 62 username and password pairs. Here are the first five:

root    xc3511
root    vizxv
root    admin
admin   admin
root    888888

They used it mostly against Minecraft servers, knocking rivals offline in a business where Jha also sold protection from such attacks. Once the code was posted online, in September 2016, others built botnets of their own from it. On October 21, Mirai botnets flooded Dyn, a company whose DNS servers answered lookups for many large websites, and Twitter, Netflix, Reddit, and others were hard to reach for hours across much of the United States. By late November, Mirai botnets together held about 600,000 devices.

Many of those devices could be reached straight from the internet. Some had public addresses of their own, some sat behind a router set, often automatically, to pass connections through, and some were routers themselves. For any of them, a rule at the network's edge denying inbound connections to TCP ports 23 and 2323, the two ports Mirai tried, would have kept it from ever reaching a login prompt.

The city bus agency's dispatch segment starts from a requirement written in plain words: buses may send their location reports and drivers' text messages to the dispatch server, dispatchers' consoles may connect to it, and nothing else may come in. The network administrator turns that into a rule list. The dispatch server is 10.50.1.10, the buses use 10.60.0.0/16, every address that begins 10.60, and the consoles sit in 10.50.2.0/24, every address that begins 10.50.2.

#  action  from                   to          proto port  carries
1  allow   buses 10.60.0.0/16     10.50.1.10  UDP   5005  location reports
2  allow   consoles 10.50.2.0/24  10.50.1.10  TCP   8800  dispatcher console
3  allow   buses 10.60.0.0/16     10.50.1.10  TCP   6500  driver messages
4  deny    anything               anything    any   any   everything else

All four lines apply to traffic coming into the dispatch segment. Each one matches on where the traffic comes from, its protocol, and the port it's headed for.

A bus at 10.60.14.7 sends a location report to UDP port 5005 on the server. Line 1 fits it, so the firewall passes it and reads no further. A laptop in the office, at 10.30.8.21, tries to connect to the server's console port, 8800. Lines 1, 2, and 3 don't fit, since the laptop isn't a bus or a console, so the deny line is the one that fits, and the connection is refused.

In the spring, the garage gets a diagnostic laptop, 10.40.3.25, that has to read each bus's fault codes from the dispatch server on TCP port 8800. The administrator writes its line.

allow   garage 10.40.3.25      10.50.1.10  TCP   8800  fault codes

Where in the list does the new line have to go, and why?

The bottom of the list looks like the place for something new, but the deny line fits every packet that reaches it, so a line written under it would never be read. The new line can go anywhere above the deny line. The administrator makes the garage line number 4 and the deny line number 5, and the list still ends on its catch-all.

San Francisco's transit agency, which runs the Muni buses and trains, faces the same split as the bus agency here. Ransomware locked about 900 of its office computers over Thanksgiving weekend in 2016, and screens in some stations showed the attacker's message. The agency opened the fare gates as a precaution, so riders traveled free, and it didn't pay the ransom of 100 bitcoin, about 73,000 dollars at the time. Trains and buses kept running; the agency said transit service was never affected. Keeping trouble in the offices away from the systems that run vehicles is the job of rule lists like the dispatch segment's, whose last line refused the office laptop.