route is a command that displays, adds and deletes entries from the kernel's TCP/IP routing table (aka "Forwarding Information Base").
iptables is a command that displays, adds, and deletes entries from Netfilter, the Linux kernel's packet filtering and manipulating subsystem. It handles NAT.
A firewall is
a type of network security tool that controls the inbound and outbound network
traffic according to its predefined rule set. We can use a firewall along with
other safety measures to protect our servers from hackers' pries and attacks.
iptables is a user-space utility program that allows a system administrator to configure the IP packet filter rules of the Linux kernel firewall, implemented as different Netfilter modules. The filters are organized in different tables, which contain chains of rules for how to treat network traffic packets. iptables allows configuring the tables provided by the Linux kernel firewall, as well as the chains and rules it stores. The kernel module currently used for iptables only applies to IPv4 traffic, to configure firewall rules for IPv6 connections instead use ip6tables, which respond to the same command structures as iptables.
iptables is made up of some basic structures, as seen below:
1. TABLES
2. CHAINS
3. TARGETS
TABLES:
TABLES are the major pieces of the packet processing system, and they consist of FILTER, NAT, and MANGLE. FILTER is used for the standard processing of packets, and it’s the default table if none other is specified. NAT is used to rewrite the source and/or destination of packets and/or track connections. MANGLE is used to otherwise modify packets, i.e. modifying various portions of a TCP header, etc.
CHAINS:
CHAINS are then associated with each table. Chains are lists of rules within a table, and they are associated with “hook points” on the system, i.e. places where you can intercept traffic and take action. Here are the default table/chain combinations:
FILTER: Input, Output, Forward
NAT: Prerouting, Postrouting, Output
MANGLE: Prerouting, Postrouting, Input, Output, Forward
And here’s when the different chains do their thing:
PREROUTING: Immediately after being received by an interface.
POSTROUTING: Right before leaving an interface.
INPUT: Right before being handed to a local process.
OUTPUT: Right after being created by a local process.
FORWARD: For any packets coming in one interface and leaving out another.
In other words, if you want to process packets as they leave your system, but without doing any NAT or MANGLE(ing), you’ll look to the OUTPUT chain within the FILTER table. If you want to process packets coming from the outside destined for your local machine, you’ll want to use the same FILTER table, but the INPUT chain. See the image below for a visual representation of this.
TARGETS:
TARGETS determine what will happen to a packet within a chain if a match is found with one of its rules. A two most common ones are DROP and ACCEPT. So if you want to drop a packet on the floor, you write a rule that matches the particular traffic and then jump to the DROP target. Conversely, if you want to allow something, you jump to the ACCEPT target — simple enough.
How Packets Move:
Packets move through netfilter by traversing chains. Each non-empty chain has a list of rules in it, which packets are checked against one after another. If a match is found, the packet is processed. If no match is found, the default action is taken. The default action for a chain is also called its policy. By default, chain policies are to jump to the ACCEPT target, but this can be set to DROP if so desired (I suggest it).
Quality Of Service(QoS) packet marking can be performed by adding rules to the PREROUTING chain in the mangle table.
iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p icmp -j RETURN
iptables rules are in memory only and won’t survive reboot. To preserve the firewall rules there is a tool to save/restore(iptables-save/iptables-restore) the rules to a file and a service(iptables-persistent on Debian/Ubuntu) to automatically save/restore the rules.
Kubernetes networking uses iptables to control the network connections between pods (and between nodes), handling many of the networking and port forwarding rules. Also, port mapping is greatly simplified (and mostly eliminated) since each pod has its own IP address and its container can listen on its native port. Be careful of using services that may create conflicting iptables rules. You can check the rules by running iptables-save, which dumps the rule set to STDOUT.
If you intend to expose application services externally, by either using the NodePort or LoadBalancing service types, traffic forwarding must be enabled in your iptables rule set. If you find that you are unable to access a service from outside of the network used by the pod where your application is running, check that your iptables rule set does not contain a rule similar to the following:
:FORWARD DROP [0:0]
In the case of Istio Service Mesh, istio-init This init container is used to setup the iptables rules so that inbound/outbound traffic will go through the sidecar proxy.
ref:
iptables -
1.https://www.karlrupp.net/en/computer/nat_tutorial
2. https://wiki.archlinux.org/index.php/Iptables
3. https://medium.com/swlh/manage-iptables-firewall-for-docker-kubernetes-daa5870aca4d
iptables is a user-space utility program that allows a system administrator to configure the IP packet filter rules of the Linux kernel firewall, implemented as different Netfilter modules. The filters are organized in different tables, which contain chains of rules for how to treat network traffic packets. iptables allows configuring the tables provided by the Linux kernel firewall, as well as the chains and rules it stores. The kernel module currently used for iptables only applies to IPv4 traffic, to configure firewall rules for IPv6 connections instead use ip6tables, which respond to the same command structures as iptables.
iptables is made up of some basic structures, as seen below:
1. TABLES
2. CHAINS
3. TARGETS
TABLES:
TABLES are the major pieces of the packet processing system, and they consist of FILTER, NAT, and MANGLE. FILTER is used for the standard processing of packets, and it’s the default table if none other is specified. NAT is used to rewrite the source and/or destination of packets and/or track connections. MANGLE is used to otherwise modify packets, i.e. modifying various portions of a TCP header, etc.
CHAINS:
CHAINS are then associated with each table. Chains are lists of rules within a table, and they are associated with “hook points” on the system, i.e. places where you can intercept traffic and take action. Here are the default table/chain combinations:
FILTER: Input, Output, Forward
NAT: Prerouting, Postrouting, Output
MANGLE: Prerouting, Postrouting, Input, Output, Forward
And here’s when the different chains do their thing:
PREROUTING: Immediately after being received by an interface.
POSTROUTING: Right before leaving an interface.
INPUT: Right before being handed to a local process.
OUTPUT: Right after being created by a local process.
FORWARD: For any packets coming in one interface and leaving out another.
In other words, if you want to process packets as they leave your system, but without doing any NAT or MANGLE(ing), you’ll look to the OUTPUT chain within the FILTER table. If you want to process packets coming from the outside destined for your local machine, you’ll want to use the same FILTER table, but the INPUT chain. See the image below for a visual representation of this.
TARGETS:
TARGETS determine what will happen to a packet within a chain if a match is found with one of its rules. A two most common ones are DROP and ACCEPT. So if you want to drop a packet on the floor, you write a rule that matches the particular traffic and then jump to the DROP target. Conversely, if you want to allow something, you jump to the ACCEPT target — simple enough.
How Packets Move:
Packets move through netfilter by traversing chains. Each non-empty chain has a list of rules in it, which packets are checked against one after another. If a match is found, the packet is processed. If no match is found, the default action is taken. The default action for a chain is also called its policy. By default, chain policies are to jump to the ACCEPT target, but this can be set to DROP if so desired (I suggest it).
Quality Of Service(QoS) packet marking can be performed by adding rules to the PREROUTING chain in the mangle table.
iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p icmp -j RETURN
iptables rules are in memory only and won’t survive reboot. To preserve the firewall rules there is a tool to save/restore(iptables-save/iptables-restore) the rules to a file and a service(iptables-persistent on Debian/Ubuntu) to automatically save/restore the rules.
Kubernetes networking uses iptables to control the network connections between pods (and between nodes), handling many of the networking and port forwarding rules. Also, port mapping is greatly simplified (and mostly eliminated) since each pod has its own IP address and its container can listen on its native port. Be careful of using services that may create conflicting iptables rules. You can check the rules by running iptables-save, which dumps the rule set to STDOUT.
If you intend to expose application services externally, by either using the NodePort or LoadBalancing service types, traffic forwarding must be enabled in your iptables rule set. If you find that you are unable to access a service from outside of the network used by the pod where your application is running, check that your iptables rule set does not contain a rule similar to the following:
:FORWARD DROP [0:0]
In the case of Istio Service Mesh, istio-init This init container is used to setup the iptables rules so that inbound/outbound traffic will go through the sidecar proxy.
ref:
iptables -
1.https://www.karlrupp.net/en/computer/nat_tutorial
2. https://wiki.archlinux.org/index.php/Iptables
3. https://medium.com/swlh/manage-iptables-firewall-for-docker-kubernetes-daa5870aca4d
iptables firewall - http://linux-training.be/networking/ch14.html
Redhat Security guide - https://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-sg-en-4/s1-firewall-ipt-fwd.html
Beginner's
guide to iptables - https://www.howtogeek.com/177621/the-beginners-guide-to-iptables-the-linux-firewall/
iptables primer - https://danielmiessler.com/study/iptables/
How to add iptables on CentOS -
1. https://wiki.centos.org/HowTos/Network/IPTables
2. https://upcloud.com/community/tutorials/configure-iptables-centos/
iptables cheat sheet -
1. https://www.andreafortuna.org/2019/05/08/iptables-a-simple-cheatsheet/
2. https://gist.github.com/davydany/0ad377f6de3c70056d2bd0f1549e1017
3. https://medium.com/faun/cheatsheet-iptables-c32d203772b7
kube-iptables-tailer is a service that gives you better visibility on networking issues in your Kubernetes cluster by detecting the traffic denied by iptables and surfacing corresponding information to the affected Pods via Kubernetes events - https://github.com/box/kube-iptables-tailer
Kubernetes iptables rules -
https://camo.githubusercontent.com/4194f82b206a9b40bf50a18760eb84b9d338b521/68747470733a2f2f63646e2e7261776769742e636f6d2f63696c69756d2f6b38732d69707461626c65732d6469616772616d2f6d61737465722f6b756265726e657465735f69707461626c65732e737667
How Kubernetes Networking works -
1. https://neuvector.com/network-security/kubernetes-networking/#:~:text=Kubernetes%20networking%20uses%20iptables%20to,networking%20and%20port%20forwarding%20rules.&text=Also%2C%20port%20mapping%20is%20greatly,listen%20on%20its%20native%20port.
2. https://docs.oracle.com/en/operating-systems/oracle-linux/kubernetes/kube_admin_config_iptables.html
3. https://www.stackrox.com/post/2020/01/kubernetes-networking-demystified/
4. https://www.digitalocean.com/community/tutorials/how-to-inspect-kubernetes-networking
Istio iptables - https://github.com/istio/cni/blob/master/tools/packaging/common/istio-iptables.sh
Istio sidecar injection model using iptables - https://istio.io/blog/2019/data-plane-setup/
iptables primer - https://danielmiessler.com/study/iptables/
How to add iptables on CentOS -
1. https://wiki.centos.org/HowTos/Network/IPTables
2. https://upcloud.com/community/tutorials/configure-iptables-centos/
iptables cheat sheet -
1. https://www.andreafortuna.org/2019/05/08/iptables-a-simple-cheatsheet/
2. https://gist.github.com/davydany/0ad377f6de3c70056d2bd0f1549e1017
3. https://medium.com/faun/cheatsheet-iptables-c32d203772b7
kube-iptables-tailer is a service that gives you better visibility on networking issues in your Kubernetes cluster by detecting the traffic denied by iptables and surfacing corresponding information to the affected Pods via Kubernetes events - https://github.com/box/kube-iptables-tailer
Kubernetes iptables rules -
https://camo.githubusercontent.com/4194f82b206a9b40bf50a18760eb84b9d338b521/68747470733a2f2f63646e2e7261776769742e636f6d2f63696c69756d2f6b38732d69707461626c65732d6469616772616d2f6d61737465722f6b756265726e657465735f69707461626c65732e737667
How Kubernetes Networking works -
1. https://neuvector.com/network-security/kubernetes-networking/#:~:text=Kubernetes%20networking%20uses%20iptables%20to,networking%20and%20port%20forwarding%20rules.&text=Also%2C%20port%20mapping%20is%20greatly,listen%20on%20its%20native%20port.
2. https://docs.oracle.com/en/operating-systems/oracle-linux/kubernetes/kube_admin_config_iptables.html
3. https://www.stackrox.com/post/2020/01/kubernetes-networking-demystified/
4. https://www.digitalocean.com/community/tutorials/how-to-inspect-kubernetes-networking
Istio iptables - https://github.com/istio/cni/blob/master/tools/packaging/common/istio-iptables.sh
Istio sidecar injection model using iptables - https://istio.io/blog/2019/data-plane-setup/
