Size: 857
Comment:
|
Size: 11867
Comment: Pre-written shorewall documentation pasted in
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
#title Shorewall Basics - wiki.ubuntu.com | #title Shorewall Basics |
Line 6: | Line 6: |
This documentation is intended to give someone a jump start on learning the art of firewall configuration via standard shorewall tools. This guide will make some of the following assumptions: |
This documentation is intended to give someone a jump start on learning the art of firewall configuration via standard shorewall tools. Shorewall is a perl based wrapper for IPTables. IPTables and Shorewall can probably do the same things, but shorewall makes it easier. This guide will make some of the following assumptions: |
Line 11: | Line 12: |
= Goals = * To configure an enterprise level firewall * To share an Internet connection via custom router = Advantages = * Massive monitoring options for all Internet traffic by using iptraf, tcpdump, and other similar tools * Custom port blocking for all members of the LAN * Flexibility for future Internet filtering via centralized configuration * Increased options and ease of configuration for VPN connections, including site to site links |
|
Line 14: | Line 23: |
* At least one network card * Functional network connectivity on most network cards * Shorewall 3.0 or newer is installed {{{sudo apt-get install shorewall}}} = Second Section = '''WORK IN PROGRESS''' ---- CategoryDocumentation CategorySecurity |
* Two network cards installed and functional * Shorewall 3.0 or newer installed: {{{sudo apt-get install shorewall}}} = Network Configuration = To start, get a linux box with two network cards that can be used in a test environment. Run {{{ifconfig -a}}}, you should get something like this: {{{ eth0 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC inet addr:10.10.10.2 Bcast:10.10.10.255 Mask:255.255.255.0 inet6 addr: fe80::240:f4ff:fed0:1e53/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:677568 errors:0 dropped:0 overruns:0 frame:0 TX packets:224780 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:434403161 (414.2 MiB) TX bytes:20222454 (19.2 MiB) Interrupt:10 Base address:0xc000 eth1 Link encap:Ethernet HWaddr 00:33:44:DD:EE:FF inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::250:bfff:fe92:7566/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:111679 errors:0 dropped:0 overruns:0 frame:0 TX packets:159632 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11942750 (11.3 MiB) TX bytes:49653148 (47.3 MiB) Interrupt:11 Base address:0xe000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:116 (116.0 b) TX bytes:116 (116.0 b) }}} === Network Interface - Notes on trust levels === Note: A standard convention for network interface trust levels is shown below eth0 -- external network interface - internet -- 0.01% trusted eth1 -- internal network interface - lan -- 70% trusted If additional interfaces are added or listed, it is best to keep the same order. The least trusted interface should be first, most trusted last. This is only a convention, not required, but highly recommended. If you see any interface that starts with tun, ppp, or ham, it probably is a vpn connection. === Functionality Requirement: Network cards === '''If you do not have at least eth0 and eth1, try your hardware again or check for module issues.''' More interfaces are fine, we will ignore them for now. If you have eth0 and eth1, then edit your /etc/network/interfaces file as appropriate. {{{ ### DHCP External: ### # The loopback network interface auto lo iface lo inet loopback # External network interface auto eth0 iface eth0 inet dhcp # Internal network interface auto eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 }}} {{{ ### Static External: ### # The loopback network interface auto lo iface lo inet loopback # External network interface auto eth0 iface eth0 inet static address 10.10.10.2 netmask 255.255.255.0 broadcast 10.2.2.255 gateway 10.10.10.1 # Internal network interface auto eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 }}} Run this command '''on one line''', or from the physical console: ifdown -a;ifup -a '''Verify that you can ping something on your outside network, the Internet, and your inside network.''' ==== Shorewall Basics ==== ---- First step: apt-get install shorewall Second step: Edit /etc/shorewall/shorewall.conf and verify IP_FORWARDING=On. Within /etc/shorewall, these files are of importance for a basic router: interfaces masq modules policy rules shorewall.conf zones All other files can be ignored or deleted. The samples are duplicated in /usr/share/doc/shorewall/default-config/. Each of these files can be used for advanced concepts later, and are simply not required. Also note that each config file has extra documentation right in the config file. ''/etc/shorewall/interfaces'' ---- This config file should be strait forward. We are simply naming each network interface. From now on, we refer to eth0 as "net" or Internet. Eth1 is now referred to as "lan". '''Every config file from here on referrs to these names.''' <pre> ### Comments, comments, and more comments. # #ZONE INTERFACE BROADCAST OPTIONS # net eth0 detect tcpflags,nosmurfs lan eth1 detect #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE </pre> ''/etc/shorewall/zones'' ---- The basic function of zones is to set ipv4 or ipv6. Also note we now have a new concept referred to as 'fw'. '''The fw entry simply means "me". It always referrs to the linux box shorewall is running on, and is completely independant of interfaces, ip addresses, or other network settings.''' Notice that fw's type is 'firewall', not ipv4. <pre> ### Comments, comments, and more comments. #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 lan ipv4 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE </pre> ''/etc/shorewall/policy'' ---- The policy sets the overall layout for who is allowed to go where. It makes broad sweeps and big changes. Start here for designing security. Notice that fw is referred to slightly different, but still the same concept. Each line is processed from top to bottom for every packet that goes to or through the router. If a packet matches the source and the destination, then the policy type determines the fate of the packet. '''Each line can be read as "if a packet is sent from the ____ to the ____ then ______ it.". Ex: If a packet is sent from the 'lan' to the 'net' then 'ACCEPT' it.''' Ex: * A device connected to the lan tries to ping our firewall. ** Rule #1 does not match, the destination is not the Internet. ** Rule #2 does match, source and destination are the same as our packet. The packet is sent on to its destination (which just happens to be the firewall itself). * A device somewhere on the 'net' tries to ping our firewall. ** Rules #1-4 do nothing, the source is not the Internet. ** Rule #5 does match. It is coming from the net. The destination does not matter. The packet is dropped, the person pinging gets no response, as if our router is not turned on. * A device connected to the lan tries to ping google.com ** Rule #1 matches, the firewall accepts it, and then passes it on (''Note: The "passing on" function usually needs to be configured in another file''). ** The ping should then make it out to google.com, and come back to us. ** When the packet comes back, it technically matches 'net to all DROP', but it is a response to a conversation we started. It is considered an ESTABLISHED connection, and therefore is automatically sent through to the lan regardless of policy. The last line of ''all all REJECT info'' simply means "if we forgot a policy variation, reject the packet". It should always be the last rule, nothing after it will be processed. The REJECT option sends a message back to the source explicitly saying "I'm not available". The REJECT option is not a good idea if you are trying to make your router invisible. <pre> ### Comments, comments, and more comments. #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST # lan net ACCEPT lan $FW ACCEPT $FW net ACCEPT $FW lan ACCEPT net all DROP # THE FOLLOWING POLICY MUST BE LAST all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE </pre> ''/etc/shorewall/rules'' ---- The rules file is for making exceptions to the policy. It is best used for making small changes to the firewall, not large changes. '''This file is not required for a normal functioning firewall unless you want to let people in from the Internet.''' ACE standardly does need remote access in order to manage devices. '''Each line can be read as "______ a packet if it is sent from the ____ to the ____ using the protocol of ____ on port number ____"''' Each entry can be restrictive. For example, the two rules below accept from the net ONLY if it happens to come from 69.17.28.128/27 (short for 69.17.28.130-158). Each entry can have multiple comma delimited fields, EX: port 21,22,53,80,443 or net:1.2.3.4,55.66.77.88 <pre> #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP ACCEPT net fw udp 1194 ACCEPT net:64.233.169.104/24 fw icmp 8 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE </pre> ''/etc/shorewall/masq'' ---- The masq file is required if you want your box to be a router. '''This file can be read as "If someone is trying to get to a network that ____ has access to, and that someone is coming in from ____ then pass it through."''' Note: Masq(erading) is almost always required for routing. This is based on the assumption that your internal network and your external network have completely different IP address ranges. When your firewall is fully configured for routing, '''it will rewrite outgoing packets to make the traffic appear to come from itself, rather then the original device on the protected lan.''' EX: Device with IP address 192.168.1.101 is on the internal lan, and wants to ping 10.2.2.1 on your external lan. If your router passed the whole packet on exactly as is, 10.2.2.1 would try to respond to 192.168.1.101. It does not know which network that is, and will fail. If your router rewrites the sender as being itself (10.2.2.114) then 10.2.2.1 will know how to respond. The route then rewrites the destination on the response so it gets to 192.168.1.101. <pre> #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC eth0 eth1 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE </pre> = Command Reference = = Additional Info = ---- CategoryDocumentation CategorySecurity CategoryNetworking |
ContentsBRTableOfContents(2) |
Introduction
This documentation is intended to give someone a jump start on learning the art of firewall configuration via standard shorewall tools. Shorewall is a perl based wrapper for IPTables. IPTables and Shorewall can probably do the same things, but shorewall makes it easier.
This guide will make some of the following assumptions:
- You are comfortable with some basics on the command line
- You are familiar with basic concepts involving IP Addresses and routers
Goals
- To configure an enterprise level firewall
- To share an Internet connection via custom router
= Advantages =
- Massive monitoring options for all Internet traffic by using iptraf, tcpdump, and other similar tools
- Custom port blocking for all members of the LAN
- Flexibility for future Internet filtering via centralized configuration
- Increased options and ease of configuration for VPN connections, including site to site links
Requirements
- Two network cards installed and functional
Shorewall 3.0 or newer installed: sudo apt-get install shorewall
Network Configuration
To start, get a linux box with two network cards that can be used in a test environment. Run ifconfig -a, you should get something like this:
eth0 Link encap:Ethernet HWaddr 00:11:22:AA:BB:CC inet addr:10.10.10.2 Bcast:10.10.10.255 Mask:255.255.255.0 inet6 addr: fe80::240:f4ff:fed0:1e53/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:677568 errors:0 dropped:0 overruns:0 frame:0 TX packets:224780 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:434403161 (414.2 MiB) TX bytes:20222454 (19.2 MiB) Interrupt:10 Base address:0xc000 eth1 Link encap:Ethernet HWaddr 00:33:44:DD:EE:FF inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::250:bfff:fe92:7566/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:111679 errors:0 dropped:0 overruns:0 frame:0 TX packets:159632 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11942750 (11.3 MiB) TX bytes:49653148 (47.3 MiB) Interrupt:11 Base address:0xe000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:116 (116.0 b) TX bytes:116 (116.0 b)
Network Interface - Notes on trust levels
Note: A standard convention for network interface trust levels is shown below
- eth0 -- external network interface
- - internet -- 0.01% trusted
- - lan -- 70% trusted
If additional interfaces are added or listed, it is best to keep the same order. The least trusted interface should be first, most trusted last. This is only a convention, not required, but highly recommended.
If you see any interface that starts with tun, ppp, or ham, it probably is a vpn connection.
Functionality Requirement: Network cards
If you do not have at least eth0 and eth1, try your hardware again or check for module issues. More interfaces are fine, we will ignore them for now.
If you have eth0 and eth1, then edit your /etc/network/interfaces file as appropriate.
### DHCP External: ### # The loopback network interface auto lo iface lo inet loopback # External network interface auto eth0 iface eth0 inet dhcp # Internal network interface auto eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
### Static External: ### # The loopback network interface auto lo iface lo inet loopback # External network interface auto eth0 iface eth0 inet static address 10.10.10.2 netmask 255.255.255.0 broadcast 10.2.2.255 gateway 10.10.10.1 # Internal network interface auto eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
Run this command on one line, or from the physical console:
- ifdown -a;ifup -a
Verify that you can ping something on your outside network, the Internet, and your inside network.
Shorewall Basics
First step: apt-get install shorewall
Second step: Edit /etc/shorewall/shorewall.conf and verify IP_FORWARDING=On.
Within /etc/shorewall, these files are of importance for a basic router:
- interfaces masq modules policy rules shorewall.conf zones
All other files can be ignored or deleted. The samples are duplicated in /usr/share/doc/shorewall/default-config/. Each of these files can be used for advanced concepts later, and are simply not required.
Also note that each config file has extra documentation right in the config file.
/etc/shorewall/interfaces
This config file should be strait forward. We are simply naming each network interface.
From now on, we refer to eth0 as "net" or Internet. Eth1 is now referred to as "lan".
Every config file from here on referrs to these names. <pre>
# #ZONE INTERFACE BROADCAST OPTIONS # net eth0 detect tcpflags,nosmurfs lan eth1 detect #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE </pre>
/etc/shorewall/zones
The basic function of zones is to set ipv4 or ipv6. Also note we now have a new concept referred to as 'fw'.
The fw entry simply means "me". It always referrs to the linux box shorewall is running on, and is completely independant of interfaces, ip addresses, or other network settings. Notice that fw's type is 'firewall', not ipv4.
<pre>
#ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 lan ipv4 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE </pre>
/etc/shorewall/policy
The policy sets the overall layout for who is allowed to go where. It makes broad sweeps and big changes. Start here for designing security.
Notice that fw is referred to slightly different, but still the same concept.
Each line is processed from top to bottom for every packet that goes to or through the router. If a packet matches the source and the destination, then the policy type determines the fate of the packet.
Each line can be read as "if a packet is sent from the to the then it.". Ex: If a packet is sent from the 'lan' to the 'net' then 'ACCEPT' it.
Ex: * A device connected to the lan tries to ping our firewall. ** Rule #1 does not match, the destination is not the Internet. ** Rule #2 does match, source and destination are the same as our packet. The packet is sent on to its destination (which just happens to be the firewall itself).
* A device somewhere on the 'net' tries to ping our firewall. ** Rules #1-4 do nothing, the source is not the Internet. ** Rule #5 does match. It is coming from the net. The destination does not matter. The packet is dropped, the person pinging gets no response, as if our router is not turned on.
* A device connected to the lan tries to ping google.com ** Rule #1 matches, the firewall accepts it, and then passes it on (Note: The "passing on" function usually needs to be configured in another file). ** The ping should then make it out to google.com, and come back to us. ** When the packet comes back, it technically matches 'net to all DROP', but it is a response to a conversation we started. It is considered an ESTABLISHED connection, and therefore is automatically sent through to the lan regardless of policy.
The last line of all all REJECT info simply means "if we forgot a policy variation, reject the packet". It should always be the last rule, nothing after it will be processed. The REJECT option sends a message back to the source explicitly saying "I'm not available". The REJECT option is not a good idea if you are trying to make your router invisible.
<pre>
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST # lan net ACCEPT lan $FW ACCEPT
$FW net ACCEPT $FW lan ACCEPT
net all DROP
# THE FOLLOWING POLICY MUST BE LAST all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE </pre>
/etc/shorewall/rules
The rules file is for making exceptions to the policy. It is best used for making small changes to the firewall, not large changes. This file is not required for a normal functioning firewall unless you want to let people in from the Internet. ACE standardly does need remote access in order to manage devices.
Each line can be read as " a packet if it is sent from the to the using the protocol of on port number "
Each entry can be restrictive. For example, the two rules below accept from the net ONLY if it happens to come from 69.17.28.128/27 (short for 69.17.28.130-158).
Each entry can have multiple comma delimited fields, EX: port 21,22,53,80,443 or net:1.2.3.4,55.66.77.88
<pre> #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP ACCEPT net fw udp 1194 ACCEPT net:64.233.169.104/24 fw icmp 8
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE </pre>
/etc/shorewall/masq
The masq file is required if you want your box to be a router.
This file can be read as "If someone is trying to get to a network that has access to, and that someone is coming in from then pass it through."
Note: Masq(erading) is almost always required for routing. This is based on the assumption that your internal network and your external network have completely different IP address ranges. When your firewall is fully configured for routing, it will rewrite outgoing packets to make the traffic appear to come from itself, rather then the original device on the protected lan.
EX: Device with IP address 192.168.1.101 is on the internal lan, and wants to ping 10.2.2.1 on your external lan. If your router passed the whole packet on exactly as is, 10.2.2.1 would try to respond to 192.168.1.101. It does not know which network that is, and will fail. If your router rewrites the sender as being itself (10.2.2.114) then 10.2.2.1 will know how to respond. The route then rewrites the destination on the response so it gets to 192.168.1.101.
<pre> #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC eth0 eth1
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE </pre>
Command Reference