Due to this predictable naming, your machine’s network interface name might have got changed to ensXX or enpXsX from eth0.
Current Network Interface Name
If you see the output of ip a command below, my CentOS 8 / RHEL 8 system is having a network adapter called enp0s3.
ip a
You can confirm that the Ethernet device got renamed during the system boot by using the dmesg command.
dmesg | grep -i eth
Disable Consistent Interface Device Naming
To regain the ethX back, edit the grub file.
vi /etc/default/grubCOPY
Look for GRUB_CMDLINE_LINUX and add the following net.ifnames=0
Generate a new grub file using the grub2-mkconfig command.
grub2-mkconfig -o /boot/grub2/grub.cfg
Update Network Interface Configurations
Rename the network interface’s configuration file from ifcfg-enp0s3 to ifcfg-eth0.
mv /etc/sysconfig/network-scripts/ifcfg-enp0s3 /etc/sysconfig/network-scripts/ifcfg-eth0
Edit the file and update the name of the network device based on the DHCP/ Static IP address for eth0.
vi /etc/sysconfig/network-scripts/ifcfg-eth0
FROM:
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="enp0s3"
DEVICE="enp0s3"
ONBOOT="yes"
IPADDR="192.168.0.10"
PREFIX="24"
GATEWAY="192.168.0.1"
DNS1="192.168.0.1"
DNS2="8.8.8.8"
IPV6_PRIVACY="no"COPY
TO:
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"
IPADDR="192.168.0.10"
PREFIX="24"
GATEWAY="192.168.0.1"
DNS1="192.168.0.1"
DNS2="8.8.8.8"
IPV6_PRIVACY="no"COPY
Reboot your system.
Verify Network Interface Name
After the system reboot, go and check whether the interface name is changed to eth0.
In this article I will show how to fix CentOS 6 error: YumRepo Error: All mirror URLs are not using ftp, http[s]
Problem
When trying update CentOS 6 with yum update command getting error:
Loaded plugins: fastestmirror, refresh-packagekit, security
Setting up Update Process
Determining fastest mirrors
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/repo/arch combination/
removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/base/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: base
Cause
CentOS 6 reached end of life on the 30th November 2020. YUM attempting connect to deprecated repositories. So, we need update deprecated repositories URL’s and point to the vault.
Resolution
To fix this problem you edit /etc/yum.repos.d/CentOS-Base.repo and replace all mirrorlist
1. Go to /etc/yum.repos.d/ directory:
# cd /etc/yum.repos.d/
2. Make copy of original file:
# cp CentOS-Base.repo CentOS-Base.repo.old
3. Open and edit file with any text editor:
# vi CentOS-Base.repo
4. Replace mirrorlist‘s
Replace sections:
[base]
[updates]
[extras]
With following:
[base]
name=CentOS-$releasever - Base
# mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
# baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
baseurl=https://vault.centos.org/6.10/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
# released updates
[updates]
name=CentOS-$releasever – Updates # mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra # baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ baseurl=https://vault.centos.org/6.10/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 # additional packages that may be useful
1. Access OpenVZ 7 node via SSH and install required template with the command:Install required template
yum install centos-7-x86_64-ez
The template name always has the structure {distribution}-{release}-{arch}-ez. As an example centos-7-x86_64-ez
2. Access the master node via SSH and create a file under /vz/template/cache directory. The file name should be a template name with tar.gz extension. In our example the name would be centos-7-x86_64-ez.tar.gz:Create a file
SSH can handle authentication using a traditional username and password combination or by using a public and private key pair. The SSH key pair establishes trust between the client and server, thereby removing the need for a password during authentication. While not required, the SSH private key can be encrypted with a passphrase for added security.
The PuTTY SSH client for Microsoft Windows does not share the same key format as the OpenSSH client. Therefore, it is necessary to create a new SSH public and private key using the PuTTYgen tool or convert an existing OpenSSH private key.
Requirements
PuTTY SSH client for Microsoft Windows
Remote server accessible over OpenSSH
Install PuTTY And PuTTYgen
Both PuTTY and PuTTYgen are required to convert OpenSSH keys and to connect to the server over SSH. These two tools can be downloaded individually or, preferably, as a Windows installer from the PuTTY Download Page.
Once the PuTTY Windows installer is downloaded, double-click the executable in the Download folder and follow the installation wizard. The default settings are suitable for most installations. Both PuTTY and PuTTYgen should now be accessible from the Windows Programs list.
Use Existing Public And Private Keys
If you have an existing OpenSSH public and private key, copy the id_rsa key to your Windows desktop. This can be done by copying and pasting the contents of the file or using an SCP client such as PSCP which is supplied with the PuTTY install or FileZilla.
Next launch PuTTYgen from the Windows Programs list.
Click Conversions from the PuTTY Key Generator menu and select Import key.
Navigate to the OpenSSH private key and click Open.
Under Actions / Save the generated key, select Save private key.
Choose an optional passphrase to protect the private key.
Save the private key to the desktop as id_rsa.ppk.
If the public key is already appended to the authorized_keys file on the remote SSH server, then proceed to Connect to Server with Private Key.
Launch PuTTYgen from the Windows Programs list and proceed with the following steps.
Under Parameters, increase the Number of bits in a generated key: to a minimum value of 2048.
Under Actions / Generate a public/private key pair, click Generate.
You will be instructed to move the mouse cursor around within the PuTTY Key Generator window as a randomizer to generate the private key.
Once the key information appears, click Save private key under Actions / Save the generated key.
Save the private key to the desktop as id_rsa.ppk.
The box under Key / Public key for pasting into OpenSSH authorized_keys file: contains the public key.
Copy Public Key To Server
The OpenSSH public key is located in the box under Key / Public key for pasting info OpenSSH authorized_keys file:. The public key begins with ssh-rsa followed by a string of characters.
Highlight entire public key within the PuTTY Key Generator and copy the text.
Launch PuTTY and log into the remote server with your existing user credentials.
Use your preferred text editor to create and/or open the authorized_keys file:vi ~/.ssh/authorized_keys
Paste the public key into the authorized_keys file.ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBp2eUlwvehXTD3xc7jek3y41n9fO0A+TyLqfd5ZAvuqrwNcR2K7UXPVVkFmTZBes3PNnab4UkbFCki23tP6jLzJx/MufHypXprSYF3x4RFh0ZoGtRkr/J8DBKE8UiZIPUeud0bQOXztvP+pVXT+HfSnLdN62lXTxLUp9EBZhe3Eb/5nwFaKNpFg1r5NLIpREU2H6fIepi9z28rbEjDj71Z+GOKDXqYWacpbzyIzcYVrsFq8uqOIEh7QAkR9H0k4lRhKNlIANyGADCMisGWwmIiPJUIRtWkrQjUOvQgrQjtPcofuxKaWaF5NqwKCc5FDVzsysaL5IM9/gij8837QN7z rsa-key-20141103
Save the file and close the text editor.
Adjust the permissions of the authorized_keys file so that the file does not allow group writable permissions.chmod 600 ~/.ssh/authorized_keys
Logout of the remote server.
Connect To Server With Private Key
Now it is time to test SSH key authentication. The PuTTYgen tool can be closed and PuTTY launched again.
Enter the remote server Host Name or IP address under Session.
Navigate to Connection > SSH > Auth.
Click Browse... under Authentication parameters / Private key file for authentication.
Locate the id_rsa.ppk private key and click Open.
Finally, click Open again to log into the remote server with key pair authentication.
For those who wants things to be done fast you can use the script:
cd ~
wget -O csf-bfm-install.sh https://raw.githubusercontent.com/poralix/directadmin-bfm-csf/master/install.sh
chmod 700 csf-bfm-install.sh
./csf-bfm-install.sh
For those who wants more control and do things manually please follow the guide below (the guide might miss certain updates, but the script will be updated whenever it’s needed).
A common method of gaining access over a server is to use a technique called a brute force attack, or dictionary attack. What the attacker will do, is use a script to try and login to an account with every possible password combination. This tends to require tens of thousands of login attempts, but eventually, the right combination will be found, and they can login normally.
To prevent this, we can use a brute force login detection system in DirectAdmin, so called BFM (Brute Force Monitor).
1. Install CSF/LFD if it’s not installed yet.
Run this as root if you unsure whether or not you have CSF/LFD installed:
csf -v
You’ve got it installed if you see output similar to this (go to step #2 in this case):
# csf -v
csf: v8.22 (DirectAdmin)
You’ve got to install it if you see output similar to this:
# csf -v
bash: csf: command not found
First download and unpack it:
cd /usr/local/src
wget https://download.configserver.com/csf.tgz
tar -zxvf csf.tgz
cd ./csf
Now it’s the right time to test whether or not your server is ready to run CSF/LFD:
# ./csftest.pl
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing xt_connlimit...OK
Testing ipt_owner/xt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK
Testing iptable_nat/ipt_DNAT...OK
RESULT: csf should function on this server
If an output in your console differs much, you’d rather not install CSF and try another way of protecting your server.
Install it:
./install.directadmin.sh
And enable it. Update /etc/csf/csf.conf:
TESTING = "0"
Start it:
service csf start
Additionally you are advised to disable Login Failure Blocking in CSF/LFD as it will be Directadmin to care of it:
This last step is optional and should only be used after you’ve tested the above setup for a while to get comfortable that you’re not going to block yourself. The block_ip.sh is only used for an active “click” by the Admin, it does not automate blocking. To automate blocking, install the following script:
cd /usr/local/directadmin/scripts/custom
wget -O brute_force_notice_ip.sh http://files.directadmin.com/services/all/brute_force_notice_ip.sh
chmod 700 brute_force_notice_ip.sh
3. Update Settings in Directadmin
To make sure that BFM is enabled login as admin into the hosting panel, go to “Administrator settings” and bring the values to the following state (or similar):
IMPORTANT! Parse service logs for brute force attacks should be set to “Yes“! The other settings might be changed to meet your needs.
Save changes, and give a minute or so to changes to take effect. Now you’ve got Directadmin which will automatically block IPs of attackers with CSF.
4. Disable iptables (optional):
That was reported that raw iptables in some cases might overwrite existing rules loaded by CSF/LFD. To avoid it we’d recommend to disable iptables and ip6tables from being loaded at boot time:
If you trust your software and security settings, then you will probably want to hide all those numerous emails about found Brute force attacks. And here is how you can achieve it:
6. The block_ip.sh script specs (for better understanding):
An IP of an attacker will be blocked with iptables via CSF if the following requirements are met:
BFM support is enabled in Directadmin and properly configured
CSF/LFD installed together with the aforementioned scripts to allow Directadmin to communicate with CSF.
IP exceeded max allowed number of login failures on any account.
IP is missing in brute force skip list (/usr/local/directadmin/data/admin/brute_skip.list).
IP is not white-listed in CSF permanently (/etc/csf/csf.allow). Any mention of an IP in the csf.allow will protect the IP from blocking.
IP is not temporary in allowed list of CSF (/var/lib/csf/csf.tempallow).
An IP can be blocked from accessing either any port on the server or only a list of ports of an attacked service. A switcher USE_PORT_SELECTED_BLOCK can be found in /usr/local/directadmin/scripts/custom/block_ip.sh. The default value is 1.
USE_PORT_SELECTED_BLOCK=1; # SET TO 1 OR 0
# 1: TO BAN ACCESS ONLY TO A PORT WHICH
# WAS BRUTEFORCED
# 0: TO BLOCK ACCESS TO ALL PORTS
#
# NOTICE: MANUAL TRIGGER FROM DIRECTADMIN
# WILL STILL BLOCK ACCESS TO ALL PORTS
# FOR AN IP
If Directadmin on your Linux server fails to create users on a remote or locally installed MySQL 5.7+ with an error “Unable to add access host”, an example of which is shown below:
Unable to add access host:
Details
Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin' and host='localhost'
Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin_test2' and host='localhost'
Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin_testdb' and host='localhost'
here you can learn on how to fix it.
Why is it so?
In MySQL 5.7, the `password` field in `mysql`.`user` table was removed, and now the field name is `authentication_string`. Hence Directadmin drops the errors when it’s not informed that it’s connected to MySQL 5.7+ server, which is actual for our case since it’s installed remotely.
to swap the password column with authentication_string for password storage.
CustomBuild 2 should be doing that during the update when you install MySQL 5.7+ locally, so just double check it’s set in the /usr/local/directadmin/conf/directadmin.conf.
If MySQL 5.7 is remote, that might be why CustomBuild 2 didn’t notice. In which case, using mysql_milestone_16=1 in the directadmin.conf should let DA swap the field correctly.
echo "mysql_milestone_16=1" >> /usr/local/directadmin/conf/directadmin.conf
service directadmin restart
Will Master's Blog 