Posted on

Yandex Cloud Services

Yandex is likely the 4th most important Search-based provider, with Google, Baidu, and Bing being ahead in terms of overall traffic. Yandex is certainly like Google and Bing (and Amazon) in terms of offering a combination of email and file storage along with file sharing and file editing tools for organizations. Essentially it is a combination of Google, Paypal, and

Yandex Disk

Disk is file storage akin more to Google Drive + Google Apps, than simply a file storage like Dropbox. They have web-based applications for editing documents, spreadsheets, and presentations (provided by Microsoft), and have a viewer that works for text files. They also include the Aviary image editor, which is convenient.

Yandex Disk over Webdav

Yandex Disk can be accessed via Webdav, which makes it especially lightweight on lightweight machines such as Chromebooks, intel Compute sticks, and for accessing files such as KeePass files using KSync on mobile devices. While integration isn't ubiquitous as it is with Dropbox and Google Drive, the Yandex Disk mobile app has a lot of functionality itself.

Storage Space on Yandex Mail / Yandex Disk

10gb are free, with another possible 10gb for referring friends. Monthly costs for additional storage are $1 USD/10gb, $2 USD/100gb, and $10 USD/1tb, with 17% discount on 1 year (2 months free). This is about the same as Google Drive. All Yandex Mail users get 10gb of Yandex Disk. Saving attachments saves them into Yandex Disk. From what I can tell there is greater integration of Mail and Disk than with Gmail and Google Drive.

Screenshots and Photos on Yandex Disk

The Yandex Disk apps for desktops and mobile have nice support for capturing and uploading screenshots and photos, as well as image editing tools.

Yandex Hosted DNS

Yandex also offers hosted DNS for free with a dns editor available after delegating any domains.

Yandex Domains

Yandex allows Mail accounts to register Domains, and then be able to manage mailboxes (up to 1,000) for that domain, as well as unlimited domains and unlimited domain aliases. This is quite mindboggling, when compared with cheap ass Google.

Yandex Mail SPF, DKIM, OAuth2

Yandex supports SPF and DKIM. Check SPF/DKIM with this testing tool. Yandex also supports Oauth2 for use with SMTP, and IMAP, and other services, including Yandex Disk. > Currently I am having trouble getting the Oauth2 to work with Postman SMTP. Hopefully that will get worked out. Certs are needed to not have a mailbox compromised based on username/password being in the database.

Yandex DNS Records

One can delegate zones to Yandex DNS and then manage records through a web-based DNS editor. Or, one can go through a process of authorization and record entries as follows: - CNAME record (unique) set to: mail.yandex.com. - MX record: mx.yandex.net. (10) - TXT record (Yandex DKIM): name=mail._domainkey value="v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2+xOv5+WXFROygWIKk1dSLXOYcoJQqL1kGHYY3ymVNYXk+gTlVwgW7o+M2a2Ci8BmVxZjW+TPdu0qnhY626HJ2SDNszznKhDgZSB4xvImyGZBbTmtgA9wDlZam9OaX+p5eN3YB0BCT0iUQqLNAGSZrGOd9gpES0Xuoswo7Qy5OwIDAQAB" - TXT record (Yandex SPF): value=“v=spf1 redirect=_spf.yandex.net”. - Alternately if additional IPs are needed to be validated, use: "v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 include:_spf.yandex.net ~all" (replace 1.2.3.4 and 5.6.7.8 with correct IP addresses

Yandex Money

Yandex is basically Google + Paypal + Uber, so it is a much bigger deal in its markets, though it is perhaps a tenth the

Posted on

GSuite DNS Records

GSuite is the latest term Google is using for what used to be called Google Apps for Domains. Google Cloud is now a provider of GSuite (along with many other services). GSuite is akin to similar offerings by Microsoft, Yandex, and more anemically, Amazon Workmail/Workdocs, and Apple.

CNAME Records

calendar = ghs.google.com.
drive = ghs.google.com.
mail = ghs.google.com.

MX Records

aspmx.l.google.com.         [1]
alt1.aspmx.l.google.com.    [5]
alt2.aspmx.l.google.com.    [5]

SPF, DKIM, DMARC Records

SPF Record

GSuite SPF record is

v=spf1 include:_spf.google.com ~all

If there is a need to add additional IP addresses for the domain, then as follows:

"v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 include:_spf.google.com ~all"

Note: Change 1.2.3.4 and 5.6.7.8 to appropriate IP addresses, as needed

DKIM Record

For GSuite, a given domain's DKIM record can be generated. Then the record added to DNS. And then, enable DKIM on the domain in the GSuite admin. DKIM looks like:

google._domainkey = "v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCAAzcVQ93IuUdrFWizejuaC4b+zTeKj48R
A7y+PzdRZgHb0abfUUvZW8KR7oADkmxeGp/B
W6ZhJz8ytlZ2JJ+ubBB7o4Lb5QQIIIpR00Tt
fZa3WORctXRhU4wyIR7CqdbaPKK7+xSJK8BQ
/mzzJ22a59FVEgjzVdIquFN+N515fwIDAQAB"

Note some DNS does not take 2048 bit keys so have to go with 1024 bit.

DMARC Record

DMARC basically sets a policy based on verification of SPF and DKIM records (or their failure). They look something like:

_dmarc = "v=DMARC1; p=none; rua=mailto:postmaster@jeffmcneill.com; adkim=r; aspf=r"

Note the p means policy and none basically means reporting only (work out the bugs first). adkim and aspf are set to r for relaxed so subdomains will pass without explicitly declaring them.

Posted on

Syncthing <= Dropbox & GDrive

Syncthing

Google Drive (GDrive) and other cloud storage alternatives such as Dropbox and Microsoft Ondrive all have the serious drawback of keeping one's information in a third party cloud repository. Privacy and security are generally compromised this way, even when paying for storage (as opposed to having an advertising model, which is worse in many ways).

Continue reading Syncthing <= Dropbox & GDrive

Posted on

Nginx and Letsencrypt SSL on Debian

It is a good idea to get PHP and MariaDB on Debian set up before Nginx (except the PhpMyAdmin which can come after).


Related Artices in Debian Services and Applications - Debian on AWS Lightsail - OpenVPN on Debian + UFW Firewall - Nginx and Letsencrypt on Debian - PHP & MariaDB on Debian

- Grav CMS on Debian

Install Nginx

Edit the /etc/apt/sources.list to add the Nginx repostitory

nano /etc/apt/sources.list

Add the following repository (currently for Debian 9/Stretch)

deb http://nginx.org/packages/mainline/debian/ stretch nginx

Download and install the key for the repository

wget https://nginx.org/keys/nginx_signing.key
sudo apt-key add nginx_signing.key

Remove nginx-common, update apt and install nginx

sudo apt-get remove -y nginx-common
sudo apt-get update -y
sudo apt-get install -y nginx

Systemd / Nginx Race Condition

There is a known race condition, with a workaround as follows:

mkdir /etc/systemd/system/nginx.service.d
printf "[Service]\nExecStartPost=/bin/sleep 0.1\n" &gt; /etc/systemd/system/nginx.service.d/override.conf
systemctl daemon-reload

Edit /etc/nginx/sites-available/default

Note: these edits are not comprehensive, just to get certbot working. Uncomment the following lines:

listen 443 ssl default_server;
listen [::]:443 ssl default_server;
...
location / {
...
try_files $uri $uri/ =404;
}

Where it says server_name _; change _ to an appropriate fqdn that has an appropriate A record. Save and restart the nginx:

service nginx restart

Letsencrypt Certbot

sudo apt-get update
sudo apt-get install -y python-certbot-nginx certbot -t stretch-backports

Run letsencrypt (automatic)

certbot

Test access from a browser.

HSTS Preload

Browsers have a list of servers that require https/ssl. Add sites to the list. Two things are required: 80 to 443 redirect, and an hsts header. For the redirect, add this server configuration:

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name _;
        return 301 https://$host$request_uri;
}

For the HSTS header, this needs to be added to each server. Can simply be added after the listen 443 ssl; line:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Nginx Info

Nginx has become the standard for much of the web, for the basic standard reason it is not creaky old (though of course still lovable) Apache. However, before we get too far ahead of ourselves, let's recall exactly what we need to know about Nginx in order for it to work as well as Apache:

  • Installation
  • Configuration files
  • Support of SSL / LetsEncrypt
  • SFTP/SCP access to file system (and file rights + ownership)
  • Multiple virtual servers / directories
  • Mimetypes
  • Support for PHP
  • Threading
  • .htaccess and related

Nginx and Related Files and Directories

Standard or default files and directories as follows:

  • /etc/nginx - application directory
  • /etc/nginx/nginx.conf - main configuration file
  • /usr/share/nginx/html - default website root directory - noted as html in nginx.conf
  • /var/log/nginx/error.log - error log
  • /var/log/nginx/access.log - access log
  • /etc/nginx/mime.types - mime types
  • /etc/php.ini - php configuration file

Nginx / PHP-FPM Security Issues

There are significant issues with PHP-FPM in terms of keeping site caching partitioned when using multiple websites/virtual sites. Opcache should be turned off and individual users should be in charge of a different php-fpm process for each site. How to do this is not listed here (just yet).

Posted on

DNS Records and Services

First, there are two kinds of DNS records: those for client look, and those for a server.

Client Lookup - DNS Resolvers

I don't trust Google DNS, though for a while it was the go to DNS, and easy to remember at 4.4.8.8 8.8.4.4 and 8.8.8.8.

For privacy, for me, there are two options, with the first being just better:

If one wants some security (as a service), then Quad9 is worth a look.

It is possible to run one's own resolver, though it takes a bit of configuring and resolvers are seen as an attack vector for various bad actors.

DNS Services

There are several DNS services to choose from. Dyn and related companies is the worst. Free DNS services such as afraid.org and he.net are unreliable, or simply not reliably fast. It makes the most sense to go with a top-rated DNS service (highly available and fast resolve times), and pay for this service (though less is more when it comes to expenses).

As with resolvers, basic DNS services can be run on one's own server, not including the Registrar functionality of placing the nameservers in the root domain servers of the Internet. Again, it takes a bit of configuring so that one has functionality, privacy, security, and is not seen as a target.

DNS Records

NS Records

There are several records to worry about. The first are nameservers, which are put into the registrar database. This can be as few as two or as many as six (possibly more).

A Records

Depending on the DNS Server, these can have wildcards or not. Generally there are at least three A records to have:

  • Root domain
  • www subdomain
  • * wildcard

For certain services, it is required to have a www. and also people mistype this, so it is best to have it as a domain, to have it on the SSL certificate, and to have a reroute from www. to the root domain.

CNAME Records

Usually only Bing Webmaster Tools requires a CNAME record. Otherwise these are generally worthless.

MX Records

These are for the mailserver. Usually a few are needed, one plus two backups. Gsuite has five records, but that is overkill. The top three make the most sense. Also, there are priority numbers, e.g, 1, 5, 10 to govern the round robbin-style resolving.

  • 1, aspmx.l.google.com.
  • 5, alt1.aspmx.l.google.com.
  • 5, alt2.aspmx.l.google.com.

TXT Records

TXT records are the go to place for every third party to put their info. Several examples of TXT Records include:

  • Yandex Webmaster Tools validation
  • Google Webmaster Tools/Analytics/GSuite/etc. validation
  • _acme-challenge records for DNS-based authentication for LetsEncrypt

PTR Records

PTR records are essentially a reverse so that an IP address is associated with a host.domain.tld. This is key for sending email.

DKIM, SPF, DMARC

These are all records for email security, at various levels. DKIM and DMARC are TXT records, and SPF can be TXT or specific SPF records, depending on the DNS service provider.

SPF Records

SPF looks like:

host.domain.com / "v=spf1 include:_spf.google.com ~all"

SPF are one of the earliest and easiest email records to set up for security, and specifically states which hosts can send email for the domain.

CAA Records

These records help tell SSL Cert providers which of those providers can generate a cert for the domain records. Each host needs two records:

  • Name (host), Type: iodef, Value: "mailto:address@domain.com"
  • Name (host), Type: issue, Value: "letsencrypt.org"
Posted on

Gsuite Free Domain Alias Mailboxes

Google likes to remove functionality on free products to induce upselling. This is a common tactic in many software/SAS models. However, the cost of adopting Gsuite is very high, relative to free. Essentially a 5-10 pack of mailboxes with $5/month for the least expensive Gsuite paid option. That's $300-$600/year. What is sadly missing is a less expensive option.

I don't mind paying money for valuable services, but an individual consumer who really only has family mailbox accounts, this is ridiculous pricing. As someone with multiple domains, here is how to get around this issue.

No Duplicate Mailboxes

The main problem comes when one wants to have mailboxes that have the same username, e.g., info@primary-domain.com and info@secondary-domain.com. Because added-on domains are always only aliases, only the primary domain is possible (e.g., info@primary-domain.com), and all subsequent domains with the same info@ are aliases of the underlying primary domain.

Steps to Support Duplicate Mailboxes

The work-around is as follows:

  • Create a unique mailbox such as secondary-domain@primary-domain.com.
  • After some amount of time (an hour at the most) the address info@secondary-domain.com will be added (provided info@primary-domain.com was already a primary or secondary mailbox address).
  • Log into secondary-domain@primary-domain.com and add info@secondary-domain.com as a second account. This will generate an email which will be sent to info@primary-domain.com. Verify access with the verification code. Set that info@secondary-domain.com as the default and configure the mailbox to always send email from that address.
  • Log into info@primary-domain.com and add a forwarding address of secondary-domain@primary-domain.com. This will generate a verification code emailed to secondary-domain@primary-domain.com. Verify this.
  • Next, create a new filter for incoming mail addressed to: info@secondary-domain.com and have it forward email to secondary-domain@primary-domain.com and also delete the email locally.

The steps above will properly route and address mail so that the new mailbox will function properly using the normally disallowed duplicate username in the free version of Gsuite.

Endgame with Gsuite

Frankly I dislike Google and Gsuite. My use is only a holding action to not have to deal with email migration. The vast majority of time I no longer use Gsuite other than calendar and email, and also the use of those accounts for YouTube and Google Business Listings, and also the Analytics/Google Ads suite. Obviously there needs to be Google accounts, but they can be independent Gmail accounts rather than Gsuite accounts. At some point ( hopefully in 2019), I'll migrate off and do self-hosting on mail and calendar, and therefore move YouTube, Business, Analytics over to Gmail accounts.

Posted on

Widespread Hacking

> This is as true today than it was more than five years ago when first posted. Due to the ongoing hacking of accounts and passwords on popular web services, it is a good time to consider the following suggested security practices. If you feel you do not have the time to deal with this, think again...

Suggested Security Practices

- Have one unique password per site/account - Have a special account not normally used, which is for administration of accounts (again, per site/account) - Generate and manage passwords with an encrypted password management tool, e.g., KeePass and others of its ilk. - Keep backup of the encrypted password management tool in the cloud (some kind of cloud-based backup). There are many options for cloud storage, and we ourselves are on our third cloud provider, with likely a fourth on the horizon. First it was Dropbox, then Google Drive, and now the highly functional Yandex Disk, with an eventual migration to Amazon WorkMail and WorkDocs, once there is functional parity, later in 2017 or 2018. - Encrypt files/drives which contain confidential information, so that in the event of intrusion, the files/drives will not be accessible, using strong encryption, e.g., VeraCrypt - Get in the habit of deleting email that has confidential information, such as passwords. - Force the use of SLL for all website browsing, when possible, especially for email and other sites with sensitive information.