security.txt files

Similar to robots.txt and humans.txt is a recent addition of a security.txt file. This is currently a draft proposal to provide a standardized way to define security policies for researchers. This is useful for bug bounty and disclosure programs. Government agencies were tasked to add these back in 2019, but COVID-19 likely delayed implementation and rollout.

This is usually applied in the root of a website at /.well-known/security.txt, but can also be immediately in the root at /security.txt. Personally, I put mine in /.well-known/ and put a redirect at the root to simplify maintenance.

For additional security, you can optionally sign the policy with PGP.

Details:

I did some searching around the web and found some examples (linked below):

File in the root path:

File in the preferred /.well-known path:

Some PGP signed examples:

Questionable, though as the files are meant to be read by humans, this would meet the most simple use case:

ads.txt file

There are many files that crawlers expect to find in well-known locations on websites, one such file is ads.txt. While you might not have paid advertisements, crawlers may still look for a copy of this file leading to HTTP 404 errors in your logs. To prevent the error and show that you should have no advertisements leading there you can add the file with placeholder values as follows:

In the root of your website, create a new file with the name ads.txt.

#ads.txt - no DIRECT or RESELLER
www.example.com, placeholder, DIRECT, placeholder 
# NONE

NOTE: If you ever do use an advertiser, they will generally inform you as to changes to make to this file.

REFERENCES:

Domain-based Message Authentication, Reporting & Conformance (DMARC) Email

DMARC was published in 2012 to build upon the SPF and DKIM email conventions for authorizing senders. It allows specification of policies and provides for reporting of actions performed under those policies.

Assistant:
http://www.kitterman.com/dmarc/assistant.html

DNS Entry Resembles:

_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=0; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; sp=none

Simple verification…. send an email to this address and you will receive a response with your SPF, DKIM and DMARC compliance status:
mailto:[email protected]

REFERENCES:

DomainKeys Identified Mail (DKIM) Email

DomainKeys (originally from Yahoo!) and Cisco, and later as an industry collaboration, is a means for and organization to claim responsibility for sending a message, in a way that can be validated by a recipient. As a result, emails are “signed” by the outgoing SMTP server and can be verified against a DNS record. Depending upon the receiver, unsigned emails MAY be treated or marked as SPAM as they could be forgeries.

The below instructions assume Ubuntu (Debian) and Postfix, but could likely be modified for other platforms.

  • Install OpenDKIM:
    sudo apt-get install opendkim opendkim-tools
  • Setup initial configuration:

    sudo vi /etc/opendkim.conf

    ADD:
    Domain example.com
    KeyFile /etc/postfix/dkim.key
    Selector dkim
    SOCKET inet:[email protected]
    PidFile /var/run/opendkim/opendkim.pid
    #Canonicalization relaxed/relaxed
    ExternalIgnoreList file:/etc/opendkim/TrustedHostList
    InternalHosts file:/etc/opendkim/TrustedHostList
    LogWhy yes
  • Add trusted hosts… (and folder path, if needed)

    sudo mkdir /etc/opendkim


    sudo vi /etc/opendkim/TrustedHostList

    ADD:

    # External Hosts that OpenDKIM will Trust (add any appropriate values)
    localhost
    127.0.0.1
    10.1.10.1
  • sudo vi /etc/default/opendkim
    ADD:

    SOCKET="inet:[email protected]"
  • sudo vi /etc/postfix/main.cf
    ADD:

    # DKIM
    # --------------------------------------
    milter_default_action = accept
    milter_protocol = 2
    smtpd_milters = inet:127.0.0.1:8891
    non_smtpd_milters = inet:127.0.0.1:8891
  • Take a look around the following file, you may need it later:
    sudo vi /etc/postfix/master.cf
  • Generate your keys:

    opendkim-genkey -t -s dkim -d example.com

    NOTE: this creates dkim.private & dkim.txt, you “might” want to make backups of them 🙂

  • Change permissions on the file:

    sudo chown opendkim:opendkim dkim.private
  • Copy to the postfix folder:

    sudo cp dkim.private /etc/postfix/dkim.key
  • NOTE: I initially had a problem with dkim refusing connections, this MIGHT be needed.

    sudo adduser postfix opendkim
  • Start things back up together:

    sudo service opendkim start
    sudo service postfix restart
  • sudo vi dkim.txt
    (copy contents, remove t=y; as it indicates test mode)
    dkim._domainkey IN TXT ( "v=DKIM1; k=rsa; p=xxxxxxxxx" ) ;

  • Add DNS for DomainKey:

    _domainkey.example.com TXT o=~
  • Add DNS for DKIM:

    dkim._domainkey.example.com TXT v=DKIM1; k=rsa; p=xxxxxxxxx
  • NOTE: you will likely need to wait a few hours for your DNS entries to propagate.

  • Simple verification…. send an email to this address and you will receive a response with your SPF, DKIM and DMARC compliance status:
    mailto:[email protected]

REFERENCES:

Sender Policy Framework (SPF) Email

This is a simple mechanism, using DNS to certify that email from your domain comes from authorized servers. This is accomplished by adding a DNS record to identify the servers from which you send legitimate email. Emails sent from other servers MAY then be assumed as forged (SPAM) and blocked by the receiving email server.

NOTE: This can be easily spoofed, as such it should be a portion of your email security strategy, look into DKIM and DMARC too!

One thing that I initially did not understand… if you are supporting IPv6 and IPv4, you should merge your records onto a single DNS TXT entry:


example.com TXT v=spf1 a mx ip4:xxx.xxx.xxx.xxx ip6:xxxx:x:xxx:xxxx:xxx:xxxx:xxxx:xxx -all

REFERENCES: