Names to disallow #43

Closed
kentonv opened this Issue Mar 17, 2015 · 6 comments

Projects

None yet

3 participants

@kentonv
Member
kentonv commented Mar 17, 2015

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
  • mail
  • email
  • 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)
@paulproteus
Member

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.

@kentonv
Member
kentonv commented Mar 17, 2015

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.

@paulproteus
Member

+1, seems reasonable to me.

@kentonv
Member
kentonv commented Mar 17, 2015

Apparently I just pinged @name. Sorry @name. (Looks like an inactive account anyhow.)

@kentonv
Member
kentonv commented Mar 18, 2015

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.

@geofft
geofft commented Mar 24, 2015

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.

@paulproteus paulproteus added this to the 1.0 milestone Mar 26, 2015
@paulproteus paulproteus added a commit that referenced this issue Mar 27, 2015
@paulproteus paulproteus Add test for blocking certain names
Refs #43
a358f94
@paulproteus paulproteus added a commit that closed this issue Mar 27, 2015
@paulproteus paulproteus Block dangerous hostnames
Close #43
4e5fd20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment