Iptables and firewall

Introduction tto ip tables: video and part2, watch these 2 vieos or read this blog for basic overview

3 mian tables,

1.Default table - used for filtering 

2.Nat table - used for NAT translation.changing ports with system or changin ip address in packet usng DNAT and SNAT

3.Mangel table - used to edit the header of ip packets

 Nice article on iptables, filtertable in particular is here

nat table nice video: 

Complete work flow picture here

some info on ip masqurading here

Diff between SNAT,DNAT and Masquerading 

Source NAT changes the source address in IP header of a packet. It may also change the source port in the TCP/UDP headers. The typical usage is to change the a private (rfc1918) address/port into a public address/port for packets leaving your network.

Destination NAT changes the destination address in IP header of a packet. It may also change the destination port in the TCP/UDP headers.The typical usage of this is to redirect incoming packets with a destination of a public address/port to a private IP address/port inside your network.

Masquerading is a special form of Source NAT where the source address is unknown at the time the rule is added to the tables in the kernel. If you want to allow hosts with private address behind your firewall to access the Internet and the external address is variable (DHCP) this is what you need to use. Masquerading will modify the source IP address and port of the packet to be the primary IP address assigned to the outgoing interface. If your outgoing interface has a address that is static, then you don't need to use MASQ and can use SNAT which will be a little faster since it doesn't need to figure out what the external IP is every time.

What is masquerading?

After study of above answers, this is what caused me to understand:

Masquerading allows an entire network of internal IP addresses to operate through one external IP address and masquerading allows conversion from one protocol to another (wired/wireless).

When the MASQUERADE chain sends a datagram from a computer it...

1. Takes note of the type of datagram it is, "TCP," "UDP," "ICMP," etc. Note: An unknown might not work correctly through MASQUERADE.
2. Modifies the datagram so that it looks like it was generated by the router machine itself (the one external address).
3. Remembers that it has done so, recording the local source and external destination IPs.
4. Transmits the datagram onto the Internet with the single external IP address.

Note: When the destination host receives this datagram, it believes the datagram has come from the one routing host and sends any reply datagrams back to that address.

When the Linux MASQUERADE chain receives a datagram from its Internet connection,

1. It looks in its table of established masqueraded connections to see if this datagram actually belongs to a computer on the LAN.
2. If it does, it reverses the modification it did on the forward path and transmits the datagram to the LAN computer.

The MASQUERADE chain is useful for internally creating and entire private IP address space, and for forwarding packets that would otherwise be incompatible.

The Ethernet, or wired protocol, assumes that the packet comes from the source and reports itself. The Wifi, or wireless protocol, assumes that the packet is being repeated and reports itself and the original source.

For this reason, Wifi and Ethernet cannot be directly bridged because they are incompatible. Masquerading causes the packets to be rebuilt and will thereby handle conversion between wired and wireless standards. Note: There are ways to cause your computer to accept the incompatibility internally and bridge, but without a full masquerade, the bridge spoof will be viewed externally as a security risk and those requests will be rejected.

Difference between OUTPUT and FORWARD chains

OUTPUT is for packets that are emitted by the host. Their destination is usually another host, but can be the same host via the loopback interface, so not all packets that go through OUTPUT are in fact outgoing.

FORWARD is for packets that are neither emitted by the host nor directed to the host. They are the packets that the host is merely routing.

Exmaple of nating:

If you under stand this use case they you are comfortable with ip tables natting:

I've had 2 machines centos_master(192.168.29.53) where i've installed apache webserver and another centos_worker machine(192.168.29.249) where you want to create nat tables.

Writing ip natting code so that, if any traffic comes o centos worker 1 on port 9090, it should hit apache webserver in centos_master.

I know you can't do See this video 2 times to get the answer

Solution:

sudo iptables --append PREROUTING --table nat --protocol tcp --destination 192.168.29.249 --dport 9090 --jump DNAT --to-destination 192.168.29.53:80

sudo iptables --append POSTROUTING --table nat --protocol tcp --destination 192.168.29.53 --dport 80 --jump SNAT --to-source 192.168.29.249:9090

Masquerading Basics

Masquerading is the Linux-specific form of NAT (network address translation). It can be used to connect a small LAN (where hosts use IP addresses from the private range — see Section�21.1.2.2. “Netmasks and Routing”) with the Internet (where official IP addresses are used). For the LAN hosts to be able to connect to the Internet, their private addresses are translated to an official one. This is done on the router, which acts as the gateway between the LAN and the Internet. The underlying principle is a simple one: The router has more than one network interface, typically a network card and a separate interface connecting with the Internet. While the latter links the router with the outside world, one or several others link it with the LAN hosts. With these hosts in the local network connected to the network card (such as eth0) of the router, they can send any packets not destined for the local network to their default gateway or router.

	Using the Correct Network Mask
When configuring your network, make sure both the broadcast address and the netmask are the same for all local hosts. Failing to do so results in a broken network because packets cannot be routed properly.

As mentioned, whenever one of the LAN hosts sends a packet destined for an Internet address, it goes to the default router. However, the router must be configured before it can forward such packets. For security reasons, SUSE LINUX does not enable this in a default installation. To enable it, set the variable IP_FORWARD in the file /etc/sysconfig/sysctl to IP_FORWARD=yes.

The target host of the connection can see your router, but knows nothing about the host in your internal network where the packets originated. This is why the technique is called masquerading. Because of the address translation, the router is the first destination of any reply packets. The router must identify these incoming packets and translate their target addresses, so packets can be forwarded to the correct host in the local network.

With the routing of inbound traffic depending on the masquerading table, there is no way to open a connection to an internal host from the outside. For such a connection, there would be no entry in the table. In addition, any connection already established has a status entry assigned to it in the table, so the entry cannot be used by another connection.

If you are following cka adim course, replace last command to add iptable nat rule with this

$ iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.15.2:80

SSh public key authentication and TLS basics

 Ssh publuc key authenticaion: video

History of ssl and tsl: here

For authentication,it uses hand shake(Using asymetric keys) and after sucessful authentication for data transfer(using symetric key) it uses record protocal.

Hand shake is very important and it goes like this:

Client: “Hello there. I want to determine secure communication between the two of us. Here are my cipher suites and compatible SSL/TLS version.”

Server: “Hello, Client. I verified your cipher suites and SSL/TLS version. I feel we’re good to travel ahead. Here are my certificate file and my public key. Verify them”

Client: “Let me verify your certificate… (After Verification) Okay, it seems fine, but I want to verify your private key. I will generate and encrypt a pre-master (shared secret key) key using your public key. Decrypt it using your private key, and we’ll use the master key to encrypt and decrypt the information.”

Server: “Done.”

[Now that both parties know who they’re rebuking, the information transferred between them is secured using the master key. When the verification part is over, the encryption takes place only through the master key. This is often called symmetric encryption.]

Client: “I’m sending you this sample message to verify that our master key works. Please send me the decrypted version of this message. If it works, our data is in safe hands.”

Server: “Yeah, it works. I feel we’ve accomplished what we were trying to find.”l we’ve accomplished what we were trying to find.”

Points to remember:

• The web server needs a certicate signed by ca authority.
• The web server sends that certificate signed by ca which contains the private key of the web server  to web browser or clients.
• Browsers validate the certificate by using ca authority public keys(ca certicates contains public keys),they are built in all browsers.CA signs the certificates of web servs using their private keys and ca certificate(which in turn contains public key) and ca certificates(or root certificates) of ca are available in all browsers
• browser then sends symmetric key encrypted with web server public key and web server decrypts the msg using its private key and now web server and browser both have symetric keys.So then can comminicate using record protocal by simply encrypting msgs using symetric key

Cerficate Generation process :

1.Web server will generate a private key using, openssl genrsa -out ca.key 2048

2.Then web server will create a certificate signing request(csr) , which contains the details of organisation and public key

3.CA authotity verifies the information and if company information is legitimate then that certificate will be signed by ca private key and ca.crt(CA certificate which contains ca public key as well) file .

Note:Incase of kubernetes cluster, ca authority needs to follow same steps but step i.e  signing csr will be performed using its own private key generated in step1 and this is called self signed certificate

Generating client certificates

step1 and step2 are same,in the step 3, ca authority will sign the csr of admin or other client certificates using cs.key(private) and ca.crt(ca certificate which contains the public key).