Names to disallow
Closed this issue · 6 comments
There are a lot of names we should probably disallow either because they have reserved meanings or because they pose an unusual phishing risk.
well-known hostnames:
- www
- smtp
- mx
- ns[0-9]
- ftp
- (maybe just disallow all names less than 6 chars?)
"admin"-ish usernames (phishing risk):
- root
- admin
- administrator
- owner
- sys
- system
- domainadmin
- domainadministrator
rfc2142 reserved email addresses (in case we ever support receiving e-mail as user@sandcats.io):
- hostmaster
- postmaster
- usenet
- news
- webmaster
- www
- uucp
- ftp
- abuse
- noc
- security
- info
- marketing
- sales
- support
Addresses that some SSL CAs will use to verify ownership (bold = non-repeat, italic = repeat listed earlier) (I swear I am not making these up):
- ssladmin
- ssladministrator
- sslwebmaster
- sysadmin
- is
- it
- mis
- hostmaster
- postmaster
- webmaster
- root
- admin
- administrator
- info
other commonly-used email addresses:
- noreply
- no-reply
- community
- mailerdaemon
- mailer-daemon
- nobody
things specific to us (phishing risk):
- sandcat
- sandcats
- sandstorm
- blackrock
- capnproto
- capnp
- garply
- (sandstorm employee first names and usernames)
For hostnames -- these are great ideas for things to block. Thanks; I was planning to get to this, just wasn't sure what to specifically block.
For email addresses -- we'll be letting individual hosts (e.g. asheesh.sandcats.io receive mail, since they'll hopefully have port 25 (SMTP) inbound open to them). Given that, I don't understand the purpose of the list of email addresses here. We could block the use of these email address names as hostnames, but that seems odd to me.
I think someday we may want people to be able to use name@sandcats.io in addition to *@name.sandcats.io. Maybe I'm wrong and we'll never do that, but I don't think it hurts to block these things just in case.
+1, seems reasonable to me.
Updated with what I hope (but have no reason to believe) is a complete list of addresses used to verify ownership by various SSL CAs.
Block wpad, used for proxy autodiscovery in IE and several other browsers. While it's unlikely that someone will stuff a general-purpose web browser into a Sandstorm grain, it's not impossible (think Selenium), and you don't want it to fetch proxy autoconfig from whoever got wpad.sandcats.io.
Block isatap, used for IPv6 tunnel autodiscovery, for similar reasons, even though it's even more unlikely someone will stuff an IPv6 stack into a grain.
Block autoconfig, which is used in Thunderbird autoconfig if you try to set up sandcats.io email. While you're at it, if you do intend to support name@sandcats.io email, reserve imap, pop, and pop3 as well as smtp.
Probably also worth blocking localhost, localdomain, and broadcasthost, as well as _tcp and _udp (if you allow underscores) so you don't have weird things happen with SRV records.
The CAs are locking down what they let people use for domain validation; there's currently a thread on mozilla.dev.security.policy on the subject. Compliant CAs aren't allowed to use anything other than administrator, admin, webmaster, hostmaster, or postmaster these days. But no harm a better-safe-than-sorry policy for those names.