diff --git a/STABLE/documentation/Accounting.html b/STABLE/documentation/Accounting.html
new file mode 100755
index 000000000..52e5e772a
--- /dev/null
+++ b/STABLE/documentation/Accounting.html
@@ -0,0 +1,114 @@
+
+
+
+
+
+
+
+ Shorewall Accounting
+
+
+
+
+
+
+
+ Shorewall and Traffic
+Accounting
+ |
+
+
+
+Shorewall Traffic Accounting support was added in Shorewall release
+1.4.7.
+
+Shorewall accounting rules are described in the file
+/etc/shorewall/accounting. By default, the accounting rules are placed
+in a chain called "accounting" and can
+thus be displayed using "shorewall show accounting". All traffic
+passing into, out of or through the firewall traverses the accounting
+chain including traffic that will later be rejected by interface options such as
+"tcpflags" and "maclist". If your kernel doesn't support the connection
+tracking match extension (Kernel 2.4.21) then some traffic rejected
+under 'norfc1918' will not traverse the accounting chain.
+
+The columns in the accounting file are as follows:
+
+ - ACTION - What to do when
+a match is found. Possible values are:
+
+ - COUNT- Simply count the match and continue trying to
+match the packet with the following accounting rules
+ - DONE- Count the match and don't attempt to match any following
+accounting rules.
+ - <chain> - The
+name of a chain to jump to. Shorewall will create the chain
+automatically. If the
+name of the chain is followed by ":COUNT" then a COUNT rule matching
+this rule will automatically be added to <chain>
+
+
+ - CHAIN - The name of the
+chain where the accounting rule is to be added. If empty or "-" then
+the "accounting" chain is assumed.
+
+ - SOURCE - Packet Source.
+The name of an interface, an address
+(host or net) or an interface name followed by ":" and a host or net
+address.
+ - DESTINATION - Packet
+Destination Format the same as the SOURCE
+column.
+ - PROTOCOL - A protocol
+name (from /etc/protocols) or a protocol
+number.
+ - DEST PORT - Destination
+Port number. Service name from
+/etc/services or port number. May only be specified if the protocol is
+TCP or UDP (6 or 17).
+ - SOURCE PORT- Source Port
+number. Service name from /etc/services
+or port number. May only be specified if the protocol is TCP or UDP (6
+or 17).
+
+
+In all columns except ACTION and CHAIN, the values "-","any" and
+"all" are treated as wild-cards.
+
+The accounting rules are evaluated in the Netfilter 'filter' table.
+This is the same environment where the 'rules' file rules are evaluated
+and in this environment, DNAT has already occurred in inbound packets
+and SNAT has not yet occurred on outbound ones.
+
+Accounting rules are not stateful -- each rule only handles traffic in
+one direction. For example, if eth0 is your internet interface and you
+have a web
+server in your DMZ connected to eth1 then to count HTTP traffic in
+both directions requires two rules:
+ #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE
# PORT PORT
DONE - eth0 eth1 tcp 80
DONE - eth1 eth0 tcp - 80
+Associating a counter with a chain allows for nice reporting. For
+example:
+ #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE
# PORT PORT
web:COUNT - eth0 eth1 tcp 80
web:COUNT - eth1 eth0 tcp - 80
web:COUNT - eth0 eth1 tcp 443
web:COUNT - eth1 eth0 tcp - 443
DONE web
+Now "shorewall show web" will give you a breakdown of your web traffic:
+
+
[root@gateway shorewall]# shorewall show web
Shorewall-1.4.6-20030821 Chain web at gateway.shorewall.net - Wed Aug 20 09:48:56 PDT 2003
Counters reset Wed Aug 20 09:48:00 PDT 2003
Chain web (4 references)
pkts bytes target prot opt in out source destination
11 1335 tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
18 1962 tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443
29 3297 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
[root@gateway shorewall]#
+
+ #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE
# PORT PORT
web - eth0 eth1 tcp 80
web - eth1 eth0 tcp - 80
web - eth0 eth1 tcp 443
web - eth1 eth0 tcp - 443
COUNT web eth0 eth1
COUNT web eth1 eth0
+Now "shorewall show web" simply gives you a breakdown by input and
+output:
+
+[root@gateway shorewall]# shorewall show accounting web
Shorewall-1.4.6-20030821 Chains accounting web at gateway.shorewall.net - Wed Aug 20 10:27:21 PDT 2003
Counters reset Wed Aug 20 10:24:33 PDT 2003
Chain accounting (3 references)
pkts bytes target prot opt in out source destination
8767 727K web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
11506 13M web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443
Chain web (4 references)
pkts bytes target prot opt in out source destination
8767 727K all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0
11506 13M all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0
[root@gateway shorewall]#
+Last updated 8/20/2003 - Tom Eastep
+Copyright
+© 2003 Thomas M. Eastep.
+
+
+
+
diff --git a/STABLE/documentation/CorpNetwork.htm b/STABLE/documentation/CorpNetwork.htm
new file mode 100644
index 000000000..3c441c522
--- /dev/null
+++ b/STABLE/documentation/CorpNetwork.htm
@@ -0,0 +1,285 @@
+
+
+
+
+ Corporate Shorewall Configuration
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Multiple IPs with DMZ and Internal
+ Servers
+ |
+
+
+
+
+
+
+
+Corporate Network
+
+Notes:
+
+
+
+ - This configuration is used on a corporate network that has a
+Linux (RedHat 8.0) server with three interfaces, running Shorewall 1.4.5
+ release,
+ - Make sure you know what public IP addresses are currently being
+used and verify these before starting.
+ - Verify your DNS settings before starting any Shorewall
+ configuration especially if you have split DNS.
+ - System names and Internet IP addresses have been changed to protect
+ the innocent.
+
+
+
+ Warning: This configuration
+uses a combination of Static NAT and Proxy ARP. This is generally not
+relevant to a simple configuration with a single public IP address.
+If you have just a single public IP address, most of what you see here
+won't apply to your setup so beware of copying parts of this configuration
+and expecting them to work for you. What you copy may or may not work
+in your configuration.
+
+
+
+ I have a T1 with 64 static IP addresses (192.0.18.65-127/26). The
+internet is connected to eth0. The local network is connected via eth1
+(10.10.0.0/22) and the DMZ is connected to eth2 (192.168.21.0/24). I have
+an IPSec tunnel connecting our offices in Germany to our offices in the
+US. I host two Microsoft Exchange servers for two different companies behind
+the firewall hence, the two Exchange servers in the diagram below.
+
+ Summary:
+
+
+
+ - SNAT for all systems connected to the LAN - Internal addresses
+10.10.x.x to external address 192.0.18.127.
+ - Static NAT for Polaris (Exchange Server #2). Internal address
+ 10.10.1.8 and external address 192.0.18.70.
+ - Static NAT for Sims (Inventory Management server). Internal
+ address 10.10.1.56 and external address 192.0.18.75.
+
+ - Static NAT for Project (Project Web Server). Internal address
+ 10.10.1.55 and external address 192.0.18.84.
+ - Static NAT for Fortress (Exchange Server). Internal address
+ 10.10.1.252 and external address 192.0.18.93.
+ - Static NAT for BBSRV (Blackberry Server). Internal address
+ 10.10.1.230 and external address 192.0.18.97.
+ - Static NAT for Intweb (Intranet Web Server). Internal address
+ 10.10.1.60 and external address 192.0.18.115.
+
+
+
+ The firewall runs on a 2Gb, Dual PIV/2.8GHz, Intel motherboard with
+ RH8.0.
+
+ The Firewall is also a proxy server running Privoxy 3.0.
+
+ The single system in the DMZ (address 192.0.18.80) runs sendmail, imap,
+ pop3, DNS, a Web server (Apache) and an FTP server (vsFTPd 1.1.0). That
+server is managed through Proxy ARP.
+
+ All administration and publishing is done using ssh/scp. I have X installed
+ on the firewall and the system in the DMZ. X applications tunnel through
+SSH to Hummingbird Exceed running on a PC located in the LAN. Access to
+the firewall using SSH is restricted to systems in the LAN, DMZ or the
+system Kaos which is on the Internet and managed by me.
+
+ 
+
+
+
+
+ The Ethernet 0 interface in the Server is configured with IP address
+ 192.0.18.68, netmask 255.255.255.192. The server's default gateway is
+ 192.0.18.65, the Router connected to my network and the ISP. This is the
+ same default gateway used by the firewall itself. On the firewall, Shorewall
+ automatically adds a host route to 192.0.18.80 through Ethernet 2 (192.168.21.1)
+because of the entry in /etc/shorewall/proxyarp (see below). I modified
+the start, stop and init scripts to include the fixes suggested when having
+an IPSec tunnel.
+
+ Some Mistakes I Made:
+
+ Yes, believe it or not, I made some really basic mistakes when building
+ this firewall. Firstly, I had the new firewall setup in parallel with the
+old firewall so that there was no interruption of service to my users.
+During my out-bound testing, I set up systems on the LAN to utilize the
+firewall which worked fine. When testing my NAT connections, from the outside,
+these would fail and I could not understand why. Eventually, I changed
+the default route on the internal system I was trying to access, to point
+to the new firewall and "bingo", everything worked as expected. This oversight
+delayed my deployment by a couple of days not to mention level of frustration
+it produced.
+
+ Another problem that I encountered was in setting up the Proxyarp system
+in the DMZ. Initially I forgot to remove the entry for the eth2 from the
+ /etc/shorewall/masq file. Once my file settings were correct, I started
+ verifying that the ARP caches on the firewall, as well as the outside system
+ "kaos", were showing the correct Ethernet MAC address. However, in testing
+ remote access, I could access the system in the DMZ only from the firewall
+and LAN but not from the Internet. The message I received was "connection
+denied" on all protocols. What I did not realize was that a "helpful"
+administrator that had turned on an old system and assigned the same address
+as the one I was using for Proxyarp without notifying me. How did I work
+this out. I shutdown the system in the DMZ, rebooted the router and flushed
+the ARP cache on the firewall and kaos. Then, from kaos, I started pinging
+that IP address and checked the updated ARP cache and lo-and-behold a
+different MAC address showed up. High levels of frustration etc., etc.
+The administrator will not be doing that again! :-)
+
+ Lessons Learned:
+
+
+ - Read the documentation.
+ - Draw your network topology before starting.
+ - Understand what services you are going to allow in and out of the
+ firewall, whether they are TCP or UDP packets and make a note of these
+port numbers.
+ - Try to get quiet time to build the firewall - you need to focus
+on the job at hand.
+ - When asking for assistance, be honest and include as much detail
+as requested. Don't try and hide IP addresses etc., you will probably
+screw up the logs and make receiving assistance harder.
+ - Read the documentation.
+
+
+
+ Futures:
+
+ This is by no means the final configuration. In the near future, I will
+be moving more systems from the LAN to the DMZ. I will also be watching
+the logs for port scan programs etc. but, this should be standard security
+ maintenance.
+
+ Here are copies of my files. I have removed most of the internal documentation
+for the purpose of this space however, my system still has the original
+files with all the comments and I highly recommend you do the same.
+
+
+Shorewall.conf
+
+
+ ##############################################################################
# /etc/shorewall/shorewall.conf V1.4 - Change the following variables to
# match your setup
#
# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
# This file should be placed in /etc/shorewall
#
# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net)
##############################################################################
# L O G G I N G
##############################################################################
LOGFILE=/var/log/messages
LOGFORMAT="Shorewall:%s:%s:"
LOGRATE=
LOGBURST=
LOGUNCLEAN=info
BLACKLIST_LOGLEVEL=
LOGNEWNOTSYN=
MACLIST_LOG_LEVEL=info
TCP_FLAGS_LOG_LEVEL=debug
RFC1918_LOG_LEVEL=debug
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SUBSYSLOCK=/var/lock/subsys/shorewall
STATEDIR=/var/lib/shorewall
MODULESDIR=
FW=fw
NAT_ENABLED=Yes
MANGLE_ENABLED=Yes
IP_FORWARDING=On
ADD_IP_ALIASES=Yes
ADD_SNAT_ALIASES=Yes
TC_ENABLED=Yes
CLEAR_TC=No
MARK_IN_FORWARD_CHAIN=No
CLAMPMSS=No
ROUTE_FILTER=Yes
NAT_BEFORE_RULES=No
MULTIPORT=Yes
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
NEWNOTSYN=Yes
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
TCP_FLAGS_DISPOSITION=DROP
#LAST LINE -- DO NOT REMOVE
+
+
+Zones File
+
+
+ #
# Shorewall 1.4 -- Sample Zone File For Two Interfaces
# /etc/shorewall/zones
#
# This file determines your network zones. Columns are:
#
# ZONE Short name of the zone
# DISPLAY Display name of the zone
# COMMENTS Comments about the zone
#
#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local Networks
dmz DMZ Demilitarized Zone
vpn1 VPN1 VPN to Germany
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+
+Interfaces File:
+
+
+ ##############################################################################
+ #ZONE INTERFACE BROADCAST OPTIONS
+ net eth0 62.123.106.127 routefilter,norfc1918,blacklist,tcpflags
+ loc eth1 detect dhcp,routefilter
+ dmz eth2 detect
+ vpn1 ipsec0
+ #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+
+Routestopped File:
+
+
+ #INTERFACE HOST(S)
eth1 -
eth2 -
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+
+Policy File:
+
+
+ ###############################################################################
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
loc fw ACCEPT
loc dmz ACCEPT
# If you want open access to the Internet from your Firewall
# remove the comment from the following line.
fw net ACCEPT
fw loc ACCEPT
fw dmz ACCEPT
dmz fw ACCEPT
dmz loc ACCEPT
dmz net ACCEPT
#
# Adding VPN Access
loc vpn1 ACCEPT
dmz vpn1 ACCEPT
fw vpn1 ACCEPT
vpn1 loc ACCEPT
vpn1 dmz ACCEPT
vpn1 fw ACCEPT
#
net all DROP info
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+
+Masq File:
+
+
+ #INTERFACE SUBNET ADDRESS
eth0 eth1 1192.0.18.126
#
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+
+NAT File:
+
+
+ #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
#
# Intranet Web Server
192.0.18.115 eth0:0 10.10.1.60 No No
#
# Project Web Server
192.0.18.84 eth0:1 10.10.1.55 No No
#
# Blackberry Server
192.0.18.97 eth0:2 10.10.1.55 No No
#
# Corporate Mail Server
192.0.18.93 eth0:3 10.10.1.252 No No
#
# Second Corp Mail Server
192.0.18.70 eth0:4 10.10.1.8 No No
#
# Sims Server
192.0.18.75 eth0:5 10.10.1.56 No No
#
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+
+Proxy ARP File:
+
+
+ #ADDRESS INTERFACE EXTERNAL HAVEROUTE
#
# The Corporate email server in the DMZ
192.0.18.80 eth2 eth0 No
#
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+
+Tunnels File:
+
+
+ # TYPE ZONE GATEWAY GATEWAY ZONE PORT
ipsec net 134.147.129.82
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+
+Rules File (The shell variables are set in /etc/shorewall/params):
+
+
+ ##############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
#
# Accept DNS connections from the firewall to the network
#
ACCEPT fw net tcp 53
ACCEPT fw net udp 53
#
# Accept SSH from internet interface from kaos only
#
ACCEPT net:192.0.18.98 fw tcp 22
#
# Accept connections from the local network for administration
#
ACCEPT loc fw tcp 20:22
ACCEPT loc net tcp 22
ACCEPT loc fw tcp 53
ACCEPT loc fw udp 53
ACCEPT loc net tcp 53
ACCEPT loc net udp 53
#
# Allow Ping To And From Firewall
#
ACCEPT loc fw icmp 8
ACCEPT loc dmz icmp 8
ACCEPT loc net icmp 8
ACCEPT dmz fw icmp 8
ACCEPT dmz loc icmp 8
ACCEPT dmz net icmp 8
DROP net fw icmp 8
DROP net loc icmp 8
DROP net dmz icmp 8
ACCEPT fw loc icmp 8
ACCEPT fw dmz icmp 8
DROP fw net icmp 8
#
# Accept proxy web connections from the inside
#
ACCEPT loc fw tcp 8118
#
# Forward PcAnywhere, Oracle and Web traffic from outside to the Demo systems
# From a specific IP Address on the Internet.
#
# ACCEPT net:207.65.110.10 loc:10.10.3.151 tcp 1521,http
# ACCEPT net:207.65.110.10 loc:10.10.2.32 tcp 5631:5632
#
# Intranet web server
ACCEPT net loc:10.10.1.60 tcp 443
ACCEPT dmz loc:10.10.1.60 tcp 443
#
# Projects web server
ACCEPT net loc:10.10.1.55 tcp 80
ACCEPT dmz loc:10.10.1.55 tcp 80
#
# Blackberry Server
ACCEPT net loc:10.10.1.230 tcp 3101
#
# Corporate Email Server
ACCEPT net loc:10.10.1.252 tcp 25,53,110,143,443
#
# Corporate #2 Email Server
ACCEPT net loc:10.10.1.8 tcp 25,80,110,443
#
# Sims Server
ACCEPT net loc:10.10.1.56 tcp 80,443
ACCEPT net loc:10.10.1.56 tcp 7001:7002
ACCEPT net:63.83.198.0/24 loc:10.10.1.56 tcp 5631:5632
#
# Access to DMZ
ACCEPT loc dmz udp 53,177
ACCEPT loc dmz tcp 80,25,53,22,143,443,993,20,110 -
ACCEPT net dmz udp 53
ACCEPT net dmz tcp 25,53,22,21,123
ACCEPT dmz net tcp 25,53,80,123,443,21,22
ACCEPT dmz net udp 53
#
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+
+Start File:
+
+
+ ############################################################################
# Shorewall 1.4 -- /etc/shorewall/start
#
# Add commands below that you want to be executed after shorewall has
# been started or restarted.
#
qt service ipsec start
+
+
+Stop File:
+
+
+ ############################################################################
# Shorewall 1.4 -- /etc/shorewall/stop
#
# Add commands below that you want to be executed at the beginning of a
# "shorewall stop" command.
#
qt service ipsec stop
+
+
+Init File:
+
+
+ ############################################################################
# Shorewall 1.4 -- /etc/shorewall/init
#
# Add commands below that you want to be executed at the beginning of
# a "shorewall start" or "shorewall restart" command.
#
qt service ipsec stop
+
+
+Last updated 7/16/2003
+
+
+
+
+Copyright 2003 Thomas M. Eastep and
+Graeme Boyle
+
+
+
+
+
diff --git a/STABLE/documentation/GenericTunnels.html b/STABLE/documentation/GenericTunnels.html
new file mode 100644
index 000000000..6509a4249
--- /dev/null
+++ b/STABLE/documentation/GenericTunnels.html
@@ -0,0 +1,203 @@
+
+
+
+
+ Generic Tunnels
+
+
+
+
+
+
+
+
+ Generic Tunnels
+ |
+
+
+
+Shorewall includes built-in support for a wide range of VPN solutions.
+If you have need for a tunnel type that does not have explicit support,
+you can generally describe the tunneling software using "generic
+tunnels"
+Bridging two Masqueraded Networks
+Suppose that we have the following situation:
+ 
+We want systems in the 192.168.1.0/24 subnetwork to be
+able to communicate with the systems in the 10.0.0.0/8 network. This is
+accomplished through use of the /etc/shorewall/tunnels file, the
+/etc/shorewall/policy file and the /etc/shorewall/tunnel script that is
+included with Shorewall.
+
+Suppose that you have tunneling software that uses two
+different protocols:
+
+a) TCP port 1071
+b) GRE (Protocol 47)
+c) The tunnel interface on system A is "tun0" and the tunnel interface
+on system B is also "tun0".
+
+On each firewall, you will need to declare a zone to
+represent the remote subnet. We'll assume that this zone is called
+'vpn' and declare it in /etc/shorewall/zones on both systems as follows.
+
+
+
+
+ | ZONE |
+ DISPLAY |
+ COMMENTS |
+
+
+ | vpn |
+ VPN |
+ Remote Subnet |
+
+
+
+
+On system A, the 10.0.0.0/8 will comprise the vpn
+zone.
+In /etc/shorewall/interfaces:
+
+
+
+
+ | ZONE |
+ INTERFACE |
+ BROADCAST |
+ OPTIONS |
+
+
+ | vpn |
+ tun0 |
+ 10.255.255.255 |
+ |
+
+
+
+
+In /etc/shorewall/tunnels on system A, we need the
+following:
+
+
+
+
+ | TYPE |
+ ZONE |
+ GATEWAY |
+ GATEWAY ZONE |
+
+
+ generic:tcp:1071
+ |
+ net |
+ 134.28.54.2 |
+ |
+
+
+ generic:47
+ |
+ net
+ |
+ 134.28.54.2
+ |
+
+ |
+
+
+
+
+These entries in /etc/shorewall/tunnels, opens the firewall so that
+TCP port 1071 and the Generalized Routing Encapsulation Protocol (47)
+will be accepted to/from the remote gateway.
+
+
+
+
+ | ZONE |
+ INTERFACE |
+ BROADCAST |
+ OPTIONS |
+
+
+ | vpn |
+ tun0 |
+ 192.168.1.255 |
+ |
+
+
+
+
+In /etc/shorewall/tunnels on system B, we have:
+
+
+
+
+ | TYPE |
+ ZONE |
+ GATEWAY |
+ GATEWAY ZONE |
+
+
+ generic:tcp:1071
+ |
+ net |
+ 206.191.148.9 |
+ |
+
+
+ generic:47
+ |
+ net
+ |
+ 134.28.54.2
+ |
+
+ |
+
+
+
+
+ You will need to allow traffic between the "vpn" zone
+and the "loc" zone on both systems -- if you simply want to admit all
+traffic in both directions, you can use the policy file:
+
+
+
+
+ | SOURCE |
+ DEST |
+ POLICY |
+ LOG LEVEL |
+
+
+ | loc |
+ vpn |
+ ACCEPT |
+ |
+
+
+ | vpn |
+ loc |
+ ACCEPT |
+ |
+
+
+
+
+On both systems, restart Shorewall and start your VPN software on
+each system. The systems in the two masqueraded subnetworks
+can now talk to each other
+Updated 8/9/2003 - Tom Eastep
+
+Copyright © 2001, 2002, 2003Thomas M. Eastep.
+
+
+
+
diff --git a/STABLE/documentation/UserSets.html b/STABLE/documentation/UserSets.html
new file mode 100644
index 000000000..33b457072
--- /dev/null
+++ b/STABLE/documentation/UserSets.html
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+
+ Controlling Traffic by UID/GID
+
+
+
+
+
+
+
+ Controlling Output
+Traffic by UID/GID
+
+ |
+
+
+
+This capability was added in Shorewall release
+1.4.7.
+
+Netfilter provides the capability to filter packets generated on the
+firewall system by User Id and/or Group Id. Shorewall provides two
+separate but related ways to use this Netfilter capability:
+
+ - Shorewall allows you to
+define collections of users called "User Sets"
+and then to restrict
+certain rules in /etc/shorewall/rules to a given User Set.
+ - Shorewall also allows you to restrict a given rule
+ to a particular user and/or group.
+
+
+Since only packets created by programs running on the Shorewall box
+itself, only rules whose SOURCE is the firewall ($FW) may be restricted
+using either of the facilities.
+User Sets
+
+Given the way that this facility is implemented in Shorewall, it is not
+possible to control logging of individual rules using a User Set and
+logging is rather specified on the User Set itself.
+
+User Sets are defined in the /etc/shorewall/usersets file. Columns in
+that file include:
+
+USERSET
+ The name of a User Set. Must be a legal
+shell
+identifier of no more than six (6) characters in length.
+REJECT
+Log level for connections rejected for this User Set.
+ACCEPT Log
+level for connections accepted for this User Set.
+DROP
+ Log level for connections dropped for this User Set.
+
+
+In the REJECT and ACCEPT columns, if you don't want to specify a value
+in the column but you want to specify a value in a following column,
+you may enter "-".
+
+Users and/or groups are added to User Sets using the
+/etc/shorewall/users file. Columns in that file are:
+
+USERSET
+ The name of a User Set defined in
+/etc/shorewall/usersets.
+USER
+ The name of a user defined on the system or a user number.
+GROUP
+The name of a group defined on the system or a number.
+
+Only one of the USER and GROUP
+column needs to be non-empty. If you wish to specify a GROUP but not a
+USER, enter "-" in the user column.
+
+If both USER and GROUP are
+specified then only programs running under that USER:GROUP pair will
+match rules specifying the User Set named in the USERSET column.
+
+Once a user set has been defined, its name may be
+placed in the USER SET column of the /etc/shorewall/rules file. IMPORTANT:
+When
+the name of a user set is given in the USER SET column, you may not
+include a log level in the ACTION column; logging of such rules is
+governed solely by the user set's definition in the
+/etc/shorewall/userset file.
+
+Example: You want members of the
+'admin' group and 'root' to be able to use ssh on the firewall to
+connect to local systems. You want to log all connections accepted for
+these users using syslog at the 'info' level.
+
+
+/etc/shorewall/usersets
+
+#USERSET REJECT ACCEPT DROP
admins - info
+
+/etc/shorewall/users
+
+
+#USERSET USER GROUP
admins - admin
admins root
+/etc/shorewall/rules
+
+#ACTION SOURCE DESTINATION PROTO PORT SOURCE ORIGINAL RATE USER
# PORT(S) DESTINATION SET
ACCEPT $FW loc tcp 22 - - - admins
+Restricting a rule to a particular user and/or
+group
+
+In cases where you may want to restrict a rule to a particular user
+and/or group, the USER SET column in the rules file may be specified as:
+
+[ <
user
+name or number> ] : [ <
group
+name or number> ]
+
+
+
+
+Example: You want user mail to
+be able to send email from the firewall to the local net zone
+
+/etc/shorewall/rules (be sure to note
+the ":" in the USER SET column entry).
+
#ACTION SOURCE DESTINATION PROTO PORT SOURCE ORIGINAL RATE USER
# PORT(S) DESTINATION SET
ACCEPT $FW loc tcp 25 - - - mail:
+
Last updated 9/19/2003 - Tom Eastep
+Copyright
+© 2003 Thomas M. Eastep.
+
+
diff --git a/STABLE/documentation/images/CorpNetwork.gif b/STABLE/documentation/images/CorpNetwork.gif
new file mode 100644
index 000000000..e67ac92cd
Binary files /dev/null and b/STABLE/documentation/images/CorpNetwork.gif differ
diff --git a/STABLE/documentation/images/Logo3.png b/STABLE/documentation/images/Logo3.png
new file mode 100755
index 000000000..ef7860115
Binary files /dev/null and b/STABLE/documentation/images/Logo3.png differ
diff --git a/STABLE/documentation/images/Tom.jpg b/STABLE/documentation/images/Tom.jpg
new file mode 100755
index 000000000..965430cd1
Binary files /dev/null and b/STABLE/documentation/images/Tom.jpg differ
diff --git a/STABLE/documentation/images/penquin_in_blue_racer_sm2.gif b/STABLE/documentation/images/penquin_in_blue_racer_sm2.gif
new file mode 100755
index 000000000..c89802dbd
Binary files /dev/null and b/STABLE/documentation/images/penquin_in_blue_racer_sm2.gif differ
diff --git a/STABLE/documentation/images/razor.gif b/STABLE/documentation/images/razor.gif
new file mode 100644
index 000000000..d38299f1c
Binary files /dev/null and b/STABLE/documentation/images/razor.gif differ
diff --git a/STABLE/documentation/shorewall_setup_guide_fr.htm b/STABLE/documentation/shorewall_setup_guide_fr.htm
new file mode 100644
index 000000000..6c4222c77
--- /dev/null
+++ b/STABLE/documentation/shorewall_setup_guide_fr.htm
@@ -0,0 +1,2524 @@
+
+
+
+
+
+ Shorewall Setup Guide
+
+
+
+
+
+
+ Guide de Configuration
+de Shorewall
+
+ |
+
+
+
+
+Note du traducteur :
+Je remercie l'équipe Shorewall, pour ce firewall
+formidable et l'aide personnelle que m'a donné Tom
+Eastep.
+J'espère que cette traduction vous aidera à utiliser efficacement ce
+firewall.
+Toutefois, si ce manuel comporte des lacunes, des incohérences ou afin
+d'améliorer sa compréhension,
+n'hésitez pas à me contacter fabien
+demassieux
+1.0 Introduction
+2.0 Concepts de Shorewall
+3.0 Interfaces Réseaux
+4.0 Adresses, Sous/Réseaux et Routage
+
+ 4.1 Adresses IP
+ 4.2 Sous-réseaux
+ 4.3 Routage
+ 4.4 Protocole de Résolution d'Adresses (ARP)
+ 4.5 RFC 1918
+
+5.0 Configurer votre Réseau
+
+ 5.1 Routé
+ 5.2 Non-routé
+
+ 5.2.1 SNAT
+ 5.2.2 DNAT
+ 5.2.3 Proxy ARP
+ 5.2.4 Static NAT
+
+ 5.3 Règles
+ 5.4 D'autres petites choses
+
+
+6.0 DNS
+7.0 Démarrer et Arrêter le firewall
+1.0 Introduction
+Ce guide est destiné aux utilisateurs qui configurent Shorewall dans
+un environnement ou un ensemble d'adresses IP publiques doivent être
+prises en compte ou à ceux qui souhaitent en savoir plus à propos de
+Shorewall que ce que contient le guide pour une utilisation Simple Adresse.
+Parce que le champ d'utilisation est si élevé, le guide vous donnera
+les
+indications générales à suivre et vous renseignera sur d'autres
+ressources si nécessaire.
+
Si vous
+utilisez LEAF
+Bering, votre configuration Shorewall n'est PAS ce que je publie
+-- Je suggère de prendre en considération l'installation de Shorewall
+LPR disponible sur le site de shorewall.net avant de poursuivre.
+Shorewall nécessite que le package iproute/iproute2 soit installé
+(sur RedHat, le package s'appelle iproute). Vous pouvez
+voir si le package est installé grâce au programme ip sur votre
+système firewall. En tant que root, vous pouvez utiliser la commande
+'which' pour vérifier que le programme est présent:
+ [root@gateway root]# which ip
/sbin/ip
[root@gateway root]#
+Je vous recommande de parcourir en premier le guide pour vous
+familiariser avec ce que cela implique puis de le reprendre afin de
+modifier votre configuration. Les Points de configuration à changer
+sont
+précédés du symbole 
.
+ Si vous
+éditez vos fichiers
+de configuration sous un système d'exploitation Windows, vous devez
+sauvegarder ceux-ci en tant que fichiers formatés Unix si votre éditeur
+le permet ou utiliser la commande dos2unix avant de les utiliser avec
+Shorewall. Idem si vous transférez vos fichiers par l'intermédiaire du
+lecteur de disquette de Windows.
+
+2.0 Concepts de Shorewall
+
+Les fichiers de configuration de Shorewall se trouvent dans le
+répertoire /etc/shorewall -- pour la plus par des paramétrages, vous
+avez juste besoin de quelques-uns d'entre eux comme cela est décrit
+dans
+le manuel. Des squelettes de fichiers sont créés durant La procédure d'installation de
+Shorewall.
+Comme chaque fichier est abordé, je vous suggère de regarder celui
+de votre système -- chaque fichier contient des instructions détaillées
+de configuration et d'autres des entrées par défaut.
+Shorewall voit le réseau ou il opère comme composé d'un ensemble de zones.
+Dans la configuration par défaut, les zones suivantes sont utilisées:
+
+
+
+ | Nom |
+ Description |
+
+
+ | net |
+ L'Internet |
+
+
+ | loc |
+ Votre réseau local
+ |
+
+
+ | dmz |
+ Zone Démilitarisée
+ |
+
+
+
+Les Zones sont définies
+dans
+le fichier
+/etc/shorewall/zones.
+Shorewall reconnaît aussi le système firewall comme sa propre zone -
+par défaut, le firewall lui-même est connu sous le nom fw
+cela peut être modifié dans le fichier /etc/shorewall/shorewall.conf
+. Dans ce guide, le nom par défaut (fw) sera utilisé.
+
+Mise à par fw, Shorewall n'attache aucune importance au nom
+des zones. Les Zones sont entièrement ce que VOUS en faites. Cela veut
+dire que vous ne devez pas vous attendre à ce que Shorewall fasse
+quelque chose de spécial "car il s'agit de la zone Internet" ou "car
+c'est la zone DMZ".
+ Editez
+le fichier
+/etc/shorewall/zones et faites tout changement qui s'impose.
+Les Règles qui concernent le trafic à autoriser ou à refuser sous
+exprimés en terme de Zones.
+
+ Shorewall est construit sur les possibilités du noyau (kernel) Netfilter. Netfilter implémente
+une fonction
+de tracking qui autorise ce qui est souvent désigné comme une
+inspection déclarée de paquets. Les propriétés de déclaration permettent au firewall
+d'être définie en terme de connexions plutôt qu'en terme de
+paquet. Avec Shorewall, vous:
+
+ - Identifiez la zone source.
+ - Identifiez la zone destination.
+ - Si la POLICE de la zone client vers la zone client est ce que
+vous souhaitez pour cette paire client/serveur, vous n'avez besoin de
+rien de plus.
+ - Si la POLICE n'est pas ce que vous souhaitez, alors vous devez
+ajouter une règle. Cette règle est exprimé en terme de zone client et
+de zone serveur.
+
+Si les connexions d'un certain type sont autorisés de la zone A au
+firewall et sont aussi autorisés du firewall à la zone B cela NE VEUT PAS dire que ces connections sont
+autorisés de la zone A à la zone B. Cela veut plutôt
+dire que vous avez un proxy qui tourne sur le firewall qui accepte les
+connections de la zone A et qui ensuite établit ces propres connections
+du firewall à la zone B.
+Pour chaque requête de connexion sur le firewall, la requête est
+d'abord évalué à travers le fichier /etc/shorewall/rules file. Si
+aucune
+règle dans ce fichier ne correspond, la connexion interroge ensuite la
+première police dans /etc/shorewall/policy qui correspond à la
+requête et l'applique. Si cette police est REJECT ou DROP, la
+requête est a nouveau évaluée à travers les règles du fichier
+/etc/shorewall/common.def.
+Le fichier de défaut /etc/shorewall/policy a les polices suivantes:
+
+
+
+
+ Zone Source
+ |
+ Zone Destination
+ |
+ Police |
+ Niveau de Log |
+ Limit:Burst |
+
+
+ | loc |
+ net |
+ ACCEPT |
+ |
+ |
+
+
+ | net |
+ all |
+ DROP |
+ info |
+ |
+
+
+ | all |
+ all |
+ REJECT |
+ info |
+ |
+
+
+
+
+La police précédente:
+
+ - Permet toutes les connexions de votre réseau local vers Internet,
+ - Drop (ignore) toutes les connexions d'Internet vers le firewall
+ou votre réseau local et génère un message au niveau info (ici se trouve la
+description des niveaux de log).
+ - Rejette toutes les autres connexions et génère un message au
+niveau info. Quant la requête est rejeté, le firewall retourne
+un RST (si le protocole est TCP) ou un ICMP port-unreachable paquet
+pour
+les autres protocoles.
+
+
+Maintenant, éditez votre
+/etc/shorewall/policy et apportez tous les changements que vous
+souhaitez.
+3.0 Interfaces Réseau
+Pour le reste de ce guide, nous utiliserons le schéma
+ci-dessous. Bien qu'il ne puisse correspondre à votre propre réseau, il
+peut être utilisé pour illustrer les aspects importants de la
+configuration de Shorewall.
+Sur ce schéma:
+
+ - La zone DMZ est composée des systèmes DMZ 1 et DMZ 2. Une DMZ est
+utilisée pour isoler vos serveurs accessibles depuis Internet de vos
+systèmes locaux. Ainsi si un de ces serveurs est compromis, vous avez
+encore votre firewall entre le système compromis et vos systèmes locaux.
+ - La zone Local est composée des systèmes Local 1, Local 2 et Local
+3.
+ - Tous les systèmes du FAI vers l'extérieur et qui
+
+ - englobe la Zone Internet.
+
+ 
+La façon la plus simple pour définir les zones est
+d'associer le nom de la zone (définie précédemment dans
+/etc/shorewall/zones) avec une interface réseau.
+C'est fait dans le fichier /etc/shorewall/interfaces.
+Le firewall illustré ci-dessus à trois interfaces. Si
+la connexion se fait à travers un câble ou un "modem" DSL , l'Interface
+Externe sera l'adaptateur qui est branché au "Modem" (e.g., eth0) tant
+que vous ne vous n'utilisez pas le Point-to-Point Protocol
+over Ethernet (PPPoE) ou le Point-to-PointTunnelingProtocol(PPTP)
+dans ce cas l'Interface Externe sera de type ppp (e.g., ppp0).
+Si vous vous connectez à travers un modem classique, votre Interface
+Externe sera également ppp0. Si vous utilisez ISDN, votre
+Interface Externe sera ippp0.
+
+ Si votre Interface Externe est ppp0 ou
+ippp0
+alors vous pouvez fixer CLAMPMSS=yes dans
+/etc/shorewall/shorewall.conf.
+Votre Interface Locale doit être un adaptateur
+Ethernet (eth0, eth1 or eth2) et doit être connecté à un hub ou
+un
+switch. Vos ordinateurs locaux doivent être connectés au même
+switch (note: Si vous avez une machine unique, vous pouvez connecter le
+firewall directement à l'ordinateur en utilisant un câble croisé).
+Votre Interface DMZ doit aussi
+être un adaptateur Ethernet (eth0, eth1 or eth2) et doit être connecté
+à un hub ou un switch. Vos ordinateurs DMZ doivent être
+connectés au même switch (note: Si vous avez une machine DMZ unique,
+vous pouvez connecter le firewall directement à l'ordinateur en
+utilisant un câble croisé).
+ Ne
+pas connecter plus d'une interface au même hub ou switch (sauf pour
+tester). Cela ne fonctionne pas comme vous pourriez vous y attendre et
+vous terminerez confus en croyant que le réseau ne fonctionne pas
+entièrement.
+
+Pour le besoin de ce Guide, nous décidons que:
+
+ -
+
L'interface externe est eth0.
+
+ -
+
L'interface locale est eth1.
+
+ -
+
L'interface DMZ est eth2.
+
+
+La configuration par défaut de Shorewall ne définit pas
+le contenu de chaque zone. Pour définir la précédente configuration en
+utilisant le fichier
+/etc/shorewall/interfaces file, ce fichier doit contenir:
+
+
+
+
+ | Zone |
+ Interface |
+ Broadcast |
+ Options |
+
+
+ | net |
+ eth0 |
+ detect |
+ norfc1918 |
+
+
+ | loc |
+ eth1 |
+ detect |
+ |
+
+
+ | dmz |
+ eth2 |
+ detect |
+ |
+
+
+
+
+
+ Editer le fichier /etc/shorewall/interfaces et
+définissez les interfaces du réseau sur votre firewall et associez
+chaque interface avec une zone. Si vous avez une zone qui est
+interfacée
+avec plus d'une interface, incluez simplement une entrée pour chaque
+interface et répéter le nom de zone autant de fois que nécessaire.
+Exemple:
+
+
+
+
+ | Zone |
+ Interface |
+ Broadcast |
+ Options |
+
+
+ | net |
+ eth0 |
+ detect |
+ norfc1918 |
+
+
+ | loc |
+ eth1 |
+ detect |
+ |
+
+
+ | loc |
+ eth2 |
+ detect |
+ dhcp |
+
+
+
+
+
+
Si vous avez plus d'une interface pour une zone, vous
+voudrez probablement une police qui permet le trafic intra-zone:
+
+
+
+
+
+ | Source Zone |
+ Destination Zone |
+ Policy |
+ Log Level |
+ Limit:Burst |
+
+
+ | loc |
+ loc |
+ ACCEPT |
+ |
+ |
+
+
+
+
+
+ Vous pouvez définir des zones plus compliquées en
+utilisant le fichier /etc/shorewall/hosts
+mais dans la plus part des cas, ce n'est pas nécessaire.
+4.0 Adressage, Sous-réseaux
+et Routage
+Normalement, votre FAI vous assigne des adresses
+Publiques. Vous pouvez configurer l'interface externe du firewall
+en utilisant l'une de ces adresses permanentes et vous pouvez décider
+comment utiliser le reste de vos adresses.
+Si vous êtes déjà familier avec l'adressage IP et le
+routage, vous pouvez aller à la prochaine section.
+La discussion suivante aborde tout juste les concepts
+d'adressage et de routage. Si vous souhaitez approfondir vos
+connaissances sur ce sujet, je vous recommande vivement l'ouvrage
+"IP
+Fundamentals: What Everyone Needs to Know about Addressing &
+Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
+4.1 Adressage IP
+
+L'adressage IP version 4 (IPv4) est codé sur
+32-bit. La notation w.x.y.z se réfère à une adresse dont le byte
+d'ordre
+supérieur est "w", le suivant à pour valeur "x", etc. Si nous prenons
+l'adresse 192.0.2.14 et l'exprimons en hexadécimal, nous obtenons:
+
+ C0.00.02.0E
+
+ou l'exprimons comme un entier de 32-bit
+
+ C000020E
+
+4.2 Sous -réseaux
+
+Vous entendrez toujours les termes "réseaux de Class
+A", "réseaux de Class B" et "réseaux de Class C". Au début de
+l'existence de l'IP, les réseaux ne comportez que trois tailles (il y
+avait aussi le réseau de Class D mais il étaient utilisés différemment):
+
+ Classe A - masque réseau 255.0.0.0, taille = 2 ** 24
+ Classe B - masque réseau 255.255.0.0, taille = 2 ** 16
+ Classe C - masque réseau 255.255.255.0, taille = 256
+
+La taille d'un réseau était uniquement déterminé par la
+valeur du byte de l'ordre supérieur, ainsi vous pouviez regarder une
+adresse IP et déterminer immédiatement le masque réseau. Le masque réseau est
+un nombre qui se termine logiquement avec une adresse qui isole le numéro de réseau; le reste de
+l'adresse est le numéro d'hôte. Par exemple, dans la Classe C
+l'adresse 192.0.2.14, le numéro hexadécimal du réseau est C00002 et le
+numéro hexadécimal d'hôte est 0E.
+Comme l'Internet se développait, il semblait clair que
+la classification en adressage 32-bit allait devenir très limité
+(rapidement, les grandes sociétés et les universités s'étaient assigné
+leur propre réseau de classe A!). Après quelques faux départs, la
+technique courante du sous-adressage
+de
+ces réseaux en plus petits sous-réseaux
+évolua; cette technique est consignée par le Classless Inter Domain
+Routing (CIDR). Aujourd'hui, tous les systèmes avec lesquels vous
+travaillerez comprennent probablement la notation CIDR. Le réseau
+basé sur les Classes est du domaine du passé .
+Un sous-réseau (aussi appelé subnetwork et subnet)
+est un ensemble d'adresses IP tel que:
+
+ -
+
Le nombre d'adresses dans le jeu est un multiple de
+2; et
+
+ -
+
La première adresse dans le jeu est un multiple de
+la taille du jeu.
+
+ -
+
La première adresse du sous-réseau est réservée et
+se réfère à l'adresse du sous-réseau.
+
+ -
+
La dernière adresse du sous-réseau est réservée
+comme adresse broadcast du sous-réseau.
+
+
+Comme vous pouvez voir dans cette définition, dans
+chacun des sous-réseau de taille n il y a (n - 2)
+adresses
+utilisables (adresses qui peuvent être assignées aux hôtes). La
+première
+et la dernière adresse du sous-réseau sont respectivement utilisées
+pour
+l'adresse du sous-réseau et de l'adresse broadcast du sous-réseau. En
+conséquence, les petits réseaux sont plus gaspilleur d'adresses IP que
+les grands.
+Comme n est un multiple de deux, nous pouvons
+facilement calculer le Logarithme
+Naturel (log2) de n. Pour les sous-réseaux
+les plus communs, la taille et son logarithme naturel sont donnés dans
+la table suivante:
+
+
+
+
+ | n |
+ log2 n |
+ (32 - log2 n) |
+
+
+ | 8 |
+ 3 |
+ 29 |
+
+
+ | 16 |
+ 4 |
+ 28 |
+
+
+ | 32 |
+ 5 |
+ 27 |
+
+
+ | 64 |
+ 6 |
+ 26 |
+
+
+ | 128 |
+ 7 |
+ 25 |
+
+
+ | 256 |
+ 8 |
+ 24 |
+
+
+ | 512 |
+ 9 |
+ 23 |
+
+
+ | 1024 |
+ 10 |
+ 22 |
+
+
+ | 2048 |
+ 11 |
+ 21 |
+
+
+ | 4096 |
+ 12 |
+ 20 |
+
+
+ | 8192 |
+ 13 |
+ 19 |
+
+
+ | 16384 |
+ 14 |
+ 18 |
+
+
+ | 32768 |
+ 15 |
+ 17 |
+
+
+ | 65536 |
+ 16 |
+ 16 |
+
+
+
+
+Vous pourrez voir que la table ci-dessus contient aussi
+une colonne (32 - log2 n). Ce nombre est la Variable de Longueur du Masque de
+Sous-réseau (VLSM Variable Length Subnet Mask) pour
+un réseau de taille n. De la
+table ci-dessus, nous pouvons dériver celle-ci, ce qui est plus facile
+à
+utiliser.
+
+
+
+
+ Taille du sous-réseau
+ |
+ VLSM |
+ Masque sous-réseau
+ |
+
+
+ | 8 |
+ /29 |
+ 255.255.255.248 |
+
+
+ | 16 |
+ /28 |
+ 255.255.255.240 |
+
+
+ | 32 |
+ /27 |
+ 255.255.255.224 |
+
+
+ | 64 |
+ /26 |
+ 255.255.255.192 |
+
+
+ | 128 |
+ /25 |
+ 255.255.255.128 |
+
+
+ | 256 |
+ /24 |
+ 255.255.255.0 |
+
+
+ | 512 |
+ /23 |
+ 255.255.254.0 |
+
+
+ | 1024 |
+ /22 |
+ 255.255.252.0 |
+
+
+ | 2048 |
+ /21 |
+ 255.255.248.0 |
+
+
+ | 4096 |
+ /20 |
+ 255.255.240.0 |
+
+
+ | 8192 |
+ /19 |
+ 255.255.224.0 |
+
+
+ | 16384 |
+ /18 |
+ 255.255.192.0 |
+
+
+ | 32768 |
+ /17 |
+ 255.255.128.0 |
+
+
+ | 65536 |
+ /16 |
+ 255.255.0.0 |
+
+
+ | 2 ** 24 |
+ /8 |
+ 255.0.0.0 |
+
+
+
+
+Notez que le VLSM est écrit avec un slash ("/") -- vous
+pouvez souvent entendre un sous-réseau de taille 64 qui fait référence
+à
+un sous-réseau "slash 26" et un de taille 8 faisant référence à un
+"slash 29".
+Le masque de sous-réseau (aussi référencé par son netmask) est
+simplement un nombre de 32-bit avec le premier bit "VLSM" à un et
+les autres à zéro. Par exemple, pour un sous-réseau de taille 64, le
+masque de sous-réseau débute par 26 bits à un:
+
+ 11111111111111111111111111000000 = FFFFFFC0 =
+FF.FF.FF.C0 = 255.255.255.192
+
+Le masque de sous-réseau a la propriété suivante: si
+vous terminez logiquement le masque de sous-réseau avec une adresse
+dans
+le sous-réseau, le résultat est l'adresse du sous-réseau. Attention, si
+vous terminez logiquement le masque de sous-réseau avec une adresse en
+dehors du sous-réseau, le résultat n'est PAS l'adresse du sous-réseau.
+Comme nous l'avons vu précédemment, la propriété du masque de
+sous-réseau est très importante dans le routage.
+Pour un sous-réseau dont l'adresse est a.b.c.d
+et dont la VLSM est /v, nous notons le sous-réseau par "a.b.c.d/v"
+en utilisant la Notation CIDR.
+Exemple:
+
+
+
+
+ | Sous-réseau: |
+ 10.10.10.0 - 10.10.10.127 |
+
+
+ | Taille Sous-réseau: |
+ 128 |
+
+
+ | Adresse Sous-réseau: |
+ 10.10.10. |
+
+
+ | Adresse Broadcast: |
+ 10.10.10.127 |
+
+
+ Notation CIDR:
+ |
+ 10.10.10.0/25 |
+
+
+
+
+Il y a deux sous-réseaux dérivés qui doivent être
+mentionnés; A savoir, le sous-réseau avec un membre et le sous-réseau
+avec 2 ** 32 membres.
+
+
+
+
+ Taille du Sous-réseau
+ |
+ Longueur VLSM
+ |
+ Masque Sous-réseau |
+ Notation CIDR |
+
+
+ | 1 |
+ 32 |
+ 255.255.255.255 |
+ a.b.c.d/32 |
+
+
+ | 2 ** 32 |
+ 0 |
+ 0.0.0.0 |
+ 0.0.0.0/0 |
+
+
+
+
+Ainsi, chaque adresse a.b.c.d peut aussi être
+écrite a.b.c.d/32 et l'ensemble des adresses possibles est
+écrit 0.0.0.0/0.
+Plus loin dans ce manuel, vous verrez la notation a.b.c.d/v
+utilisé pour décrire la configuration IP d'une interface réseau
+(l'utilitaire 'ip' utilise aussi cette syntaxe). cela veut simplement
+dire que l'interface est configuré avec une adresse ip a.b.c.d
+et
+avec le masque de réseau qui correspond à la variable VLSM /v.
+Exemple: 192.0.2.65/29
+ L'interface est configuré avec
+l'adresse IP 192.0.2.65 et le masque de réseau 255.255.255.248.
+
+A partir de Shorewall version 1.4.6, /sbin/shorewall
+supporte la commande ipcalc qui calcule automatiquement
+l'information du [sous]-réseau.
+
+Exemple 1:
+
+
+ ipcalc 10.10.10.0/25
CIDR=10.10.10.0/25
NETMASK=255.255.255.128
NETWORK=10.10.10.0
BROADCAST=10.10.10.127
+
+Exemple 2
+
+ ipcalc 10.10.10.0 255.255.255.128
CIDR=10.10.10.0/25
NETMASK=255.255.255.128
NETWORK=10.10.10.0
BROADCAST=10.10.10.127
+
+4.3 Routage
+L'un des buts des sous-réseaux est la base du routage.
+Ci-dessous se trouve la table de routage de mon firewall:
+
+
+ [root@gateway root]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas
206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3
192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3
192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0
[root@gateway root]#
+
+
Le périphérique texas est le tunnel GRE vers un
+site peer à Dallas, la zone Texas.
+
+Les trois premières routes sont des routes
+hôte puisqu'elles indiquent comment aller vers un hôte unique.
+Dans la sortie de 'netstat' cela peut-être vu par le "Genmask" (Masque
+sous-réseau) de 255.255.255.255 et le "H" dans la colonne
+"Flags".
+Les autres sont des routes 'net' car elles indiquent au noyau comment
+router des paquets à un sous-réseau. La dernière route est la route par défaut est la passerelle
+(gateway) mentionnée est appelé passerelle par défaut (default
+gateway).
+Quant le noyau essaye d'envoyer un paquet à une adresse
+IP A, il commence au début de la table de routage et :
+
+ -
+
A est logiquement terminé avec la valeur du
+'Genmask' dans l'entrée de la table.
+
+ -
+
Le résultat est comparé avec la valeur de la
+destination 'Destination' dans l'entrée de la table.
+
+ -
+
Si le résultat et la valeur de la
+'Destination' sont identiques, alors:
+
+ -
+
Si la colonne 'Gateway' est n'est pas nulle, le
+paquet est envoyé au gateway à travers l'interface nommée dans la
+colonne 'Iface'.
+
+ -
+
Sinon, le paquet est directement envoyé à A à
+travers l'interface nommée dans la colonne 'iface'.
+
+
+
+ -
+
Autrement, les étapes précédentes sont répétées sur
+l'entrée suivante de la table.
+
+
+Puisque la route par défaut correspond à toutes les
+adresses IP (A donne 0.0.0.0 = 0.0.0.0), les paquets qui ne
+correspondent à aucune des autres entrées de la table de routage sont
+envoyés au gateway par défaut
+qui généralement est un routeur vers le FAI.
+Voici un exemple. Supposez que vous souhaitez router un
+paquet à 192.168.1.5. Cette adresse ne correspond à aucune route d'hôte
+dans la table mais si nous terminons logiquement cette adresse avec
+255.255.255.0, le résultat est 192.168.1.0 qui correspond à la l'entrée
+dans la table:
+
+
+ 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
+
+
Donc le paquet vers 192.168.1.5 est directement envoyé à travers
+eth2.
+
Un des points qui doit être souligné -- tous les
+paquets sont envoyés en utilisant la table de routage et les réponses
+ne
+sont pas exclues de ce principe. Il semble y avoir une croyance
+de la part des ceux qui croient que les paquets réponses sont comme les
+saumons et contiennent un code génétique qui leur permet de suivre la
+route emprunté par les paquets envoyés. Ce n'est pas le cas; La réponse
+peut prendre un chemin totalement différent de celui de la requête du
+client -- les routes requête/réponse sont totalement indépendantes.
+4.4 Protocole de Résolution
+d'Adresse (ARP)
+Quant on envoie des paquets à travers Ethernet, les
+adresses IP ne sont pas utilisées. Bien que l'adressage Ethernet soit
+basé sur les adresses Media Access Control (MAC). Chaque
+périphérique Ethernet à sa propre adresse MAC qui est contenu
+dans
+une PROM lors de la fabrication. Vous pouvez obtenir l'adresse MAC
+grâce
+à l'utilitaire 'ip':
+
+
+
[root@gateway root]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
[root@gateway root]#
+
+
+
Comme vous pouvez le constater ci-dessus, l'adresse MAC
+codé sur 6 bytes (48 bits). Une carte MAC est généralement aussi
+imprimé sur la carte elle-même.
+
+
Parce que IP utilise les adresses IP et Ethernet les
+adresses MAC, un mécanisme est nécessaire pour transcrire une adresse
+IP
+en adresse MAC; C'est ce dont est chargé le protocole de résolution
+d'adresse Address Resolution Protocol (ARP). Voici ARP en
+action:
+
+
+
+
[root@gateway root]# tcpdump -nei eth2 arp
tcpdump: listening on eth2
09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0
2 paquets received by filter
0 paquets dropped by kernel
[root@gateway root]#
+
+
Dans cet échange , 192.168.1.254 (MAC 2:0:8:e3:4c:48)
+veut connaître l'adresse MAC du périphérique avec l'adresse IP
+192.168.1.19. Le système ayant cette adresse IP répond que l'adresse
+MAC
+du périphérique avec l'adresse IP 192.168.1.19 est 0:6:25:aa:8a:f0.
+Afin de rendre disponible les informations d'échange
+ARP chaque fois qu'un paquet est envoyé, le système maintient un cache ARP des
+correspondances IP<->MAC. Vous pouvez voir le cache ARP sur votre
+système (également sur les systèmes Windows) en utilisant la commande
+'arp':
+
+
+
[root@gateway root]# arp -na
? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
+
+Les détails de réponse sont le résultat de
+l'utilisation de l'option 'n' (Windows 'arp' n'accepte pas cette
+option)
+qui force le programme 'arp' à la translation de résolution de noms
+IP->DNS. Si je n'utilise pas cette option, la marque de question
+aurait été remplacé par le FQDN correspondant à chaque adresse IP.
+Notez
+que la dernière information dans la table d'enregistrement est celle
+que
+nous voyons en utilisant précédemment tcpdump.
+4.5 RFC 1918
+Les adresses IP sont alloués par l'autorité Internet Assigned Number Authority (IANA)
+qui délégue des allocations géographiques basés sur le Regional
+Internet Registries (RIRs). Par exemple, les allocations pour les
+Etats-Unis sont déléguées à American
+Registry for Internet Numbers (ARIN). Ces RIRs peuvent
+déléguer à des bureaux nationaux. La plus part d'entre nous ne traite
+pas avec autorités mais obtienne plutôt leur adresse IP par leur FAI.
+Dans la réalité, généralement on ne peut se permettre
+autant d'adresses IP Publiques que de périphériques à assigner si bien
+que nous utiliseront des adresses IP Privées.
+RFC 1918 réserve plusieurs plages d'adresse IP à cet usage:
+
+
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
+
+
Les adresses réservées par la RFC 1918 sont parfois
+appelées non-routable car le routeur passerelle Internet ne
+renvoit pas les paquets qui ont une adresse de destination RFC-1918.
+cela est compréhensible car tout le monde peut choisir ces adresses
+pour
+un usage privé.
+
+
Quant on choisit des adresses de ces plages, il y a
+deux choses à garder en mémoire:
+
+
+ -
+
Comme l'espace des adresses IPv4 s'épuise, de plus
+en plus d'organisation (comprenant les FAI) commencent à utiliser les
+adresses RFC 1918 dans leur infrastructures.
+
+ -
+
Vous ne voulez pas utiliser des adresses IP qui
+sont utilisés par votre FAI ou une autre organisation avec laquelle
+vous
+souhaiter établir une liaison VPN.
+
+
+
+
C'est pourquoi c'est une bonne idée de vérifier avec
+votre FAI s'il n'utilise pas (ou ne prévoie pas d'utiliser) des
+adresses
+privées avant de décider les adresses que vous allez utiliser.
+
+
5.0 Configurer votre Réseau
+
+
+
Le choix de configuration de votre réseau dépend
+d'abord du nombre d'adresses Public IP dont vous avez besoin, c'est à
+dire du nombre d'entités adressables que vous avez sur votre réseau. En
+fonction du nombre d'adresses que vous avez, votre FAI peut servir ce
+jeu d'adresses de deux manières:
+
+
+
+ -
+
Routé - Le trafic vers chacune de vos
+adresses sera routé à travers une unique adresse passerelle.
+Cela sera généralement fait si votre FAI vous assigne un sous-réseau
+complet (/29 ou plus). Dans ce cas, vous assignerez l'adresse
+passerelle comme adresse IP de l'interface externe de votre
+firewall/router.
+
+ -
+
Non-routé - Votre FAI vous enverra
+directement le trafic de chaque adresse directement.
+
+
+
+
Dans les paragraphes qui suivent, nous étudierons
+chaque cas séparément.
+
+
Avant de commencer, il y a une chose que vous devez
+vérifier:
+
Si vous
+utilisez le package Debian, vérifier
+svp votre fichier shorewall.conf afin de contrôler les paramètres
+suivants; si ce n'est pas juste, appliquer les changements
+nécessaires:
+
+
+ - NAT_ENABLED=Yes (Shorewall versions antérieures à 1.4.6)
+ - IP_FORWARDING=On
+
+
+
+
Supposons que votre fournisseur d'accès FAI vous a
+assigné le sous-réseau 192.0.2.64/28 routé à travers 192.0.2.65. cela
+veut dire que vous avez les adresses IP 192.0.2.64 - 192.0.2.79
+et que l'adresse externe de votre firewall est 192.0.2.65. Votre FAI
+vous a aussi dit que vous pouvez utiliser le masque de réseau
+255.255.255.0 (ainsi votre /28 est une partie de /24). Avec ces
+adresses
+IP, vous pouvez scinder votre réseau /28 en deux /29 et configurer
+votre
+réseau comme l'indique le diagramme suivant.
+
+
+
+
Ici, la zone démilitarisé DMZ comprend le sous-réseau
+192.0.2.64/29 et le réseau Local 192.0.2.72/29. La passerelle par
+défaut
+pour les hôtes dans la DMZ pourra être configuré à 192.0.2.66 et la
+passerelle par défaut pour les hôtes du réseau local pourra être
+192.0.2.73.
+
+
Notez que cet arrangement est plus gourmand en adresses
+publiques puisqu'il utilise 192.0.2.64 et 192.0.2.72 pour les adresses
+du sous-réseau, 192.0.2.71 et 192.0.2.79 pour les adresses
+broadcast du réseau, de même que 192.0.2.66 et 168.0.2.73 pour les
+adresses internes que le firewall/routeur. Néanmoins, cela montre
+comment nous pouvons faire avec un réseau /24 plutôt qu'un /28,
+l'utilisation de 6 adresses IP parmi les 256 peut être justifié par la
+simplicité du paramétrage.
+
+
Le lecteur astucieux aura remarqué que l'interface
+externe du firewall/Routeur est actuellement inclus dans le sous-réseau
+DMZ (192.0.2.64/29). Que se passe-t-il si DMZ 1 (192.0.2.67) essaye de
+communiquer avec 192.0.2.65? La table de routage sur DMZ 1 peut
+ressembler à cela:
+
+
+ Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0
0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0
+
+
+
Cela indique que DMZ 1 enverra une requête ARP "qui-a
+192.0.2.65" et aucune interface sur le segment Ethernet DMZ à
+cette adresse IP. Assez bizarrement, le firewall répondra à la
+requête avec l'adresse MAC de sa propre Interface DMZ!! DMZ 1
+peut alors envoyer des trames Ethernet frames adressées à cette
+adresse MAC et les trames seront reçues (correctement) par le
+firewall/routeur.
+
+
C'est plutôt une possibilité inattendue d'ARP sur la
+partie du Noyau Linux qui pousse cet avertissement très tôt dans ce
+manuel à propos de la connexion de plusieurs interfaces
+firewall/routeur
+au même hub ou switch. Quant une requête ARP destiné à une des
+adresses firewall/routeur est envoyé par un autre système connecté au
+hub/switch, toutes les interfaces du firewall qui se connectent au
+hub/switch peuvent répondre! C'est alors une course à la réponse qui
+"est-là" qui atteindra en premier l'émetteur.
+
+
Avec la situation précédente mais non-routé, vous
+pouvez configurer votre réseau exactement comme décrit ci-dessus avec
+une condition supplémentaire; spécifiez simplement l'option "proxyarp"
+sur les trois interfaces du firewall dans le fichier
+/etc/shorewall/interfaces.
+
+
La plus part d'entre nous n'a pas le luxe d'avoir assez
+d'adresses publiques IP pour configurer notre réseau comme montré dans
+le précédent exemple (même si la configuration est routé).
+
+
Pour le besoin de cette section, admettons que notre
+FAI nous a assigné les adresses IP 192.0.2.176-180 et nous a dit
+d'utiliser le masque de réseau 255.255.255.0 et la passerelle par
+défaut
+192.0.2.254.
+
+
Clairement, ce jeu d'adresses ne comprend pas de
+sous-réseau et n'a pas suffisamment d'adresses pour toutes les
+interfaces de notre réseau. Il y a quatre possibilités qui peuvent être
+utilisées pour règler ce problème.
+
+
+ -
+
Translation d'Adresses Réseau Source : Source
+Network Address Translation (SNAT).
+
+ -
+
Translation d'Adresses Réseau Destination :
+Destination Network Address Translation (DNAT) aussi nommé Port
+Forwarding.
+
+ -
+
Proxy ARP.
+
+ -
+
Translation d''Adresses Réseau : Network
+Address Translation (NAT) aussi appelé Static NAT.
+
+
+
+
Souvent une combinaison de ces techniques est utilisée.
+Chacune d'entre elle sera détaillée dans la section suivante.
+
+
Avec SNAT, un segment interne LAN est configuré en
+utilisant les adresses RFC 1918. Quant un hôte A sur ce segment interne
+initialise une connexion à l'hôte B sur Internet, le
+firewall/routeur réécrit les entêtes IP dans la requête pour utiliser
+une de vos adresses publiques IP en tant qu'adresse source. Quant B
+répond et que la réponse est reçu par le firewall, le firewall change
+l'adresse destination par celle RFC 1918 de A et renvoi la
+réponse à A.
+
+
Supposons que vous décidiez d'utiliser SNAT sur votre
+zone locale et utilisiez l'adresse publique 192.0.2.176 à la fois comme
+adresse externe du firewall et l'adresse source des requêtes Internet
+envoyées depuis cette zone.
+
+
+
La zone locale a été assigné au sous-réseau
+192.168.201.0/29 (netmask 255.255.255.248).
+
+
+ Le système dans la zone locale pourra être configuré
+avec la passerelle par défaut 192.168.201.1 (L'adresse IP de
+l'interface local du firewall).
+
+
+
+
+
+
+
+ | INTERFACE |
+ SOUS-RESEAU |
+ ADDRESSE |
+
+
+ | eth0 |
+ 192.168.201.0/29 |
+ 192.0.2.176 |
+
+
+
+
+
+
Cet exemple utilise la technique normale pour assigner
+la même adresse publique IP pour l'interface externe du firewall et
+pour
+SNAT. Si vous souhaitez utiliser une adresse IP différente, vous pouvez
+soit utiliser les outils de configuration réseau de votre distribution
+pour ajouter cette adresse IP ou vous pouvez mettre la variable
+ADD_SNAT_ALIASES=Yes dans /etc/shorewall/shorewall.conf si bien que
+Shorewall ajoutera l'adresse pour vous.
+
+
Quant SNAT est utilisé, il est impossible pour les
+hôtes sur Internet d'initialiser une connexion avec un des systèmes
+puisque ces systèmes n'ont pas d'adresses publiques IP. DNAT fournit
+une
+méthode pour autoriser des connexions sélectionnés depuis Internet.
+
+
+Supposons que votre fille souhaite héberger un
+server web sur son système "Local 3". Vous pouvez autoriser les
+connexions d'Internet à son serveur en ajoutant l'entrée suivante dans
+le fichier /etc/shorewall/rules:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL DESTINATION |
+
+
+ | DNAT |
+ net |
+ loc:192.168.201.4 |
+ tcp |
+ www |
+ - |
+ 192.0.2.176 |
+
+
+
+
+
+
Si une des amies de votre fille avec une adresse A veut
+accéder au serveur de votre fille, elle peut se connecter à l'adresse
+http://192.0.2.176 (l'adresse IP externe
+de votre firewall) et le firewall réécrira l'adresse IP à 192.168.201.4
+(le système de votre fille) et enverra la requête. Quant le serveur de
+votre fille répond, le firewall réécrira la source de réponse avec
+192.0.2.176 et retournera la réponse à A.
+
+
Cet exemple l'adresse externe IP du firewall pour DNAT.
+Vous pouvez utiliser une autre de vos adresses IP publiques, mais
+Shorewall n'ajoutera pas pour vous cette adresse à l'interface externe
+du firewall.
+
+
Le principe du proxy ARP est:
+
+
+ -
+
Un hôte H derrière votre firewall est
+assigné à une de vos adresses publiques (A), a le même masque de
+réseau (M) que l'interface externe du firewall.
+
+ -
+
Le firewall répond à ARP "qui a" demandé A.
+
+
+ -
+
Quant H délivre une requête ARP "qui a"
+pour
+une adresse du sous -réseau définit par A et M,
+le
+firewall répondra (avec l'adresse MAC si le firewall s'interface à H).
+
+
+
+
Supposons que nous décidons d'utiliser Proxy ARP sur
+DMZ de notre exemple réseau.
+
+
+
Ici, nous avons assigné les adresses IP 192.0.2.177
+au système DMZ 1 et 192.0.2.178 à DMZ 2. Notez que nous avons juste
+assigné une adresse arbitraire RFC 1918 et un masque de sous-réseau à
+l'interface DMZ de notre firewall. Cette adresse et le masque ne sont
+pas pertinentes - vérifiez juste que celle-ci n'écrase pas un autre
+sous-réseau déjà définit.
+
+
+
+
+
+
+
+ | ADDRESS |
+ INTERFACE |
+ EXTERNAL |
+ HAVE ROUTE |
+
+
+ | 192.0.2.177 |
+ eth2 |
+ eth0 |
+ No |
+
+
+ | 192.0.2.178 |
+ eth2 |
+ eth0 |
+ No |
+
+
+
+
+
+
Parce que la variable HAVE ROUTE contient No,
+Shorewall ajoutera les routes d'hôte à travers eth2 à 192.0.2.177 et
+192.0.2.178.
+
+
Les interfaces ethernet de DMZ 1 et DMZ 2 pourront être
+configurées pour avoir les adresses IP apparentes mais devront avoir la
+même passerelle par défaut que le firewall lui-même -- nommé
+192.0.2.254. En d'autres termes, elles pourront être configurées juste
+comme elles devraient être si elles étaient parallèles au firewall
+plutôt que derrière lui.
+
+
NOTE: Ne pas ajouter le(s) adresse(s) ARP
+(192.0.2.177 et 192.0.2.178 dans l'exemple ci-dessus) à
+l'interface externe (eth0 dans cet exemple) du firewall.
+
+
+
+
+
+
Un mot de mise en garde à sa place ici. Les FAIs
+configure(nt) typiquement leur routeur avec un timeout de cache ARP
+élevé. Si vous déplacer un système parallèle à votre firewall derrière
+le Proxy ARP du firewall, cela peut mettre des HEURES avant que le
+système puisse communiquer avec Internet. Il y a deux choses que vous
+pouvez essayer de faire:
+
+
+ - (Courtoisement de Bradey Honsinger) Une lecture de Stevens' TCP/IP
+Illustrated, Vol 1 révèle qu'un paquet ARP
+
+"gratuitous" peut entraîner le routeur de votre FAI à rafraîchir son
+cache(section 4.7). Une "gratuitous" ARP est simplement une requête
+d'un
+hôte demandant l'adresse MAC de sa propre adresse IP; éventuellement
+pour vérifier que l'adresse IP n'est pas dupliquée,...
+
+si l'hôte envoyant la commande "gratuitous" ARP vient juste de changer
+son adresse IP..., ce paquet entraîne tous les autres hôtes...qui ont
+une entrée dans son cache pour l'ancienne adresse matériel de mettre à
+jour également ses caches ARP."
+
+Ce qui est exactement, bien sûr, ce que vous souhaitez faire lorsque
+vous basculez un hôte vulnérable à Internet derrière Shorewall
+utilisant
+proxy ARP (ou static NAT). Heureusement, des packages récents (Redhat)
+iputils incluent "arping", avec l'option "-U" qui fait cela:
+
+ arping -U -I <net
+if> <newly proxied IP>
+ arping -U -I eth0
+66.58.99.83 # for example
+
+Stevens continue en mentionnant que tous les systèmes répondent
+correctement au gratuitous ARPs, et "googling" pour "arping
+-U" semble aller dans ce sens.
+
+
+ - Vous pouvez appeler votre FAI et dire de purger l'ancienne entrée
+du cache ARP mais la plupart ne veulent ou ne peuvent le faire.
+
+Vous pouvez vérifier si le cache ARP de votre FAI est ancien en
+utilisant ping et tcpdump. Supposez que vous pensez que la
+passerelle routeur a une ancienne entrée ARP pour 192.0.2.177.
+Sur
+le firewall, lancez tcpdump de cette façon:
+
+
tcpdump -nei eth0 icmp
+
+
+
Maintenant depuis 192.0.2.177, utilisez ping vers la
+passerelle du FAI (que nous supposons être 192.0.2.254):
+
+
+
+
Nous pouvons maintenant observer le résultat de tcpdump:
+
+
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
+
+
Notez que l'adresse source MAC dans la
+requête echo est différente de l'adresse de
+destination dans la réponse echo!! Dans le cas ou
+0:4:e2:20:20:33 était l'adresse MAC de l'interface NIC eth0 du firewall
+tandis que 0:c0:a8:50:b2:57 était l'adresse MAC de DMZ 1. En
+d'autre termes, le cache ARP de la passerelle associe encore
+192.0.2.177 avec la NIC de DMZ 1 plutôt qu'avec eth0 du firewall.
+
+
Avec static NAT, vous assignez les adresses systèmes
+RFC 1918 puis établissez une à une l'assignation entre ces adresses et
+les adresses publiques. Pour les occurrences des connexions sortantes
+SNAT (Source Network Address Translation) et pour les occurrences
+des connexions entrantes DNAT (Destination Network Address
+Translation). Voyons avec l'exemple précédent du serveur web de votre
+fille tournant sur le système Local 3.
+
+
+
+
Rappel du paramétrage, le réseau local utilise SNAT et
+partage l'IP externe du firewall (192.0.2.176) pour les connexions
+sortantes. cela est obtenu avec l'entrée suivante dans le fichier
+/etc/shorewall/masq:
+
+
+
+
+
+ | INTERFACE |
+ SOUS-RESEAU |
+ ADDRESSE |
+
+
+ | eth0 |
+ 192.168.201.0/29 |
+ 192.0.2.176 |
+
+
+
+
+
+
+Supposons maintenant que vous avez décidé d'allouer à
+votre fille sa propre adresse IP (192.0.2.179) pour l'ensemble des
+connexions entrantes et sortantes. Vous devrez faire cela en
+ajoutant une entrée dans le fichier /etc/shorewall/nat.
+
+
+
+
+
+ | EXTERNAL |
+ INTERFACE |
+ INTERNAL |
+ ALL INTERFACES |
+ LOCAL |
+
+
+ | 192.0.2.179 |
+ eth0 |
+ 192.168.201.4 |
+ No |
+ No |
+
+
+
+
+
+
Avec cette entrée active, votre fille a sa propre
+adresse IP et les deux autres systèmes locaux partagent l'adresse IP du
+firewall.
+
+
Une fois
+que la relation entre 192.0.2.179
+et192.168.201.4 est établie par l'entrée ci-dessus, ce n'est pas
+nécessaire d'utiliser une règle DNAT pour le serveur web de votre fille
+-- vous devez simplement utiliser une règle ACCEPT:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL DESTINATION |
+
+
+ | ACCEPT |
+ net |
+ loc:192.168.201.4 |
+ tcp |
+ www |
+ |
+ |
+
+
+
+
+
+
+
+
Un mot de mise en garde à sa place ici. FAIs
+configure(nt) typiquement leur routeur avec un timeout de cache ARP
+élevé. Si vous déplacer un système parallèle à votre firewall derrière
+le Proxy ARP du firewall, cela peut mettre des HEURES avant que le
+système puisse communiquer avec Internet. Il y a deux choses que vous
+pouvez essayer de faire:
+
+
+ - (Courtoisement de Bradey Honsinger) Une lecture de Stevens' TCP/IP
+Illustrated, Vol 1 révèle qu'un paquet ARP
+
+"gratuitous" peut entraîner le routeur de votre FAI à rafraîchir son
+cache(section 4.7). Une "gratuitous" ARP est simplement une requête
+d'un
+hôte demandant l'adresse MAC de sa propre adresse IP; éventuellement
+pour vérifier que l'adresse IP n'est pas dupliquée,...
+
+"si l'hôte envoyant la "gratuitous" ARP vient juste de changer son
+adresse IP..., ce paquet entraîne tous les autres hôtes...qui ont une
+entrée dans son cache pour l'ancienne adresse matériel de mettre à jour
+également ses caches ARP."
+
+Ce qui est exactement, bien sûr, ce que vous souhaitez faire lorsque
+vous basculez un hôte vulnérable à Internet derrière Shorewall
+utilisant
+proxy ARP (ou static NAT). Heureusement, les versions récentes des
+packages Redhat's iputils incluent "arping", avec l'option "-U" qui
+fait
+cela:
+
+ arping -U -I <net
+if> <newly proxied IP>
+ arping -U -I eth0
+66.58.99.83 # for example
+
+Stevens continue en mentionnant que tous les systèmes répondent
+correctement au gratuitous ARPs, et "googling" pour "arping
+-U" semble aller dans ce sens.
+
+
+ - Vous pouvez appeler votre FAI et dire de purger l'ancienne entrée
+du cache ARP mais la plupart ne veulent ou ne peuvent le faire.
+
+Vous pouvez vérifier si le cache ARP de votre FAI est ancien en
+utilisant ping et tcpdump. Supposez que vous pensez que la
+passerelle routeur a une ancienne entrée ARP pour 192.0.2.177.
+Sur
+le firewall, lancez tcpdump de cette façon:
+
+
tcpdump -nei eth0 icmp
+
+
+
Maintenant depuis 192.0.2.177, utilisez ping vers la
+passerelle du FAI (que nous supposons être 192.0.2.254):
+
+
+
+
+
Nous pouvons maintenant observer le résultat de tcpdump:
+
+
+
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
+
+
+
Notez que l'adresse source MAC dans la
+requête echo est différente de l'adresse de
+destination dans la réponse echo!! Dans le cas ou
+0:4:e2:20:20:33 était l'adresse MAC de l'interface NIC eth0 du firewall
+tandis que 0:c0:a8:50:b2:57 était l'adresse MAC de DMZ 1. En
+d'autre termes, le cache ARP de la passerelle associe encore
+192.0.2.177 avec la NIC de DMZ 1 plutôt qu'avec eth0 du firewall.
+
+
5.3 Règles
+
+
Avec les
+polices par défaut, vos systèmes locaux
+(Local 1-3) peuvent accéder à tous les serveurs sur Internet et la DMZ
+ne peut accéder à aucun autre hôte (incluant le firewall). Avec les
+exceptions des règles règles NAT qui entraîne la
+translation d'adresses et permet aux requêtes de connexion translatées
+de passer à travers le firewall, la façon d'autoriser des
+requêtes
+à travers le firewall est d'utiliser des règles ACCEPT.
+
+
+
NOTE: Puisque les colonnes SOURCE PORT et ORIG.
+DEST. ne sont pas utilisées dans cette section, elle ne sont pas
+affichées.
+
+
Vous souhaiter certainement autoriser ping entre vos
+zones:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+
+
+ | ACCEPT |
+ net |
+ dmz |
+ icmp |
+ echo-request |
+
+
+ | ACCEPT |
+ net |
+ loc |
+ icmp |
+ echo-request |
+
+
+ | ACCEPT |
+ dmz |
+ loc |
+ icmp |
+ echo-request |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ icmp |
+ echo-request |
+
+
+
+
+
+
En supposant que vous avez des serveurs mail et pop3
+actifs sur DMZ 2 et un serveur Web sur DMZ 1. Les règles dont vous avez
+besoin sont:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ COMMENTS |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis Internet
+ |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ pop3 |
+ # Pop3 depuis Internet |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis le Réseau Local |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ pop3 |
+ # Pop3 depuis le Réseau Local |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis le firewall |
+
+
+ | ACCEPT |
+ dmz:192.0.2.178 |
+ net |
+ tcp |
+ smtp |
+ # Mails vers Internet
+ |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ tcp |
+ http |
+ # WWW depuis le Net
+ |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ tcp |
+ https |
+ # HTTP sécurisé depuis le Net |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ tcp |
+ https |
+ # HTTP sécurisé depuis le Réseau Local |
+
+
+
+
+
+
Si vous utilisez un serveur DNS publique sur
+192.0.2.177, vous devez ajouter les règles suivantes:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ COMMENTS |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis Internet |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis le firewall |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis le firewall |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis le Réseau local
+ |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis le Réseau local |
+
+
+ | ACCEPT |
+ dmz:192.0.2.177 |
+ net |
+ udp |
+ domain |
+ # UDP DNS vers Internet |
+
+
+ | ACCEPT |
+ dmz:192.0.2.177 |
+ net |
+ tcp |
+ domain |
+ # TCP DNS vers Internet |
+
+
+
+
+
+
Vous souhaitez probablement communiquer entre votre
+firewall et les systèmes DMZ depuis le réseau local -- Je recommande
+SSH
+qui, grâce à son utilitaire scp peut aussi faire de la diffusion
+et de la mise à jour de logiciels.
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ COMMENTS |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ tcp |
+ ssh |
+ # SSH vers la DMZ |
+
+
+ | ACCEPT |
+ loc |
+ fw |
+ tcp |
+ ssh |
+ # SSH vers le firewall |
+
+
+
+
+
+
5.4 D'autres petites choses
+
+
+
La discussion précédente reflète ma préférence
+personnelle pour l'utilisation de Proxy ARP associé à mes serveurs de
+la
+DMZ et SNAT/NAT pour mes systèmes locaux. Je préfère utiliser NAT
+seulement dans le cas ou un système qui fait partie d'un sous-réseau
+RFC
+1918 à besoin d'avoir sa propre adresse IP.
+
+
Si vous
+ne l'avez pas fait, ce peut-être une bonne
+idée de parcourir le fichier /etc/shorewall/shorewall.conf
+afin de voir si autre chose pourrait être intéressant. Vous pouvez
+aussi
+regarder aux autres fichiers de configuration que vous n'avez pas
+touché
+pour un aperçu des autres possibilités de Shorewall.
+
+
Dans le cas ou vous n'auriez pas validé les étapes,
+ci-dessous se trouve un jeu final des fichiers de configuration pour
+notre réseau exemple. Uniquement ceux qui auraient étés modifiés de la
+configuration originale sont montrés.
+
+
/etc/shorewall/interfaces (Les "options" seront
+spécifiques aux sites).
+
+
+
+
+
+ | Zone |
+ Interface |
+ Broadcast |
+ Options |
+
+
+ | net |
+ eth0 |
+ detect |
+ norfc1918,routefilter |
+
+
+ | loc |
+ eth1 |
+ detect |
+ |
+
+
+ | dmz |
+ eth2 |
+ detect |
+ |
+
+
+
+
+
+
La configuration décrit nécessite que votre réseau soit
+démarré avant que Shorewall puisse se lancer. Cela ouvre un
+lapse de temps durant lequel vous n'avez pas de protection firewall.
+Si vous remplacez 'detect' par les valeurs des adresses broadcoast dans
+les entrées suivantes, vous pouvez activer Shorewall avant les
+interfaces réseau.
+
+
+
+
+
+
+ | Zone |
+ Interface |
+ Broadcast |
+ Options |
+
+
+ | net |
+ eth0 |
+ 192.0.2.255 |
+ norfc1918,routefilter |
+
+
+ | loc |
+ eth1 |
+ 192.168.201.7 |
+ |
+
+
+ | dmz |
+ eth2 |
+ 192.168.202.7 |
+ |
+
+
+
+
+
+
/etc/shorewall/masq - Sous-réseau Local
+
+
+
+
+
+
+ | INTERFACE |
+ SOUS-RESEAU |
+ ADDRESS |
+
+
+ | eth0 |
+ 192.168.201.0/29 |
+ 192.0.2.176 |
+
+
+
+
+
+
/etc/shorewall/proxyarp - DMZ
+
+
+
+
+
+ | ADDRESS |
+ INTERFACE |
+ EXTERNAL |
+ HAVE ROUTE |
+
+
+ | 192.0.2.177 |
+ eth2 |
+ eth0 |
+ No |
+
+
+ | 192.0.2.178 |
+ eth2 |
+ eth0 |
+ No |
+
+
+
+
+
+
/etc/shorewall/nat- Le système de ma fille
+
+
+
+
+
+
+ | EXTERNAL |
+ INTERFACE |
+ INTERNAL |
+ ALL INTERFACES |
+ LOCAL |
+
+
+ | 192.0.2.179 |
+ eth0 |
+ 192.168.201.4 |
+ No |
+ No |
+
+
+
+
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ COMMENTS |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ pop3 |
+ # Pop3 depuis Internet |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis le Réseau Local
+ |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ pop3 |
+ # Pop3 depuis le Réseau Local |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis le firewall |
+
+
+ | ACCEPT |
+ dmz:192.0.2.178 |
+ net |
+ tcp |
+ smtp |
+ # Mail vers Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ http |
+ # WWW depuis le Net |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ https |
+ # HTTP sécurisé depuis le Net |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ https |
+ # HTTP sécurisé depuis le Réseau Local |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis Internet |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis le firewall |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis le firewall |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis le Réseau Local |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis le Réseau Local |
+
+
+ | ACCEPT |
+ dmz:192.0.2.177 |
+ net |
+ udp |
+ domain |
+ # UDP DNS vers Internet |
+
+
+ | ACCEPT |
+ dmz:192.0.2.177 |
+ net |
+ tcp |
+ domain |
+ # TCP DNS vers Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz |
+ icmp |
+ echo-request |
+ # Ping |
+
+
+ | ACCEPT |
+ net |
+ loc |
+ icmp |
+ echo-request |
+ # " |
+
+
+ | ACCEPT |
+ dmz |
+ loc |
+ icmp |
+ echo-request |
+ # " |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ icmp |
+ echo-request |
+ # " |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ tcp |
+ ssh |
+ # SSH vers DMZ |
+
+
+ | ACCEPT |
+ loc |
+ fw |
+ tcp |
+ ssh |
+ # SSH vers le firewall |
+
+
+
+
+
+
En donnant une collection d'adresses RFC 1918 et
+publiques dans la configuration, cela justifie d'avoir des serveurs DNS
+interne et externe. Vous pouvez combiner les deux dans un unique
+serveur BIND 9 utilisant les vues (Views). Si vous n'êtes pas
+intéressé par les vues BIND 9, vous pouvez allez à la section suivante.
+
+
Supposons que votre domain est foobar.net et vous
+voulez que les deux systèmes DMZ s'appellent www.foobar.net et
+mail.foobar.net, les trois systèmes locaux "winken.foobar.net,
+blinken.foobar.net et nod.foobar.net. Vous voulez que le firewall soit
+connu à l'extérieur sous le nom firewall.foobar.net, son interface vers
+le réseau local gateway.foobar.net et son interface vers la DMZ
+dmz.foobar.net. Mettons le serveur DNS sur 192.0.2.177 qui sera aussi
+connu sous le nom ns1.foobar.net.
+
+
Le fichier /etc/named.conf devrait ressembler à
+cela:
+
+
+
+
options {
directory "/var/named";
listen-on { 127.0.0.1 ; 192.0.2.177; };
};
logging {
channel xfer-log {
file "/var/log/named/bind-xfer.log";
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; };
};
+
+
#
# Ceci est la vue présente sur vos systèmes internes.
#
view "internal" {
#
# Les clients suivants peuvent voir le serveur
#
match-clients { 192.168.201.0/29;
192.168.202.0/29;
127.0.0.0/8;
192.0.2.176/32;
192.0.2.178/32;
192.0.2.179/32;
192.0.2.180/32; };
#
# Si le serveur ne peut répondre à la requête, il utilisera des serveurs externes
#
#
recursion yes;
zone "." in {
type hint;
file "int/root.cache";
};
zone "foobar.net" in {
type master;
notify no;
allow-update { none; };
file "int/db.foobar";
};
zone "0.0.127.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.127.0.0";
};
zone "201.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.201";
};
zone "202.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.202";
};
zone "176.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.176";
};
(or status NAT for that matter)
zone "177.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.177";
};
zone "178.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.178";
};
zone "179.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.206.124.146.179";
};
};
#
# Ceci est la vue qui sera présente pour le monde extérieur
#
view "external" {
match-clients { any; };
#
# Si nous pouvons répondre à la requéte, nous le disons
#
recursion no;
zone "foobar.net" in {
type master;
notify yes;
allow-update {none; };
allow-transfer { <secondary NS IP>; };
file "ext/db.foobar";
};
zone "176.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.176";
};
zone "177.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.177";
};
zone "178.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.178";
};
zone "179.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.179";
};
};
+
+
+
Voici les fichiers de /var/named (ceux qui ne sont pas
+présents font partis de votre distribution BIND).
+
db.192.0.2.176 - Zone inverse de l'interface externe du
+firewall
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
; Filename: db.192.0.2.176
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
+
+
+
db.192.0.2.177 - Zone inverse pour le serveur
+www/DNS
+server
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
; Filename: db.192.0.2.177
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
+
+
+
+
db.192.0.2.178 - Zone inverse du serveur mail
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
; Filename: db.192.0.2.178
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
+
+
+
+
db.192.0.2.179 - Zone inverse du serveur web
+publique
+de votre fille
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
; Filename: db.192.0.2.179
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
+
+
+
+
int/db.127.0.0 - Zone inverse pour localhost
+
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
; Filename: db.127.0.0
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001092901 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR localhost.foobar.net.
+
+
+
int/db.192.168.201 - Zone inverse pour le réseau local.
+cela n'est montré qu'aux clients internes
+
+
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
; Filename: db.192.168.201
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
2002032501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR gateway.foobar.net.
2 86400 IN PTR winken.foobar.net.
3 86400 IN PTR blinken.foobar.net.
4 86400 IN PTR nod.foobar.net.
+
+
+
int/db.192.168.202 - Zone inverse de l'interface DMZ du
+firewall
+
+
+
+
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
; Filename: db.192.168.202
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
2002032501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR dmz.foobar.net.
+
+
+
int/db.foobar - Forward zone pour l'utilisation des
+clients internes.
+
+
+ ;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2002071501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ); minimum (1 day)
;############################################################
; foobar.net Nameserver Records (NS)
;############################################################
@ 604800 IN NS ns1.foobar.net.
;############################################################
; Foobar.net Office Records (ADDRESS)
;############################################################
localhost 86400 IN A 127.0.0.1
firewall 86400 IN A 192.0.2.176
www 86400 IN A 192.0.2.177
ns1 86400 IN A 192.0.2.177
www 86400 IN A 192.0.2.177
gateway 86400 IN A 192.168.201.1
winken 86400 IN A 192.168.201.2
blinken 86400 IN A 192.168.201.3
nod 86400 IN A 192.168.201.4
+
+
+
ext/db.foobar - Forward zone pour les clients externes
+
+
+
+
+
;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2002052901 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ); minimum (1 day)
;############################################################
; Foobar.net Nameserver Records (NS)
;############################################################
@ 86400 IN NS ns1.foobar.net.
@ 86400 IN NS <secondary NS>.
;############################################################
; Foobar.net Foobar Wa Office Records (ADDRESS)
;############################################################
localhost 86400 IN A 127.0.0.1
;
; The firewall itself
;
firewall 86400 IN A 192.0.2.176
;
; The DMZ
;
ns1 86400 IN A 192.0.2.177
www 86400 IN A 192.0.2.177
mail 86400 IN A 192.0.2.178
;
; The Local Network
;
nod 86400 IN A 192.0.2.179
;############################################################
; Current Aliases for foobar.net (CNAME)
;############################################################
;############################################################
; foobar.net MX Records (MAIL EXCHANGER)
;############################################################
foobar.net. 86400 IN A 192.0.2.177
86400 IN MX 0 mail.foobar.net.
86400 IN MX 1 <backup MX>.
+
+
+
7.0 Démarrer et
+Stopper le firewall
+
+
Le firewall est démarré en utilisant la commande
+"shorewall start" et arrêté avec "shorewall stop". Quand le firewall
+est
+arrêté, le routage est actif sur les hôtes qui ont une entrée dans le
+fichier /etc/shorewall/routestopped.
+Le firewall actif peut-être relancé grâce à la commande "shorewall
+restart". Si vous voulez retirer toute trace de Shorewall de votre
+configuration Netfilter, utilisez "shorewall clear".
+
+
Editez
+le fichier /etc/shorewall/routestopped
+file et ajouter les systèmes qui doivent pouvoir se connecter au
+firewall quant il est arrêté.
+
+
ATTENTION: Si vous êtes connecté à votre
+firewall depuis Internet, ne pas exécutez la commande "shorewall
+stop" tant que vous n'avez pas une entrée active pour l'adresse IP de
+votre hôte dans le fichier /etc/shorewall/routestopped.
+Egalement, je ne recommande pas d'utiliser "shorewall restart"; il est
+préférable d'utiliser une configuration
+alternative et la tester avec la commande "shorewall try".
+
Last updated 8/26/2003 - Fabien
+Demassieux and Tom Eastep
+Copyright 2002,
+2003 Fabien Demassieux and Thomas M. Eastep
+
+
+
+
+