How to check the routing table Linux (Ubuntu | Debian | Centos) CLI

This is a quick reference guide on how to check the routing table on Linux Based Operating Systems.

1. route -n

[root@vps1 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.125.254    0.0.0.0         UG    0      0        0 ens3
10.0.125.0      0.0.0.0         255.255.255.0   U     0      0        0 ens3
172.16.5.0      10.0.125.253    255.255.255.0   UG    0      0        0 ens3

2. netstat -rn

[root@vps1 ~]#  netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.125.254    0.0.0.0         UG        0 0          0 ens3
10.0.125.0      0.0.0.0         255.255.255.0   U         0 0          0 ens3
172.16.5.0      10.0.125.253    255.255.255.0   UG        0 0          0 ens3

3. ip route list

[root@vps1 ~]# ip route list
default via 10.0.125.254 dev ens3
10.0.125.0/24 dev ens3 proto kernel scope link src 10.0.125.11
172.16.5.0/24 via 10.0.125.253 dev ens3

Thank you for reading and please feel free to leave any feedback.

How to run a packet capture using tcpdump Linux CLI

This is a quick reference on how to to run a packet capture using tcpdump on Linux Based Operating Systems.

1. tcpdump -D

This will list the available interfaces.

root@test:~# tcpdump -D
1.eth0 [Up, Running]
2.eth1 [Up, Running]
3.eth2 [Up, Running]

2. tcpdump -i

This will capture all traffic on the specified interface.

root@test:~# tcpdump -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes

2. tcpdump port

You can filter the traffic by specifying the port number.

The following examples filters by interface and port number. If you run the command without specifying the interface it will select the first interface (eth0 in this case).

root@test:~# tcpdump -i eth2 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:00:21.501011 IP 10.0.125.10.44516 > google-public-dns-a.google.com.http: Flags [S], seq 4102846987, win 29200, options [mss 1460,sackOK,TS val 26158995 ecr 0,nop,wscale 7], length 0
13:00:22.500454 IP 10.0.125.10.44516 > google-public-dns-a.google.com.http: Flags [S], seq 4102846987, win 29200, options [mss 1460,sackOK,TS val 26159245 ecr 0,nop,wscale 7], length 0

3. tcpdump src

Filter based on source IP address.

root@test:~# tcpdump src 10.0.125.10 -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:03:52.900872 IP 10.0.125.10.44520 > google-public-dns-a.google.com.http: Flags [S], seq 1863096986, win 29200, options [mss 1460,sackOK,TS val 26211845 ecr 0,nop,wscale 7], length 0

4. tcpdump dst

Filter based on destination IP address.

root@test:~# tcpdump dst 8.8.8.8 -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:07:49.548608 IP 10.0.125.10.44522 > google-public-dns-a.google.com.http: Flags [S], seq 2687856649, win 29200, options [mss 1460,sackOK,TS val 26271007 ecr 0,nop,wscale 7], length 0

5. tcpdump host

Filter based on host IP address.

root@test:~# tcpdump host 10.0.125.10 -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:12:39.924415 IP 10.0.125.10.44524 > google-public-dns-a.google.com.http: Flags [S], seq 2438985162, win 29200, options [mss 1460,sackOK,TS val 26343601 ecr 0,nop,wscale 7], length 0

6. tcpdump net

Filter based on subnet.

root@test:~# tcpdump net 10.0.125.0/24 -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
13:15:27.052086 IP 10.0.125.10.44526 > google-public-dns-a.google.com.http: Flags [S], seq 2268200896, win 29200, options [mss 1460,sackOK,TS val 26385383 ecr 0,nop,wscale 7], length 0

How to secure your FTP server using FTPS and VSFTPD on Linux Cli

This is a detailed guide on how to secure your FTP server using FTPS and VSFTPD on Linux Based Operating Systems.

1.Generate your certificate

1.1 Generate private RSA key

You can change the encryption by replacing -aes256 to say -aes128 for example. The private key is used to generate the certificate.

openssl genrsa -aes256 -out SSL.key

1.2 Generate Certificate Signing Request or CSR

openssl req -new -key SSL.key -out certificate.csr

IMPORTANT: At this point you may want to send the CSR to a Certificate Authority who will create a certificate for you. If this is the case you can skip the rest of step 1 and move to step 2.

1.3 Remove the private key password from the private key

cp SSL.key SSL.key.orig
openssl rsa -in SSL.key.orig -out ssl.key

Please see the difference between the two files below – you also notice that the files are named differently – one is SSL.key and the other is ssl.key (which we use in the final step to create the certificate). VSFTPD will not be able to use the certificate as it would not have the passphrase, so this needs to be removed.

root@GNS3-Server:~# cat SSL.key
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,E35C0C8969A325B4AF35E737933BD2B6

root@GNS3-Server:~# cat ssl.key
-----BEGIN RSA PRIVATE KEY-----

1.4 Generate Certificate

openssl x509 -req -days 365 -in certificate.csr -signkey ssl.key -out mycertificate.crt

1.5 Copy the private key file and certificate to /etc/pki/tls/certs/

You may need to create these directories /tls/certs

cp ssl.key /etc/pki/tls/certs/
cp mycertificate.crt /etc/pki/tls/certs

2. Configure VSFTP to use your certificate

2.1 Edit /etc/vsftpd

nano  /etc/vsftpd

I have added the full file as an example.

root@GNS3-Server:~# cat /etc/vsftpd.conf
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
nopriv_user=vsftpd
virtual_use_local_privs=YES
guest_enable=YES
user_sub_token=$USER
local_root=/var/www/$USER
chroot_local_user=YES
hide_ids=YES
guest_username=vsftpd
ssl_enable=YES

allow_anon_ssl=YES

ssl_tlsv1=YES

ssl_sslv2=NO

ssl_sslv3=NO

rsa_cert_file=/etc/pki/tls/certs/mycertificate.crt

rsa_private_key_file=/etc/pki/tls/certs/ssl.key

ssl_ciphers=HIGH

require_ssl_reuse=NO


2.2 Restart VSFTPD

service vsftpd restart

3. Test

You should get a certificate error if the certificate is not signed by a certificate authority.

If you are new to the world of Linux, an avid Linux enthusiast or a student why not try our 0.99p per month Linux VPS.

Simply click on the screen shot below to find out more or navigate to https://piggybank.cloud

Thank you for reading and please feel free to leave any feedback.

How to create a FTP Linux server where users have access only to specific directories using VSFTPD Linux CLI

This is a detailed reference guide on how to create a FTP Linux server where users have access only to specific directories using VSFTPD.

1. Install vsftpd, libpam-pwdfile and apache2

Omit the apache2 part if this is already installed.

apt-get install vsftpd libpam-pwdfile apache2 

2. Edit vsftpd.conf

2.1 Make a backup of the file vsftpd.conf

mv /etc/vsftpd.conf /etc/vsftpd.conf.bak

2.2 Edit the file /etc/vsftpd.conf

nano /etc/vsftpd.conf

2.3 Remove any existing configuration and add only the following

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
nopriv_user=vsftpd
virtual_use_local_privs=YES
guest_enable=YES
user_sub_token=$USER
local_root=/var/www/$USER
chroot_local_user=YES
hide_ids=YES
guest_username=vsftpd

The chroot_local_user=YES line disables operations outside user’s home directory.

3. Create users

This will create users that do not have shell access meaning they will only have access via FTP.

3.1 Create directory /etc/vsftp

mkdir /etc/vsftpd

3.2 Create file ftpd.passwd and add the first user

htpasswd -cd /etc/vsftpd/ftpd.passwd user1

3.3 Create additional users (the command differs from above)

The above command will prompt you for a password. The below command will allow you to add additional users with one command.

htpasswd -db /etc/vsftpd/ftpd.passwd user2 123

4. Edit /etc/pam.d/vsftpd

4.1 Make a back up the file /etc/pam.d/vsftpd

mv /etc/pam.d/vsftpd /etc/pam.d/vsftpd.bak

4.2 Edit the file /etc/pam.d/vsftpd

nano /etc/pam.d/vsftpd

4.3 Remove any existing configuration and add only the following

auth required pam_pwdfile.so pwdfile /etc/vsftpd/ftpd.passwd
account required pam_permit.so

5. Create a local user without shell access

useradd --home /home/vsftpd --gid nogroup -m --shell /bin/false vsftpd

6. Create a directory to share will all users

mkdir /home/vsftpd/public_share

7. Create directories and mount shared directory

You will need to configure this for each and every user.

7.1 Create directories

mkdir /var/www/user1
chmod -w /var/www/user1
mkdir /var/www/user1/www
chmod -R 755 /var/www/user1/www
chown -R vsftpd:nogroup /var/www/user1

7.2 Mount the shared directory created at step 6

mount --bind /home/vsftpd/public_share /var/www/user1/www

8. Restart vsftpd

service vsftpd restart

9. Test

How to debug an IPSEC VPN on a Fortigate CLI

This is a quick reference guide on how to debug an IPSEC VPN on a Fortigate.

1. Check IPSEC traffic

Run a packet sniffer to make sure that traffic is hitting the Fortigate. There are various combinations you can run depending on how many VPN’s you have configured.

diagnose sniffer packet any "port 500"
interfaces=[any]
filters=[port 500]

diagnose sniffer packet any "port 4500"
interfaces=[any]
filters=[port 4500]

diagnose sniffer packet any "port 4500 and host 92.203.x.x"
interfaces=[any]
filters=[port 4500 and host 92.203.x.x]

diagnose sniffer packet any "port 500 and host 92.203.x.x"
interfaces=[any]
filters=[port 500 and host 92.203.x.x]

diagnose sniffer packet any "host 92.203.x.x"
interfaces=[any]
filters=[host 92.203.x.x]

2. Debug the VPN using diagnose debug application ike -1

Replace 1.2.3.4 with the public IP address of the remote device.

diagnose debug reset
diagnose vpn ike log-filter dst-addr4 1.2.3.4
diagnose debug application ike -1
diagnose debug enable 

Sample output

ike 0:VPN: connection expiring due to phase1 down
ike 0:VPN: deleting
ike 0:VPN: deleted
ike 0:: schedule auto-negotiate
ike 0:VPN:718429: initiator: main mode is sending 1st message...
ike 0:VPN:718429: cookie c7daf8252121d228/0000000000000000
ike 0:VPN:718429: out C7DAF8252121D22800000000000000000110020000000000000001200D00003800000001000000010000002C010100010000002401010000800B0001800C708080010007800E01008003000180020002800400050D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D500000148299031757A36082C6A621DE00000000
ike 0:VPN:718429: sent IKE msg (ident_i1send): 91.159.x.1x:500->193.x.x.x:500, len=288, id=c7daf8252121d228/0000000000000000

Thank you for reading and please feel free to leave any feedback.

How to generate a certifcate signing request (CSR) to be signed by a Certificate Authority on Linux (Ubuntu | Debian | Centos) CLI

This is a quick reference guide on how to generate a certifcate signing request (CSR) to be signed by a Certificate Authority on Linux Based Operating Systems.

1.Generate your certificate

1.1 Generate private RSA key

You can change the encryption by replacing -aes256 to say -aes128 for example. The private key is used to generate the certificate.

openssl genrsa -aes256 -out SSL.key

1.2 Generate Certificate Signing Request or CSR

You will need to ensure that the information below is accurate, especially if you are renewing a current certificate.

Common name (e.g., http://www.example.com), organization name and location (country, state/province, city/town)

root@server:~# openssl req -new -key SSL.key -out certificate.csr
Enter pass phrase for SSL.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

2. Send this to a certificate authority of your choosing.

You will need to send the file that you created (in this case certificate.csr) to a certificate authority.

The certificate authority will sign this CSR which will generate the final SSL certificate.

Thank you for reading and please feel free to leave any feedback.

How to configure ssh key authentication for root Linux (Ubuntu | Debian | Centos) CLI.

This is a quick reference guide on how to configure ssh key authentication for root on Linux Based Operating Systems.

1. Generate a public and private key pair using puTTYgen

Please see examples of the public and private key – you can use these to test.

Public Key

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEA0Xw9YhMethjXaHrTWK+Iys3g8Iiu6xCsQMD812s1KzYXeuVZFc1GFF5V48aTZdlv6UucQA4V0tQ0zOGJC3S8jBrtxzTFTTB8PZE10K/Xl60rwJOIS2FC/QqP37kk13RVVIliKwUSbafeq19tWd8yJ1SpIH44EjUZFpDcakukpO1R9QdPtaN9VJJMb1MrPTdLEYpSOtcrniZSlE9aB/CABFYFBcTsMNDz8BAEntpZEUM+KoaQ1GAPo4qYywrFr9sCdhAvhjwYpytSneWwcpPvb0DLVevJO7b0DaGPKOKD4EFxzHnkJVFOKtyvUyuchAhNn0dd85wtbA2vr5uyz/PT0Q== rsa-key-20190521

Private key

2. Paste the public key string into /.ssh/authorized keys

root@VPS:~/.ssh# ls
authorized_keys
root@VPS:~/.ssh# nano authorized_keys

3. Configure passwordless SSH

root@VPS:~# cd /etc/ssh/
root@VPS:/etc/ssh# ls
moduli                  ssh_host_ed25519_key      ssh_import_id
ssh_config              ssh_host_ed25519_key.pub  sshd_config
ssh_host_ecdsa_key      ssh_host_rsa_key          sshd_config.ucf-dist
ssh_host_ecdsa_key.pub  ssh_host_rsa_key.pub
root@VPS:/etc/ssh# nano sshd_config
PasswordAuthentication no
PermitRootLogin without-password

4. Restart sshd

root@VPS:/etc/ssh# service sshd restart

5. Configure Putty

You will need to select the private key for authentication. Just select the private key file you have generated using puTTYgen. You can use the file TEST that I have inserted into this document to test. Please note that you need a key pair to authenticate, so a public key on your server and the private key configured on your putty.

Once this is configured you connect normally using ssh and entering the username root.

You will get the following error if you do not have a private key configured on your putty session.

Thank you for reading and please feel free to leave any feedback.

How to configure 2FA authentication using Google authenticator on Centos 7 CLI.

This is a quick reference guide on how to configure 2FA authentication using Google authenticator on Centos 7.

WARNING: Please be extremely cautious when configuring this as you could potentially lock yourself out of your system if mis-configured.

In this guide I will create a separate user for 2FA authentication and leave root as password authentication only.

1. Create a new user

[root@vpscen ~]# adduser authtest
[root@vpscen ~]# passwd authtest
Changing password for user authtest.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

2. Edit /etc/ssh/sshd_config

[root@vpscen ~]# nano /etc/ssh/sshd_config

Change ChallengeResponseAuthentication to yes

# Change to no to disable s/key passwords
ChallengeResponseAuthentication yes
#ChallengeResponseAuthentication no

3. Install Google Authenticator

[root@vpscen ~]#yum update
[root@vpscen ~]# yum install google-authenticator

4. Change to user and run Google Authenticator

IMPORTANT: Only run this command in the user account that you would like to authenticate using 2FA Authentication.

[root@vpscen ~]# su authtest
[authtest@vpscen root]$ google-authenticator

Once you have run the google-authenticator command and answered some questions about your preferences, you will receive your token information to set up your token used to generate your OTP.

If by accident you run this command in the wrong user account: To revert this you can delete this from the users home directory by running the following command.

[root@vpscen ~]#rm /home/authtest/.google_authenticator

To remove from root

[root@vpscen ~]#rm .google_authenticator

5. Change back to root and edit /etc/pam.d/sshd

[authtest@vpscen ssh]$ exit
exit
[root@vpscen ssh]#
nano /etc/pam.d/sshd

add the following line to the bottom of the file:

auth required pam_google_authenticator.so nullok

6. Restart sshd

[root@vpscen ssh]# service sshd restart

7. Test Authentication

At this point I would open a duplicate putty window and test that root still has password authentication.

To test the 2FA authentication – you will be prompted for you password and then your OTP that is generated using your google Authenticator app.

If you are new to the world of Linux, an avid Linux enthusiast or a student why not try our 0.99p per month Linux VPS.

Simply click on the screen shot below to find out more or navigate to https://piggybank.cloud

Thank you for reading and please feel free to leave any feedback.

Allow SSH root login Linux

This is a quick and easy guide on how to allow the root user remote access via SSH to your Linux machine.

  1. Connect to your Virtual Machine using the VNC in your Customer portal.
  2. Edit /etc/ssh/sshd_config using nano text editor.
  3. Edit line – PasswordAuthentication and set to yes as per screenshot.
  4. Edit line – PermitRootLogin and set to yes as per screenshot.
  5. Press ctrl x and save.
  6. Restart the SSH service as per screenshot.

sudo nano /etc/ssh/sshd_config  

sudo service sshd restart  

VNC access to your Virtual Machine

Thank you for reading – if you would like to get in touch please follow the following link
https://piggybankcloud.blog/contact-piggybank-cloud/

Setting up 2FA using GoogleAuthenticator for SSH Access – Ubuntu

To get you up and running with a Virtual Server to set this up on please check out the following post:

Deploying a Virtual Machine on Piggybank’s cloud platform – The ultimate guide

Easy 2FA for your server

Setting up 2FA is usually a long process however if you just want something for a server or two here is a good way to get started.

The Google AUthenticator is actually free so we can just use PAM via SSH to plug into this.

First update the apt repositories

sudo apt-get update

Install the Package using apt-get

sudo apt-get install libpam-google-authenticator

Edit the ssh daemon PAM file

we will add the .so file which is a shared object file essentially a compiled binary file a bit like a windows DLL

nano /etc/pam.d/sshd

Add the following to the file

auth required pam_google_authenticator.so

Edit the sshd config file

This is the SSH config file for our Virtual server, we need to allow challengeResponse Authentication, this basically lets the server Ask us for a code so we enter our password then it can request more, so it challenged the user

nano /etc/ssh/sshd_config

Find the line:

ChallengeResponseAuthentication no

and change to

ChallengeResponseAuthentication yes

uncomment if need be (E.g. if its commented out delete the #)

Restart the SSH server

Now we have made changes we need to restart the SSH daemon / service this will ensure the new config is applied.

sudo service ssh restart

Generate a OTP (one time password) account

Now we need to create the seed which will essentially generate the same OTP on the server and then on the client.

Login as the user and run:

google-authenticator

If you need to change user e.g. you are root then run

su SOMEUSER

This will change you to that user.

Now we can import the google authenticator account onto our device, its a soft token so its all done via software, simply download the APP from android marketplace or IOS apple store and click import, you can just scan the QR code you see on your screen, you will see it simply keeps generating one time passwords.

Enter Yes to all and note the scratch codes or copy and paste the link.
Once the link has been copy and pasted into a browser it will show a QR code.
Scan this on your Google Authenticator App.
Or add it using the scratch codes, (theres a PC based APP).

Login

Now you have setup your OTP and app when you log in using that user the challenge response will kick in, it will ask for your OTP once you have entered a valid username and password.

enter your username
Your UNIX password
Your OTP on your app.

Done…

All done, a very simple way of securing access, don’t lose your token and ideally its only good for the odd few accounts on a server, the better way to do this would be using a 2FA solution which we will cover next.