@sitelock musing

[shawnw]

Talk on <Hardcode> today about blocking TOR sites made me think about another of my hundreds of back burner ideas.

Right now, sitelock records are stored in a text file (access.cnf), and loaded into a linked list. It's read at startup and after a SIGHUP (Along with a bunch of other stuff), and written every time a @sitelock is run. IP addresses and resolved hostnames are matched using wildcard globs or regular expressions.

So, a few ideas:

• Also support blocking IP addresses by CIDR masks (192.168.0.0/16 etc.). I know MUX does this and I think Rhost too? We're kind of the odd one out here.
• Load sitelock rules into an on-disk sqlite database instead of keeping them in memory. This allows external programs to manipulate the list of blocked sites without having to do a SIGHUP to get changes synced with the mush - for example, a cronjob that periodically updates a list of TOR sites. They just have to insert or delete rows from a table.

[shawnw]

Another idea: change the access.cnf flatfile format from the current format to JSON (Continue to support reading the old one for backward compatibility) for easier loading and making it easier to support future extensions and additions.

Instead of lines like

*.foo.com -2 !create !guest # Only spammers come from here

an array of objects like

{"pattern": "*.foo.com", "type": "wildcard", "dbref": -2,
  "create": false, "guest": false, "connect": true,
  "comment": "Only spammers come from here"}

[HarryCordewener]

I'd rather see it as an in-game object/attribute tree model rather than changing the format on a file.

[shawnw]

Another note so I don't forget. If/when adding ip masks, make ipv4 mapped ipv6 addresses like ::ffff:1.2.3.4 check both IPv4 and IPv6 masks.

Maybe do this with wildcard patterns too if it looks like a ipv4 address in the pattern and the IP being matched against is mapped.

[captdeaf]

@sitelock actually works mostly with strings and patterns. That's why I overloaded its usage for help http sitelock. But it doesn't deal well with spaces (hence the need for `s in the sitelock pattern).

It'd be nice to have multiple key:vals to sitelock, rather than treating it as one glob. @sitelock type:http path:/ ip:127.0.0.1 ... etc.

And for non-http uses, adding multiple key:val types makes it expandable, e.g: ip:, ip6:, hostname:*.comcast.net, isp:comcast (using a free ip to isp db), limit:5/1m (5 per minute), etc.

For backwards compat, only use key:val type with /new or some better-named switch?

[shawnw]

I'm not proposing doing away with pattern matching rules, just adding other types of matches, if that wasn't clear.

[captdeaf]

Yeah I'm doing the same, just want it to be explicit pattern instead of "Try all the patterns we have against this IP. And against this hostname. And ..."

[shawnw]

Being able to mark a pattern as just hostname, or just ip address, (Or just http request) is another enhancement that's easy to do. Adding it to the list.

[captdeaf]

well to be clear, adding multiple patterns to a single rule would be ideal, especially for http.

e.g: A single rule for path:/chat/* ip:127.0.0.1 method:POST would be a clean way to limit POSTs to /chat/*. (e.g: if GET is public for @chan/recall equivalent, then POST could allow system scripts to chat on channels, for e.g: updates, downage, etc.)