Kubernetes has been around for a while now. Although you can find  numerous guides for various applications, they often require you to be  already familiar with Kubernetes or running a cluster in a cloud  environment provided by major providers.

pod: basic unit of a deployment, runs containers that can comunicate on localhost and share Pod IP address. 

kubeadm: a toolbox to bootstrap the cluster. 

kubelet: the component that runs on all of the machines in your cluster and does things like starting pods and containers.

kubectl: the command line util to talk to your cluster. 

master node: controls and manages worker nodes. 

Kubernetes has been around for a while now. Although you can find numerous guides for various applications, they often require you to be already familiar with Kubernetes or running a cluster in a cloud environment provided by major providers.

This makes Kubernetes unnecessarily hard to get into. All you need to follow this guide is a basic understanding of networking concepts and some basic knowledge about containers. Kubernetes being a container orchestration tool implies you'll want to run containerized applications.

I won't go into too much detail about the internal workings of the cluster or Kubernetes itself. My goal is to provide you with an easy-to-follow guide to get your first cluster and application up and running. A lot of the guide is based on official documentation of components I used.

We'll use kubeadm to build a cluster that comes with minimum requirements:

   - One or more machines running one of:
       - Ubuntu 16.04+
       - Debian 9+
       - CentOS 7+
       - Red Hat Enterprise Linux (RHEL) 7+
       - Fedora 25+
       - HypriotOS v1.0.1+
       - Flatcar Container Linux (tested with 2512.3.0)
   - 2 GB or more of RAM per machine (any less will leave little room for your apps).
   - 2 CPUs or more.
   - Full network connectivity between all machines in the cluster (public or private network is fine).
   - Unique hostname, MAC address, and product_uuid for every node. See here for more details.
   - Certain ports are open on your machines. See here for more details.
   - Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.


These are the official requirements. I would add one more, and it's sufficient disk space available on each machine. By default, Kubernetes will evict nodes when a device uses more than 90% of disk space. You can change this threshold but let's not complicate things any further.

Setting up the cluster, deploying the application, and exposing it to the outside world is, on paper, a pretty straightforward task. Still, when following official guides, you'll inevitably run into various roadblocks. I'll try to make this guide as complete as possible so you can avoid most of them.

I tested everything below on virtual machines with exactly minimum requirements, Ubuntu server 20.04 and 30GB drives.

Installing curl, kubeadm, kubelet, and kubectl
1.1 Configure prerequisites
1.2 Installation

Installing runtime - Containerd
2.1 Configure prerequisites
2.2 Installation

Installing curl, kubeadm, kubelet and kubectl

First, you'll want to enable IP-Forwarding and let iptables see bridged traffic.

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

sudo sysctl --system

sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

You will need container runtime to, well, run containers. Docker, containerd, and cri-o are well documented and commonly used.

containerd is an industry-standard container runtime with an emphasis on simplicity, robustness, and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc.

Docker is the most popular runtime by far, but for future compatibility purposes, let's use containerd.

There's been a bit of fuzz about Docker being deprecated in the future and the death of Docker as a result. To put your mind at ease, it came from a series of misconceptions. Cliffnotes version: Kubernetes uses Container Runtime Interface (CRI) to allow kubelet to interact with containers. Docker runtime was not built with Kubernetes in mind and is not CRI compliant. Docker, however, produces OCI images that will work with any runtime.

cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

Setup required sysctl params. These persist across reboots.

cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

sudo apt-get update && sudo apt-get install -y containerd

sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml

You have now installed everything you need to initialize your cluster. Before init, you have to specify a pod network. Keep in mind that every pod gets its own IP address. I use a very small /24 suffix in the example, but you will need more addresses for most real applications. Pods should also run in a different network than your host machines.

sudo kubeadm init --pod-network-cidr=192.168.2.0/24

If everything went well, you should see this message:

## Your Kubernetes control-plane has initialized successfully!
## 
## To start using your cluster, you need to run the following as a regular user:
## 
##   mkdir -p $HOME/.kube
##   sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
##   sudo chown $(id -u):$(id -g) $HOME/.kube/config
## 
## You should now deploy a pod network to the cluster.
## Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
##   https://kubernetes.io/docs/concepts/cluster-administration/addons/
## 
## Then you can join any number of worker nodes by running the following on each as root:
## 
## kubeadm join 192.168.0.10:6443 --token boq2jb.qk3gu4v01l5cg2xc \
##     --discovery-token-ca-cert-hash sha256:35ad26fc926cb98e16f10447a1b43bc947d07c2c19b380c148d4c1478c7bf834



At this point, kubeadm is very instructive about what to do next. First, enable Kubernetes environment configuration for a regular user.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Now you must deploy a pod network plugin.

Right now, your pods cannot communicate with one another. Even according to official documentation, Kubernetes networking can be challenging to understand exactly how it is expected to work. Kubernetes only provides guidelines on how networking should work. Luckily there are numerous implementations available.

Most popular CNI plugins include flannel, Calico, weave, canal, and more can be found here.

For easy setup, let's use Calico in this example.

Calico is an open-source networking and network security solution for containers, virtual machines, and native host-based workloads.

Kubernetes uses YAML files to describe objects. For the first time now, we'll need to edit one.

kubectl create -f https://docs.projectcalico.org/manifests/tigera-operator.yaml
wget https://docs.projectcalico.org/manifests/custom-resources.yaml

Change cidr field in custom-resource.yaml to match your pod network CIDR. Moreover, master nodes are by default tainted, which means that they can't run pods. While it's possible to set up toleration for specific pods, let's just remove the taint all together now.

kubectl create -f custom-resources.yaml 
kubectl taint nodes --all node-role.kubernetes.io/master-

Everything you've done so far on the master node must be done on the worker node as well, with exception of running kubeadm init and copying /etc/Kubernetes/admin.conf to $HOME/.kube/config.

To add a node as a worker, you'll need to run the join command you saw when you initialized the cluster instead. You can print the join command any time using:

kubeadm token create --print-join-command

Don't forget to install a network plugin on worker nodes as well.

Now if you run kubectl get nodes on the master you should get similar output:

NAME     STATUS   ROLES                  AGE   VERSION
mando    Ready                     7d    v1.20.2
master   Ready    control-plane,master   7d    v1.20.2

If you try to run the same on the worker node, you'll get an error. Either connection to the server localhost:8080 was refused - did you specify the right host or port? or failed to find any PEM data in certificate input. If you tried copying /etc/Kubernetes/admin.conf to $HOME/.kube/config you noticed that the file doesn't exist. A quick workaround is to copy contents of $HOME/.kube/config on the master to the same file on the worker. After that, you should be able to get the output above even on the worker.

Now it's time to deploy some pods. Let's say our goal is to run five replicas of Nginx at any given time, and we want those replicas distributed as evenly as possible among the nodes.

Without us explicitly telling it not to, Kubernetes would have no problem scheduling all the pods on the same node provided the node has the necessary resources available.

Let's get some example configuration for us to modify.

wget https://k8s.io/examples/controllers/nginx-deployment.yaml

Now we want to change the number of replicas to 5 and set topologySpreadConstraints. The final file should look roughly like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: nginx



Topology Spread Constraints are available from Kubernetes v1.19 and quite fun to play with.

maxSkew defines a maximum permitted difference between the number of matching Pods. This is exactly what we want from our cluster. The difference is set to 1, which for five replicas on our two-node cluster means three and two pods scheduled on our nodes. To learn more about topologyKey visit documentation here.

whenUnsatisfiable: DoNotSchedule means that if maxSkew can't be satisfied, Kubernetes will not start more pods even if the number of replicas is lower than specified. The alternative is ScheduleAnyway, which is, however, a soft constraint and may result in ignoring maxSkew for a number of reasons.

You watch pods being created status with watch kubectl get pods -o wide.

When all pods are running, you should be able to query all Nginx pods from any node in a cluster on port 80. Note that pods do not respond to ICMP. To test the setup, you can use curl with the corresponding port. In my case:

You should now see a "Welcome to Nginx!" page. If you run into a "No Route to Host" problem, check firewall settings.

Right now, your webserver is running in a cluster in multiple replicas, but one more problem remains to be solved. So far, you can only access it from inside of the cluster.

In this final part, you want to set up access to your server from the outside. And since you are running it in the cluster, you don't really care which of the pods respond, but it would make sense to distribute the load equally among them.

Kubernetes uses services to make multiple pods accessible through one IP address. You can very easily create such a service for your deployment

kubectl expose deployment/nginx-deployment

Service will be assigned Cluster IP. Curl on this address on port 80 should lead to the Welcome page. But when you run kubectl get services, you'll notice no external IP has been assigned. You will need a load balancer for that.

LoadBalancer service is available in Kubernetes but is by itself unusable for bare metal clusters. It will only assign external IP when you are running Kubernetes in the cloud and depends on your provider's implementation.

Luckily there is an easy solution in the form of MetalLB. MetalLB is currently in beta, but for the most part, it just works and is very easy to set up. It can work in multiple modes, including BGP, but Layer 2 configuration is sufficient for us.

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/metallb.yaml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

kubectl get configmap kube-proxy -n kube-system -o yaml | \
sed -e "s/strictARP: false/strictARP: true/" | \
kubectl apply -f - -n kube-system

You need to create config.yaml and specify the address-pool for MetalLB to give out. You can set your public IPs right away or your private network with additional forwarding. This time you can use the same network as the host machine's.

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: my-ip-space
      protocol: layer2
      addresses:
      - 192.168.0.210-192.168.0.250


Now that you have the address pool ready, the last step is to create a LoadBalancer service to get one of the addresses assigned to the service. Example loadbalancer.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-balancer
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer


And that's it! When you check kubectl get services, you should see an external address, assigned by MetalLB, through which your server is accessible from the outside of the cluster.

Build Kubernetes bare-metal cluster with external access

Securing your server as a Linux administrator has been a bit of a hassle in past years. Nftables is developed by the netfilter project, which stands behind iptables as well. It’s meant to directly address the most pressing problems and inconveniences 

Securing your server as a Linux administrator has been a bit of a hassle in past years. You had to get familiar with a variety of tools, most notably the iptables and it’s derivatives ip6tables, ebtables and arptables. Keeping them in sync requires you to either manually update all of them with every change or create a custom script to do it for you.

Nftables is developed by the netfilter project, which stands behind iptables as well. It’s meant to directly address the most pressing problems and inconveniences. While nftables has been a part of linux kernel since 2014 only very recently it has become a recommended solution for network traffic filtering.

table refers to a container of chains with no specific semantics.

chain within a table refers to a container of rules.

rule refers to an action to be configured within a chain.

Nftables keeps the best from its predecessor. It reuses the existing hook infrastructure, Connection Tracking System, NAT engine, logging infrastructure, userspace queueing and so on.

nftables are a perfect example of changing the promblematic parts, while keeping what was already perfected.

As you will see in the following examples nftables provides very readable syntax, which makes it easy to get into. Data structures set, map and dictionary all contribute to less repetition during configuration.

If you’re no stranger to network analyzers, nftables atomic commands may seem familiar to you. The syntax has been inspired by tcpdump.

Netfilter provided us with an iptables-translate tool to ease the transition from iptables. Interestingly enough some linux distributions use it by default when you try to configure iptables. You might actually be using nftables already without even knowing it!

Many of the following examples are taken directly from nftables documentation wiki with some slight modifications I thought would make it more readable.

New ingress hook allows you to filter L2 traffic. It comes before prerouting, after the packet is passed up from the NIC driver. This means you can enforce very early filtering policies. When adding a chain on ingress hook, it is mandatory to specify the device where the chain will be attached

nft add chain netdev foo dev0filter { type filter hook ingress device eth0 priority 0 \; }

All the hooks used by netfilter are shown in the following diagram.

nftables comes with a built-in generic set infrastructure which allows you to create both named and anonymous sets. For example allowing IPv6 packet on different ports

nft add rule ip6 firewall input tcp dport {telnet, http, https} accept

is a simple rule that makes use of an anonymous set.

If you expect to update your sets over time you can use a named set, which can be easily edited whenever you like. Keep in mind that they are always associated with one table.

nft add set firewall spammers { type ipv4_address\;}
nft add element firewall spammers { 192.168.1.1, 192.168.1.3 }
nft add rule ip firewall filter ip saddr @spammers drop
//when later .2 starts spamming as well
nft add element firewall spammers { 192.168.1.2 }


Map is an extension to a generic set that stores key-value pairs. The following example shows how the destination TCP port selects the destination IP address to DNAT the packet:

nft add rule ip nat prerouting dnat tcp dport map {\
80 : 192.168.1.100, 8888 : 192.168.1.101 }


If the TCP destination port is 80, then the packet is DNAT’ed to 192.168.1.100. If the TCP destination port is 8888, then the packet is DNAT’ed to 192.168.1.101.

Note: You must first define table nat and chain prerouting.

Also known as verdict maps, dictionaries allow you to attach an action to an element. Since the dictionary also has a generic set under the hood, the syntax is very similar to maps. You can create a simple ruleset very quickly. As it’s a named dictionary, you can add or remove element-action pairs whenever you like.

nft add map firewall mydict { type ipv4_addr : verdict\; }
nft add element firewall mydict { 192.168.0.10 : drop, 192.168.0.11 : accept }
nft add rule firewall input ip saddr vmap @mydict


Great example to show how dictionaries (and other structures) can help to reduce the number of traversed chains is attachment of a particular chain to chosen layer 4 protocol.

nft add rule ip firewall input ip protocol vmap {\ 
tcp : jump tcp-chain, udp : jump udp-chain , icmp : jump icmp-chain }


This example above assumes that you’ve already created the tcp-chain, udp-chain and icmp-chain custom chains.

Nftables provides concatenations to allow you to put more selectors together using all the structures mentioned above. Using them you can easily match ip address AND port, source address AND destination address and pretty much any arbitrary combination of elements.

nft add rule ip firewall input ip saddr . ip daddr . ip protocol {\
1.1.1.1 . 2.2.2.2 . tcp, 1.1.1.1 . 3.3.3.3 . udp} accept

If the packet’s source IP address AND destination IP address AND level 4 protocol match any rules from the set, nftables accepts the packet.

This practice makes it easy to create complex rules which are internally hashed and performed nearly O(1) according to documentation.

Let’s have a look at the simplest webserver firewall configuration. It only accepts ssh connections, IPv4 ping and HTTP(s) trafic.

nft add table inet firewall
nft add chain inet firewall input { type filter hook input priority 0 \; policy drop\; } 
# Allow Established/Related
nft add rule inet firewall input ct state established,related accept
# Drop Invalid Connections
nft add rule inet firewall input ct state invalid drop
# allow ping
nft add rule inet firewall input ip protocol icmp limit rate 4/second accept
# allow ssh and http(s)
nft add rule inet firewall input tcp dport { 22, http, https }
nft add rule inet firewall input udp dport { 22, http, https }
# don't forward anything, you're not a router!
nft add chain inet firewall forward { type filter hook forward priority 0 \; policy drop\; } 
# allow all outgoing traffic
nft add chain inet firewall output { type filter hook output priority 0 \; policy accept\; }

You can also forgo atomic rule use completely and create the whole ruleset in a text file, which you can easily load. Simply use nft -f <filepath>. Your file is in the same format as nft list ruleset which means that nft list ruleset > file is a perfectly fine way to backup your setup.

flush ruleset

table inet firewall {
    chain inbound {
    type filter hook input priority 0; policy drop;
        tcp dport 22 accept

        tcp dport { http, https } accept
        udp dport { http, https } accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain outbound {
        type filter hook output priority 0; policy accept;
    }
}

You can also export your rules to xml or json.

This one is obligatory. Most of you know, but it never hurts to be reminded. You must escape semicolon in bash!

In some examples you can see alternative approach using nft ‘<commands>’

nft add chain inet my_table my_input { type filter hook input priority 0 \; policy drop \; }
nft add chain inet my_table my_input '{ type filter hook input priority 0 ; policy drop ; }'
nft 'add chain inet my_table my_input { type filter hook input priority 0 ; policy drop ; }'

All of the examples above are equivalent. Just use the one you’re the most comfortable with.

Nftables defaults to the ip(v4) protocol family when not told otherwise. While it’s not a bad design you may end up defining rules you don’t really want.

New inet family exists specifically so you don’t have to duplicate your rules for both protocols.

In the sample configuration you can see that we first flush ruleset before adding the rules. It’s a recommended practice to prevent duplicate rules.

https://linux-audit.com/nftables-beginners-guide-to-traffic-filtering/

https://wiki.archlinux.org/index.php/Nftables

Properly securing your server can go a long way in saving you a lot of time, money and headaches. Global statistics clearly suggest that cyber criminality is a fact of life now, creating billions of dollars in losses worldwide. We at DataPacket do not take security lightly. In this article, we provide 9 useful tips.

Properly securing your server can go a long way in saving you a lot of time, money and headaches. Global statics clearly suggest that cyber criminality is a fact of life now, creating billions of dollars in losses worldwide.

We at DataPacket do not take security lightly. In this article, we provide 9 useful tips for securing your server and fighting off the most common threats. No matter what business you’re in, we promise that following our advice is going to be worth it in the long run. 

Keep your system up-to-date and back up your data

Choose a provider with sophisticated DDoS protection

#1 Keep your system up-to-date and back up your data

Starting with the obvious, keeping your system up-to-date and backing up your data is the very least you can do in terms of securing your server. While this may seem like a no-brainer, you’d be surprised how many people neglect these simple precautions.

The root user is the first user created by default with most Linux installations. Root has unlimited privileges over the entire system and can run any command – including those capable of causing irreversible damage.

Using root for your day-to-day tasks poses a long-term risk. Since root is the default user on most Linux distributions, you’re already giving bots – or people, for that matter – half the information they need to hack into your system by brute-forcing your password.

There are two steps to reducing these risks. First, you need to create a new user with limited privileges. Second, you must disable root access via SSH.

Connect to your server as root via SSH.

Create a new user by running the following command:
adduser YourUserName

The system will prompt you to enter a password and other credentials.

Give the user you created privileges to use sudo. That way, you’ll be able to perform administrative tasks.
usermod -aG sudo YourUserName

Switch to the new user you’ve created.
su YourUserName

As the new user, make sure that you really have sudo privileges. You may be prompted to enter the password you previously created for the new user.
sudo -l

The output should be something like this:
User YourUserName may run the following commands:
(ALL : ALL) ALL

From now on, only log into your server using the new account. Remember that you’ll still be able to execute all critical administrative tasks using sudo, but without compromising on security.

After you’ve created your own account with root privileges, go ahead and disable root access via SSH.

Make sure you’re logged in as the new user you’ve created.

To disable root login, you’ll need to edit the SSH configuration file. Open it in an editor:
sudo nano /etc/ssh/sshd_config

Look for the following line:
#PermitRootLogin prohibit-password

And change it to:
PermitRootLogin no

Don’t forget to remove the hash symbol!

Restart the SSH service:
sudo service ssh restart

Now you’re done! That wasn’t so bad, was it? Preventing brute-force attacks is an essential part of securing your server. While hardening SSH access is a good place to start, there are other techniques worth considering as well, such as installing the Fail2ban package.

Make sure the new port isn’t blocked or already in use. Also, please keep in mind that certain services may stop working if the default port is changed.

A simple SSH hardening tip is to change the default SSH port from 22 to something random, like 2946. Attackers often launch brute-force attacks against port 22 because that’s where SSH usually listens. By changing the default port, these breach attempts stop being an issue.

Connect to your server via SSH. If you haven’t created a new user already, log in as root.

Execute the following command:
sudo nano /etc/ssh/sshd_config

In the file that opens, find the following line:
#Port 22

Remove the # and change 22 to the port number you wish to use.

Save the file and run the following command to restart the SSH service:
sudo service sshd restart

If you detect suspicious activity on a randomly chosen port, chances are that you’re being targeted by a more sophisticated attack. In case that happens, take additional measures as soon as possible.

Do not lose your private key. If you lose it, you’ll lock yourself out of your server.

By default, SSH uses password authentication. Not only does that make your server vulnerable to brute force or dictionary attacks, but there are other drawbacks as well:

They’re often easy to guess. Did you know that passwords like 123456 or 111111 are still among the most widely used worldwide? Seriously, if 123456 is your password, go change it right now.

On the other hand, if you choose a password that is strong enough (think 4dCZ?dn%q@n&), you may not be able to remember it.

During the authentication process, the password needs to be transferred to the server, creating yet another vulnerability to potential eavesdroppers.

To limit your exposure, we recommend that you configure your server to use key authentication. As an added measure, you can also disable password-based logins.

Generate your key-pair by running the following command on your local machine:
ssh-keygen -t rsa

You’ll be prompted to enter a file in which you wish to store your private key. You can press enter here, saving the key into a default location.

Choose a passphrase. You’ll need to enter it each time you use the key-pair. If you don’t wish to use a passphrase, just press enter again. Please see image below.

Upload the public key on your server. After running the following command, you’ll be prompted to enter your password.
ssh-copy-id_username@remote_host

Log into your server with the following command. You’ll no longer need to enter your password.
ssh username@remote_host

Disable password authentication (optional)

While keys are virtually impossible to crack by brute force, strong passwords provide a similar level of security. That being said, you might find yourself in a situation where disabling password authentication altogether is the best way to go.

Open the SSH configuration file in an editor:
sudo nano /etc/ssh/sshd_config

Find the following line:
#PasswordAuthentication yes

And change it to:
PasswordAuthentication no

Don’t forget to remove the hash symbol!

Close the current SSH connection and try to log in again using a password:
ssh -o PerferredAuthentications username@remote_host

The output should be something like this:
Permission denied (publickey).

As suggested above, most bots trying to brute-force your password can be fought off by hardening your SSH access. That being said, thousands of unsuccessful attempts (sometimes per day) still increase server load, clutter up your logs, and are a nuisance in general.

Fail2ban monitors authentication logs for suspicious activities such as failed login attempts. After a pre-defined number of failures, the detected IP is blocked for a given duration. While this is an effective way of dealing with brute-force or dictionary attacks, it does not eliminate all security threats. Our recommendation is to use Fail2ban in combination with other lines of defense.

For more information on how to use this tool, please refer to the official documentation.

If you’re new to iptables, we recommend that you first test your rules on a computer you have physical access to. Otherwise, if you’re not absolutely sure about what you’re doing, you risk locking yourself out of your server.

While there are several firewall utilities available out there, we fully recommend that you spare a moment to configure iptables – a free command-line firewall tool pre-installed by default in most Linux distributions. Iptables works by matching network traffic against a set of user-defined rules and deciding what to do next.

To give you a clear idea of what iptables can do, let’s list a few everyday scenarios:

Filter out traffic from suspicious domains

Deny traffic entering through a certain port

Being a complex and powerful tool, iptables also allows you to get a bit more creative with the rules you create:

Only allow MySQL connections from a specific network interface

Block all SSH connections from a specific subnet

There are two approaches you can take when configuring a firewall:

Blacklisting – blocks packets that match your criteria

Whitelisting – blocks packets that don’t match your criteria

To learn more about iptables, please refer to the official documentation.

#7 Choose a provider with sophisticated DDoS protection

If your server suddenly becomes flooded with large amounts of fake traffic, you’ve fallen victim to a DDoS attack. The purpose of a DDoS attack is to waste your hardware resources, which usually results in slowing your server down, or worse, making it completely inaccessible by your customers, potentially costing you a lot of business.

DDoS protection quality varies by provider. We at DataPacket have been continuously building our own DDoS protection environment. Thanks to real-time toxic traffic detection and filtering, our customers have one less thing to worry about.

If you have any reason to think that you are likely to become a target of a DDoS attack, or if you simply adopt the protection is the best medicine approach, do not hesitate to contact our sales team.

Tempting as it might sound, there is no one-size-fits-all security strategy. If your goal is to reduce the attack surface to a bare minimum, make sure to use several lines of defence.

MTR (my traceroute) is a dynamic network performance diagnostic tool combining the functionality of ping and traceroute. MTR reports are widely used for analysing network connection bottlenecks and issues. However, it is very commonly misinterpreted.

All MTR examples in this article are hypothetical, not based on real network data.

MTR (my traceroute) is a dynamic network performance diagnostic tool combining the functionality of ping and traceroute. It investigates the connection between destination host and source server (eg. your DataPacket server). Precisely described, it analyses the response time and packet loss of routers (hops) passed on the way to destination and back through TTL (time to live) using ICMP. MTR sends a stream of packets while successively increasing TTLs where each packet is discarded by the successive hop (first hop has TTL one, second hop has TTL two, etc.), so we can see the trace to a given host.

MTR is an interactive tool, constantly updating its output. Whenever our customer spots a connectivity issue, we ask for an MTR report. An MTR report doesn’t generate continuous sending of ICMP packets but gives you a greater range of data, sending 10 packets to each hop by default. Mtr reports are widely used for analysing network connection bottlenecks and issues. However, it is very commonly misinterpreted.

MTR comes pre-installed on just about every Linux distribution. In the opposite case, run the following commands:

apt update && apt upgrade
apt install mtr-tiny

For Windows, there is an application called WinMTR and for MAC, install the homebrew package manager to run MTR.

SSH into your server to generate a report examining the path from your server to your home ISP. Add your home IP address to the command.

option flag. If you’d like the results to be more reliable, increase the cycle counts 

 (10 cycles by default) and decrease the interval 

DataPacket blog

Build Kubernetes bare-metal cluster with external access

Securing your server with nftables

Secure your Server like a Pro

MTR – diagnose network issues

BGP in our network: How does the internet GPS work

10Gbps network bandwidth test – Iperf tutorial

Multi-homed vs. Single-homed network – How does it impact your business?

Using Collectd to monitor your server’s health and performance

U.S. Dedicated Servers – How to choose the right location?

Advantages and disadvantages of various RAID levels