If you understood how Netfilter works after reading my previous article, you are able to configure some basic rules to filter traffic between two or more networks.
Let's suppose the following scenario: You've got a system with two network interfaces connected to an Intranet (eth0) and to the outside (eth1) and you want only traffic from the former to the later to be allowed, but only through a local proxy.
I'll show you how to do that with some iptables commands stored in a shell script that will use variables so you can easily modify it for your own network.
The file with this shell script must have execution permission for the root and shouldn't be readable for any one else. Save it in the directory /etc/network/if-pre-up.d/ if you're working with Debian or Ubuntu, as it's my case.
#!/bin/sh
# Variables
# Group 1
LOCALNET=192.168.111.0/24
LOCALPROXY=192.168.111.2
LANDEV=eth0
WANDEV=eth1
# Delete any previous ruleset
# Group 2
iptables -F
iptables -X
iptables -Z
# Set the default policy
# Group 3
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
# Allow traffic for loopback interface
# Group 4
iptables -A INPUT -i lo -j ACCEPT
# Allow HTTP and HTTPS for the local proxy
# Group 5
iptables -A FORWARD -s $LOCALPROXY -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -d $LOCALPROXY -p tcp --sport 80 -j ACCEPT
iptables -A FORWARD -s $LOCALPROXY -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -d $LOCALPROXY -p tcp --sport 443 -j ACCEPT
# Allow DNS traffic (consider changing LOCALNET for LOCALPROXY)
# Group 6
iptables -A FORWARD -s $LOCALNET -p tcp --dport 53 -j ACCEPT
iptables -A FORWARD -d $LOCALNET -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -s $LOCALNET -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -d $LOCALNET -p udp --sport 53 -j ACCEPT
# Masquerade local addresses
# Group 7
iptables -t nat -A POSTROUTING -s $LOCALNET -o $WANDEV -j MASQUERADE
# Allow routing through network interfaces
# Group 8
echo 1 > /proc/sys/net/ipv4/ip_forward
The lines in group 1 have to be changed with your own settings. Next, group 2 makes the ruleset to be completely deleted. In group 3, the default policy is setup for each chain in the filter table (iptables works with the filter table if no other table is specified). Users trying to reach the outside network won't be able to get a connection and no message will be sent back due to the DROP policy in the FORWARD chain.
After that, group 4 allows any loopback interface traffic (i.e. connections to localhost). Next, in group 5, web traffic is allowed for the local proxy, so users will have to use it in order to navigate. Last filter rules, in group 6, allow dns queries for all the Intranet, but you can consider allowing it for only the local proxy depending on your security policy.
The rules in groups 6 and 7 are coupled, for one allows the traffic from the Intranet to the outside network while the other allows the traffic back to the local network.
The rule in group 7 is the only one in the nat table in this example. It makes the source IP address to be changed for the outside network interface IP address, so the local addresses are masqueraded. This kind of Network Address Translation is named source NAT or SNAT.
Finally, in group 8, the traffic is allowed to be routed between the network interfaces.
Once the shell script is executed, you should get the following output from the command iptables -nL:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT tcp -- 192.168.111.2 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 192.168.111.2 tcp spt:80
ACCEPT tcp -- 192.168.111.2 0.0.0.0/0 tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 192.168.111.2 tcp spt:443
ACCEPT tcp -- 192.168.111.0/24 0.0.0.0/0 tcp dpt:53
ACCEPT tcp -- 0.0.0.0/0 192.168.111.0/24 tcp spt:53
ACCEPT udp -- 192.168.111.0/24 0.0.0.0/0 udp dpt:53
ACCEPT udp -- 0.0.0.0/0 192.168.111.0/24 udp spt:53
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Now you can try to establish some connections. Execute telnet www.google.com 80 from the local proxy:
And watch for the incoming and outgoing connexions through the firewall with the command:
watch -n 1 'sudo iptables -nvL | grep 80'
The first column is a counter of packets and the second is a counter of bytes that matched that rule.
I hope you can find here the answer to your question about systems configuration. I hope you can find in this toolbox the tool you need for your system to be configured.
Showing posts with label networking. Show all posts
Showing posts with label networking. Show all posts
Tuesday, April 14, 2015
Basic filter rules with Netfilter (iptables)
Labels:
chain,
firewall,
Internet,
Intranet,
ip_forward,
iptables,
kernel,
Linux,
masquerade,
nat,
Netfilter,
networking,
proxy,
routing,
table
Tuesday, January 8, 2013
DHCP forwarding with a relay server
What if you have several local networks and you don't want a DHCP server on each? Don't worry about that! You only need a single DHCP server and many DHCP relay servers forwarding the requests to it.
I'll explain how to configure both servers using an example of two networks 192.168.56.0/24, on which is the main DHCP server, and 10.0.0.0/24, on which is the DHCP relay server, as shown in this figure:
The main DHCP server is an Ubuntu 12.04 precise and the DHCP relay server is a Debian 6.0.5 squeeze. The packages you need to install are:
I'll explain how to configure both servers using an example of two networks 192.168.56.0/24, on which is the main DHCP server, and 10.0.0.0/24, on which is the DHCP relay server, as shown in this figure:
The main DHCP server is an Ubuntu 12.04 precise and the DHCP relay server is a Debian 6.0.5 squeeze. The packages you need to install are:
- The DHCP server: isc-dhcp-server
- The DHCP relay server: isc-dhcp-relay
You are supposed to configure the main DHCP server for its own network and, in addition, you'll have to configure it for the other network(s). In my example, the end of the /etc/dhcp/dhcp.conf file looks like this:
option domain-name "local.net";
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10 10.0.0.20;
option routers 10.0.0.1;
option domain-name-servers 10.0.0.250, 10.0.0.251;
}
subnet 192.168.56.0 netmask 255.255.255.0 {
range 192.168.56.10 192.168.56.20;
option routers 192.168.56.1;
}
This is a very basic configuration and you might want to include more directives for your own networks.
When installing the package isc-dhcp-relay, the setup process will start automatically and it will modify the file /etc/default/isc-dhcp-relay. However, in case you might want to change something later, here's the content of the file for my example:
# Defaults for isc-dhcp-relay initscript
# sourced by /etc/init.d/isc-dhcp-relay
# installed at /etc/default/isc-dhcp-relay by the maintainer scripts
#
# This is a POSIX shell fragment
#
# What servers should the DHCP relay forward requests to?
SERVERS="192.168.56.2"
# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES=""
# Additional options that are passed to the DHCP relay daemon?
OPTIONS=""
You can specify many DHCP servers to relay to of the interface on which to bind for requests. Just read the man page for more information.
After the changes and restarting both DHCP servers, the clients in the same network as the DHCP relay server should be able to requests an IP address (try with sudo ifup eth0 on the client):
Listening on LPF/eth0/08:00:27:2b:4c:c3
Sending on LPF/eth0/08:00:27:2b:4c:c3
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 10.0.0.2
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 10.0.0.2
bound to 10.0.0.10 -- renewal in 248 seconds.
Notice that the IP address was offered by the DHCP relay server, not the main DHCP server.
Now the interface is configured (type sudo ifconfig eth0 on the client):
eth0 Link encap:Ethernet HWaddr 08:00:27:2b:4c:c3
inet addr:10.0.0.10 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe2b:4cc3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:49 errors:0 dropped:0 overruns:0 frame:0
TX packets:102 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8373 (8.1 KiB) TX bytes:17609 (17.1 KiB)
Just for curiosity, look at the end of the syslog on the main DHCP server and you will read something similar to this:
Jan 7 20:40:30 odin dhcpd: DHCPDISCOVER from 08:00:27:2b:4c:c3 via 10.0.0.2
Jan 7 20:40:30 odin dhcpd: DHCPOFFER on 10.0.0.10 to 08:00:27:2b:4c:c3 via 10.0.0.2
Jan 7 20:40:30 odin dhcpd: DHCPREQUEST for 10.0.0.10 (192.168.56.2) from 08:00:27:2b:4c:c3 via 10.0.0.2
Jan 7 20:40:30 odin dhcpd: DHCPACK on 10.0.0.10 to 08:00:27:2b:4c:c3 via 10.0.0.2
Jan 7 20:44:38 odin dhcpd: DHCPREQUEST for 10.0.0.10 from 08:00:27:2b:4c:c3 via vboxnet0
Jan 7 20:44:38 odin dhcpd: DHCPACK on 10.0.0.10 to 08:00:27:2b:4c:c3 via vboxnet0
Once again, it's the DHCP relay server who made the request on the client's behalf.
Subscribe to:
Posts (Atom)


