Google Chrome browse is not using my host DNS settings.

Environment –
Operating System : CentOS release 6.8
Google Chrome: Version 55.0.2883.87 (64-bit)

I have an Intranet DNS server with internal domain name. The domain name is resolved internally by my DNS server to an internal private IP address. With Firefox I could always visit my internal site without issues, but recently I installed Chrome browser into my CentOS desktop and when I tried to visit my internal site, it was directing me to an Internet site which I don’t own. Apparently Google Chrome was ignoring my dns setting and using its own name servers.

My first attempt – flush DNS on Chrome (failed)
I went to the DNS configuration for chrome and cleared host cache. The dns settings clearly showed my ‘nameservers’ as the 192.168.1.1 (my internal name servers) and yet Chrome was not using it. Even after cleaning the host cache and flushing sockets, it didn’t help.

Chrome setting to view and manage DNS settings –

chrome://net-internals/#dns

My second attempt – block IPv6 (worked)
After running tcpdump on port 53, Chrome was calling an IPv6 address 2001:4860:4860::8888 to resolve domains.

Added below lines to

 /etc/sysctl.conf 

in order to disable IPv6 temporarily for a test –

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

And executed the command

 sysctl -p 

to apply the new kernel settings. After this change and flushing dns, I was able to visit my internal site.

I am guessing the DNS IPs used by Chrome as somehow internally coded, and haven’t been able to find those settings.

References –

https://www.reddit.com/r/chrome/comments/1xj69t/chrome_ignoring_system_dns_and_using_google_dns/

https://www.howtogeek.com/197804/how-to-clear-the-google-chrome-dns-cache-on-windows/

Free SSL certificates with Let’s Encrypt certbot – tested in Ubuntu 14.04 with Apache 2.

It is nice to have a site with valid SSL certificates, your visitors will be happy when they see that green padlock. Unfortunately it generally costs time and money to setup SSL certificates. Most big businesses with buy SSL certificates from well know Certificate Authorities(CAs) such as VeriSign, Symantec or GlobalSign. If you run a personal blog though and you can still get free SSL certificates.

Benefits of certificates –

a. Search engines such as Google give preference to secure sites
b. Security reasons – encryption and extended validation.

Disadvantages –

a. Introduces latency or delay
b. Operational cost to setup/renew certificates

One of the most popular SSL certificate providers was StarCom or StarSSL, until Google recently stopped trusting the certificates issues by this CA in Google Chrome. In the blog post, Google says –‘Google has determined that two CAs, WoSign and StartCom, have not maintained the high standards expected of CAs and will no longer be trusted by Google Chrome, in accordance with our Root Certificate Policy. ‘

So what is the alternative? Once my site was blocked by Chrome with a cert warning – ERR_CERT_AUTHORITY_INVALID – I did a research on new options and I can across “Let us encrypt”. And it was way better than StartSSL as it was easy to generate and renew certificates. Every thing was automated. No more certificate creation and renewal hassle.

Here are the steps I followed to get new certificates for my site –

1. Install certbot

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-apache

2. Get SSL certificates and modify Apache configuration automagically with certbot!!

root@localhost:~# certbot --apache

Interactive session –

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):notshowingmyemail@example.com

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: Y

Here, certbot automatically detects my domains –

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: danasmera.com
2: www.danasmera.com
3: linuxfreelancer.com
4: www.linuxfreelancer.com
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):1,2,3,4

Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for danasmera.com
tls-sni-01 challenge for www.danasmera.com
tls-sni-01 challenge for linuxfreelancer.com
tls-sni-01 challenge for www.linuxfreelancer.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate for danasmera.com to VirtualHost /etc/apache2/sites-available/danasmera-ssl
Deploying Certificate for www.danasmera.com to VirtualHost /etc/apache2/sites-available/danasmera-ssl
Deploying Certificate for linuxfreelancer.com to VirtualHost /etc/apache2/sites-available/linuxfreelancer-ssl
Deploying Certificate for www.linuxfreelancer.com to VirtualHost /etc/apache2/sites-available/linuxfreelancer-ssl

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Just making sure my apache configuration is valid after certbot modified it –

root@localhost:~# apache2ctl -t
Syntax OK

certbot will create a ‘/etc/letsencrypt/live/’ directory and dump the SSL certificate, private key and cert chain in that directory –

SSLCertificateFile /etc/letsencrypt/live/danasmera.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/danasmera.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/danasmera.com/chain.pem

Certbot created a multidomain SSL certiticate for 90 days, and a renewal cron job was added to my server so that I don’t have to do manual renewals –

root@localhost:~# cat /etc/cron.d/certbot
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

References –

https://certbot.eff.org/all-instructions/#ubuntu-14-04-trusty-apache
https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html

Linux kernel – check the kernel options enabled during kernel compilation.

You might want to know whether a certain kernel option was enabled or not when your kernel was built, say if Symmetric multiprocessing (SMP) was enabled, or if KVM was compiled directly into the kernel or just as a loadable module. To answer this, you can look at the /boot/config-$(uname -r) file.

To find out if SMP is enabled in your system for instance, search for all SMP keywords in the kernel configuration –

daniel@linubuvma:~$ grep SMP /boot/config-$(uname -r)
CONFIG_X86_64_SMP=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_SMP=y
# CONFIG_X86_VSMP is not set
# CONFIG_MAXSMP is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_VIDEO_VP27SMPX=m

The ‘CONFIG_SMP=y’ setting indicates that the SMP module was compiled directly in the kernel, it is part of the monolithic kernel.

If your kernel was built with ‘CONFIG_IKCONFIG_PROC’, then the /proc/config.gz will contain the .config file the Linux kernel was compiled with.

daniel@linubuvma:~$ grep CONFIG_IKCONFIG_PROC  /boot/config-$(uname -r)
daniel@linubuvma:~$
daniel@linubuvma:~$ ls /proc/config.gz
ls: cannot access /proc/config.gz: No such file or directory

In my case, the kernel was not built with ‘CONFIG_IKCONFIG_PROC’.

How to share your terminal session with another user in real time.

Linux has a script command which is mainly used for ‘typescripting’ all output printed on terminal. Commands typed on a terminal and the resulting output can be written to a file for later retrieval.

One little known use of the script command is for sharing your terminal session with another user, this would particularly be useful for telecooperation say between a user and instructor. The instructor can lead the session by executing commands on the shell while the student would observe. Here is one way of doing this –

1. Instructor creates a named pipe using mkfifo

instructor@linubuvma:/$ mkfifo /tmp/shared-screen

instructor@linubuvma:/$ ls -al /tmp/shared-screen 
prw-rw-r-- 1 instructor instructor 0 Mar 31 00:08 /tmp/shared-screen

instructor@linubuvma:/$ script -f /tmp/shared-screen 

2. Student views the session in real time by reading the shared-screen file –

student@linubuvma:/tmp$ cat shared-screen
Script started on Fri 31 Mar 2017 12:09:42 AM EDT

As soon as the student runs the

cat shared-screen

command, the script command also gets started on the instructor’s session.

Whatever is typed on the instructor’s terminal will show up on the student’s screen and the student’s terminal will be restored as soon as the instructor exits or terminates the script session –

instructor@linubuvma:/$ free -m
             total       used       free     shared    buffers     cached
Mem:          3946       3572        374         40        288        996
-/+ buffers/cache:       2288       1658
Swap:         4092        195       3897
instructor@linubuvma:/$ exit
exit

Script done on Fri 31 Mar 2017 12:12:02 AM EDT
student@linubuvma:/tmp$

Note – the student’s screen will show the user id of the instructor at the bash prompt, as it is a replica of the instructors session. Once the instructor terminates the session, the student will get back to their original bash prompt.

References –

http://man7.org/linux/man-pages/man1/script.1.html

User administration: restricting access

1. With the chage command, an account expiration can be set. Once that date is reached, the user cannot log into the system interactively.
Let us run ‘chage’ interactively to set user’s account expiry –

[root@kauai /]# chage sshtest
Changing the aging information for sshtest
Enter the new value, or press ENTER for the default

	Minimum Password Age [0]: 
	Maximum Password Age [99999]: 
	Last Password Change (YYYY-MM-DD) [2015-11-04]: 
	Password Expiration Warning [7]: 
	Password Inactive [-1]: 
	Account Expiration Date (YYYY-MM-DD) [-1]: 2017-03-30

[root@kauai /]# chage -l sshtest
Last password change					: Nov 04, 2015
Password expires					: never
Password inactive					: never
Account expires						: Mar 30, 2017
Minimum number of days between password change		: 0
Maximum number of days between password change		: 99999
Number of days of warning before password expires	: 7

2. In addition to this, the usermod command can “lock” an account with the -L option. Say when a user is no longer with a company, the administrator may lock and expire an account with a single usermod command. The date must be given as the number of days since January 1, 1970. Setting the expiredate to 1 will immediately lock the account –

[student@serverX ~]$ sudo usermod -L -e 1 elvis

[student@serverX ~]$ sudo usermod -L elvis
[student@serverX ~]$ su - elvis
Password: elvis
su: Authentication failure

Locking the account prevents the user from authenticating with a password to the system. It is the recommended method of preventing access to an account by an employee who has left the company. If the employee returns, the account can later be unlocked with

usermod -U USERNAME

. If the account was also expired, be sure to also change the expiration date.

3. The nologin shell. Sometimes a user needs an account with a password to authenticate to a system, but does not need an interactive shell on the system.
For example, a mail server may require an account to store mail and a password for the user to authenticate with a mail client used to retrieve mail.
That user does not need to log directly into the system.

A common solution to this situation is to set the user’s login shell to /sbin/nologin. If the user attempts to log into the system directly,
the nologin “shell” will simply close the connection.

[root@serverX ~]# usermod -s /sbin/nologin student
[root@serverX ~]# su - student
Last login: Tue Feb  4 18:40:30 EST 2014 on pts/0
This account is currently not available.

References –

https://linux.die.net/man/1/chage
https://linux.die.net/man/1/chmod

How to be your own Certificate Authority(CA) with self signed certificates

This is a hands on tutorial on how you can setup your own Certificate Authority(CA) for internal network use. Once the CA certs are setup, you will generate certificate request(CSR) for your clients and sign them with your CA certs to create SSL certs for your internal network use. If you import your CA certs to your browser, you will be able to visit all internal sites using https without any browser warning, as long as the certs the your internal services are using are signed by your internal CA.

*Demo – Own CA for the home.net internal domain

1. Prepare certificate environment and default parameters to use when creating CSR –

# mkdir /etc/ssl/CA
# mkdir /etc/ssl/newcerts
# sh -c "echo '100000' > /etc/ssl/CA/serial"
# touch /etc/ssl/CA/index.txt

# cat /etc/ssl/openssl.cnf
 dir		= /etc/ssl		# Where everything is kept
 database	= $dir/CA/index.txt	# database index file.
 certificate	= $dir/certs/home_cacert.pem 	# The CA certificate
 serial		= $dir/CA/serial 		# The current serial number
 private_key	= $dir/private/home_cakey.pem  # The private key
 default_days	= 1825			# how long to certify for
 default_bits		= 2048
 countryName_default		= US
 stateOrProvinceName_default	= California
 0.organizationName_default	= Home Ltd

2. Create self signed root certificate and install the root certificate and key –

# openssl req -new -x509 -extensions v3_ca -keyout home_cakey.pem -out home_cacert.pem -days 3650
# mv home_cakey.pem /etc/ssl/private/
# mv home_cacert.pem /etc/ssl/certs/

3. Generate a CSR for the domain you want to issue a certificate –

# openssl genrsa -des3 -out home_server.key 2048
# openssl rsa -in home_server.key -out server.key.insecure
# mv server.key server.key.secure
# mv server.key.insecure server.key

4. Create the CSR now and generate a CA signed certificate –

# openssl req -new -key server.key -out server.csr
# openssl ca -in server.csr -config /etc/ssl/openssl.cnf

Directory structure after signing and issuing certificates –

# ls -l /etc/ssl/CA/
total 24
-rw-r--r-- 1 root root 444 Aug 29 18:20 index.txt
-rw-r--r-- 1 root root  21 Aug 29 18:20 index.txt.attr
-rw-r--r-- 1 root root  21 Aug 29 18:16 index.txt.attr.old
-rw-r--r-- 1 root root 328 Aug 29 18:18 index.txt.old
-rw-r--r-- 1 root root   7 Aug 29 18:20 serial
-rw-r--r-- 1 root root   7 Aug 29 18:19 serial.old

# ls -l /etc/ssl/newcerts/
total 32
-rw-r--r-- 1 root root 4612 Aug 29 16:24 100000.pem
-rw-r--r-- 1 root root 4613 Aug 29 16:51 100001.pem
-rw-r--r-- 1 root root 4574 Aug 29 17:50 100002.pem
-rw-r--r-- 1 root root 4619 Aug 29 18:20 100003.pem

# cat /etc/ssl/CA/index.txt
V	190828202443Z		100000	unknown	/C=US/ST=California/O=Home Ltd/OU=Home/CN=www.home.net/emailAddress=daniel@home.net
V	190828205127Z		100001	unknown	/C=US/ST=California/O=Home Ltd/OU=Home/CN=wiki.home.net/emailAddress=daniel@home.net
V	190828215006Z		100002	unknown	/C=US/ST=California/O=Home Ltd/CN=home.net/emailAddress=daniel@home.net
V	190828222038Z		100003	unknown	/C=US/ST=California/O=Home Ltd/OU=Home/CN=homevm.home.net/emailAddress=daniel@home.net

# cat /etc/ssl/CA/serial
10411A

Now that you have your certificate, in this example /etc/ssl/certs/home_cacert.pem, you can import it to your web client such as a web browser, LDAP client etc.

References –

https://help.ubuntu.com/12.04/serverguide/certificates-and-security.html