From c2ccd7fd3d4b5bbe126481548509da01d8661808 Mon Sep 17 00:00:00 2001 From: teastep Date: Tue, 2 Dec 2003 23:51:46 +0000 Subject: [PATCH] Shorewall 1.4.8 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@800 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/6to4.htm | 201 +- Shorewall-docs/Banner.html | 45 + Shorewall-docs/CorpNetwork.htm | 404 ++- Shorewall-docs/Documentation.htm | 58 +- Shorewall-docs/ECN.html | 133 +- Shorewall-docs/FAQ.htm | 313 +- Shorewall-docs/FTP.html | 63 +- Shorewall-docs/GenericTunnels.html | 13 +- Shorewall-docs/GnuCopyright.htm | 651 +++-- Shorewall-docs/IPIP.htm | 299 +- Shorewall-docs/IPSEC.htm | 57 +- Shorewall-docs/Install.htm | 344 +-- Shorewall-docs/MAC_Validation.html | 186 +- Shorewall-docs/Multiple_Zones.html | 551 ++++ Shorewall-docs/NAT.htm | 196 +- Shorewall-docs/NetfilterOverview.html | 104 + Shorewall-docs/News.htm | 303 +- Shorewall-docs/OPENVPN.html | 456 ++- Shorewall-docs/PPTP.htm | 378 ++- Shorewall-docs/ProxyARP.htm | 325 +-- Shorewall-docs/SeattleInTheSpring.html | 59 +- Shorewall-docs/Shorewall_CA_html.html | 134 +- Shorewall-docs/Shorewall_CVS_Access.html | 74 +- Shorewall-docs/Shorewall_Doesnt.html | 37 +- Shorewall-docs/Shorewall_Squid_Usage.html | 200 +- .../Shorewall_and_Aliased_Interfaces.html | 1181 ++++---- Shorewall-docs/Shorewall_and_Kazaa.html | 32 + Shorewall-docs/Shorewall_index_frame.htm | 156 +- Shorewall-docs/Shorewall_sfindex_frame.htm | 144 +- Shorewall-docs/SourceforgeBanner.html | 45 + Shorewall-docs/UserSets.html | 141 + Shorewall-docs/VPN.htm | 112 +- Shorewall-docs/blacklisting_support.htm | 143 +- Shorewall-docs/configuration_file_basics.htm | 31 +- Shorewall-docs/copyright.htm | 52 +- Shorewall-docs/dhcp.htm | 110 +- Shorewall-docs/download.htm | 47 +- Shorewall-docs/errata.htm | 156 +- Shorewall-docs/fallback.htm | 84 +- Shorewall-docs/gnu_mailman.htm | 105 +- Shorewall-docs/images/Legend.png | Bin 1815 -> 1570 bytes Shorewall-docs/images/Logo.png | Bin 0 -> 3293 bytes Shorewall-docs/images/Logo1.gif | Bin 0 -> 10788 bytes Shorewall-docs/images/Logo2.gif | Bin 0 -> 10788 bytes Shorewall-docs/images/Logo3.png | Bin 0 -> 2275 bytes Shorewall-docs/images/MultiPPTP.png | Bin 0 -> 16164 bytes Shorewall-docs/images/MultiZone1.png | Bin 0 -> 11070 bytes Shorewall-docs/images/MultiZone1A.png | Bin 0 -> 13543 bytes Shorewall-docs/images/MultiZone1B.png | Bin 0 -> 13620 bytes Shorewall-docs/images/MultiZone2.png | Bin 0 -> 10370 bytes Shorewall-docs/images/Netfilter.png | Bin 25936 -> 26876 bytes Shorewall-docs/images/ProtectedBy.png | Bin 0 -> 4978 bytes Shorewall-docs/images/netfilterconf.png | Bin 0 -> 43376 bytes Shorewall-docs/images/staticnat.png | Bin 9725 -> 6422 bytes Shorewall-docs/images/staticnat.vsd | Bin 273392 -> 273392 bytes Shorewall-docs/index.htm | 33 +- Shorewall-docs/kernel.htm | 83 +- Shorewall-docs/mailing_list.htm | 26 +- Shorewall-docs/myfiles.htm | 25 +- Shorewall-docs/ping.html | 13 +- Shorewall-docs/ports.htm | 266 +- Shorewall-docs/quotes.htm | 183 +- Shorewall-docs/samba.htm | 106 +- Shorewall-docs/seattlefirewall_index.htm | 675 ++--- Shorewall-docs/shoreline.htm | 16 +- .../shorewall_extension_scripts.htm | 161 +- Shorewall-docs/shorewall_features.htm | 161 +- .../shorewall_firewall_structure.htm | 332 --- Shorewall-docs/shorewall_logging.html | 46 +- Shorewall-docs/shorewall_mirrors.htm | 21 +- Shorewall-docs/shorewall_prerequisites.htm | 107 +- Shorewall-docs/shorewall_quickstart_guide.htm | 76 +- Shorewall-docs/shorewall_setup_guide.htm | 45 +- Shorewall-docs/shorewall_setup_guide_fr.htm | 2515 +++++++++++++++++ Shorewall-docs/sourceforge_index.htm | 602 ++-- Shorewall-docs/standalone.htm | 27 +- Shorewall-docs/standalone_fr.html | 769 +++-- .../starting_and_stopping_shorewall.htm | 21 +- Shorewall-docs/support.htm | 48 +- Shorewall-docs/three-interface.htm | 33 +- Shorewall-docs/three-interface_fr.html | 2064 +++++++------- Shorewall-docs/traffic_shaping.htm | 619 ++-- Shorewall-docs/troubleshoot.htm | 23 +- Shorewall-docs/two-interface.htm | 33 +- Shorewall-docs/two-interface_fr.html | 2060 +++++++------- Shorewall-docs/upgrade_issues.htm | 693 ++--- Shorewall-docs/useful_links.html | 66 +- .../whitelisting_under_shorewall.htm | 502 ++-- 88 files changed, 11590 insertions(+), 8983 deletions(-) create mode 100755 Shorewall-docs/Banner.html create mode 100755 Shorewall-docs/Multiple_Zones.html create mode 100755 Shorewall-docs/NetfilterOverview.html create mode 100644 Shorewall-docs/Shorewall_and_Kazaa.html create mode 100755 Shorewall-docs/SourceforgeBanner.html create mode 100755 Shorewall-docs/UserSets.html create mode 100755 Shorewall-docs/images/Logo.png create mode 100644 Shorewall-docs/images/Logo1.gif create mode 100644 Shorewall-docs/images/Logo2.gif create mode 100755 Shorewall-docs/images/Logo3.png create mode 100755 Shorewall-docs/images/MultiPPTP.png create mode 100755 Shorewall-docs/images/MultiZone1.png create mode 100755 Shorewall-docs/images/MultiZone1A.png create mode 100755 Shorewall-docs/images/MultiZone1B.png create mode 100755 Shorewall-docs/images/MultiZone2.png create mode 100755 Shorewall-docs/images/ProtectedBy.png create mode 100644 Shorewall-docs/images/netfilterconf.png delete mode 100644 Shorewall-docs/shorewall_firewall_structure.htm create mode 100755 Shorewall-docs/shorewall_setup_guide_fr.htm diff --git a/Shorewall-docs/6to4.htm b/Shorewall-docs/6to4.htm index c7410c168..6ce05185e 100755 --- a/Shorewall-docs/6to4.htm +++ b/Shorewall-docs/6to4.htm @@ -1,144 +1,113 @@ - 6to4 Tunnels - - - - - - - - - - - -
-

6to4 Tunnels

-
- + +

6to4 Tunnels
+

The 6to4 tunnel documentation is provided by Eric de Thouars.
-

- -

Warning: The 6to4 tunnel feature of Shorewall - only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 -security measures.

- -

6to4 tunneling with Shorewall can be used to connect your IPv6 network - to another IPv6 network over an IPv4 infrastructure

- -

More information on Linux and IPv6 can be found in the +

Warning: The 6to4 tunnel feature of +Shorewall only facilitates IPv6 over IPv4 tunneling. It does not +provide any IPv6 +security measures.

+

6to4 tunneling with Shorewall can be used to connect your IPv6 +network to another IPv6 network over an IPv4 infrastructure

+

More information on Linux and IPv6 can be found in the Linux IPv6 HOWTO. -Details on how to setup a 6to4 tunnels are described in the section Setup - of 6to4 tunnels.

- +of 6to4 tunnels.

Connecting two IPv6 Networks

-

Suppose that we have the following situation:

-

-

- -

We want systems in the 2002:100:333::/64 subnetwork to be - able to communicate with the systems in the 2002:488:999::/64 network. This - is accomplished through use of the /etc/shorewall/tunnels file and the "ip" - utility for network interface and routing configuration.

- -

Unlike GRE and IPIP tunneling, the /etc/shorewall/policy, - /etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There - is no need to declare a zone to represent the remote IPv6 network. This -remote network is not visible on IPv4 interfaces and to iptables. All that -is visible on the IPv4 level is an IPv4 stream which contains IPv6 traffic. - Separate IPv6 interfaces and ip6tables rules need to be defined to handle + width="745" height="427" alt="">

+

We want systems in the 2002:100:333::/64 subnetwork to +be able to communicate with the systems in the 2002:488:999::/64 +network. This is accomplished through use of the /etc/shorewall/tunnels +file and the "ip" utility for network interface and routing +configuration.

+

Unlike GRE and IPIP tunneling, the +/etc/shorewall/policy, /etc/shorewall/interfaces and +/etc/shorewall/zones files are not used. There is no need to declare a +zone to represent the remote IPv6 network. This +remote network is not visible on IPv4 interfaces and to iptables. All +that +is visible on the IPv4 level is an IPv4 stream which contains IPv6 +traffic. Separate IPv6 interfaces and ip6tables rules need to be +defined to handle this traffic.

- -

In /etc/shorewall/tunnels on system A, we need the following:

- -
+

In /etc/shorewall/tunnels on system A, we need the +following:

+
- - - - - - - - - - - - - - - + + + + + + + + + + + + + +
TYPEZONEGATEWAYGATEWAY ZONE
6to4net134.28.54.2 
TYPEZONEGATEWAYGATEWAY ZONE
6to4net134.28.54.2 
-
- -

This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6 - encapsulation protocol (41) will be accepted to/from the remote gateway.

- +
+

This entry in /etc/shorewall/tunnels, opens the firewall so that the +IPv6 encapsulation protocol (41) will be accepted to/from the remote +gateway.

Use the following commands to setup system A:

- -
+

>ip tunnel add tun6to4 mode sit ttl 254 remote 134.28.54.2
- >ip link set dev tun6to4 up
- >ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4
- >ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2

-
- +>ip link set dev tun6to4 up
+>ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4
+>ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2

+

Similarly, in /etc/shorewall/tunnels on system B we have:

- -
+
- - - - - - - - - - - - - - - + + + + + + + + + + + + + +
TYPEZONEGATEWAYGATEWAY ZONE
6to4net206.191.148.9 
TYPEZONEGATEWAYGATEWAY ZONE
6to4net206.191.148.9 
-
- +

And use the following commands to setup system B:

- -
+

>ip tunnel add tun6to4 mode sit ttl 254 remote 206.191.148.9
- >ip link set dev tun6to4 up
- >ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4
- >ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1

-
- -

On both systems, restart Shorewall and issue the configuration commands - as listed above. The systems in both IPv6 subnetworks can now talk to each - other using IPv6.

- -

Updated 5/18/2003 - Tom Eastep -

- -

Copyright © +>ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4
+>ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1

+
+

On both systems, restart Shorewall and issue the configuration +commands as listed above. The systems in both IPv6 subnetworks can now +talk to each other using IPv6.

+

Updated 5/18/2003 - Tom Eastep +

+

Copyright © 2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.

-
-
-
-
+
+
+
+
diff --git a/Shorewall-docs/Banner.html b/Shorewall-docs/Banner.html new file mode 100755 index 000000000..cd2fe8127 --- /dev/null +++ b/Shorewall-docs/Banner.html @@ -0,0 +1,45 @@ + + + + + Banner + + + + + + + + + + + +
+
(Shorewall Logo)
+ 		+
Note: Search +is unavailable Daily 0200-0330 GMT.
+ +

Quick Search
+         Extended Search

+
+
+ + diff --git a/Shorewall-docs/CorpNetwork.htm b/Shorewall-docs/CorpNetwork.htm index 3c441c522..d6e05e68b 100644 --- a/Shorewall-docs/CorpNetwork.htm +++ b/Shorewall-docs/CorpNetwork.htm @@ -1,285 +1,229 @@ - + Corporate Shorewall Configuration - - - - - - - + - - - - - - - - -
-

Multiple IPs with DMZ and Internal - Servers

-
- +//-->
- -

Corporate Network

- +

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.
    • - +
  • 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.

- -

(Corporate Network Diagram) +

Warning: This +configuration +uses a combination of One-to-one 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:

- -

- -

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.
    • - +
  • SNAT for all systems connected to the LAN - Internal addresses +10.10.x.x to external address 192.0.18.127.
    • +
  • One-to-one NAT for Polaris (Exchange Server #2). +Internal +address 10.10.1.8 and external address 192.0.18.70.
    • +
  • One-to-one NAT for Sims (Inventory Management server). +Internal address 10.10.1.56 and external address 192.0.18.75.
    +
    • +
  • One-to-one NAT for Project (Project Web Server). +Internal +address 10.10.1.55 and external address 192.0.18.84.
    • +
  • One-to-one NAT for Fortress (Exchange Server). Internal +address 10.10.1.252 and external address 192.0.18.93.
    • +
  • One-to-one NAT for BBSRV (Blackberry Server). Internal +address 10.10.1.230 and external address 192.0.18.97.
    • +
  • One-to-one 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.

+

(Corporate Network Diagram)

+

+

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.

-
- +

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

-
- +#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 +

+

Last updated 11/13/2003 -
-

- -

Copyright 2003 Thomas M. Eastep and +//
+

+

Copyright 2003 Thomas M. Eastep +and Graeme Boyle
-

-
-
+

+
+
diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index 5539401a4..07d3e3f14 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -12,17 +12,8 @@ - - - - - - -
-

Shorewall 1.4 Reference

-
+

Shorewall 1.4 Reference
+

This documentation is intended primarily for reference. Step-by-step instructions for configuring Shorewall in common setups may be found in the
  • common.def -- a parameter file installed in in /etc/shorewall that defines firewall-wide rules that are applied before a DROP or REJECT policy is applied.
    • -
  • interfaces -- a parameter +
  • init.sh -- a shell +script installed in /etc/init.d to automatically start Shorewall during +boot.
    +
    • +
  • interfaces -- a parameter file installed in /etc/shorewall/ and used to describe the interfaces on the firewall system.
  • hosts -- a parameter file installed @@ -78,15 +73,12 @@ possibly also the IP address(es)) of devices.
  • masq - This file also describes IP masquerading under Shorewall and is installed in /etc/shorewall.
    • -
  • firewall -- +
  • firewall -- a shell program that reads the configuration files in /etc/shorewall -and configures your firewall. This file is installed in your init.d -directory (/etc/rc.d/init.d ) where it is renamed shorewall. -/etc/shorewall/firewall (/var/lib/shorewall/firewall in versions -1.3.2-1.3.8 and /usr/lib/shorewall/firewall in 1.3.9 and later) is a -symbolic link to this program.
    • +and configures your firewall. This file is installed in +/usr/share/shorewall.
  • nat -- a parameter file in -/etc/shorewall used to define static NAT .
    • +/etc/shorewall used to define one-to-one NAT .
  • proxyarp -- a parameter file in /etc/shorewall used to define Proxy Arp .
  • rfc1918 -- a parameter file in @@ -1190,6 +1182,13 @@ header-rewriting rule.
  • LOG - Log the packet -- requires a syslog level (see below).
    • +
  • QUEUE - Forward the packet to a user-space application. This +facility is provided to allow interfacing to ftwall for Kazaa filtering. Note: When the +protocol specified in the PROTO column is TCP ("tcp", "TCP" or "6"), +Shorewall will only pass connection requests (SYN packets) to user +space. This is for compatibility with ftwall.

    • Beginning with Shorewall version 1.4.7, you may rate-limit the rule by optionally following ACCEPT, DNAT[-], REDIRECT[-] or LOG with
    @@ -2253,16 +2252,20 @@ following (I haven't tried it):

    In /etc/shorewall/start, include:

    qt service ipsec start

    /etc/shorewall/nat

    -

    The /etc/shorewall/nat file is used to define static NAT. There is -one entry in the file for each static NAT relationship that you wish to +

    The /etc/shorewall/nat file is used to define one-to-one NAT. There +is +one entry in the file for each one-to-one NAT relationship that you +wish to define. In order to make use of this feature, you must have NAT enabled .

    IMPORTANT: If all you want to do is forward ports to servers behind your firewall, you do NOT want to use -static NAT. Port forwarding can be accomplished with simple entries in +one-to-one NAT. Port forwarding can be accomplished with simple entries +in the rules file. Also, in most cases Proxy ARP provides a superior solution to static -NAT because the internal systems are accessed using the same IP address + href="#ProxyArp"> Proxy ARP provides a superior solution to +one-to-one NAT because the internal systems are accessed using the same +IP address internally and externally.

    Columns in an entry are:

     -
  • Proxy -ARP
    • +
  • PPTP
    • +
  • Proxy ARP
  • Requirements
  • Samba
    • @@ -197,8 +196,7 @@ Subnets and Routing
  • 5.3 Rules
    • @@ -235,14 +234,11 @@ Starting and Stopping the Firewall href="starting_and_stopping_shorewall.htm">Starting/stopping the Firewall
      -
    • Description of all /sbin/shorewall -commands
      • +
    • Description of all /sbin/shorewall commands
    • How to safely test a Shorewall configuration change
    -
  • Static NAT
    • -
  • Squid as a Transparent Proxy -with Shorewall
    • +
  • Squid with Shorewall
  • Traffic Accounting
  • Traffic Shaping/QOS
    • @@ -255,14 +251,14 @@ doesn't work)
  • VPN

    If you use one of these guides and have a suggestion for improvement please let me know.

    -

    Last modified 9/23/2003 - Tom +

    Last modified 11/22/2003 - Tom Eastep

    Copyright 2002, 2003 Thomas M. Eastep
    diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm index 3df10dd9e..d66583d76 100644 --- a/Shorewall-docs/shorewall_setup_guide.htm +++ b/Shorewall-docs/shorewall_setup_guide.htm @@ -10,18 +10,8 @@ - - - - - - -
    -

    Shorewall Setup Guide

    -
    -
    +

    Shorewall Setup Guide
    +

    1.0 Introduction
    2.0 Shorewall Concepts
    3.0 Network Interfaces
    @@ -41,7 +31,7 @@

    5.2.1 SNAT
    5.2.2 DNAT
    5.2.3 Proxy ARP
    - 5.2.4 Static NAT

    + 5.2.4 One-to-one NAT

    5.3 Rules
    5.4 Odds and Ends

    @@ -929,7 +919,15 @@ a VPN relationship.

    So it's a good idea to check with your ISP to see if they are using (or are planning to use) private addresses before you -decide the addresses that you are going to use.

    +decide the addresses that you are going to use.
    +

    +

    NOTE: In this +document, external "real" IP addresses are of the form 192.0.2.x. +192.0.2.0/24 is reserved by RFC 3330 for use as public IP addresses in +printed examples. These addresses are not to be confused with addresses +in 192.168.0.0/16; as described above, these addresses are reserved by +RFC 1918 for private use.
    +

    5.0 Setting up your Network

    @@ -1077,7 +1075,7 @@ also known as Port Forwarding.

  • Network Address Translation (NAT) also -referred to as Static NAT.

    +referred to as One-to-one NAT.

    • @@ -1230,12 +1228,13 @@ your public IP addresses (A) and is assigned the same netmask (M)

    When H issues an ARP "who has" request for an address in the subnetwork defined by A and M, the firewall will -respond (with the MAC if the firewall interface to H).

    +respond (with the MAC if the firewall interface) to H.

    -

    Let suppose that we decide to use Proxy ARP on the DMZ +

    Let us suppose that we decide to use Proxy ARP on the +DMZ in our example network.

    @@ -1323,7 +1322,7 @@ accordingly."

    Which is, of course, exactly what you want to do when you switch a host from being exposed to the Internet to behind Shorewall using proxy ARP -(or static NAT for that matter). Happily enough, recent versions +(or one-to-one NAT for that matter). Happily enough, recent versions of Redhat's iputils package include "arping", whose "-U" flag does just that:

    @@ -1371,10 +1370,10 @@ words, the gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the firewall's eth0.

    -

    5.2.4 Static NAT

    +

    5.2.4 One-to-one NAT

    -

    With static NAT, you assign local systems RFC 1918 +

    With one-to-one NAT, you assign local systems RFC 1918 addresses then establish a one-to-one mapping between those addresses and public IP addresses. For outgoing connections SNAT (Source Network @@ -1486,7 +1485,7 @@ daughter's web server -- you would rather just use an ACCEPT rule:

    A word of warning is in order here. ISPs typically configure their routers with a long ARP cache timeout. If you move a system from parallel to your firewall to behind your firewall with -static NAT, it will probably be HOURS before that system can +one-to-one NAT, it will probably be HOURS before that system can communicate with the internet. There are a couple of things that you can try:

    @@ -1506,7 +1505,7 @@ accordingly."

    Which is, of course, exactly what you want to do when you switch a host from being exposed to the Internet to behind Shorewall using proxy ARP -(or static NAT for that matter). Happily enough, recent versions +(or one-to-one NAT for that matter). Happily enough, recent versions of Redhat's iputils package include "arping", whose "-U" flag does just that:

    @@ -2367,7 +2366,7 @@ create an alternate configuration and test it using the "shorewall try" command.

    -

    Last updated 7/6/2003 - Last updated 11/18/2003 - Tom Eastep

    Copyright 2002, 2003 Thomas M. Eastep
    diff --git a/Shorewall-docs/shorewall_setup_guide_fr.htm b/Shorewall-docs/shorewall_setup_guide_fr.htm new file mode 100755 index 000000000..ec9e15533 --- /dev/null +++ b/Shorewall-docs/shorewall_setup_guide_fr.htm @@ -0,0 +1,2515 @@ + + + + + + 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 One-to-one 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:

    + + + + + + + + + + + + + + + + + + + +
    NomDescription
    netL'Internet
    locVotre réseau local
    +
    dmzZone 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:

    +
      +
    1. Identifiez la zone source.
      2. +
    2. Identifiez la zone destination.
      3. +
    3. Si la POLICE de la zone client vers la zone destination est ce +que +vous souhaitez pour cette paire client/serveur, vous n'avez besoin de +rien de plus.
      4. +
    4. 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.
      5. +
    +

    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
    +     		PoliceNiveau de LogLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    +
    +

    La police précédente:

    +
      +
    1. Permet toutes les connexions de votre réseau local vers Internet,
      2. +
    2. 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).
      3. +
    3. 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.
      4. +
    +

        +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:

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918
    loceth1detect 
    dmzeth2detect 
    +
    +

    +    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:

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918
    loceth1detect 
    loceth2detectdhcp
    +
    +
    +

    Si vous avez plus d'une interface pour une zone, vous +voudrez probablement une police qui permet le trafic intra-zone:

    +
    +
    +
    + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    loclocACCEPT  
    +
    +
    +

    +    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:

    +
      +
    1. +

      Le nombre d'adresses dans le jeu est un multiple de +2; et

      +
      2. +
    2. +

      La première adresse dans le jeu est un multiple de +la taille du jeu.

      +
      3. +
    3. +

      La première adresse du sous-réseau est réservée et +se réfère à l'adresse du sous-réseau.

      +
      4. +
    4. +

      La dernière adresse du sous-réseau est réservée +comme adresse broadcast du sous-réseau.

      +
      5. +
    +

    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:

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    nlog2 n(32 - log2 n)
    8329
    16428
    32527
    64626
    128725
    256824
    512923
    10241022
    20481121
    40961220
    81921319
    163841418
    327681517
    655361616
    +
    +

    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
    +     		VLSMMasque sous-réseau
    +
    8/29255.255.255.248
    16/28255.255.255.240
    32/27255.255.255.224
    64/26255.255.255.192
    128/25255.255.255.128
    256/24255.255.255.0
    512/23255.255.254.0
    1024/22255.255.252.0
    2048/21255.255.248.0
    4096/20255.255.240.0
    8192/19255.255.224.0
    16384/18255.255.192.0
    32768/17255.255.128.0
    65536/16255.255.0.0
    2 ** 24/8255.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éseauNotation CIDR
    132255.255.255.255a.b.c.d/32
    2 ** 3200.0.0.00.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:
    +

    +
    +
    +
      +
    1. +

      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.

      +
      2. +
    2. +

      Non-routé - Votre FAI vous enverra +directement le trafic de chaque adresse directement.

      +
      3. +
    +
    +
    +

    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
      +
      • +
    +
    +
    +

    5.1 Routage

    +
    +
    +

    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.

    +
    +
    +

    5.2 Non-routé

    +
    +
    +

    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é One-to-one NAT.

      +
      • +
    +
    +
    +

    Souvent une combinaison de ces techniques est utilisée. +Chacune d'entre elle sera détaillée dans la section suivante.

    +
    +
    +

     5.2.1 SNAT

    +
    +
    +

    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).
    +
     
    +
    +    SNAT est configuré dans Shorewall avec le +fichier  /etc/shorewall/masq.
    +
    +
    + + + + + + + + + + + + + +
    INTERFACESOUS-RESEAUADDRESSE
    eth0192.168.201.0/29192.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.

    +
    +
    +

    5.2.2 DNAT

    +
    +
    +

    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:

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    DNATnetloc:192.168.201.4tcpwww-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.

    +
    +
    +

    5.2.3 Proxy ARP

    +
    +
    +

    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.
    +
     
    +
    +    La configuration de Proxy ARP est faite dans le +fichier /etc/shorewall/proxyarp.
    +
    +
    + + + + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    +
    +
    +
    +

    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:
    +

    +
      +
    1. (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 one-to-one 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.
      +
      +
      2. +
    2. 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.
      3. +
    +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):

    +
    +
    +
    	ping 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.2.4 One-to-one NAT

    +
    +
    +

    Avec one-to-one 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:

    +
    +
    +
    + + + + + + + + + + + + + +
    INTERFACESOUS-RESEAUADDRESSE
    eth0192.168.201.0/29192.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.

    +
    +
    +
    + + + + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    +
    +
    +
    +

    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:

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    ACCEPTnetloc:192.168.201.4tcpwww  
    +
    +
    +
    +
    +
    +

    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:
    +

    +
      +
    1. (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 one-to-one 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.
      +
      +
      2. +
    2. 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.
      3. +
    +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):

    +
    +
    +
    	ping 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:

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-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:

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail depuis Internet
    +
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 depuis Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail depuis le Réseau Local
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 depuis le Réseau Local
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail depuis le firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mails vers Internet
    +
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW depuis le Net
    +
    ACCEPTnetdmz:192.0.2.177tcphttps# HTTP sécurisé depuis le Net
    ACCEPTlocdmz:192.0.2.177tcphttps# 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:

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS depuis Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS depuis Internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS depuis le firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS depuis le firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS depuis le Réseau local
    +
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS depuis le Réseau local
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS vers Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# 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.

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH vers la DMZ
    ACCEPTlocfwtcpssh# 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).

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    +
    +
    +
    +

    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.
    +

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    +
    +
    +
    +

    /etc/shorewall/masq - Sous-réseau Local
    +

    +
    +
    +
    + + + + + + + + + + + + + +
    INTERFACESOUS-RESEAUADDRESS
    eth0192.168.201.0/29192.0.2.176
    +
    +
    +
    +

    /etc/shorewall/proxyarp - DMZ

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    +
    +
    +
    +

    /etc/shorewall/nat- Le système de ma fille
    +

    +
    +
    +
    + + + + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    +
    +
    +
    +

    /etc/shorewall/rules

    +
    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail depuis Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 depuis Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail depuis le Réseau Local
    +
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 depuis le Réseau Local
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail depuis le firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail vers Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW depuis le Net
    ACCEPTnetdmz:192.0.2.178tcphttps# HTTP sécurisé depuis le Net
    ACCEPTlocdmz:192.0.2.178tcphttps# HTTP sécurisé depuis le Réseau Local
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS depuis Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS depuis Internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS depuis le firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS depuis le firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS depuis le Réseau Local
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS depuis le Réseau Local
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS vers Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS vers Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH vers DMZ
    ACCEPTlocfwtcpssh# SSH vers le firewall
    +
    +
    +
    +

    6.0 DNS

    +
    +
    +

    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

    +
    +
    +

    La procédure +d'installation configure votre système pour que Shorewall démarre +au +boot du système.

    +
    +
    +

    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 11/13/2003 - Fabien +Demassieux and Tom Eastep

    +

    Copyright 2002, +2003 Fabien Demassieux and Thomas M. Eastep
    +

    +
    +
    + + diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index 05cb287ed..b730008b1 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -7,18 +7,6 @@ - - - - - - -
    (Shorewall Logo)
    -
    -
    +

    Site Problem

    +The server that normally hosts www.shorewall.net and ftp.shorewall.net +is currently down. Until it is back up, a small server with very +limited bandwidth is being used temporarly. You will likely experience +better response time from the Sourceforge site +or from one of the other mirrors. +Sorry for the inconvenience.
    +

    Introduction

      @@ -37,14 +34,12 @@ and control that facility. Netfilter can be used in ipchains compatibility mode.
    • iptables - the utility program used to configure and -control -Netfilter. The term 'iptables' is often used to refer to the -combination of iptables+Netfilter (with Netfilter not in -ipchains compatibility mode).
      +control Netfilter. The term 'iptables' is often used to refer to the +combination of iptables+Netfilter (with Netfilter not in ipchains +compatibility mode).
    -The -Shoreline Firewall, more commonly known as "Shorewall", is +The Shoreline Firewall, more commonly known as "Shorewall", is high-level tool for configuring Netfilter. You describe your firewall/gateway requirements using entries in a set of configuration files. Shorewall reads those configuration files and with the help of @@ -56,14 +51,14 @@ and can thus take advantage of Netfilter's connection state tracking capabilities.

    This program is free software; you can redistribute it and/or modify it under the terms of Version 2 of the -GNU General Public License as published by the Free Software -Foundation.
    + href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU +General Public License as published by the Free Software Foundation.

    This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details.
    +General +Public License for more details.

    You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., @@ -81,356 +76,205 @@ Shorewall. For older versions:

    Getting Started with Shorewall

    -New to Shorewall? Start by -selecting the QuickStart Guide -that most closely match your environment and -follow the step by step instructions.
    +New to Shorewall? Start by selecting the QuickStart Guide that most +closely match your environment and follow the step by step instructions.

    Looking for Information?

    The Documentation -Index is a good place to start as is the Quick Search to your -right. +Index is a good place to start as is the Quick Search in the frame +above.

    Running Shorewall on Mandrake with a two-interface setup?

    If so, the documentation on this site will not apply directly -to your setup. If you want to -use the documentation that you find here, you will want to consider -uninstalling what you have and installing a setup that matches the -documentation on this site. See the Two-interface -QuickStart Guide for +to +your setup. If you want to use the documentation that you find here, +you will want to consider uninstalling what you have and installing a +setup that matches the documentation on this site. See the Two-interface QuickStart Guide for details.

    News

    - 10/06/2003 - Shorewall 1.4.7 11/01/2003 - Shorewall 1.4.8 RC2 (New)
    -
    -Problems Corrected since version 1.4.6 (Those in bold font -were corrected since 1.4.7 RC2).
    -
      -
    1. Corrected problem in 1.4.6 where the MANGLE_ENABLED -variable was being tested before it was set.
      2. -
    2. Corrected handling of MAC addresses in the SOURCE column of -the tcrules file. Previously, these addresses resulted in an invalid -iptables command.
      3. -
    3. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled exists. This prevents people from -shooting themselves in the foot prior to having configured Shorewall.
      4. -
    4. A change introduced in version 1.4.6 caused error messages -during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses -were being added to a PPP interface; the addresses were successfully -added in spite of the messages.
      -   
      -The firewall script has been modified to eliminate the error messages
      5. -
    5. Interface-specific dynamic blacklisting chains are -now displayed by "shorewall monitor" on the "Dynamic Chains" page -(previously named "Dynamic Chain").
      6. -
    6. Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
      7. -
    7. The 'shorewall reject' -and -'shorewall drop' commands now delete any existing rules for the subject -IP address before adding a new DROP or REJECT rule. Previously, there -could be many rules for the same IP address in the dynamic chain so -that multiple 'allow' commands were required to re-enable traffic -to/from the address.
      8. -
    8. When ADD_SNAT_ALIASES=Yes in -shorewall.conf, the following entry in /etc/shorewall/masq resulted in -a startup error:
      - 
      -   eth0 eth1     -206.124.146.20-206.124.146.24
      -
      -
      9. -
    9. Shorewall previously choked over -IPV6 -addresses configured on interfaces in contexts where Shorewall needed -to detect something about the interface (such as when "detect" appears -in the BROADCAST column of the /etc/shorewall/interfaces file).
      10. -
    10. Shorewall will now load -module files that are formed from the module name by appending ".o.gz".
      11. -
    11. When Shorewall adds a route to a -proxy -ARP host and such a route already exists, two routes resulted -previously. This has been corrected so that the existing route is -replaced if it already exists.
      12. -
    12. The rfc1918 file has been -updated to reflect recent allocations.
      13. -
    13. The documentation of the -USER SET column in the rules file has been corrected.
      14. -
    14. If there is no policy -defined for -the zones specified in a rule, the firewall script previously -encountered a shell syntax error:
      -                                                                                                                                                                                    -
      -        [: NONE: unexpected operator
      -                                                                                                                                                                                    -
      -Now, the absence of a policy generates an error message and the -firewall is stopped:
      -                                                                                                                                                                                    -
      -        No policy defined from zone -<source> to zone <dest>
      -
      -
      15. -
    15. Previously, if neither -/etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall -would fail to start and would not remove the lock file. Failure to -remove the lock file resulted in the following during subsequent -attempts to start:
      -                                                                                                                                                                                    -
      -    Loading /usr/share/shorewall/functions...
      -    Processing /etc/shorewall/params ...
      -    Processing /etc/shorewall/shorewall.conf...
      -    Giving up on lock file /var/lib/shorewall/lock
      -    Shorewall Not Started
      -
      -Shorewall now reports a fatal error if neither of these two files exist -and correctly removes the lock fille.
      16. -
    16. The order of processing -the -various options has been changed such that blacklist entries now take -precedence over the 'dhcp' interface setting.
      17. -
    17. The log message generated -from the -'logunclean' interface option has been changed to reflect a disposition -of LOG rather than DROP.
      18. -
    18. When a user name and/or a -group -name was specified in the USER SET column and the destination zone was -qualified with a IP address, the user and/or group name was not being -used to qualify the rule.
      - 
      -    Example:
      - 
      -    ACCEPT fw  net:192.0.2.12 tcp 23 - - - vladimir:
      -
      -
      19. -
    19. The /etc/shorewall/masq -file has had the spurious "/" character at the front removed.
      20. -
    - Migration Issues:
    -
      -
    1. Shorewall IP Traffic Accounting has changed since snapshot -20030813 -- see the Accounting Page for -details.
      2. -
    2. The Uset Set capability introduced in SnapShot 20030821 has -changed -- see the User Set page for -details.
      3. -
    3. The -per-interface Dynamic Blacklisting facility introduced in the first -post-1.4.6 Snapshot has been removed. The facility had too many -idiosyncrasies for dial-up users to be a viable part of Shorewall.
      -
      4. -
    - New Features:
    -
      -
    1. Shorewall now creates a dynamic blacklisting chain for each -interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject' -commands use the routing table to determine which of these chains is to -be used for blacklisting the specified IP address(es).
      -
      -Two new commands ('dropall' and 'rejectall') have been introduced that -do what 'drop' and 'reject' used to do; namely, when an address is -blacklisted using these new commands, it will be blacklisted on all of -your firewall's interfaces.
      2. -
    2. Thanks to Steve Herber, the 'help' command can now give -command-specific help (e.g., shorewall help <command>).
      3. -
    3. A new option "ADMINISABSENTMINDED" has been added to -/etc/shorewall/shorewall.conf. This option has a default value of "No" -for existing users which causes Shorewall's 'stopped' state  to -continue as it has been; namely, in the stopped state only traffic -to/from hosts listed in /etc/shorewall/routestopped is accepted.
      -
      -With ADMINISABSENTMINDED=Yes (the default for new installs), in -addition to traffic to/from the hosts listed in -/etc/shorewall/routestopped, Shorewall will allow:
      -
      -   a) All traffic originating from the firewall itself; and
      -   b) All traffic that is part of or related to an -already-existing connection.
      -
      - In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" -entered through an ssh session will not kill the session.
      -
      - Note though that even with ADMINISABSENTMINDED=Yes, it is still -possible for people to shoot themselves in the foot.
      -
      - Example:
      -
      - /etc/shorewall/nat:
      -
      -     206.124.146.178    -eth0:0    192.168.1.5   
      -
      - /etc/shorewall/rules:
      -
      -   ACCEPT    net    -loc:192.168.1.5    tcp    22
      -   ACCEPT    loc    -fw        tcp    22
      -
      -From a remote system, I ssh to 206.124.146.178 which establishes an SSH -connection with local system 192.168.1.5. I then create a second SSH -connection -from that computer to the firewall and confidently type "shorewall -stop". -As part of its stop processing, Shorewall removes eth0:0 which kills my -SSH -connection to 192.168.1.5!!!
      4. -
    4. Given the wide range of VPN software, I can never hope to -add specific support for all of it. I have therefore decided to add -"generic" tunnel support.
      - 
      -Generic tunnels work pretty much like any of the other tunnel types. -You usually add a zone to represent the systems at the other end of the -tunnel and you add the appropriate rules/policies to
      -implement your security policy regarding traffic to/from those systems.
      - 
      -In the /etc/shorewall/tunnels file, you can have entries of the form:
      -
      -generic:<protocol>[:<port>]  <zone>  <ip -address>    <gateway zones>
      - 
      -where:
      - 
      -       <protocol> is the protocol -used by the tunnel
      -       <port>  if the protocol -is 'udp' or 'tcp' then this is the destination port number used by the -tunnel.
      -       <zone>  is the zone of -the remote tunnel gateway
      -       <ip address> is the IP -address of the remote tunnel gateway.
      -       <gateway zone>   -Optional. A comma-separated list of zone names. If specified, the -remote gateway is to be considered part of these zones.
      5. -
    5. An 'arp_filter' option has been added to the -/etc/shorewall/interfaces file. This option causes -/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the -result that this interface will only answer ARP 'who-has' requests from -hosts that are routed out through that interface. Setting this option -facilitates testing of your firewall where multiple firewall interfaces -are connected to the same HUB/Switch (all interfaces connected to the -single HUB/Switch should have this option specified). Note that using -such a configuration in a production environment is strongly -recommended against.
      6. -
    6. The ADDRESS column in /etc/shorewall/masq may now include a -comma-separated list of addresses and/or address ranges. Netfilter will -use all listed addresses/ranges in round-robin fashion. \
      7. -
    7. An /etc/shorewall/accounting file has been added to allow -for traffic accounting.  See the accounting -documentation for a description of this facility.
      8. -
    8. Bridge interfaces (br[0-9]) may now be used in -/etc/shorewall/maclist.
      9. -
    9. ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in -/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT -rules, rate limiting occurs in the nat table DNAT rule; the -corresponding ACCEPT rule in the filter table is not rate limited. If -you want to limit the filter table rule, you will need o create two -rules; a DNAT- rule and an ACCEPT rule which can be rate-limited -separately.
      - 
      - Warning: When rate -limiting is specified on a rule with "all" in the SOURCE or DEST -fields, the limit will apply to each pair of zones individually rather -than as a single limit for all pairs of covered by the rule.
      - 
      -To specify a rate limit,
      -
      -a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
      - 
      -      < -<rate>/<interval>[:<burst>] >
      - 
      -  -where
      - 
      -      <rate> is the sustained rate per -<interval>
      -      <interval> is "sec" or "min"
      -      <burst> is the largest burst -accepted within an <interval>. If not given, the default of 5 is -assumed.
      - 
      -There may be no white space between the ACTION and "<" nor there may -be any white space within the burst specification. If you want to -specify logging of a rate-limited rule, the ":" and log level comes -after the ">" (e.g., ACCEPT<2/sec:4>:info ).
      -
      -b) A new RATE LIMIT column has been added to the /etc/shorewall/rules -file. You may specify the rate limit there in the format:
      -
      -      -<rate>/<interval>[:<burst>]
      - 
      -Let's take an example:
      - 
      -         -ACCEPT<2/sec:4>        -net     dmz     -tcp     80
      -   
      -The first time this rule is reached, the packet will be accepted; in -fact, since the burst is 4, the first four packets will be accepted. -After this, it will be 500ms (1 second divided by the rate
      -of 2) before a packet will be accepted from this rule, regardless of -how many packets reach it. Also, every 500ms which passes without -matching a packet, one of the bursts will be regained; if no packets -hit the rule for 2 second, the burst will be fully recharged; back -where we started.
      -
      10. -
    10. Multiple chains may now be displayed in one "shorewall -show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
      11. -
    11. Output rules (those with $FW as the SOURCE) may now be -limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for -details.
      12. -
    -

    8/27/2003 - Shorewall Mirror in Australia 

    -

    Thanks to Dave Kempe and Solutions First (http://www.solutionsfirst.com.au), -there is now a Shorewall Mirror in Australia:

    - -

    8/26/2003 - French Version of the Shorewall Setup -Guide 

    -Thanks to Fabien Demassieux, there is now a French translation of the -Shorewall Setup Guide. Merci Beacoup, Fabien! 9/15/2003 -- Shorewall 1.4.7 Beta 2 (New) -

    8/5/2003 - Shorewall-1.4.6b (New)
    + src="file:///vfat/Shorewall-docs/images/new10.gif" alt="(New)" title="">

    - Problems Corrected since version 1.4.6:
    +Given the small number of new features and the relatively few lines of +code that were changed, there will be no Beta for 1.4.8.
    +

    http://shorewall.net/pub/shorewall/Beta
    + ftp://shorewall.net/pub/shorewall/Beta
    +
    +     Problems Corrected since version 1.4.7:
    +

      -
    1. Previously, if TC_ENABLED is set to yes in shorewall.conf -then Shorewall would fail to start with the error "ERROR:  Traffic -Control requires Mangle"; that problem has been corrected.
      2. -
    2. Corrected handling of MAC addresses in the SOURCE column of +
    3. Tuomo Soini has supplied a correction to a problem that +occurs +using some versions of 'ash'. The symptom is that "shorewall start" +fails with:
      + 
      +   local: --limit: bad variable name
      +   iptables v1.2.8: Couldn't load match +`-j':/lib/iptables/libipt_-j.so:
      +   cannot open shared object file: No such file or directory
      +   Try `iptables -h' or 'iptables --help' for more +information.
      4. +
    4. Andres Zhoglo has supplied a correction that avoids trying +to use the multiport match iptables facility on ICMP rules.
      + 
      +   Example of rule that previously caused "shorewall start" +to fail:
      + 
      +           +ACCEPT      loc  $FW  +icmp    0,8,11,12
      +
      +
      5. +
    5. Previously, if the following error message was issued, +Shorewall was left in an inconsistent state.
      + 
      +   Error: Unable to determine the routes through interface xxx
      +
      +
      6. +
    6. Handling of the LOGUNCLEAN option in shorewall.conf has +been corrected.
      7. +
    7. In Shorewall 1.4.2, an optimization was added. This +optimization +involved creating a chain named "<zone>_frwd" for most zones +defined using the /etc/shorewall/hosts file. It has since been +discovered that in many cases these new chains contain redundant rules +and that the "optimization" turns out to be less than optimal. The +implementation has now been corrected.
      8. +
    8. When the MARK value in a tcrules entry is followed by ":F" +or +":P", the ":F" or ":P" was previously only applied to the first +Netfilter rule generated by the entry. It is now applied to all entries.
      9. +
    9. An incorrect comment concerning Debian's use of the +SUBSYSLOCK option has been removed from shorewall.conf.
      10. +
    10. Previously, neither the 'routefilter' interface option nor the -tcrules file. Previously, these addresses resulted in an invalid -iptables -command.
      11. -
    11. The "shorewall stop" command is now disabled when -/etc/shorewall/startup_disabled -exists. This prevents people from shooting themselves in the foot prior -to -having configured Shorewall.
      12. -
    12. A change introduced in version 1.4.6 caused error messages -during -"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were -being -added to a PPP interface; the addresses were successfully added in -spite -of the messages.
      -  
      -The firewall script has been modified to eliminate the error messages.
      13. +ROUTE_FILTER parameter were working properly. This has been corrected +(thanks to Eric Bowles for his analysis and patch). The definition of +the ROUTE_FILTER option has changed however. Previously, +ROUTE_FILTER=Yes was documented as enabling route filtering on all +interfaces (which didn't work). Beginning with this release, setting +ROUTE_FILTER=Yes will enable route filtering of all interfaces brought +up while Shorewall is started. As a consequence, ROUTE_FILTER=Yes can +coexist with the use of the 'routefilter' option in the interfaces file. +
    13. If MAC verification was enabled on an interface with a /32 +address and +a broadcast address then an error would occur during startup.
      14. +
    +Migration Issues:
    +
      +
    1. The definition of the ROUTE_FILTER option in shorewall.conf +has changed as described in item 8) above.
      +
      2. +
    +New Features:
    +
      +
    1. A new QUEUE action has been introduced for rules. QUEUE +allows +you to pass connection requests to a user-space filter such as ftwall +(http://p2pwall.sourceforge.net). The ftwall program +allows for effective filtering of p2p applications such as Kazaa. For +example, to use ftwall to filter P2P clients in the 'loc' zone, you +would add the following rules:
      +
      +   QUEUE   loc    +     net    tcp
      +   QUEUE   loc    +     net    udp
      +   QUEUE   loc    +     fw     udp
      +
      +You would normally want to place those three rules BEFORE any ACCEPT +rules for loc->net udp or tcp.
      +
      +Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), +Shorewall will only pass connection requests (SYN packets) to user +space. This is for compatibility with ftwall.
      2. +
    2. A +BLACKLISTNEWNONLY option has been added to shorewall.conf. When this +option is set to "Yes", the blacklists (dynamic and static) are only +consulted for new connection requests. When set to "No" (the default if +the variable is not set), the blacklists are consulted on every packet.
      +
      +Setting this option to "No" allows blacklisting to stop existing +connections from a newly blacklisted host but is more expensive in +terms of packet processing time. This is especially true if the +blacklists contain a large number of entries.
      3. +
    3. Chain names used in the /etc/shorewall/accounting file may +now begin with a digit ([0-9]) and may contain embedded dashes ("-").
      4. +
    +

    10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper +bag awards Shorewall +1.4.7c released.

    +
      +
    1. The saga with "<zone>_frwd" chains continues. The +1.4.7c script +produces a ruleset that should work for everyone even if it is not +quite optimal. My apologies for this ongoing mess.
      2. +
    +

    10/24/2003 - Shorewall 1.4.7b (New)

    +

    This is a bugfx rollup of the 1.4.7a fixes plus:
    +

    +
      +
    1. The fix for problem 5 in 1.4.7a was wrong with the result +that +"<zone>_frwd" chains might contain too few rules. That wrong code +is corrected in this release.
      +
      2. +
    +

    10/21/2003 - Shorewall 1.4.7a

    +

    This is a bugfix rollup of the following problem corrections:
    +

    +
      +
    1. Tuomo Soini has supplied a correction to a problem that +occurs +using some versions of 'ash'. The symptom is that "shorewall start" +fails with:
      + 
      +   local: --limit: bad variable name
      +   iptables v1.2.8: Couldn't load match +`-j':/lib/iptables/libipt_-j.so:
      +   cannot open shared object file: No such file or directory
      +   Try `iptables -h' or 'iptables --help' for more +information.
      +
      +
      2. +
    2. Andres Zhoglo has supplied a correction that avoids trying +to use the multiport match iptables facility on ICMP rules.
      + 
      +   Example of rule that previously caused "shorewall start" +to fail:
      + 
      +           +ACCEPT      loc  $FW  +icmp    0,8,11,12
      +
      +
      3. +
    3. Previously, if the following error message was issued, +Shorewall was left in an inconsistent state.
      + 
      +   Error: Unable to determine the routes through +interface xxx
      +
      +
      4. +
    4. Handling of the LOGUNCLEAN option in shorewall.conf has +been corrected.
      5. +
    5. In Shorewall 1.4.2, an optimization was added. This +optimization +involved creating a chain named "<zone>_frwd" for most zones +defined using the /etc/shorewall/hosts file. It has since been +discovered that in many cases these new chains contain redundant rules +and that the "optimization" turns out to be less than optimal. The +implementation has now been corrected.
      6. +
    6. When the MARK value in a tcrules entry is followed by ":F" +or +":P", the ":F" or ":P" was previously only applied to the first +Netfilter rule generated by the entry. It is now applied to all entries.

    More News

    @@ -453,44 +297,22 @@ Bering 1.2!!!

    This site is hosted by the generous folks at SourceForge.net

    - + href="http://www.sf.net">SourceForge.net +
    +

    Donations

    		 -
    -


    - Note:     Search is unavailable Daily 0200-0330 GMT.
    - 

    -

    Quick Search
    - - -

    -
    -

    Extended Search

    -
    -
    + style="border-collapse: collapse; width: 100%; background-color: rgb(51, 102, 255);" + id="AutoNumber2"> -
    +

    @@ -503,7 +325,7 @@ Children's Foundation. Thanks!
    -

    Updated 10/06/2003 - Tom Eastep +

    Updated 11/17/2003 - Tom Eastep

    diff --git a/Shorewall-docs/standalone.htm b/Shorewall-docs/standalone.htm index 6a2ca5ec8..dbbc6cd5d 100644 --- a/Shorewall-docs/standalone.htm +++ b/Shorewall-docs/standalone.htm @@ -9,17 +9,8 @@ Standalone Firewall - - - - - - -
    -

    Standalone Firewall

    -
    +

    Standalone Firewall
    +

    Setting up Shorewall on a standalone Linux system is very easy if you understand the basics and follow the documentation.

    This guide doesn't attempt to acquaint you with all of the features @@ -113,7 +104,9 @@ first checked against the /etc/shorewall/rules file. If no rule in that file matches the connection request then the first policy in /etc/shorewall/policy that matches the request is applied. If that policy is REJECT or DROP  the request is first checked against the -rules in /etc/shorewall/common (the samples provide that file for you).

    +rules in /etc/shorewall/common if that file exists; otherwise the rules +in /etc/shorewall/common.def are checked.
    +

    The /etc/shorewall/policy file included with the one-interface sample has the following policies:

    @@ -365,9 +358,15 @@ to /etc/shorewall/routestopped. Also, I don't recommend using "shorewall restart"; it is better to create an alternate configuration and test it using the "shorewall try" command.

    + href="starting_and_stopping_shorewall.htm">"shorewall try" command.
    +

    +

    Additional Recommended Reading

    +I highly recommend that you review the Common Configuration File +Features page -- it contains helpful tips about Shorewall features +than make administering your firewall easier.
    -

    Last updated 2/08/2003 - Last updated 11/15/2003 - Tom Eastep

    Copyright 2002, 2003 Thomas M. Eastep

    diff --git a/Shorewall-docs/standalone_fr.html b/Shorewall-docs/standalone_fr.html index 4b21a122b..fa5380532 100755 --- a/Shorewall-docs/standalone_fr.html +++ b/Shorewall-docs/standalone_fr.html @@ -1,471 +1,426 @@ - - - - Standalone Firewall - - - - - - - - - -
    -

    Standalone Firewall

    -
    - -

    Version 2.0.1 Française

    - + +

    Standalone Firewall

    Notes du traducteur :
    - Je ne prétends pas être un vrai traducteur dans le sens ou mon travail -n'est pas des plus précis (loin de là...). Je ne me suis pas attaché à une -traduction exacte du texte, mais plutôt à en faire une version française intelligible -par tous (et par moi). Les termes techniques sont la plupart du temps conservés -sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver -dans le reste des documentations ainsi que dans les fichiers de configuration. +Je ne prétends pas être un vrai traducteur dans le sens ou mon travail +n'est pas des plus précis (loin de là...). Je ne me suis pas attaché à +une traduction exacte du texte, mais plutôt à en faire une version +française intelligible +par tous (et par moi). Les termes techniques sont la plupart du temps +conservés +sous leur forme originale et mis entre parenthèses car vous pouvez les +retrouver +dans le reste des documentations ainsi que dans les fichiers de +configuration. N?hésitez pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM -pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour + href="mailto:vetsel.patrice@wanadoo.fr">VETSEL Patrice (merci à +JMM +pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP +pour son formidable outil et sa disponibilité)    .

    - -

    Mettre en place un système Linux en tant que firewall (écluse) - pour un petit réseau est une chose assez simple, si vous comprenez les bases - et suivez la documentation.

    - -

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il -se focalise sur ce qui est nécessaire pour configurer Shorewall, dans son +

    Mettre en place un système Linux en tant que firewall +(écluse) pour un petit réseau est une chose assez simple, si vous +comprenez les bases et suivez la documentation.

    +

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. +Il +se focalise sur ce qui est nécessaire pour configurer Shorewall, dans +son utilisation la plus courante :

    -
      -
    • Un système Linux
      • -
    • Une seule adresse IP externe
      • -
    • Une connexion passant par un modem câble, ADSL, ISDN, Frame Relay, - rtc...
      • - +
    • Un système Linux
      • +
    • Une seule adresse IP externe
      • +
    • Une connexion passant par un modem câble, ADSL, ISDN, Frame +Relay, rtc...
    - -

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. -Vous pouvez voir si le paquet est installé en vérifiant la présence du programme - ip sur votre système de firewall. Sous root, utilisez la commande 'which' - pour rechercher le programme :

    - +

    Ce guide suppose que vous avez le paquet iproute/iproute2 +d'installé. +Vous pouvez voir si le paquet est installé en vérifiant la présence du +programme ip sur votre système de firewall. Sous root, utilisez la +commande 'which' pour rechercher le programme :

         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    Je vous recommande dans un premier temps de parcourir tout le guide pour - vous familiariser avec ce qu'il va se passer, et de revenir au début en -effectuant le changements dans votre configuration. Les points, où les changements -dans la configuration sont recommandées, sont signalés par une - .

    - -

    - Si vous éditez vos fichiers de configuration sur un système Windows, vous - devez les sauver comme des fichiers Unix si votre éditeur supporte cette -option sinon vous devez les faire passer par dos2unix avant d'essayer de les -utiliser. De la même manière, si vous copiez un fichier de configuration depuis -votre disque dur Windows vers une disquette, vous devez lancer dos2unix sur +

    Je vous recommande dans un premier temps de parcourir tout le guide +pour vous familiariser avec ce qu'il va se passer, et de revenir au +début en +effectuant le changements dans votre configuration. Les points, où les +changements +dans la configuration sont recommandées, sont signalés par une .

    +

    Si +vous éditez vos fichiers de configuration sur un système Windows, vous +devez les sauver comme des fichiers Unix si votre éditeur supporte +cette option sinon vous devez les faire passer par dos2unix avant +d'essayer de les +utiliser. De la même manière, si vous copiez un fichier de +configuration depuis +votre disque dur Windows vers une disquette, vous devez lancer dos2unix +sur la copie avant de l'utiliser avec Shorewall.

    - -

    Les Concepts de Shorewall

    -

    - Les fichiers de configuration pour Shorewall sont situés dans le répertoire - /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec - quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez le one-interface sample, -un-tarez le (tar -zxvf one-interface.tgz) et copiez les fichiers vers /etc/shorewall - (Ils remplaceront les fichiers de même nom déjà existant dans /etc/shorewall -installés lors de l'installation de Shorewall).

    - -

    Parallèlement à la description, je vous suggère de jeter un oeil à ceux - physiquement présents sur votre système -- chacun des fichiers contient -des instructions de configuration détaillées et des entrées par défaut.

    - -

    Shorewall voit le réseau où il tourne comme composé par un ensemble de - zones. Dans les fichiers de configuration fournis pour une unique + alt=""> Les fichiers de configuration pour Shorewall sont situés dans +le répertoire /etc/shorewall -- pour de simples paramétrages, vous +n'avez à faire qu'avec quelques un d'entre eux comme décris dans ce +guide. Après avoir installé Shorewall, téléchargez +le one-interface +sample, un-tarez le (tar -zxvf one-interface.tgz) et copiez les +fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même nom +déjà existant dans /etc/shorewall installés lors de l'installation de +Shorewall).

    +

    Parallèlement à la description, je vous suggère de jeter un oeil à +ceux physiquement présents sur votre système -- chacun des fichiers +contient +des instructions de configuration détaillées et des entrées par défaut.

    +

    Shorewall voit le réseau où il tourne comme composé par un ensemble +de zones. Dans les fichiers de configuration fournis pour une +unique interface, une seule zone est définie :

    - - - - - - - - - - - - + + + + + + + + + +
    NameDescription
    netThe Internet
    NameDescription
    netThe Internet
    -

    Les zones de Shorewall sont définies dans /etc/shorewall/zones.

    - -

    Shorewall reconnaît aussi le système de firewall comme sa propre zone -- par défaut, le firewall lui-même est connu en tant que fw.

    - -

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées - en utilisant les termes de zones.

    - +

    Shorewall reconnaît aussi le système de firewall comme sa propre +zone +- par défaut, le firewall lui-même est connu en tant que fw.

    +

    Les règles concernant le trafic à autoriser ou à interdire sont +exprimées en utilisant les termes de zones.

      -
    • Vous exprimez les politiques par défaut pour les connexions d'une -zone à une autre dans le fichier /etc/shorewall/policy - .
      • -
    • Vous définissez les exceptions à ces règles de politiques par défaut - dans le fichier /etc/shorewall/rules.
      • - +
    • Vous exprimez les politiques par défaut pour les connexions d'une +zone à une autre dans le fichier +/etc/shorewall/policy .
      • +
    • Vous définissez les exceptions à ces règles de politiques par +défaut dans le fichier /etc/shorewall/rules.
    - -

    Pour chacune des demandes de connexion entrantes dans le firewall, les - demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. - Si aucune des règles dans ce fichier ne correspondent, alors la première -politique dans /etc/shorewall/policy qui y correspond est appliquée. Si cette -politique est REJECT ou DROP la requête est alors comparée par rapport aux -règles contenues dans /etc/shorewall/common (l'archive d'exemple vous fournit +

    Pour chacune des demandes de connexion entrantes dans le firewall, +les demandes sont en premier lieu comparées par rapport au fichier +/etc/shorewall/rules. Si aucune des règles dans ce fichier ne +correspondent, alors la première +politique dans /etc/shorewall/policy qui y correspond est appliquée. Si +cette +politique est REJECT ou DROP la requête est alors comparée par rapport +aux +règles contenues dans /etc/shorewall/common (l'archive d'exemple vous +fournit ce fichier).

    - -

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive one-interface - a les politiques suivantes :

    - -
    +

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive +one-interface a les politiques suivantes :

    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    fwnetACCEPT
    -
    -
    netall
    -     		DROPinfo
    -
    allallREJECTinfo
    -
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    fwnetACCEPT
    +
    +
    netall
    +     		DROPinfo
    +
    allallREJECTinfo
    +
    -
    - +
    - Ces politiques vont : +Ces politiques vont :
      -
    1. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      2. -
    2. drop (ignorer) toutes les demandes de connexion depuis l'Internet -vers votre firewall
      3. -
    3. rejeter toutes les autres requêtes de connexion (Shorewall à besoin - de cette politique).
      4. - +
    4. permettre toutes demandes de connexion depuis le firewall vers +l'Internet
      5. +
    5. drop (ignorer) toutes les demandes de connexion depuis l'Internet +vers votre firewall
      6. +
    6. rejeter toutes les autres requêtes de connexion (Shorewall à +besoin de cette politique).
    - -

    A ce point, éditez votre /etc/shorewall/policy et faites y les changements - que vous désirez.

    - +

    A ce point, éditez votre /etc/shorewall/policy et faites y les +changements que vous désirez.

    Interface Externe

    - -

    Le firewall possède une seule interface réseau. Lorsque la - connexion Internet passe par un modem câble ou par un routeur ADSL (pas -un simple modem), l'External Interface (interface externe) sera l'adaptateur - ethernet (eth0) qui y est connecté à moins que vous vous connectiez - par Point-to-Point Protocol over Ethernet - (PPPoE) ou Point-to-Point TunnelingProtocol(PPTP) - dans ce cas l'interface externe sera ppp0. Si vous vous connectez - par un simple modem (RTC), votre interface externe sera aussi ppp0. - Si vous vous connectez en utilisant l'ISDN (numéris), votre interface externe - sera ippp0.

    - +

    Le firewall possède une seule interface réseau. Lorsque +la connexion Internet passe par un modem câble ou par un routeur ADSL +(pas +un simple modem), l'External Interface (interface externe) sera +l'adaptateur ethernet (eth0) qui y est connecté à moins que +vous vous connectiez par Point-to-Point Protocol +over Ethernet (PPPoE) ou Point-to-Point TunnelingProtocol(PPTP) +dans ce cas l'interface externe sera ppp0. Si vous vous +connectez par un simple modem (RTC), votre interface externe sera aussi +ppp0. Si vous vous connectez en utilisant l'ISDN (numéris), +votre interface externe sera ippp0.

    - L'exemple de configuration de Shorewall pour une interface suppose que -votre interface externe est eth0. Si votre configuration est différente, - vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. - Puisque vous y êtes, vous pourriez parcourir la liste d'options qui sont - spécifiées pour l'interface. Quelques astuces :

    - + height="13"> L'exemple de configuration de Shorewall pour une +interface suppose que votre interface externe est eth0. Si +votre configuration est différente, vous devrez modifier le fichier +d'exemple /etc/shorewall/interfaces en conséquence. Puisque vous y +êtes, vous pourriez parcourir la liste d'options qui sont spécifiées +pour l'interface. Quelques astuces :

      -
    • -

      Si votre interface externe est ppp0 ou ippp0, - vous pouvez remplacer le "detect" dans la seconde colonne par un "-". -

      -
      • -
    • -

      Si votre interface externe est ppp0 ou ippp0 - ou bien si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" - de la liste d'option.

      -
      • - +
    • +

      Si votre interface externe est ppp0 ou ippp0, +vous pouvez remplacer le "detect" dans la seconde colonne par un "-".

      +
      • +
    • +

      Si votre interface externe est ppp0 ou ippp0 +ou bien si vous avez une adresse IP statique, vous pouvez enlever le +"dhcp" de la liste d'option.

      +
    - -
    +

    Adresse IP

    -
    - -
    -

    La RFC 1918 définie plusieurs plage d'adresses IP privée +

    +
    +

    La RFC 1918 définie plusieurs plage d'adresses IP +privée (PrivateIP) pour l'utilisation dans des réseaux privés :

    - -
    +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -

    Ces adresses sont parfois désignées comme étant non-routables - car les routeurs sur les backbones Internet ne font pas passer les paquets - dont les adresses de destinations sont définies dans la RFC 1918. Dans certains - cas, les fournisseurs (provider ou ISP) utilisent ces adresses et utilisent - le Network Address Translation afin de récrire les entêtes des paquets - lorsqu'ils les font circuler depuis ou vers l'Internet.

    - +
    +

    Ces adresses sont parfois désignées comme étant non-routables +car les routeurs sur les backbones Internet ne font pas passer les +paquets dont les adresses de destinations sont définies dans la RFC +1918. Dans certains cas, les fournisseurs (provider ou ISP) utilisent +ces adresses et utilisent le Network Address Translation afin +de récrire les entêtes des paquets lorsqu'ils les font circuler depuis +ou vers l'Internet.

    - Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface - externe et si elle est comprise dans une des plages précédentes, vous devriez - enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    -
    - -
    + width="13" height="13"> Avant de lancer Shorewall, vous devriez +regarder l'adresse de votre interface externe et si elle est comprise +dans une des plages précédentes, vous devriez enlever l'option +'norfc1918' dans le fichier /etc/shorewall/interfaces.

    +
    +

    Permettre d'autres connexions

    -
    - -
    -

    Si vous désirez autoriser d'autres connexions depuis l'Internet - vers votre firewall, le format général est :

    -
    - -
    -
    +
    +
    +

    Si vous désirez autoriser d'autres connexions depuis +l'Internet vers votre firewall, le format général est :

    +
    +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>
    +
    +
    -
    -
    - -
    -

    Exemple - Vous voulez faire tourner un serveur Web et un + +

    +
    +

    Exemple - Vous voulez faire tourner un serveur Web et +un serveur POP3 sur votre système de firewall :

    -
    - -
    -
    +
    +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80
    -
    -
    ACCEPTnetfwtcp110
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80
    +
    +
    ACCEPTnetfwtcp110
    +
    +
    -
    -
    - -
    -

    Si vous ne savez pas quel port ou protocole une application - particulière utilise, regardez ici.

    -
    - -
    -

    Important: Je ne vous recommande pas d'autoriser le - telnet depuis ou vers l'Internet car il utilise du texte en clair (même -pour le login et le mot de passe !). Si vous voulez avoir un accès au shell -de votre firewall depuis Internet, utilisez SSH :

    -
    - -
    -
    +
    +
    +
    +

    Si vous ne savez pas quel port ou protocole une +application particulière utilise, regardez ici.

    +
    +
    +

    Important: Je ne vous recommande pas +d'autoriser le telnet depuis ou vers l'Internet car il utilise du texte +en clair (même +pour le login et le mot de passe !). Si vous voulez avoir un accès au +shell +de votre firewall depuis Internet, utilisez SSH :

    +
    +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    +
    +
    -
    -
    - -
    + +
    +
         ACCEPT	net	fw	tcp	22
    -
    - -
    +
    +

    - A ce point, éditez /etc/shorewall/rules pour rajouter les autres connexions - désirées.

    -
    - -
    + height="13"> A ce point, éditez /etc/shorewall/rules pour rajouter les +autres connexions désirées.

    +
    +

    Lancer et Arrêter son Firewall

    -
    - -
    +
    +

    Arrow - La procédure d'installation configure votre -système pour lancer Shorewall au boot du système, mais au début avec la version -1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall - avec que la configuration soit finie. Une fois que vous en aurez fini avec - la configuration du firewall, vous pouvez permettre le lancement de Shorewall - en supprimant le fichier /etc/shorewall/startup_disabled.
    -

    - -

    IMPORTANT: Les utilisateurs -des paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.
    -

    -
    - -
    -

    Le firewall est activé en utilisant la commande "shorewall - start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, -le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un - firewall qui tourne peut être relancé en utilisant la commande "shorewall - restart". Si vous voulez enlever toutes traces de Shorewall sur votre -configuration de Netfilter, utilisez "shorewall clear".

    -
    - -
    -

    ATTENTION: Si vous êtes connecté à votre firewall -depuis Internet, n'essayez pas une commande "shorewall stop" tant que vous -n'avez pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle -vous êtes connectée) dans /etc/shorewall/routestopped. - De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; - il est plus intéressant de créer une configuration alternative - et de la tester en utilisant la commande "shorewall try".

    -
    - + height="13" alt="Arrow"> La procédure +d'installation configure votre système pour lancer Shorewall au +boot du système, mais au début avec la version 1.3.9 de Shorewall le +lancement est désactivé, n'essayer pas de lancer Shorewall avec que la +configuration soit finie. Une fois que vous en aurez fini avec la +configuration du firewall, vous pouvez permettre le lancement de +Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
    +

    +

    IMPORTANT: Les +utilisateurs +des paquets .deb doivent éditer /etc/default/shorewall et mettre +'startup=1'.
    +

    +
    +
    +

    Le firewall est activé en utilisant la commande +"shorewall start" et arrêté avec "shorewall stop". Lorsque le firewall +est stoppé, +le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. +Un firewall qui tourne peut être relancé en utilisant la commande +"shorewall restart". Si vous voulez enlever toutes traces de Shorewall +sur votre +configuration de Netfilter, utilisez "shorewall clear".

    +
    +
    +

    ATTENTION: Si vous êtes connecté à votre +firewall +depuis Internet, n'essayez pas une commande "shorewall stop" tant que +vous +n'avez pas ajouté une entrée pour votre adresse IP (celle à partir de +laquelle +vous êtes connectée) dans /etc/shorewall/routestopped. +De la même manière, je ne vous recommande pas d'utiliser "shorewall +restart"; il est plus intéressant de créer une configuration alternative +et de la tester en utilisant la commande "shorewall try".

    +

    Last updated 12/9/2002 - Tom Eastep

    - -

    Copyright 2002 Thomas - M. Eastep

    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    +

    Copyright 2002 +Thomas M. Eastep

    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    diff --git a/Shorewall-docs/starting_and_stopping_shorewall.htm b/Shorewall-docs/starting_and_stopping_shorewall.htm index 061924369..cef5ea24c 100644 --- a/Shorewall-docs/starting_and_stopping_shorewall.htm +++ b/Shorewall-docs/starting_and_stopping_shorewall.htm @@ -9,19 +9,12 @@ Starting and Stopping Shorewall - - - - - - -
    -

    Starting/Stopping and -Monitoring the Firewall

    -
    -

    If you have a permanent internet connection such as DSL or Cable, I +

    +

    Starting/Stopping and Monitoring the Firewall
    +

    +
    +


    +If you have a permanent internet connection such as DSL or Cable, I recommend that you start the firewall automatically at boot. Once you have installed "firewall" in your init.d directory, simply type "chkconfig --add firewall". This will start the firewall in run levels @@ -44,7 +37,7 @@ restart" in that script.

    You can manually start and stop Shoreline Firewall using the "shorewall" shell program. Please refer to the Shorewall + href="starting_and_stopping_shorewall.htm#StateDiagram">Shorewall State Diagram is shown at the bottom of this page.

    • shorewall start - starts the firewall
      • diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm index 78b4b75d7..76dd2c49c 100644 --- a/Shorewall-docs/support.htm +++ b/Shorewall-docs/support.htm @@ -7,19 +7,11 @@ Shorewall Support Guide - - - - - - -
      -

      Shorewall Support Guide -

      -
      +

      Shorewall +Support Guide

      Before Reporting a Problem or Asking a Question

      There are a number of sources of Shorewall information. Please try @@ -29,15 +21,15 @@ these before you post.
    • More than half of the questions posted on the support list have answers directly accessible from the Documentation + href="shorewall_quickstart_guide.htm#Documentation">Documentation Index
      • -
    • The FAQ has +
    • The FAQ has solutions to more than 20 common problems.
      • -
    • The Troubleshooting +
    • The Troubleshooting Information contains a number of tips to help you solve common problems.
      • -
    • The Errata +
    • The Errata has links to download updated components.
    • The Site and Mailing List Archives search facility can locate documents and posts about similar problems:
      • @@ -98,6 +90,13 @@ error messages, log entries, command output, and other output is better than a paraphrase or summary.

      +
    • Please don't describe your problem as "Computer A can't see +Computer B". Of course it can't -- it hasn't any eyes! If ping from A +to B fails, say so (and see below for information about reporting +'ping' problems). If Computer B doesn't show up in "Network +Neighborhood" then say so.
      +
      +
    • Please don't describe your environment and then ask us to send you custom configuration files. We're here to answer your questions but we can't do your job for you.
      @@ -143,7 +142,11 @@ problem is that some type of connection to/from or through your firewall isn't working then please perform the following four steps:

      -1. /sbin/shorewall reset
      +1. If +shorewall isn't running then /sbin/shorewall/start. Otherwise +/sbin/shorewall reset.

      2. Try making the connection that is failing.

      @@ -189,7 +192,7 @@ unless one also knows the policies).
    • If an error occurs when you try to "shorewall start", include a trace (See the Troubleshooting + href="troubleshoot.htm">Troubleshooting section for instructions).

      • @@ -232,7 +235,10 @@ you can post non MNF-specific Shorewall questions to the       . Do not expect to get free MNF support on the list

      Otherwise, please post your question or problem to the Shorewall users -mailing list.

      +mailing list. IMPORTANT: If +you are not subscribed to the list, please say so -- otherwise, you +will not be included in any replies.
      +

      Subscribing to the Users Mailing List

      @@ -245,7 +251,7 @@ mailing list.

      For information on other Shorewall mailing lists, go to http://lists.shorewall.net

      -

      Last Updated 9/17/2003 - Tom Eastep

      +

      Last Updated 11/12/2003 - Tom Eastep

      Copyright © 2001, 2002, 2003 Thomas M. Eastep.
      diff --git a/Shorewall-docs/three-interface.htm b/Shorewall-docs/three-interface.htm index c8cd300d3..50b01becf 100644 --- a/Shorewall-docs/three-interface.htm +++ b/Shorewall-docs/three-interface.htm @@ -9,17 +9,8 @@ Three-Interface Firewall - - - - - - -
      -

      Three-Interface Firewall

      -
      +

      Three-Interface Firewall
      +

      Setting up a Linux system as a firewall for a small network with DMZ is a fairly straight-forward task if you understand the basics and follow the documentation.

      @@ -28,7 +19,11 @@ of Shorewall. It rather focuses on what is required to configure Shorewall in one of its more popular configurations:

      • Linux system used as a firewall/router for a small local network.
        • -
      • Single public IP address.
        • +
      • Single public IP address. If you have +more than one public IP address, this is not the guide you want -- see +the Shorewall Setup Guide +instead.
        +
      • DMZ connected to a separate ethernet interface.
      • Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, ...
        • @@ -128,7 +123,9 @@ file matches the connection request then the first policy in /etc/shorewall/policy that matches the request is applied. If that policy is REJECT or DROP  the request is first checked against the rules in -/etc/shorewall/common (the samples provide that file for you).

        +/etc/shorewall/common if that file exists; otherwise the file +/etc/shorewall/common.def is checked
        +

        The /etc/shorewall/policy file included with the three-interface sample has the following policies:

        @@ -1064,9 +1061,15 @@ from to /etc/shorewall/routestopped Also, I don't recommend using "shorewall restart"; it is better to create an alternate configuration and test it using the "shorewall try" command.

        + href="starting_and_stopping_shorewall.htm">"shorewall try" command.
        +

        +

        Additional Recommended Reading

        +I highly recommend that you review the Common Configuration File +Features page -- it contains helpful tips about Shorewall features +than make administering your firewall easier. -

        Last updated 8/8/2003 - Last updated 11/15/2003 - Tom Eastep

        Copyright 2002, 2003 Thomas M. Eastep
        diff --git a/Shorewall-docs/three-interface_fr.html b/Shorewall-docs/three-interface_fr.html index 4a0d35712..4165e7db7 100755 --- a/Shorewall-docs/three-interface_fr.html +++ b/Shorewall-docs/three-interface_fr.html @@ -1,1197 +1,1125 @@ - - - - Three-Interface Firewall - - - - - - - - - -
        -

        Three-Interface Firewall

        -
        - -

        Version 2.0.1 Française

        - + +

         Three-Interface Firewall

        Notes du traducteur :
        - Je ne prétends pas être un vrai traducteur dans le sens ou mon travail - n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à une - traduction exacte du texte, mais plutôt à en faire une version française -intelligible par tous (et par moi). Les termes techniques sont la plupart -du temps conservés sous leur forme originale et mis entre parenthèses car -vous pouvez les retrouver dans le reste des documentations ainsi que dans -les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer -ce document VETSEL Patrice -(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à -Tom EASTEP pour son formidable outil et sa disponibilité).

        - +Je ne prétends pas être un vrai traducteur dans le sens ou mon travail +n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à +une traduction exacte du texte, mais plutôt à en faire une version +française intelligible par tous (et par moi). Les termes techniques +sont la plupart du temps conservés sous leur forme originale et mis +entre parenthèses car vous pouvez les retrouver dans le reste des +documentations ainsi que dans les fichiers de configuration. N?hésitez +pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à +JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom +EASTEP pour son formidable outil et sa disponibilité).


        - Mettre en place un système linux en tant que firewall pour un petit -réseau contenant une DMZ est une chose assez simple à réaliser si vous -comprenez les bases et suivez cette documentation.

        - -

        Ce guide ne prétend pas vous mettre au courant de toutes les possibilités - de Shorewall. Il se focalise sur les besoins pour configurer Shorewall -dans une de ses utilisations les plus populaire :

        - +Mettre en place un système linux en tant que firewall pour un petit +réseau contenant une DMZ est une chose assez simple à réaliser si vous +comprenez les bases et suivez cette documentation.

        +

        Ce guide ne prétend pas vous mettre au courant de toutes les +possibilités de Shorewall. Il se focalise sur les besoins pour +configurer Shorewall +dans une de ses utilisations les plus populaire :

          -
        • Un système Linux utilisé en tant que firewall/routeur pour un -petit réseau local.
          • -
        • Une seule adresse IP publique.
          • -
        • Une DMZ connectée sur une interface Ethernet séparée.
          • -
        • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame -Relay, RTC, ...
          • - +
        • Un système Linux utilisé en tant que firewall/routeur pour un +petit réseau local.
          • +
        • Une seule adresse IP publique.
          • +
        • Une DMZ connectée sur une interface Ethernet séparée.
          • +
        • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame +Relay, RTC, ...
        -

        Voici le schéma d'une installation typique.

        -

        -

        - -

        Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. -Vous pouvez voir si le paquet est installé en vérifiant la présence du programme - ip sur votre système de firewall. Sous root, utilisez la commande 'which' - pour rechercher le programme :

        - + height="635">

        +

        Ce guide suppose que vous avez le paquet iproute/iproute2 +d'installé. +Vous pouvez voir si le paquet est installé en vérifiant la présence du +programme ip sur votre système de firewall. Sous root, utilisez la +commande 'which' pour rechercher le programme :

             [root@gateway root]# which ip
             /sbin/ip
             [root@gateway root]#
        - -

        Je vous recommande dans un premier temps de parcourir tout le guide pour - vous familiariser avec ce qu'il va se passer, et de revenir au début en -effectuant le changements dans votre configuration. Les points où, les changements -dans la configuration sont recommandées, sont signalés par une -

        - -

        - Si vous éditez vos fichiers de configuration sur un système Windows, -vous devez les sauver comme des fichiers Unix si votre éditeur offre cette -option sinon vous devez les faire passer par dos2unix avant d'essayer de -les utiliser. De la même manière, si vous copiez un fichier de configuration -depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix -sur la copie avant de l'utiliser avec Shorewall.

        - +

        Je vous recommande dans un premier temps de parcourir tout le guide +pour vous familiariser avec ce qu'il va se passer, et de revenir au +début en +effectuant le changements dans votre configuration. Les points où, les +changements +dans la configuration sont recommandées, sont signalés par une

        +

        Si +vous éditez vos fichiers de configuration sur un système Windows, vous +devez les sauver comme des fichiers Unix si votre éditeur offre cette +option sinon vous devez les faire passer par dos2unix avant d'essayer +de les utiliser. De la même manière, si vous copiez un fichier de +configuration depuis votre disque dur Windows vers une disquette, vous +devez lancer dos2unix sur la copie avant de l'utiliser avec Shorewall.

        -

        Les Concepts de Shorewall

        -

        - Les fichiers de configuration pour Shorewall sont situés dans le répertoire - /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec - quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez la configuration - d'exemple three-interface - sample, un-tarez la (tar -zxvf three-interfaces.tgz) et copiez - les fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même - nom déjà existant dans /etc/shorewall installés lors de l'installation de - Shorewall).

        - -

        En même temps que chacun des fichiers est présenté, je vous suggère de - jeter un oeil à ceux qui se trouvent réellement sur votre système -- chacun - des fichiers contient des instructions de configuration détaillées et des - entrées par défaut.

        - -

        Shorewall voit le réseau où il tourne comme composé par un ensemble de - zones. Dans les fichiers de configuration fournis pour trois interfaces, - trois zones sont définies :

        - + alt=""> Les fichiers de configuration pour Shorewall sont situés dans +le répertoire /etc/shorewall -- pour de simples paramétrages, vous +n'avez à faire qu'avec quelques un d'entre eux comme décris dans ce +guide. Après avoir installé Shorewall, téléchargez +la configuration d'exemple three-interface +sample, un-tarez la (tar -zxvf three-interfaces.tgz) et +copiez les fichiers vers /etc/shorewall (Ils remplaceront les fichiers +de même nom déjà existant dans /etc/shorewall installés lors de +l'installation de Shorewall).

        +

        En même temps que chacun des fichiers est présenté, je vous suggère +de jeter un oeil à ceux qui se trouvent réellement sur votre système -- +chacun des fichiers contient des instructions de configuration +détaillées et des entrées par défaut.

        +

        Shorewall voit le réseau où il tourne comme composé par un ensemble +de zones. Dans les fichiers de configuration fournis pour trois +interfaces, trois zones sont définies :

        - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + +
        NameDescription
        netThe Internet
        locVotre réseau local
        dmzZone Demilitarisée
        NameDescription
        netThe Internet
        locVotre réseau local
        dmzZone Demilitarisée
        -

        Les noms de zone sont définis dans /etc/shorewall/zones.

        - -

        Shorewall reconnaît aussi le système de firewall comme sa propre zone -- par défaut, le firewall lui même est connu en tant que fw.

        - -

        Les règles concernant le trafic à autoriser ou à interdire sont exprimées - en utilisant les termes de zones.

        - +

        Shorewall reconnaît aussi le système de firewall comme sa propre +zone +- par défaut, le firewall lui même est connu en tant que fw.

        +

        Les règles concernant le trafic à autoriser ou à interdire sont +exprimées en utilisant les termes de zones.

          -
        • Vous exprimez les politiques par défaut pour les connexions d'une - zone à une autre dans le fichier /etc/shorewall/policy - .
          • -
        • Vous définissez les exceptions à ces règles de politiques par -défaut dans le fichier /etc/shorewall/rules.
          • - +
        • Vous exprimez les politiques par défaut pour les connexions d'une +zone à une autre dans le fichier +/etc/shorewall/policy .
          • +
        • Vous définissez les exceptions à ces règles de politiques par +défaut dans le fichier /etc/shorewall/rules.
        - -

        Pour chacune des demandes de connexion entrantes dans le firewall, les - demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. - Si aucune des règles dans ce fichier ne correspondent, alors la première - politique dans /etc/shorewall/policy qui y correspond est appliquée. Si -cette politique est REJECT ou DROP la requête est alors comparée par rapport -aux règles contenues dans /etc/shorewall/common (l'archive d'exemple vous -fournit ce fichier).

        - -

        Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive three-interface - sample a les politiques suivantes :

        - -
        +

        Pour chacune des demandes de connexion entrantes dans le firewall, +les demandes sont en premier lieu comparées par rapport au fichier +/etc/shorewall/rules. Si aucune des règles dans ce fichier ne +correspondent, alors la première politique dans /etc/shorewall/policy +qui y correspond est appliquée. Si +cette politique est REJECT ou DROP la requête est alors comparée par +rapport +aux règles contenues dans /etc/shorewall/common (l'archive d'exemple +vous +fournit ce fichier).

        +

        Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive +three-interface sample a les politiques suivantes :

        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        locnetACCEPT
        -
        -
        netallDROPinfo
        -
        allallREJECTinfo
        -
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        locnetACCEPT
        +
        +
        netallDROPinfo
        +
        allallREJECTinfo
        +
        -
        - -
        -

        Dans l'archive three-interface, la ligne suivante est existante mais - elle est commentée. Si vous souhaitez que votre système de firewall puisse - avoir un accès complet aux serveurs sur Internet, décommentez la.

        - +
        +
        +

        Dans l'archive three-interface, la ligne suivante est existante +mais elle est commentée. Si vous souhaitez que votre système de +firewall puisse avoir un accès complet aux serveurs sur Internet, +décommentez la.

        - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + +
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        fwnetACCEPT
        -
        -
        Source ZoneDestination ZonePolicyLog LevelLimit:Burst
        fwnetACCEPT
        +
        +
        -
        - +

        Les politiques précédentes vont :

        -
          -
        1. permettre toutes demandes de connexion depuis le firewall vers +
        2. permettre toutes demandes de connexion depuis le firewall vers l'Internet
          3. -
        3. drop (ignorer) toutes les demandes de connexion depuis l'Internet - vers votre firewall ou vers votre réseau local
          4. -
        4. Facultativement accepter toutes les demandes de connexion depuis - votre firewall et vers Internet (si vous decommentez la politique précédente)
          5. -
        5. reject (rejeter) toutes les autres demandes de connexion.
          6. - +
        6. drop (ignorer) toutes les demandes de connexion depuis l'Internet +vers votre firewall ou vers votre réseau local
          7. +
        7. Facultativement accepter toutes les demandes de connexion depuis +votre firewall et vers Internet (si vous decommentez la politique +précédente)
          8. +
        8. reject (rejeter) toutes les autres demandes de connexion.
        - -

        - A ce point, éditez votre /etc/shorewall/policy et faites y les changements - que vous désire

        - +

        A +ce point, éditez votre /etc/shorewall/policy et faites y les +changements que vous désire

        Les Interfaces Réseau

        -

        -

        - -

        Le firewall a trois interfaces de réseau. Lorsque la connexion - Internet passe par le câble ou par un ROUTEUR (pas un simple modem) ADSL - (non USB), l'interface vers l'extérieur (External Interface) sera l'adaptateur - sur lequel est connecté le routeur (e.g., eth0) à moins que vous ne vous - connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling - Protocol (PPTP), dans ce cas l'interface extérieure sera une interface -de type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), - votre interface extérieure sera aussi ppp0. Si votre connexion passe par + height="635">

        +

        Le firewall a trois interfaces de réseau. Lorsque la +connexion Internet passe par le câble ou par un ROUTEUR (pas un simple +modem) ADSL (non USB), l'interface vers l'extérieur (External +Interface) sera l'adaptateur sur lequel est connecté le routeur (e.g., +eth0) à moins que vous ne vous connectiez par Point-to-PointProtocol +overEthernet (PPPoE) ou par Point-to-PointTunneling Protocol (PPTP), +dans ce cas l'interface extérieure sera une interface +de type ppp (e.g., ppp0). Si vous vous connectez par un simple modem +(RTC), votre interface extérieure sera aussi ppp0. Si votre connexion +passe par Numéris (ISDN), votre interface extérieure sera ippp0.

        -

        - Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez - CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

        - -

        Votre Interface locale sera un adaptateur Ethernet - (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos -ordinateurs locaux seront connectés à ce même switch (note : si vous n'avez -qu'un seul ordinateur en local, vous pouvez le connecter directement au -firewall par un câble croisé).

        - -

        Votre interface DMZ sera aussi un adaptateur Ethernet - (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs - appartenant à la DMZ seront connectés à ce même switch (note : si vous -n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement -au firewall par un câble croisé).

        - + height="13"> Si votre interface vers l'extérieur est ppp0 ou ippp0 +alors vous mettrez CLAMPMSS=yes dans +/etc/shorewall/shorewall.conf.

        +

        Votre Interface locale sera un adaptateur +Ethernet (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. +Vos +ordinateurs locaux seront connectés à ce même switch (note : si vous +n'avez +qu'un seul ordinateur en local, vous pouvez le connecter directement au +firewall par un câble croisé).

        +

        Votre interface DMZ sera aussi un adaptateur +Ethernet (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. +Vos ordinateurs appartenant à la DMZ seront connectés à ce même switch +(note : si vous +n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter +directement +au firewall par un câble croisé).

        - Ne connectez pas l'interface interne et externe sur le même -hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez -pas que ce soit shorewall qui ne marche pas.

        - + width="60" height="60"> Ne connectez pas l'interface interne +et externe sur le même +hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez +pas que ce soit shorewall qui ne marche pas.

        - L'exemple de configuration de Shorewall pour trois interfaces suppose - que l'interface externe est eth0, l'interface locale est eth1 - et que la DMZ est sur l'interface eth2. Si votre configuration -diffère, vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces -en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste des -options qui sont spécifiées pour les interfaces. Quelques trucs :

        - + height="13"> L'exemple de configuration de Shorewall pour trois +interfaces suppose que l'interface externe est eth0, l'interface +locale est eth1 + et que la DMZ est sur l'interface eth2. Si votre +configuration +diffère, vous devrez modifier le fichier d'exemple +/etc/shorewall/interfaces +en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste +des +options qui sont spécifiées pour les interfaces. Quelques trucs :

          -
        • -

          Si votre interface externe est ppp0 ou ippp0, vous pouvez - remplacer le "detect" dans la seconde colonne par un "-".

          -
          • -
        • -

          Si votre interface externe est ppp0 ou ippp0 ou bien -si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la +

        • +

          Si votre interface externe est ppp0 ou ippp0, vous +pouvez remplacer le "detect" dans la seconde colonne par un "-".

          +
          • +
        • +

          Si votre interface externe est ppp0 ou ippp0 ou +bien +si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de +la liste d'option.

          -
          • - +
        -

        Adresses IP

        - -

        Avant d'aller plus loin, nous devons dire quelques mots au - sujet du Protocole d'adresse Internet (IP). Normalement, votre fournisseur - Internet (ISP) vous assignera une seule adresse IP (single Public IP address). - Cette adresse peut être assignée par le Dynamic Host Configuration Protocol - (DHCP) ou lors de l'établissement de votre connexion lorsque vous vous -connectez (modem standard) ou établissez votre connexion PPP. Dans de rares -cas , votre provider peu vous assigner une adresse statique (staticIP address); -cela signifie que vous configurez votre interface externe sur votre firewall -afin d'utiliser cette adresse de manière permanente. Une fois votre adresse -externe assignée, elle va être partagée par tout vos systèmes lors de l'accès -à Internet. Vous devrez assigner vos propres adresses à votre réseau local -(votre interface interne sur le firewall ainsi que les autres ordinateurs). -La RFC 1918 réserve plusieurs plages d'IP (Private IP address ranges) à +

        Avant d'aller plus loin, nous devons dire quelques mots +au sujet du Protocole d'adresse Internet (IP). Normalement, votre +fournisseur Internet (ISP) vous assignera une seule adresse IP (single +Public IP address). Cette adresse peut être assignée par le Dynamic +Host Configuration Protocol (DHCP) ou lors de l'établissement de votre +connexion lorsque vous vous +connectez (modem standard) ou établissez votre connexion PPP. Dans de +rares +cas , votre provider peu vous assigner une adresse statique (staticIP +address); +cela signifie que vous configurez votre interface externe sur votre +firewall +afin d'utiliser cette adresse de manière permanente. Une fois votre +adresse +externe assignée, elle va être partagée par tout vos systèmes lors de +l'accès +à Internet. Vous devrez assigner vos propres adresses à votre réseau +local +(votre interface interne sur le firewall ainsi que les autres +ordinateurs). +La RFC 1918 réserve plusieurs plages d'IP (Private IP address ranges) à cette fin :

        - -
        +
             10.0.0.0    - 10.255.255.255
             172.16.0.0  - 172.31.255.255
             192.168.0.0 - 192.168.255.255
        -
        - -
        +
        +

        - Avant de lancer Shorewall, vous devriez regarder l'adresse de votre -interface externe et si elle est comprise dans une des plages précédentes, -vous devriez enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

        -
        - -
        -

        Vous devrez assigner les adresses locales à un sous-réseau - (sub-network ou subnet) et les adresse pour la DMZ à un autre - sous-réseau. Pour ce faire, nous pouvons considérer qu'un sous-réseau consiste - en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera - une masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0 -est réservée comme l'adresse du sous-réseau (Subnet Address) -et x.y.z.255 est réservée en tant qu'adresse de broadcast du sous-réseau -(Subnet Broadcast Address). Sous Shorewall, un sous-réseau -est décrit/désigné en utilisant la notation Classless InterDomain Routing(CIDR) -qui consiste en l'adresse du sous-réseau suivie par "/24". Le "24" se réfère -au nombre de bits "1" consécutifs dans la partie gauche du masque de sous-réseau. + height="13"> Avant de lancer Shorewall, vous devriez regarder +l'adresse de votre +interface externe et si elle est comprise dans une des plages +précédentes, +vous devriez enlever l'option 'norfc1918' dans le fichier +/etc/shorewall/interfaces.

        +
        +
        +

        Vous devrez assigner les adresses locales à un +sous-réseau (sub-network ou subnet) et les adresse pour +la DMZ à un autre sous-réseau. Pour ce faire, nous pouvons considérer +qu'un sous-réseau consiste en une plage d'adresse x.y.z.0 à x.y.z.255. +Chacun des sous-réseaux possèdera une masque (Subnet Mask) de +255.255.255.0. L'adresse x.y.z.0 +est réservée comme l'adresse du sous-réseau (Subnet Address) +et x.y.z.255 est réservée en tant qu'adresse de broadcast du +sous-réseau +(Subnet Broadcast Address). Sous Shorewall, un +sous-réseau +est décrit/désigné en utilisant la notation Classless InterDomain +Routing(CIDR) +qui consiste en l'adresse du sous-réseau suivie par "/24". Le "24" se +réfère +au nombre de bits "1" consécutifs dans la partie gauche du masque de +sous-réseau.

        -
        - -
        +
        +

        Exemple de sous-réseau (subnet) :

        -
        - -
        -
        +
        +
        +
        - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + +
        Plage:10.10.10.0 - 10.10.10.255
        Subnet Address:10.10.10.0
        Broadcast Address:10.10.10.255
        CIDR Notation:10.10.10.0/24
        Plage:10.10.10.0 - 10.10.10.255
        Subnet Address:10.10.10.0
        Broadcast Address:10.10.10.255
        CIDR Notation:10.10.10.0/24
        -
        -
        - -
        -

        Il est de convention d'assigner à l'interface interne la -première adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple -précédent) ou la dernière utilisable (10.10.10.254).

        -
        - -
        -

        L'un des buts d'un sous-réseau est de permettre à tous les - ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs -ils peuvent communiquer directement. Pour communiquer avec des systèmes -en dehors du sous-réseau, les ordinateurs envoient des paquets à travers -le gateway (routeur).

        -
        - -
        +
        + +
        +

        Il est de convention d'assigner à l'interface interne +la +première adresse utilisable dans le sous-réseau (10.10.10.1 dans +l'exemple +précédent) ou la dernière utilisable (10.10.10.254).

        +
        +
        +

        L'un des buts d'un sous-réseau est de permettre à tous +les ordinateurs dans le sous-réseau de savoir avec quels autres +ordinateurs +ils peuvent communiquer directement. Pour communiquer avec des systèmes +en dehors du sous-réseau, les ordinateurs envoient des paquets à +travers +le gateway (routeur).

        +
        +

        - Vos ordinateurs locaux (ordinateur local 1 et 2) devraient être configurés - avec leur passerelle par défaut (default gateway)pointant sur l'adresse - IP de l'interface interne du firewall, et les ordinateurs de la DMZ devraient - être configurés avec leur passerelle par défaut (default gateway) - pointant sur l'adresse IP de l'interface DMZ du firewall.

        -
        - -

        Cette courte description ne fait que survoler les concepts - de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur -l'adressage IP et le routage, je vous recommande chaudement "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

        - -

        Pour rappel, ce guide supposera que vous avez configuré votre - réseau comme montrer ci-dessous :

        - + height="13"> Vos ordinateurs locaux (ordinateur local 1 et 2) +devraient être configurés avec leur passerelle par défaut (default +gateway)pointant sur l'adresse IP de l'interface interne du +firewall, et les ordinateurs de la DMZ devraient être configurés avec +leur passerelle par défaut (default gateway) pointant sur +l'adresse IP de l'interface DMZ du firewall.

        + +

        Cette courte description ne fait que survoler les +concepts de routage et de sous-réseau. Si vous vous voulez en apprendre +plus sur +l'adressage IP et le routage, je vous recommande chaudement "IP +Fundamentals: What Everyone Needs to Know about Addressing & +Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

        +

        Pour rappel, ce guide supposera que vous avez configuré +votre réseau comme montrer ci-dessous :

        -

        - -

        La passerelle par défaut (default gateway) pour les ordinateurs - de la DMZ sera 10.10.11.254 et le passerelle par défaut pour les -ordinateurs en local sera 10.10.10.254.

        - + height="635">

        +

        La passerelle par défaut (default gateway) pour les +ordinateurs de la DMZ sera 10.10.11.254 et le passerelle par défaut +pour les +ordinateurs en local sera 10.10.10.254.

        IP Masquerading (SNAT)

        - -

        Les adresses réservées par la RFC 1918 sont parfois désignées - comme non-routables car les routeurs Internet (backbone) ne font pas circuler - les paquets qui ont une adresse de destination appartenant à la RFC-1918. - Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une - connexion à un serveur par Internet, le firewall doit appliquer un NAT (Network - Address Translation). Le firewall ré écrit l'adresse source dans le paquet, - et l'a remplace par l'adresse de l'interface externe du firewall; en d'autres - mots, le firewall fait croire que c'est lui même qui initie la connexion. - Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer - les paquets au firewall (souvenez vous que les paquets qui ont pour adresse - de destination, une adresse réservée par la RFC 1918 ne pourront pas être - routés à travers Internet, donc l'hôte Internet ne pourra adresser sa réponse - à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il remet - l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur - 1.

        - -

        Sur les systèmes Linux, ce procédé est souvent appelé de -l'IP Masquerading mais vous verrez aussi le terme de Source Network Address -Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter +

        Les adresses réservées par la RFC 1918 sont parfois +désignées comme non-routables car les routeurs Internet (backbone) ne +font pas circuler les paquets qui ont une adresse de destination +appartenant à la RFC-1918. Lorsqu'un de vos systèmes en local +(supposons l'ordinateur1) demande une connexion à un serveur par +Internet, le firewall doit appliquer un NAT (Network Address +Translation). Le firewall ré écrit l'adresse source dans le paquet, et +l'a remplace par l'adresse de l'interface externe du firewall; en +d'autres mots, le firewall fait croire que c'est lui même qui initie la +connexion. Ceci est nécessaire afin que l'hôte de destination soit +capable de renvoyer les paquets au firewall (souvenez vous que les +paquets qui ont pour adresse de destination, une adresse réservée par +la RFC 1918 ne pourront pas être routés à travers Internet, donc l'hôte +Internet ne pourra adresser sa réponse à l'ordinateur 1). Lorsque le +firewall reçoit le paquet de réponse, il remet l'adresse de destination +à 10.10.10.1 et fait passer le paquet vers l'ordinateur 1.

        +

        Sur les systèmes Linux, ce procédé est souvent appelé +de +l'IP Masquerading mais vous verrez aussi le terme de Source Network +Address +Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec +Netfilter :

        -
          -
        • -

          Masquerade désigne le cas ou vous laissez votre firewall - détecter automatiquement l'adresse de l'interface externe.

          -
          • -
        • -

          SNAT désigne le cas où vous spécifiez explicitement l'adresse - source des paquets sortant de votre réseau local.

          -
          • - +
        • +

          Masquerade désigne le cas ou vous laissez votre +firewall détecter automatiquement l'adresse de l'interface externe.

          +
          • +
        • +

          SNAT désigne le cas où vous spécifiez explicitement +l'adresse source des paquets sortant de votre réseau local.

          +
        - -

        Sous Shorewall, autant le Masquerading que le SNAT sont configuré - avec des entrés dans le fichier /etc/shorewall/masq.

        - +

        Sous Shorewall, autant le Masquerading que le SNAT sont +configuré avec des entrés dans le fichier /etc/shorewall/masq.

        - Si votre interface externe est eth0, votre interface locale eth1 - et votre interface pour la DMZ eth2 vous n'avez pas besoin de modifier - le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq - et changez le en conséquence.

        - + height="13"> Si votre interface externe est eth0, votre +interface locale eth1 et votre interface pour la DMZ eth2 +vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. +Dans le cas contraire, éditez /etc/shorewall/masq et changez le en +conséquence.

        - Si votre IP externe est statique, vous pouvez la mettre dans la troisième - colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre - firewall fonctionnera bien si vous laissez cette colonne vide. Le fait -de mettre votre IP statique dans la troisième colonne permet un traitement -des paquets sortant un peu plus efficace.
        -

        - + height="13"> Si votre IP externe est statique, vous pouvez la mettre +dans la troisième colonne dans /etc/shorewall/masq si vous le désirez, +de toutes façons votre firewall fonctionnera bien si vous laissez cette +colonne vide. Le fait +de mettre votre IP statique dans la troisième colonne permet un +traitement +des paquets sortant un peu plus efficace.
        +

        - Si vous utilisez les paquets Debian, vérifiez que votre fichier de configuration - shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas - faite les changements nécessaires :
        -

        - + height="13" alt=""> Si vous utilisez les paquets Debian, vérifiez que +votre fichier de configuration shorewall.conf contient bien les valeurs +suivantes, si elles n'y sont pas faite les changements nécessaires :
        +

          -
        • NAT_ENABLED=Yes
          • -
        • IP_FORWARDING=On
          -
          • - +
        • NAT_ENABLED=Yes
          • +
        • IP_FORWARDING=On
          +
        -

        Port Forwarding (DNAT)

        - -

        Un de nos buts est de, peut être, faire tourner un ou plusieurs - serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse - RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter - directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes - de connexion au firewall qui ré écrit l'adresse de destination de votre -serveur, et fait passer le paquet à celui-ci. Lorsque votre serveur répond, -le firewall applique automatiquement un SNAT pour ré écrire l'adresse source +

        Un de nos buts est de, peut être, faire tourner un ou +plusieurs serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs +on une adresse RFC-1918, il n'est pas possible pour les clients sur +Internet de se connecter directement à eux. Il est nécessaire à ces +clients d'adresser leurs demandes de connexion au firewall qui ré écrit +l'adresse de destination de votre +serveur, et fait passer le paquet à celui-ci. Lorsque votre serveur +répond, +le firewall applique automatiquement un SNAT pour ré écrire l'adresse +source dans la réponse.

        - -

        Ce procédé est appelé Port Forwarding ou Destination Network - Address Translation(DNAT). Vous configurez le port forwarding en utilisant - les règles DNAT dans le fichier /etc/shorewall/rules.

        - -

        La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules - est :

        - -
        +

        Ce procédé est appelé Port Forwarding ou Destination +Network Address Translation(DNAT). Vous configurez le port forwarding +en utilisant les règles DNAT dans le fichier /etc/shorewall/rules.

        +

        La forme générale d'une simple règle de port forwarding dans +/etc/shorewall/rules est :

        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:<server local ip address> [:<server - port>]<protocol><port>
        -
        -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:<server local ip address> [:<server +port>]<protocol><port>
        +
        +
        -
        - -

        Si vous ne spécifiez pas le <server port>, il est supposé - être le même que <port>.

        - -

        Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et vous - voulez faire passer les paquets entrant en TCP sur le port 80 à ce système - :

        - -
        +
        +

        Si vous ne spécifiez pas le <server port>, il est +supposé être le même que <port>.

        +

        Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et +vous voulez faire passer les paquets entrant en TCP sur le port 80 à ce +système :

        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
        ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
        ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
        -
        - +

        Deux points importants à garder en mémoire :

        -
          -
        • Lorsque vous vous connectez à votre serveur à partir de votre -réseau local, vous devez utiliser l'adresse IP interne du serveur (10.10.11.2).
          • -
        • Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes - de connexion entrantes sur le port 80. Si vous avez des problèmes pour -vous connecter à votre serveur web, essayez la règle suivante et connectez -vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est votre - IP externe).
          • - +
        • Lorsque vous vous connectez à votre serveur à partir de votre +réseau local, vous devez utiliser l'adresse IP interne du serveur +(10.10.11.2).
          • +
        • Quelques fournisseurs Internet (Provider/ISP) bloquent les +requêtes de connexion entrantes sur le port 80. Si vous avez des +problèmes pour +vous connecter à votre serveur web, essayez la règle suivante et +connectez +vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est +votre IP externe).
        - -
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp5000
        -
        -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp5000
        +
        +
        -
        - -

        Si vous voulez avoir la possibilité de vous connecter à votre serveur -depuis le réseau local en utilisant votre adresse externe, et si vous avez -une adresse IP externe statique (fixe), vous pouvez remplacer la règle loc->dmz +

        +

        Si vous voulez avoir la possibilité de vous connecter à votre +serveur +depuis le réseau local en utilisant votre adresse externe, et si vous +avez +une adresse IP externe statique (fixe), vous pouvez remplacer la règle +loc->dmz précédente par :

        - -
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp80-<external IP>
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp80-<external IP>
        -
        - -

        Si vous avez une IP dynamique, alors vous devez vous assurer que votre - interface externe est en route avant de lancer Shorewall et vous devez -suivre les étapes suivantes (en supposant que votre interface externe est -eth0) :

        - +
        +

        Si vous avez une IP dynamique, alors vous devez vous assurer que +votre interface externe est en route avant de lancer Shorewall et vous +devez +suivre les étapes suivantes (en supposant que votre interface externe +est +eth0) :

          -
        1. Insérez ce qui suit dans /etc/shorewall/params :
          -
          - ETH0_IP=`find_interface_address eth0`
          -
          2. -
        2. Faites votre règle loc->dmz :
          3. - +
        3. Insérez ce qui suit dans /etc/shorewall/params :
          +
          +ETH0_IP=`find_interface_address eth0`
          +
          4. +
        4. Faites votre règle loc->dmz :
        - -
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATloc
        -         		dmz:10.10.11.2:80tcp80-$ETH0_IP
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATloc
        +         		dmz:10.10.11.2:80tcp80-$ETH0_IP
        -
        - -

        Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre +

        +

        Si vous voulez accéder à votre serveur dans la DMZ en utilisant +votre adresse IP externe, regardez FAQ 2a.

        - -

        - A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

        - +

        A +ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

        Domain Name Server (DNS)

        - -

        Normalement, quand vous vous connectez à votre fournisseur - (ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le - firewall (Domain Name Service) est configuré automatiquement (c.a.d., le -fichier /etc/resolv.conf a été écrit). Il arrive que votre provider vous -donne une paire d'adresse IP pour les DNS (name servers) afin que vous configuriez -manuellement votre serveur de nom primaire et secondaire. La manière dont -le DNS est configuré sur votre firewall est de votre responsabilité. Vous +

        Normalement, quand vous vous connectez à votre +fournisseur (ISP), une partie consiste à obtenir votre adresse IP, +votre DNS pour le firewall (Domain Name Service) est configuré +automatiquement (c.a.d., le +fichier /etc/resolv.conf a été écrit). Il arrive que votre provider +vous +donne une paire d'adresse IP pour les DNS (name servers) afin que vous +configuriez +manuellement votre serveur de nom primaire et secondaire. La manière +dont +le DNS est configuré sur votre firewall est de votre responsabilité. +Vous pouvez procéder d'une de ses deux façons :

        -
          -
        • -

          Vous pouvez configurer votre système interne pour utiliser - les noms de serveurs de votre provider. Si votre fournisseur vous donne -les adresses de leurs serveurs ou si ces adresses sont disponibles sur leur -site web, vous pouvez configurer votre système interne afin de les utiliser. -Si cette information n'est pas disponible, regardez dans /etc/resolv.conf -sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement - "nameserver" dans ce fichier.

          -
          • -
        • +
        • +

          Vous pouvez configurer votre système interne pour +utiliser les noms de serveurs de votre provider. Si votre fournisseur +vous donne +les adresses de leurs serveurs ou si ces adresses sont disponibles sur +leur +site web, vous pouvez configurer votre système interne afin de les +utiliser. +Si cette information n'est pas disponible, regardez dans +/etc/resolv.conf +sur votre firewall -- les noms des serveurs sont donnés dans +l'enregistrement "nameserver" dans ce fichier.

          +
          • +

        • - Vous pouvez installer/configurer un cache dns (Caching Name Server) -sur votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre -en cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour -les utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette -approche, vous configurez votre système interne pour utiliser le firewall -lui même comme étant le seul serveur de nom primaire. Vous pouvez utiliser -l'adresse IP interne du firewall (10.10.10.254 dans l'exemple) pour l'adresse -de serveur de nom si vous décidez de faire tourner le serveur de nom sur -votre firewall. Pour permettre à vos systèmes locaux de discuter avec votre -serveur cache de nom, vous devez ouvrir le port 53 (UDP ET  TCP) sur le -firewall vers le réseau local; vous ferez ceci en ajoutant les règles suivantes -dans /etc/shorewall/rules.

          -
          • - + width="13" height="13"> Vous pouvez installer/configurer un cache dns +(Caching Name Server) +sur votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre +en cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour +les utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette +approche, vous configurez votre système interne pour utiliser le +firewall +lui même comme étant le seul serveur de nom primaire. Vous pouvez +utiliser +l'adresse IP interne du firewall (10.10.10.254 dans l'exemple) pour +l'adresse +de serveur de nom si vous décidez de faire tourner le serveur de nom +sur +votre firewall. Pour permettre à vos systèmes locaux de discuter avec +votre +serveur cache de nom, vous devez ouvrir le port 53 (UDP ET  TCP) +sur le +firewall vers le réseau local; vous ferez ceci en ajoutant les règles +suivantes +dans /etc/shorewall/rules.

          +
        - -
        -

        Si vous faites tourner le serveur de nom sur le firewall - : +

        +

        Si vous faites tourner le serveur de nom sur le +firewall : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp53
        -
        -
        ACCEPTlocfwudp53
        -
        -
        ACCEPTdmzfwtcp53
        -
        -
        ACCEPTdmzfwudp53
        -
        -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp53
        +
        +
        ACCEPTlocfwudp53
        +
        +
        ACCEPTdmzfwtcp53
        +
        +
        ACCEPTdmzfwudp53
        +
        +
        -

        -
        - -
        -
        +

        +
        +
        +

        Le serveur de nom tourne sur l'ordinateur 1 de la DMZ

        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocdmz:10.10.11.1tcp53
        -
        -
        ACCEPTlocdmz:10.10.11.1udp53
        -
        -
        ACCEPTfwdmz:10.10.10.1tcp53
        -
        -
        ACCEPTfwdmz:10.10.10.1udp53
        -
        -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocdmz:10.10.11.1tcp53
        +
        +
        ACCEPTlocdmz:10.10.11.1udp53
        +
        +
        ACCEPTfwdmz:10.10.10.1tcp53
        +
        +
        ACCEPTfwdmz:10.10.10.1udp53
        +
        +
        -
        -
        - -
        +
        + +

        Autres Connexions

        -
        - -
        -

        L'exemple pour trois interfaces contient les règles suivantes - :

        -
        - -
        -
        +
        +
        +

        L'exemple pour trois interfaces contient les règles +suivantes :

        +
        +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTfwnetudp53
        -
        -
        ACCEPTfwnettcp53
        -
        -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTfwnetudp53
        +
        +
        ACCEPTfwnettcp53
        +
        +
        -
        -
        - -
        -

        Ces règles permettent l'accès DNS depuis votre firewall et - peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy - autorisant toutes les connexions depuis votre firewall et vers Internet.

        -
        - -
        + +
        +
        +

        Ces règles permettent l'accès DNS depuis votre firewall +et peuvent être enlevées si vous avez décommenté la ligne dans +/etc/shorewall/policy autorisant toutes les connexions depuis votre +firewall et vers Internet.

        +
        +

        L'exemple contient aussi :

        -
        - -
        -
        +
        +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp22
        -
        -
        ACCEPTlocdmztcp22
        -
        -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTlocfwtcp22
        +
        +
        ACCEPTlocdmztcp22
        +
        +
        -
        -
        - -
        -

        Cette règle permet de faire fonctionner une serveur SSH sur - le firewall et sur tous les systèmes de la DMZ et d'y autoriser la connexion - à partir de votre réseau local.

        -
        - -
        -

        Si vous désirez permettre d'autres connexions entre vos systèmes, - la forme générale est :

        -
        - -
        -
        +
        +
        +
        +

        Cette règle permet de faire fonctionner une serveur SSH +sur le firewall et sur tous les systèmes de la DMZ et d'y autoriser la +connexion à partir de votre réseau local.

        +
        +
        +

        Si vous désirez permettre d'autres connexions entre vos +systèmes, la forme générale est :

        +
        +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPT<source zone><destination zone><protocol><port>
        -
        -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPT<source zone><destination zone><protocol><port>
        +
        +
        -
        -
        - -
        -

        Exemple - Vous voulez faire tourner un serveur DNS disponible - pour le publique sur votre firewall :

        -
        - -
        -
        +
        +
        +
        +

        Exemple - Vous voulez faire tourner un serveur DNS +disponible pour le publique sur votre firewall :

        +
        +
        +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
        ACCEPTnetfwudp
        -         		53#permet les accès DNSdepuis Internet
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
        ACCEPTnetfwudp
        +         		53#permet les accès DNSdepuis Internet
        -
        -
        - -
        -

        Ces deux règles seront, bien sur, ajoutées aux règles décrites - dans "Vous pouvez installer/configurer un cache dns (Caching Name Server) - sur votre firewall ou dans la DMZ".

        -
        - -
        -

        Si vous ne savez pas quel port ou protocole une application - particulière utilise, regardez ici.

        -
        - -
        -

        Important: Je ne vous recommande pas d'autoriser le telnet - depuis ou vers l'Internet car il utilise du texte en clair (même pour le - login et le mot de passe !). Si vous voulez avoir un accès au shell de votre - firewall depuis Internet, utilisez SSH :

        -
        - -
        -
        +
        +
        +
        +

        Ces deux règles seront, bien sur, ajoutées aux règles +décrites dans "Vous pouvez installer/configurer un cache dns (Caching +Name Server) sur votre firewall ou dans la DMZ".

        +
        +
        +

        Si vous ne savez pas quel port ou protocole une +application particulière utilise, regardez ici.

        +
        +
        +

        Important: Je ne vous recommande pas d'autoriser le +telnet depuis ou vers l'Internet car il utilise du texte en clair (même +pour le login et le mot de passe !). Si vous voulez avoir un accès au +shell de votre firewall depuis Internet, utilisez SSH :

        +
        +
        +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp22
        -
        -
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        ACCEPTnetfwtcp22
        +
        +
        -
        -
        - -
        + +
        +

        - Et maintenant, éditez /etc/shorewall/rules pour rajouter les autres -connexions désirées.

        -
        - -
        + height="13"> Et maintenant, éditez /etc/shorewall/rules pour rajouter +les autres +connexions désirées.

        +
        +

        Lancer et Arrêter son Firewall

        -
        - -
        +
        +

        Arrow - La procédure d'installation configure votre - système pour lancer Shorewall au boot du système, mais au début avec la -version 1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de -lancer Shorewall avec que la configuration soit finie. Une fois que vous -en avez fini avec la configuration du firewall, vous pouvez permettre le -lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
        -

        - -

        IMPORTANT: Les utilisateurs des paquets .deb doivent éditer - /etc/default/shorewall et mettre 'startup=1'.
        -

        -
        - -
        -

        Le firewall est activé en utilisant la commande "shorewall - start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, -le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un - firewall qui tourne peut être relancé en utilisant la commande "shorewall - restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration - de Netfilter, utilisez "shorewall clear".

        -
        - -
        + height="13" alt="Arrow"> La procédure +d'installation configure votre système pour lancer Shorewall au +boot du système, mais au début avec la +version 1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de +lancer Shorewall avec que la configuration soit finie. Une fois que +vous +en avez fini avec la configuration du firewall, vous pouvez permettre +le +lancement de Shorewall en supprimant le fichier +/etc/shorewall/startup_disabled.
        +

        +

        IMPORTANT: Les utilisateurs des paquets .deb doivent +éditer /etc/default/shorewall et mettre 'startup=1'.
        +

        +
        +
        +

        Le firewall est activé en utilisant la commande +"shorewall start" et arrêté avec "shorewall stop". Lorsque le firewall +est stoppé, +le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. +Un firewall qui tourne peut être relancé en utilisant la commande +"shorewall restart". Si vous voulez enlever toutes traces de Shorewall +sur votre configuration de Netfilter, utilisez "shorewall clear".

        +
        +

        - L'exemple pour trois interfaces suppose que vous voulez permettre le -routage depuis/vers eth1 (votre réseau local) et eth2(DMZ) - lorsque Shorewall est arrêté. Si ces deux interfaces ne sont pas -connectées à votre réseau local et votre DMZ, ou si vous voulez permettre -un ensemble d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.

        -
        - -
        -

        ATTENTION: Si vous êtes connecté à votre firewall depuis -Internet, n'essayez pas une commande "shorewall stop" tant que vous n'avez -pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous + height="13"> L'exemple pour trois interfaces suppose que vous voulez +permettre le routage depuis/vers eth1 (votre réseau local) et +eth2(DMZ) lorsque Shorewall est arrêté. Si ces deux interfaces ne +sont pas connectées à votre réseau local et votre DMZ, ou si vous +voulez permettre un ensemble d'hôtes différents, modifiez +/etc/shorewall/routestopped en conséquence.

        +
        +
        +

        ATTENTION: Si vous êtes connecté à votre firewall +depuis +Internet, n'essayez pas une commande "shorewall stop" tant que vous +n'avez +pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle +vous êtes connectée) dans /etc/shorewall/routestopped. - De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; - il est plus intéressant de créer une configuration alternativeet de la - tester en utilisant la commande "shorewall try".

        -
        - + href="configuration_file_basics.htm#Configs">alternativeet de +la tester en utilisant la commande "shorewall try".

        +

        Last updated 05/19/2003 - Tom Eastep

        - -

        Copyright 2002, 2003 -Thomas M. Eastep
        -

        -
        +

        Copyright 2002, +2003 Thomas M. Eastep
        +

        +
        diff --git a/Shorewall-docs/traffic_shaping.htm b/Shorewall-docs/traffic_shaping.htm index 4b127c911..40c2c9c5c 100644 --- a/Shorewall-docs/traffic_shaping.htm +++ b/Shorewall-docs/traffic_shaping.htm @@ -1,341 +1,306 @@ - - - - Traffic Shaping - - - - - - - - - -
        -

        Traffic Shaping/Control

        -
        - -

        Shorewall has limited support for traffic shaping/control. - In order to use traffic shaping under Shorewall, it is essential that - you get a copy of the Linux Advanced Routing - and Shaping HOWTO, version 0.3.0 or later. It is also necessary -to be running Linux Kernel 2.4.18 or later.

        - -

        Shorewall traffic shaping support consists of the following:

        - + +

        Traffic Shaping/Control
        +

        +

        Shorewall has limited support for traffic +shaping/control. In order to use traffic shaping under Shorewall, it is +essential that you get a copy of the Linux +Advanced Routing and Shaping HOWTO, version 0.3.0 or later. It is +also necessary to be running Linux Kernel 2.4.18 or later.

        +

        Shorewall traffic shaping support consists of the +following:

          -
        • A new TC_ENABLED parameter in /etc/shorewall.conf. - Traffic Shaping also requires that you enable packet mangling.
          • -
        • A new CLEAR_TC parameter in /etc/shorewall.conf (Added - in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), - the setting of this variable determines whether Shorewall clears the traffic - shaping configuration during Shorewall [re]start and Shorewall stop.
          -
          • -
        • /etc/shorewall/tcrules - A file where you -can specify firewall marking of packets. The firewall mark value -may be used to classify packets for traffic shaping/control.
          -
          • -
        • /etc/shorewall/tcstart - A user-supplied file - that is sourced by Shorewall during "shorewall start" and which - you can use to define your traffic shaping disciplines and classes. - I have provided a sample that does - table-driven CBQ shaping but if you read the traffic shaping sections - of the HOWTO mentioned above, you can probably code your own faster - than you can learn how to use my sample. I personally use - HTB (see below). - HTB support may eventually become an integral part of Shorewall -since HTB is a lot simpler and better-documented than CBQ. As of 2.4.20, - HTB is a standard part of the kernel but iproute2 must be patched in - order to use it.
          -
          - In tcstart, when you want to run the 'tc' utility, -use the run_tc function supplied by shorewall if you want tc errors - to stop the firewall.
          -
          - You can generally use off-the-shelf traffic shaping scripts by -simply copying them to /etc/shorewall/tcstart. I use The Wonder Shaper (HTB version) - that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart -and modified it according to the Wonder Shaper README). WARNING: If - you use use Masquerading or SNAT (i.e., you only have one external IP address) - then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb] - script won't work. Traffic shaping occurs after SNAT has already been -applied so when traffic shaping happens, all outbound traffic will have -as a source address the IP addresss of your firewall's external interface.
          -
          • -
        • /etc/shorewall/tcclear - A user-supplied file - that is sourced by Shorewall when it is clearing traffic shaping. - This file is normally not required as Shorewall's method of clearing - qdisc and filter definitions is pretty general.
          • - -
        - Shorewall allows you to start traffic shaping when Shorewall itself - starts or it allows you to bring up traffic shaping when you bring up your - interfaces.
        -
        - To start traffic shaping when Shorewall starts:
        - -
          -
        1. Set TC_ENABLED=Yes and CLEAR_TC=Yes
          2. -
        2. Supply an /etc/shorewall/tcstart script to configure your traffic - shaping rules.
          3. -
        3. Optionally supply an /etc/shorewall/tcclear script to stop -traffic shaping. That is usually unnecessary.
          4. -
        4. If your tcstart script uses the 'fwmark' classifier, you can -mark packets using entries in /etc/shorewall/tcrules.
          5. - -
        - To start traffic shaping when you bring up your network interfaces, - you will have to arrange for your traffic shaping configuration script -to be run at that time. How you do that is distribution dependent and will -not be covered here. You then should:
        - -
          -
        1. Set TC_ENABLED=Yes and CLEAR_TC=No
          2. -
        2. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear - scripts.
          3. -
        3. If your tcstart script uses the 'fwmark' classifier, - you can mark packets using entries in /etc/shorewall/tcrules.
          4. - -
        - -

        Kernel Configuration

        - -

        This screen shot show how I've configured QoS in my Kernel:

        - -

        -

        - -

        /etc/shorewall/tcrules

        - -

        The fwmark classifier provides a convenient way to classify - packets for traffic shaping. The /etc/shorewall/tcrules file provides - a means for specifying these marks in a tabular fashion.
        -

        - -

        Normally, packet marking occurs in the PREROUTING chain before - any address rewriting takes place. This makes it impossible to mark inbound - packets based on their destination address when SNAT or Masquerading -are being used. Beginning with Shorewall 1.3.12, you can cause packet -marking to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN -option in shorewall.conf.
        -

        - -

        Columns in the file are as follows:

        - -
          -
        • MARK - Specifies the mark value is to be assigned -in case of a match. This is an integer in the range 1-255. Beginning -with Shorewall version 1.3.14, this value may be optionally followed by -":" and either 'F' or 'P' to designate that the marking will occur in the -FORWARD or PREROUTING chains respectively. If this additional specification -is omitted, the chain used to mark packets will be determined by the setting -of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
          -
          - Example - 5
          -
          • -
        • SOURCE - The source of the packet. If the packet -originates on the firewall, place "fw" in this column. Otherwise, -this is a comma-separated list of interface names, IP addresses, MAC -addresses in Shorewall Format and/or -Subnets.
          -
          - Examples
          -     eth0
          -     192.168.2.4,192.168.1.0/24
          -
          • -
        • DEST -- Destination of the packet. Comma-separated -list of IP addresses and/or subnets.
          -
          • -
        • PROTO - Protocol - Must be the name of a protocol -from /etc/protocol, a number or "all"
          -
          • -
        • PORT(S) - Destination Ports. A comma-separated list - of Port names (from /etc/services), port numbers or port ranges (e.g., - 21:22); if the protocol is "icmp", this column is interpreted as - the destination icmp type(s).
          -
          • -
        • CLIENT PORT(S) - (Optional) Port(s) used by the client. - If omitted, any source port is acceptable. Specified as a comma-separate - list of port names, port numbers or port ranges.
          • - -
        - -

        Example 1 - All packets arriving on eth1 should be marked - with 1. All packets arriving on eth2 and eth3 should be marked with - 2. All packets originating on the firewall itself should be marked with - 3.

        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        1eth10.0.0.0/0all  
        2eth20.0.0.0/0all  
        2
        -         		eth3
        -         		0.0.0.0/0
        -         		all
        -
        -
        -
        3fw0.0.0.0/0all  
        - -

        Example 2 - All GRE (protocol 47) packets not originating - on the firewall and destined for 155.186.235.151 should be marked -with 12.

        - - - - - - - - - - - - - - - - - - - - - -
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        120.0.0.0/0155.186.235.15147  
        - -

        Example 3 - All SSH packets originating in 192.168.1.0/24 - and destined for 155.186.235.151 should be marked with 22.

        - - - - - - - - - - - - - - - - - - - - - -
        MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
        22192.168.1.0/24155.186.235.151tcp22 
        - -

        My Setup
        -

        - -

        While I am currently using the HTB version of The Wonder Shaper (I just copied - wshaper.htb to /etc/shorewall/tcstart and modified it as shown - in the Wondershaper README), I have also run with the following set of -hand-crafted rules in my /etc/shorewall/tcstart file:
        -

        - -
        - 
        run_tc qdisc add dev eth0 root handle 1: htb default 30

        run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

        echo "   Added Top Level Class -- rate 384kbit"
        - - 
        run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
        run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
        run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1
        - - 
        echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
        - - 
        run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
        run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
        run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
        - - 
        echo "   Enabled PFIFO on Second Level Classes"
        - - 
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
        run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
        - - 
        echo "   Defined fwmark filters"
        -
        - -

        My tcrules file that went with this tcstart file is shown in Example 1 - above. You can look at my configuration to -see why I wanted shaping of this type.
        -

        - -
          -
        1. I wanted to allow up to 140kbits/second for traffic outbound - from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ -traffic can use all available bandwidth if there is no traffic from the -local systems or from my laptop or firewall).
          2. -
        2. My laptop and local systems could use up to 224kbits/second.
          3. -
        3. My firewall could use up to 20kbits/second.
          4. - -
        - You see the rest of my Shorewall configuration - to see how this fit in.
        - -

        Last Updated 3/19/2003 - Tom Eastep

        - -

        Copyright - © 2001, 2002, 2003 Thomas M. Eastep.
        -

        -
        -
        +
      • A new TC_ENABLED parameter in /etc/shorewall.conf. +Traffic Shaping also requires that you enable packet mangling.
        • +
      • A new CLEAR_TC parameter in /etc/shorewall.conf (Added +in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), +the setting of this variable determines whether Shorewall clears the +traffic shaping configuration during Shorewall [re]start and Shorewall +stop.
        +
        • +
      • /etc/shorewall/tcrules - A file where you +can specify firewall marking of packets. The firewall mark value +may be used to classify packets for traffic shaping/control.
        +
        • +
      • /etc/shorewall/tcstart - A user-supplied file that is +sourced by Shorewall during "shorewall start" and which you can use to +define your traffic shaping disciplines and classes. I have provided a sample that does +table-driven CBQ shaping but if you read the traffic shaping sections +of the HOWTO mentioned above, you can probably code your own faster +than you can learn how to use my sample. I personally use HTB (see below). HTB +support may eventually become an integral part of Shorewall since HTB +is a lot simpler and better-documented than CBQ. As of 2.4.20, HTB is a +standard part of the kernel but iproute2 must be patched in order to +use it.

        -
        -
        -
        +In tcstart, when you want to run the 'tc' utility, +use the run_tc function supplied by shorewall if you want tc errors to +stop the firewall.
        +
        +You can generally use off-the-shelf traffic shaping scripts by simply +copying them to /etc/shorewall/tcstart. I use The Wonder Shaper (HTB +version) that way (i.e., I just copied wshaper.htb to +/etc/shorewall/tcstart +and modified it according to the Wonder Shaper README). WARNING: If +you use use Masquerading or SNAT (i.e., you only have one external IP +address) then listing internal hosts in the NOPRIOHOSTSRC variable in +the wshaper[.htb] script won't work. Traffic shaping occurs after SNAT +has already been +applied so when traffic shaping happens, all outbound traffic will have +as a source address the IP addresss of your firewall's external +interface.
        +
        • +
      • /etc/shorewall/tcclear - A user-supplied file that is +sourced by Shorewall when it is clearing traffic shaping. This file is +normally not required as Shorewall's method of clearing qdisc and +filter definitions is pretty general.
        • +
      +Shorewall allows you to start traffic shaping when Shorewall itself +starts or it allows you to bring up traffic shaping when you bring up +your interfaces.
      +
      +To start traffic shaping when Shorewall starts:
      +
        +
      1. Set TC_ENABLED=Yes and CLEAR_TC=Yes
        2. +
      2. Supply an /etc/shorewall/tcstart script to configure your traffic +shaping rules.
        3. +
      3. Optionally supply an /etc/shorewall/tcclear script to stop +traffic shaping. That is usually unnecessary.
        4. +
      4. If your tcstart script uses the 'fwmark' classifier, you can mark +packets using entries in /etc/shorewall/tcrules.
        5. +
      +To start traffic shaping when you bring up your network interfaces, you +will have to arrange for your traffic shaping configuration script to +be run at that time. How you do that is distribution dependent and will +not be covered here. You then should:
      +
        +
      1. Set TC_ENABLED=Yes and CLEAR_TC=No
        2. +
      2. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear +scripts.
        3. +
      3. If your tcstart script uses the 'fwmark' classifier, +you can mark packets using entries in /etc/shorewall/tcrules.
        4. +
      +

      Kernel Configuration

      +

      This screen shot show how I've configured QoS in my +Kernel:

      +

      +

      /etc/shorewall/tcrules

      +

      The fwmark classifier provides a convenient way to +classify packets for traffic shaping. The /etc/shorewall/tcrules file +provides a means for specifying these marks in a tabular fashion.
      +

      +

      Normally, packet marking occurs in the PREROUTING chain +before any address rewriting takes place. This makes it impossible to +mark inbound packets based on their destination address when SNAT or +Masquerading +are being used. Beginning with Shorewall 1.3.12, you can cause packet +marking to occur in the FORWARD chain by using the +MARK_IN_FORWARD_CHAIN +option in shorewall.conf.
      +

      +

      Columns in the file are as follows:

      +
        +
      • MARK - Specifies the mark value is to be assigned in case of a +match. This is an integer in the range 1-255. Beginning with Shorewall +version 1.3.14, this value may be optionally followed by +":" and either 'F' or 'P' to designate that the marking will occur in +the +FORWARD or PREROUTING chains respectively. If this additional +specification +is omitted, the chain used to mark packets will be determined by the +setting +of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
        +
        +Example - 5
        +
        • +
      • SOURCE - The source of the packet. If the packet +originates on the firewall, place "fw" in this column. Otherwise, +this is a comma-separated list of interface names, IP addresses, MAC +addresses in Shorewall Format +and/or +Subnets.
        +
        +Examples
        +    eth0
        +    192.168.2.4,192.168.1.0/24
        +
        • +
      • DEST -- Destination of the packet. Comma-separated list of IP +addresses and/or subnets.
        +
        • +
      • PROTO - Protocol - Must be the name of a protocol from +/etc/protocol, a number or "all"
        +
        • +
      • PORT(S) - Destination Ports. A comma-separated list of Port names +(from /etc/services), port numbers or port ranges (e.g., 21:22); if the +protocol is "icmp", this column is interpreted as the destination icmp +type(s).
        +
        • +
      • CLIENT PORT(S) - (Optional) Port(s) used by the client. If +omitted, any source port is acceptable. Specified as a comma-separate +list of port names, port numbers or port ranges.
        • +
      +

      Example 1 - All packets arriving on eth1 should be +marked with 1. All packets arriving on eth2 and eth3 should be marked +with 2. All packets originating on the firewall itself should be marked +with 3.

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      1eth10.0.0.0/0all  
      2eth20.0.0.0/0all  
      2
      +       		eth3
      +       		0.0.0.0/0
      +       		all
      +
      +
      +
      3fw0.0.0.0/0all  
      +

      Example 2 - All GRE (protocol 47) packets not +originating on the firewall and destined for 155.186.235.151 should be +marked with 12.

      + + + + + + + + + + + + + + + + + + + +
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      120.0.0.0/0155.186.235.15147  
      +

      Example 3 - All SSH packets originating in +192.168.1.0/24 and destined for 155.186.235.151 should be marked with +22.

      + + + + + + + + + + + + + + + + + + + +
      MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
      22192.168.1.0/24155.186.235.151tcp22 
      +

      My Current Setup
      +

      +

      I am currently using the HTB version of The Wonder Shaper (I just +copied wshaper.htb to /etc/shorewall/tcstart and modified it as +shown in the Wondershaper README). WonderShaper +DOES NOT USE THE +/etc/shorewall/tcrules file. While I currently have entries in +/etc/shorewall/tcrules, I do so for policy routing for Squid and not +for Traffic Shaping.

      +

      My Old Setup
      +

      +

      I have also run with the following set of hand-crafted rules in my /etc/shorewall/tcstart +file.
      +

      +
      + 
      run_tc qdisc add dev eth0 root handle 1: htb default 30

      run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

      echo "   Added Top Level Class -- rate 384kbit"
      + 
      run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
      run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
      run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1
      + 
      echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
      + 
      run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
      run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
      run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
      + 
      echo "   Enabled PFIFO on Second Level Classes"
      + 
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
      run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
      + 
      echo "   Defined fwmark filters"
      +
      +

      My tcrules file that went with this tcstart file is shown in Example +1 above. When I was using these rules:
      +

      +
        +
      1. I wanted to allow up to 140kbits/second for traffic outbound from +my DMZ (eth1 -- note that the ceiling is set to 384kbit so outbound DMZ +traffic can use all available bandwidth if there is no traffic from the +local systems or from my laptop or firewall).
        2. +
      2. My laptop (which at that time connected via eth3) and local +systems (eth2) could use up to 224kbits/second.
        3. +
      3. My firewall could use up to 20kbits/second.
        4. +
      +Once www.shorewall.net was moved off-site, I no longer needed these +shaping rules and The Wonder Shaper does all that I now require.
      +

      Last Updated 10/21/2003 - Tom +Eastep

      +

      Copyright +© 2001, 2002, 2003 Thomas M. Eastep.
      +

      +
      +
      +
      +
      +
      +
      diff --git a/Shorewall-docs/troubleshoot.htm b/Shorewall-docs/troubleshoot.htm index 9669a7ab9..b7afdf2b4 100644 --- a/Shorewall-docs/troubleshoot.htm +++ b/Shorewall-docs/troubleshoot.htm @@ -8,19 +8,10 @@ - - - - - - -
      -

      Shorewall TroubleshootingBeating head on table

      -
      +

      Shorewall +Troubleshooting Beating head on table

      "If you think you can you can; if you think you can't you're right.
      If you don't believe that you can, why should someone else?" -- Gunnar @@ -145,8 +136,8 @@ sending the packets or the destination host isn't in any zone (using an /etc/shorewall/hosts file are you?); or
    • the source and destination hosts are both connected to the -same interface and you don't have a policy or rule for the -source zone to or from the destination zone.
      • +same interface and you haven't specified the 'routeback' option on that +interface.
    • Remember that Shorewall doesn't automatically allow ICMP type 8 @@ -199,7 +190,7 @@ in /etc/shorewall/shorewall.conf.
      •  -

      Last updated 8/29/2003 - Tom Eastep

      +

      Last updated 11/1/2003 - Tom Eastep

      Copyright © 2001, 2002 Thomas M. Eastep.

      diff --git a/Shorewall-docs/two-interface.htm b/Shorewall-docs/two-interface.htm index 2d849b165..e43e72d7b 100644 --- a/Shorewall-docs/two-interface.htm +++ b/Shorewall-docs/two-interface.htm @@ -10,18 +10,8 @@ - - - - - - -
      -

      Basic Two-Interface -Firewall

      -
      +

      Basic Two-Interface Firewall
      +

      Setting up a Linux system as a firewall for a small network is a fairly straight-forward task if you understand the basics and follow the documentation.

      @@ -30,7 +20,10 @@ of Shorewall. It rather focuses on what is required to configure Shorewall in its most common configuration:

      • Linux system used as a firewall/router for a small local network.
        • -
      • Single public IP address.
        • +
      • Single public IP address. If you have +more than one public IP address, this is not the guide you want -- see +the Shorewall Setup Guide +instead.
      • Internet connection through cable modem, DSL, ISDN, Frame Relay, dial-up ...
      @@ -140,8 +133,8 @@ that file matches the connection request then the first policy in /etc/shorewall/policy that matches the request is applied. If that policy is REJECT or DROP  the request is first checked against -the rules in /etc/shorewall/common (the samples provide that file -for you).

      +the rules in /etc/shorewall/common if that file exists; otherwise the +rules in /etc/shorewall/common.def are checked.

      The /etc/shorewall/policy file included with the two-interface sample has the following policies:

      @@ -946,9 +939,15 @@ have added an entry for the IP address that you are connected from to alternate configuration and test it using the "shorewall try" command.

      + href="starting_and_stopping_shorewall.htm">"shorewall try" command.
      +

      +

      Additional Recommended Reading

      +I highly recommend that you review the Common Configuration File +Features page -- it contains helpful tips about Shorewall features +than make administering your firewall easier. -

      Last updated 8/8/2003 - Last updated 11/15/2003 - Tom Eastep

      Copyright 2002, 2003 Thomas M. Eastep
      diff --git a/Shorewall-docs/two-interface_fr.html b/Shorewall-docs/two-interface_fr.html index 5262afb6f..93f4ea84a 100755 --- a/Shorewall-docs/two-interface_fr.html +++ b/Shorewall-docs/two-interface_fr.html @@ -1,1381 +1,1339 @@ - Two-Interface Firewall - - - - - - - - - - - - - - - -
      -

      Basic Two-Interface Firewall

      -
      - -

      Version 2.0.1 Française

      - + +

      Basic Two-Interface Firewall


      - Notes du traducteur :
      - Je ne prétends pas être un vrai traducteur dans le sens ou -mon travail n’est pas des plus précis (loin de là...). Je ne -me suis pas attaché à une traduction exacte du texte, mais plutôt -à en faire une version française intelligible par tous (et -par moi). Les termes techniques sont la plupart du temps conservés - sous leur forme originale et mis entre parenthèses car vous pouvez - les retrouver dans le reste des documentations ainsi que dans les fichiers - de configuration. N’hésitez pas à me contacter afin d’améliorer - ce document VETSEL Patrice - (merci à JMM pour sa relecture et ses commentaires pertinents, ainsi - qu'à Tom EASTEP pour son formidable outil et sa disponibilité)      .
      -
      -

      - -

      Mettre en place un système Linux en tant que firewall - pour un petit réseau est une chose assez simple, si vous comprenez - les bases et suivez la documentation.

      - -

      Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il -se focalise sur ce qui est nécessaire pour configurer Shorewall, dans - son utilisation la plus courante :

      - +Notes du traducteur :
      +Je ne prétends pas être un vrai traducteur dans le sens ou +mon travail n’est pas des plus précis (loin de là...). Je +ne me suis pas attaché à une traduction exacte du texte, +mais plutôt +à en faire une version française intelligible par tous +(et +par moi). Les termes techniques sont la plupart du temps +conservés sous leur forme originale et mis entre +parenthèses car vous pouvez les retrouver dans le reste des +documentations ainsi que dans les fichiers de configuration. +N’hésitez pas à me contacter afin d’améliorer ce +document VETSEL Patrice +(merci à JMM pour sa relecture et ses commentaires pertinents, +ainsi qu'à Tom EASTEP pour son formidable outil et sa +disponibilité)      .
      +
      +

      +

      Mettre en place un système Linux en tant que +firewall pour un petit réseau est une chose assez simple, si +vous comprenez les bases et suivez la documentation.

      +

      Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. +Il +se focalise sur ce qui est nécessaire pour configurer Shorewall, +dans son utilisation la plus courante :

        -
      • -

        Un système Linux utilisé - en tant que firewall/routeur pour un petit réseau local.

        -
        • -
      • -

        Une seule adresse IP publique.

        -
        • -
      • -

        Une connexion Internet par le biais d'un modem câble, ADSL, - ISDN, "Frame Relay", RTC ...

        -
        • - +
      • +

        Un système Linux +utilisé en tant que firewall/routeur pour un petit réseau +local.

        +
        • +
      • +

        Une seule adresse IP publique.

        +
        • +
      • +

        Une connexion Internet par le biais d'un modem câble, +ADSL, ISDN, "Frame Relay", RTC ...

        +
      -

      Voici un schéma d'une installation typique.

      -

      -

      - -

      Si vous faites tourner Shorewall sous Mandrake 9.0 ou plus récent, - vous pouvez facilement réaliser la configuration ci-dessus en utilisant - l'applet Mandrake "Internet Connection Sharing". Depuis le "Mandrake Control - Center", sélectionnez "Network & Internet" et "Connection Sharing". - Vous ne devriez pas avoir besoin de vous référer à -ce guide.

      - -

      Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. - Vous pouvez voir si le paquet est installé en vérifiant - la présence du programme ip sur votre système de firewall. + align="bottom" width="444" height="635" border="0">

      +

      Si vous faites tourner Shorewall sous Mandrake 9.0 ou plus +récent, vous pouvez facilement réaliser la configuration +ci-dessus en utilisant l'applet Mandrake "Internet Connection Sharing". +Depuis le "Mandrake Control Center", sélectionnez "Network & +Internet" et "Connection Sharing". Vous ne devriez pas avoir besoin de +vous référer à +ce guide.

      +

      Ce guide suppose que vous avez le paquet iproute/iproute2 +d'installé. Vous pouvez voir si le paquet est +installé en vérifiant la présence du programme ip +sur votre système de firewall. Sous root, utilisez la commande 'which' pour rechercher le programme :

      - 
           [root@gateway root]# which ip
           /sbin/ip
           [root@gateway root]#
      - -

      Je vous recommande dans un premier temps de parcourir tout le guide pour - vous familiariser avec ce qui va se passer, et de revenir au début - en effectuant le changements dans votre configuration. Les points où, - les changements dans la configuration sont recommandées, sont signalés - par une - .

      - +

      Je vous recommande dans un premier temps de parcourir tout le guide +pour vous familiariser avec ce qui va se passer, et de revenir au +début en effectuant le changements dans votre configuration. Les +points où, les changements dans la configuration sont +recommandées, sont signalés par une .

      -     Si vous éditez vos fichiers de configuration -sur un système Windows, vous devez les sauver comme des fichiers -Unix si votre éditeur offre cette option sinon vous devez les faire -passer par dos2unix avant d'essayer de les utiliser. De la même manière, - si vous copiez un fichier de configuration depuis votre disque dur Windows - vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser - avec Shorewall.

      - + width="60" height="60" border="0">     Si vous +éditez vos fichiers de configuration +sur un système Windows, vous devez les sauver comme des fichiers +Unix si votre éditeur offre cette option sinon vous devez les +faire +passer par dos2unix avant d'essayer de les utiliser. De la même +manière, si vous copiez un fichier de configuration depuis votre +disque dur Windows vers une disquette, vous devez lancer dos2unix sur +la copie avant de l'utiliser avec Shorewall.

      -

      Les Concepts de Shorewall

      -

      -     Les fichiers de configuration pour Shorewall sont dans - le répertoire /etc/shorewall -- pour de simples configurations, vous - n'aurez seulement à faire qu'avec quelques fichiers comme décrit - dans ce guide. Après avoir installé Shorewall, + width="13" height="13" border="0">     Les fichiers de +configuration pour Shorewall sont dans le répertoire +/etc/shorewall -- pour de simples configurations, vous n'aurez +seulement à faire qu'avec quelques fichiers comme décrit +dans ce guide. Après avoir installé +Shorewall, télé chargez le two-interface sample, -un-tarez le (tar -zxvf two-interfaces.tgz) et copiez les fichiers vers /etc/shorewall -(ces fichiers remplaceront les fichiers de même nom).

      - -

      Parallèlement à la présentation de chacun des fichiers, - je vous suggère de regarder le fichier qui se trouve réellement - sur votre système -- tous les fichiers contiennent des instructions - de configuration détaillées et des valeurs par défaut.

      - -

      Shorewall voit le réseau où il tourne, comme un ensemble - de zones. Dans une configuration avec deux interfaces, les noms des - zones suivantes sont utilisés:

      - + href="http://www1.shorewall.net/pub/shorewall/Samples/">two-interface +sample, un-tarez le (tar -zxvf two-interfaces.tgz) et copiez les +fichiers vers /etc/shorewall (ces fichiers remplaceront les fichiers de +même nom).

      +

      Parallèlement à la présentation de chacun des +fichiers, je vous suggère de regarder le fichier qui se trouve +réellement sur votre système -- tous les fichiers +contiennent des instructions de configuration détaillées +et des valeurs par défaut.

      +

      Shorewall voit le réseau où il tourne, comme un +ensemble de zones. Dans une configuration avec deux interfaces, +les noms des zones suivantes sont utilisés:

      + - - - + + - + - - - + + + - + - - - + + + - + - - - + + +
      +

      Nom

      -       		+

      Description

      -
      +

      net

      -       		+

      Internet

      -
      +

      loc

      -       		+

      Votre réseau local

      -
      -

      Les zones sont définies dans le fichier/etc/shorewall/zones .

      - -

      Shorewall reconnaît aussi le système de firewall comme sa - propre zone - par défaut, le firewall est connu comme fw.

      - -

      Les règles à propos de quel trafic autoriser, et de quel - trafic interdire sont exprimées en terme de zones.

      - +

      Shorewall reconnaît aussi le système de firewall comme +sa propre zone - par défaut, le firewall est connu comme fw.

      +

      Les règles à propos de quel trafic autoriser, et de +quel trafic interdire sont exprimées en terme de zones.

        -
      • -

        Vous exprimez votre politique par défaut - pour les connexions d'une zone vers une autre zone dans le fichier /etc/shorewall/policy .

        -
        • -
      • -

        Vous définissez les exceptions à ces politiques pas - défaut dans le fichier /etc/shorewall/rules - .

        -
        • - +
      • +

        Vous exprimez votre politique par +défaut pour les connexions d'une zone vers une autre zone dans +le fichier /etc/shorewall/policy . +

        +
        • +
      • +

        Vous définissez les exceptions à ces politiques +pas défaut dans le fichier /etc/shorewall/rules + .

        +
      - -

      Pour chaque connexion demandant à entrer dans le firewall, la requête - est en premier lieu comparée par rapport au fichier /etc/shorewall/rules. - Si aucune règle dans ce fichier ne correspond à la demande -de connexion alors la première politique dans le fichier /etc/shorewall/policy - qui y correspond sera appliquée. Si cette politique est REJECT ou -DROP  la requête est dans un premier temps comparée par +

      Pour chaque connexion demandant à entrer dans le firewall, la +requête est en premier lieu comparée par rapport au +fichier /etc/shorewall/rules. Si aucune règle dans ce fichier ne +correspond à la demande +de connexion alors la première politique dans le fichier +/etc/shorewall/policy qui y correspond sera appliquée. Si cette +politique est REJECT ou +DROP  la requête est dans un premier temps comparée +par rapport aux règles contenues dans /etc/shorewall/common.

      - -

      Le fichier /etc/shorewall/policy inclue dans l'archive d'exemple (two-interface) - a les politiques suivantes:

      - +

      Le fichier /etc/shorewall/policy inclue dans l'archive d'exemple +(two-interface) a les politiques suivantes:

      +
      -
      +
      - - - + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + - + - + - + - + - - - + + +
      +

      Source Zone

      -       		+

      Destination Zone

      -       		+

      Policy

      -       		+

      Log Level

      -       		+

      Limit:Burst

      -
      +

      loc

      -       		+

      net

      -       		+

      ACCEPT

      -       		+

       

      -       		+

       

      -
      +

      net

      -       		+

      all

      -       		+

      DROP

      -       		+

      info

      -       		+

       

      -
      +

      all

      -       		+

      all

      -       		+

      REJECT

      -       		+

      info

      -       		+

       

      -
      -
      +
      - -
      Dans le fichier d'exemple (two-interface), la ligne suivante -est inclue mais elle est commentée. Si vous voulez que votre firewall -puisse avoir un accès complet aux serveurs sur Internet, décommentez - la ligne.
      - +
      Dans le fichier d'exemple (two-interface), la ligne +suivante +est inclue mais elle est commentée. Si vous voulez que votre +firewall +puisse avoir un accès complet aux serveurs sur Internet, +décommentez la ligne.
      +
      -
      +
      - - - + + - + - + - + - + - - - + + + - + - + - + - + - - - + + +
      +

      Source Zone

      -       		+

      Destination Zone

      -       		+

      Policy

      -       		+

      Log Level

      -       		+

      Limit:Burst

      -
      +

      fw

      -       		+

      net

      -       		+

      ACCEPT

      -       		+

       

      -       		+

       

      -
      -
      +
      -

      Ces politiques vont:

      -
        -
      1. -

        permettre toutes les demandes de connexion - depuis votre réseau local vers l'Internet

        -
        2. -
      2. -

        drop (ou ignorer) toutes les demandes - de connexion depuis l'Internet vers votre firewall ou votre réseau - local.

        -
        3. -
      3. -

        Facultativement accepter toutes les - demandes de connexion de votre firewall vers l'Internet (si vous avez -dé commenté la politique additionnelle)

        -
        4. -
      4. -

        reject (rejeter) toutes les autres demandes de connexion.

        -
        5. - +
      5. +

        permettre toutes les demandes de +connexion depuis votre réseau local vers l'Internet

        +
        6. +
      6. +

        drop (ou ignorer) toutes les +demandes de connexion depuis l'Internet vers votre firewall ou votre +réseau local.

        +
        7. +
      7. +

        Facultativement accepter toutes +les demandes de connexion de votre firewall vers l'Internet (si vous +avez +dé commenté la politique additionnelle)

        +
        8. +
      8. +

        reject (rejeter) toutes les autres demandes de connexion.

        +
      -

      -     A ce point, éditez votre fichier /etc/shorewall/policy - et faite les changements que vous désirez.

      - + width="13" height="13" border="0">     A ce point, +éditez votre fichier /etc/shorewall/policy et faite les +changements que vous désirez.

      Network Interfaces

      -

      -

      - -

      Le firewall a deux interfaces de réseau. Lorsque la - connexion Internet passe par le câble ou par un ROUTEUR (pas un simple - modem) ADSL (non USB), l'interface vers l'extérieur (External -Interface) sera l'adaptateur sur lequel est connecté le routeur -(e.g., eth0)  à moins que vous ne vous connectiez -par Point-to-PointProtocol overEthernet -(PPPoE) ou par Point-to-PointTunnelingProtocol(PPTP), - dans ce cas l'interface extérieure sera une interface de type ppp - (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), votre - interface extérieure sera aussi ppp0. Si votre connexion passe - par Numéris (ISDN), votre interface extérieure seraippp0.

      - + align="bottom" width="444" height="635" border="0">

      +

      Le firewall a deux interfaces de réseau. Lorsque +la connexion Internet passe par le câble ou par un ROUTEUR (pas +un simple modem) ADSL (non USB), l'interface vers l'extérieur (External +Interface) sera l'adaptateur sur lequel est connecté le +routeur +(e.g., eth0)  à moins que vous ne vous +connectiez +par Point-to-PointProtocol overEthernet +(PPPoE) ou par Point-to-PointTunnelingProtocol(PPTP), +dans ce cas l'interface extérieure sera une interface de type +ppp (e.g., ppp0). Si vous vous connectez par un simple modem +(RTC), votre interface extérieure sera aussi ppp0. Si +votre connexion passe par Numéris (ISDN), votre interface +extérieure seraippp0.

      -     Si votre interface vers l'extérieur estppp0 - ou ippp0  alors vous mettrez CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

      - -

      Votre Internal Interface (interface vers votre réseau - local -> LAN) sera un adaptateur Ethernet (eth1 ou eth0) et sera connectée - à un hub ou switch (ou un PC avec un câble croisé). -Vos autres ordinateurs seront connectés à ce même hub/switch

      - + align="bottom" width="13" height="13" border="0">     +Si votre interface vers l'extérieur estppp0 ou ippp0  +alors vous mettrez CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

      +

      Votre Internal Interface (interface vers votre +réseau local -> LAN) sera un adaptateur Ethernet (eth1 ou +eth0) et sera connectée à un hub ou switch (ou un PC avec +un câble croisé). +Vos autres ordinateurs seront connectés à ce même +hub/switch

      - Ne connectez pas l'interface interne et externe sur le même - hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez - pas que ce soit shorewall qui ne marche pas.

      - + align="bottom" width="60" height="60" border="0"> Ne +connectez pas l'interface interne et externe sur le même hub ou +switch (même pour tester). Cela ne fonctionnera pas et ne croyez +pas que ce soit shorewall qui ne marche pas.

      -     Le fichier de configuration d'exemple pour deux interfaces - suppose que votre interface externe est eth0et que l'interne est -eth1. Si votre configuration est différente, vous devrez modifier -le fichier /etc/shorewall/interfaces -en conséquence. Tant que vous y êtes, vous pourriez parcourir -la liste des options qui sont spécifiées pour les interfaces. + align="left" width="13" height="13" border="0">     Le +fichier de configuration d'exemple pour deux interfaces suppose que +votre interface externe est eth0et que l'interne est +eth1. Si votre configuration est différente, vous devrez +modifier +le fichier /etc/shorewall/interfaces +en conséquence. Tant que vous y êtes, vous pourriez +parcourir +la liste des options qui sont spécifiées pour les +interfaces. Quelques trucs:

      -
        -
      • -

        Si votre interface vers l'extérieur est ppp0 - ou ippp0, vous pouvez remplacer le "detect" dans la seconde colonne - par un "-".

        -
        • -
      • -

        Si votre interface vers l'extérieur est ppp0 - ou ippp0 ou si vous avez une adresse IP statique, vous pouvez enlever - "dhcp" dans la liste des options.

        -
        • - +
      • +

        Si votre interface vers l'extérieur est ppp0 +ou ippp0, vous pouvez remplacer le "detect" dans la seconde +colonne par un "-".

        +
        • +
      • +

        Si votre interface vers l'extérieur est ppp0 +ou ippp0 ou si vous avez une adresse IP statique, vous pouvez +enlever "dhcp" dans la liste des options.

        +
      -

      Adresses IP

      - -

      Avant d'aller plus loin, nous devons dire quelques mots au - sujet de Internet Protocol (IP) addresses. Normalement, votre fournisseur - Internet (ISP) vous assignera une seule adresse IP (single PublicIP - address). Cette adresse peut être assignée par le Dynamic - Host Configuration Protocol(DHCP) ou lors de l'établissement de -votre connexion lorsque vous vous connectez (modem standard) ou établissez - votre connexion PPP. Dans de rares cas , votre provider peut vous assigner - une adresse statique (staticIP address); cela signifie que vous devez - configurer l'interface externe de votre firewall afin d'utiliser cette adresse - de manière permanente. Votre adresse externe assignée, elle - va être partagée par tous vos systèmes lors de l'accès - à Internet. Vous devrez assigner vos propres adresses dans votre réseau -local (votre interface interne sur le firewall  ainsi que les autres +

      Avant d'aller plus loin, nous devons dire quelques mots +au sujet de Internet Protocol (IP) addresses. Normalement, +votre fournisseur Internet (ISP) vous assignera une seule adresse IP +(single PublicIP address). Cette adresse peut être +assignée par le Dynamic Host Configuration Protocol(DHCP) +ou lors de l'établissement de +votre connexion lorsque vous vous connectez (modem standard) ou +établissez votre connexion PPP. Dans de rares cas , votre +provider peut vous assigner une adresse statique (staticIP +address); cela signifie que vous devez configurer l'interface externe +de votre firewall afin d'utiliser cette adresse de manière +permanente. Votre adresse externe assignée, elle va être +partagée par tous vos systèmes lors de l'accès +à Internet. Vous devrez assigner vos propres adresses dans votre +réseau +local (votre interface interne sur le firewall  ainsi que les +autres ordinateurs). La RFC 1918 réserve plusieurs plages d'IP (PrivateIP address ranges) à cette fin :

      - 
           10.0.0.0    - 10.255.255.255an
           172.16.0.0  - 172.31.255.255
           192.168.0.0 - 192.168.255.255
      -

      -     Avant de lancer Shorewall, vous devriez regarder l'adresse - IP de votre interface externe, et si elle est dans les plages précédentes, - vous devriez enlever l'option 'norfc1918' dans la ligne concernant l'interface - externe dans le fichier /etc/shorewall/interfaces.

      - -

      Vous devrez assigner vos adresses depuis le même sous-réseau - (sub-network/subnet). Pour ce faire, nous pouvons considérer - un sous-réseau dans une plage d'adresses x.y.z.0 - x.y.z.255. Chaque - sous-réseau aura un masque (Subnet Mask) de 255.255.255.0. -L'adresse x.y.z.0 est réservée comme l'adresse de sous-réseau -(Subnet Address) et x.y.z.255 est réservée en tant qu'adresse -de broadcast (Subnet Broadcast Address). Dans Shorewall, un + align="bottom" width="13" height="13" border="0">     +Avant de lancer Shorewall, vous devriez regarder l'adresse IP de votre +interface externe, et si elle est dans les plages +précédentes, vous devriez enlever l'option 'norfc1918' +dans la ligne concernant l'interface externe dans le fichier +/etc/shorewall/interfaces.

      +

      Vous devrez assigner vos adresses depuis le même +sous-réseau (sub-network/subnet). Pour ce faire, nous +pouvons considérer un sous-réseau dans une plage +d'adresses x.y.z.0 - x.y.z.255. Chaque sous-réseau aura un +masque (Subnet Mask) de 255.255.255.0. +L'adresse x.y.z.0 est réservée comme l'adresse de +sous-réseau +(Subnet Address) et x.y.z.255 est réservée en +tant qu'adresse +de broadcast (Subnet Broadcast Address). Dans Shorewall, +un sous-réseau est décrit en utilisant la notation Classless InterDomain - Routing (CIDR) qui consiste en l'adresse du sous-réseau suivie - par "/24". Le "24" se réfère au nombre consécutif de - bits marquant "1" dans la partie gauche du masque de sous-réseau.

      - + href="shorewall_setup_guide.htm#Subnets">la notation Classless +InterDomain Routing (CIDR) qui consiste en l'adresse du +sous-réseau suivie par "/24". Le "24" se réfère au +nombre consécutif de bits marquant "1" dans la partie gauche du +masque de sous-réseau.

      Un exemple de sous-réseau (sub-network) :

      - +
      -
      +
      - - - + + - + - - - + + + - + - - - + + + - + - - - + + + - + - - - + + +
      +

      Plage:

      -       		+

      10.10.10.0 - 10.10.10.255

      -
      +

      Subnet Address:

      -       		+

      10.10.10.0

      -
      +

      Broadcast Address:

      -       		+

      10.10.10.255

      -
      +

      CIDR Notation:

      -       		+

      10.10.10.0/24

      -
      -
      +
      - -

      Il est de mise d'assigner l'interface interne (LAN) à - la première adresse utilisable du sous-réseau (10.10.10.1 -dans l'exemple précédent) ou la dernière adresse utilisable - (10.10.10.254).

      - -

      L'un des buts d'un sous-réseau est de permettre à - tous les ordinateurs dans le sous-réseau de savoir avec quels autres - ordinateurs ils peuvent communiquer directement. Pour communiquer avec des - systèmes en dehors du sous-réseau, les ordinateurs envoient - des paquets à travers le gateway (routeur).

      - +

      Il est de mise d'assigner l'interface interne (LAN) +à la première adresse utilisable du sous-réseau +(10.10.10.1 +dans l'exemple précédent) ou la dernière adresse +utilisable (10.10.10.254).

      +

      L'un des buts d'un sous-réseau est de permettre +à tous les ordinateurs dans le sous-réseau de savoir avec +quels autres ordinateurs ils peuvent communiquer directement. Pour +communiquer avec des systèmes en dehors du sous-réseau, +les ordinateurs envoient des paquets à travers le gateway +(routeur).

      -     Vos ordinateurs en local (ordinateur 1 et ordinateur -2 dans le diagramme) devraient être configurés avec leur passerelle - par défaut (default gateway) pointant sur l'adresse IP de l'interface + align="bottom" width="13" height="13" border="0">     +Vos ordinateurs en local (ordinateur 1 et ordinateur 2 dans le +diagramme) devraient être configurés avec leur passerelle +par défaut (default gateway) pointant sur l'adresse IP de +l'interface interne du firewall.

      - -

      The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning more -about IP addressing and routing, I highly recommend "IP Fundamentals: -What Everyone Needs to Know about Addressing & Routing", Thomas A. +

      The foregoing short discussion barely scratches the +surface regarding subnetting and routing. If you are interested in +learning more +about IP addressing and routing, I highly recommend "IP +Fundamentals: +What Everyone Needs to Know about Addressing & Routing", Thomas +A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

      - -

      Le reste de ce guide assumera que vous avez configuré - votre réseau comme montré ci-dessous :

      - +

      Le reste de ce guide assumera que vous avez +configuré votre réseau comme montré ci-dessous :

      -

      - -

      La passerelle par défaut pour les ordinateurs 1 et - 2 devrait être 10.10.10.254.

      - + align="bottom" width="444" height="635" border="0">

      +

      La passerelle par défaut pour les ordinateurs 1 +et 2 devrait être 10.10.10.254.

      IP Masquerading (SNAT)

      - -

      Les adresses réservées par la RFC 1918 sont - parfois désignées comme non-routables car les routeurs - Internet (backbone) ne font pas circuler les paquets qui ont une adresse -de destination appartenant à la RFC-1918. Lorsqu'un de vos systèmes - en local (supposons l'ordinateur1) demande une connexion à un serveur - par Internet, le firewall doit appliquer un NAT (Network Address Translation). - Le firewall ré écrit l'adresse source dans le paquet, et l'a - remplace par l'adresse de l'interface externe du firewall; en d'autres mots, - le firewall fait croire que c'est lui même qui initie la connexion. - Ceci est nécessaire afin que l'hôte de destination soit capable - de renvoyer les paquets au firewall (souvenez vous que les paquets qui ont - pour adresse de destination, une adresse réservée par la RFC - 1918 ne pourront pas être routés à travers Internet, -donc l'hôte Internet ne pourra adresser sa réponse à -l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, -il remet l'adresse de destination à 10.10.10.1 et fait passer le paquet +

      Les adresses réservées par la RFC 1918 +sont parfois désignées comme non-routables car +les routeurs Internet (backbone) ne font pas circuler les paquets qui +ont une adresse +de destination appartenant à la RFC-1918. Lorsqu'un de vos +systèmes en local (supposons l'ordinateur1) demande une +connexion à un serveur par Internet, le firewall doit appliquer +un NAT (Network Address Translation). Le firewall ré +écrit l'adresse source dans le paquet, et l'a remplace par +l'adresse de l'interface externe du firewall; en d'autres mots, le +firewall fait croire que c'est lui même qui initie la connexion. +Ceci est nécessaire afin que l'hôte de destination soit +capable de renvoyer les paquets au firewall (souvenez vous que les +paquets qui ont pour adresse de destination, une adresse +réservée par la RFC 1918 ne pourront pas être +routés à travers Internet, +donc l'hôte Internet ne pourra adresser sa réponse +à +l'ordinateur 1). Lorsque le firewall reçoit le paquet de +réponse, +il remet l'adresse de destination à 10.10.10.1 et fait passer le +paquet vers l'ordinateur 1.

      - -

      Sur les systèmes Linux, ce procédé est - souvent appelé de l'IP Masquerading mais vous verrez aussi -le terme de Source Network Address Translation (SNAT) utilisé. - Shorewall suit la convention utilisée avec Netfilter:

      - +

      Sur les systèmes Linux, ce procédé +est souvent appelé de l'IP Masquerading mais vous verrez +aussi +le terme de Source Network Address Translation (SNAT) +utilisé. Shorewall suit la convention utilisée avec +Netfilter:

        -
      • -

        Masquerade désigne le cas ou vous laissez - votre firewall détecter automatiquement l'adresse de l'interface -externe.

        -
        • -
      • -

        SNAT désigne le cas où vous spécifiez - explicitement l'adresse source des paquets sortant de votre réseau - local.

        -
        • - +
      • +

        Masquerade désigne le cas ou vous +laissez votre firewall détecter automatiquement l'adresse de +l'interface +externe.

        +
        • +
      • +

        SNAT désigne le cas où vous +spécifiez explicitement l'adresse source des paquets sortant de +votre réseau local.

        +
      - -

      Sous Shorewall, autant le Masquerading que le SNAT sont configuré - avec des entrés dans le fichier /etc/shorewall/masq. Vous utiliserez - normalement le Masquerading si votre adresse IP externe est dynamique, et - SNAT si elle est statique.

      - +

      Sous Shorewall, autant le Masquerading que le SNAT sont +configuré avec des entrés dans le fichier +/etc/shorewall/masq. Vous utiliserez normalement le Masquerading si +votre adresse IP externe est dynamique, et SNAT si elle est statique.

      -     Si votre interface externe du firewall est eth0, - vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. Dans - le cas contraire, éditez /etc/shorewall/masq et changez la première - colonne par le nom de votre interface externe, et la seconde colonne par + align="bottom" width="13" height="13" border="0">     +Si votre interface externe du firewall est eth0, vous n'avez +pas besoin de modifier le fichier fourni avec l'exemple. Dans le cas +contraire, éditez /etc/shorewall/masq et changez la +première colonne par le nom de votre interface externe, et la +seconde colonne par le nom de votre interface interne.

      -

      -     Si votre IP externe est statique, vous pouvez la mettre - dans la troisième colonne dans /etc/shorewall/masq si vous le désirez, - de toutes façons votre firewall fonctionnera bien si vous laissez -cette colonne vide. Le fait de mettre votre IP statique dans la troisième - colonne permet un traitement des paquets sortant un peu plus efficace.
      -
      - -     Si vous utilisez les paquets Debian, vérifiez -que votre fichier de configuration shorewall.conf contient bien les valeurs -suivantes, si elles n'y sont pas faite les changements nécessaires:

      - + align="bottom" width="13" height="13" border="0">     +Si votre IP externe est statique, vous pouvez la mettre dans la +troisième colonne dans /etc/shorewall/masq si vous le +désirez, de toutes façons votre firewall fonctionnera +bien si vous laissez +cette colonne vide. Le fait de mettre votre IP statique dans la +troisième colonne permet un traitement des paquets sortant un +peu plus efficace.
      +
      +     Si vous utilisez les +paquets Debian, vérifiez que votre fichier de configuration +shorewall.conf contient bien les valeurs suivantes, si elles n'y sont +pas faite les changements nécessaires:

        -
      • -

        NAT_ENABLED=Yes

        -
        • -
      • +
      • +

        NAT_ENABLED=Yes

        +
        • +

      • IP_FORWARDING=On

        -
        • - +
      -

      Port Forwarding (DNAT)

      - -

      Un de nos buts est de , peut être, faire tourner un - ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces ordinateurs - on une adresse RFC-1918, il n' est pas possible pour les clients sur Internet - de se connecter directement à eux. Il est nécessaire à - ces clients d'adresser leurs demandes de connexion au firewall qui ré - écrit l'adresse de destination de votre serveur, et fait passer le - paquet à celui-ci. Lorsque votre serveur répond, le firewall - applique automatiquement un SNAT pour ré écrire l'adresse -source dans la réponse.

      - -

      Ce procédé est appelé Port Forwarding - ou Destination Network Address Translation(DNAT). Vous configurez -le port forwarding en utilisant les règles DNAT dans le fichier /etc/shorewall/rules.

      - -

      La forme générale d'une simple règle de port forwarding - dans /etc/shorewall/rules est:

      - +

      Un de nos buts est de , peut être, faire tourner +un ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces +ordinateurs on une adresse RFC-1918, il n' est pas possible pour les +clients sur Internet de se connecter directement à eux. Il est +nécessaire à ces clients d'adresser leurs demandes de +connexion au firewall qui ré écrit l'adresse de +destination de votre serveur, et fait passer le paquet à +celui-ci. Lorsque votre serveur répond, le firewall applique +automatiquement un SNAT pour ré écrire l'adresse +source dans la réponse.

      +

      Ce procédé est appelé Port +Forwarding ou Destination Network Address Translation(DNAT). +Vous configurez +le port forwarding en utilisant les règles DNAT dans le fichier +/etc/shorewall/rules.

      +

      La forme générale d'une simple règle de port +forwarding dans /etc/shorewall/rules est:

      +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - - + + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      DNAT

      -       		+

      net

      -       		-

      loc:<server local ip address> [:<server port>]

      -       		+ +

      loc:<server local ip address> [:<server +port>]

      +

      <protocol>

      -       		+

      <port>

      -       		+

       

      -       		+

       

      -
      -
      +
      - -

      Exemple - vous faites tourner un serveur Web sur l'ordinateur 2 et vous - voulez faire passer les requêtes TCP sur le port 80 à ce système - :

      - +

      Exemple - vous faites tourner un serveur Web sur l'ordinateur 2 et +vous voulez faire passer les requêtes TCP sur le port 80 à +ce système :

      +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      DNAT

      -       		+

      net

      -       		+

      loc:10.10.10.2

      -       		+

      tcp

      -       		+

      80

      -       		+

       

      -       		+

       

      -
      -
      +
      -

      Deux points importants à garder en mémoire :

      -
        -
      • -

        Vous devez tester la règle précédente - depuis un client à l'extérieur de votre réseau local - (c.a.d., ne pas tester depuis un navigateur tournant sur l'ordinateur 1 -ou 2 ou sur le firewall). Si vous voulez avoir la possibilité d'accéder - à votre serveur web en utilisant l'adresse IP externe de votre firewall, - regardez Shorewall FAQ #2.

        -
        • -
      • -

        Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes - entrantes de connexion sur le port 80. Si vous avez des problèmes - à vous connecter à votre serveur web, essayez la règle - suivante et connectez vous sur le port 5000.

        -
        • - +
      • +

        Vous devez tester la règle +précédente depuis un client à l'extérieur +de votre réseau local (c.a.d., ne pas tester depuis un +navigateur tournant sur l'ordinateur 1 +ou 2 ou sur le firewall). Si vous voulez avoir la possibilité +d'accéder à votre serveur web en utilisant l'adresse IP +externe de votre firewall, regardez Shorewall +FAQ #2.

        +
        • +
      • +

        Quelques fournisseurs Internet (Provider/ISP) bloquent les +requêtes entrantes de connexion sur le port 80. Si vous avez des +problèmes à vous connecter à votre serveur web, +essayez la règle suivante et connectez vous sur le port 5000.

        +
      - +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      DNAT

      -       		+

      net

      -       		+

      loc:10.10.10.2:80

      -       		+

      tcp

      -       		+

      5000

      -       		+

       

      -       		+

       

      -
      -
      +
      -

      -     A ce point, modifiez /etc/shorewall/rules pour ajouter - les règles DNAT dont vous avez besoin.

      - + width="13" height="13" border="0">     A ce point, +modifiez /etc/shorewall/rules pour ajouter les règles DNAT dont +vous avez besoin.

      Domain Name Server (DNS)

      - -

      Normalement, quand vous vous connectez à votre fournisseur - (ISP), une partie consiste à obtenir votre adresse IP, votre DNS -pour le firewall (Domain Name Service) est configuré automatiquement - (c.a.d.,le fichier /etc/resolv.conf a été écrit). Il - arrive que votre provider vous donne une paire d'adresse IP pour les DNS - (name servers) afin que vous configuriez manuellement votre serveur -de nom primaire et secondaire. La manière dont le DNS est configuré - sur votre firewall est de votre responsabilité. Vous pouvez - procéder d'une de ses deux façons :

      - +

      Normalement, quand vous vous connectez à votre +fournisseur (ISP), une partie consiste à obtenir votre adresse +IP, votre DNS +pour le firewall (Domain Name Service) est configuré +automatiquement (c.a.d.,le fichier /etc/resolv.conf a été +écrit). Il arrive que votre provider vous donne une paire +d'adresse IP pour les DNS (name servers) afin que vous +configuriez manuellement votre serveur +de nom primaire et secondaire. La manière dont le DNS est +configuré sur votre firewall est de votre +responsabilité. Vous pouvez procéder d'une de ses deux +façons :

        -
      • -

        Vous pouvez configurer votre système interne -pour utiliser les noms de serveurs de votre provider. Si votre fournisseur -vous donne les adresses de leurs serveurs ou si ces adresses sont disponibles - sur leur site web, vous pouvez configurer votre système interne -afin de les utiliser. Si cette information n' est pas disponible, regardez -dans /etc/resolv.conf sur votre firewall -- les noms des serveurs sont - donnés dans l'enregistrement "nameserver" dans ce fichier.

        -
        • -
      • +
      • +

        Vous pouvez configurer votre système interne +pour utiliser les noms de serveurs de votre provider. Si votre +fournisseur +vous donne les adresses de leurs serveurs ou si ces adresses sont +disponibles sur leur site web, vous pouvez configurer votre +système interne +afin de les utiliser. Si cette information n' est pas disponible, +regardez +dans /etc/resolv.conf sur votre firewall -- les noms des serveurs sont +donnés dans l'enregistrement "nameserver" dans ce fichier.

        +
        • +

      • -     Vous pouvez configurer un cache dns (Caching Name - Server) sur votre firewall. Red Hat a un RPM pour mettre en -cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les -utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, -vous configurez votre système interne pour utiliser le firewall -lui même comme étant le seul serveur de nom primaire. Vous -pouvez utiliser l'adresse IP interne du firewall (10.10.10.254 dans l'exemple) -pour l'adresse de serveur de nom. Pour permettre à vos systèmes -locaux de discuter avec votre serveur cache de nom, vous devez ouvrir le -port 53 (UDP ET  TCP) sur le firewall vers le réseau local; -vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules. -

        -
        • - + align="bottom" width="13" height="13" border="0">     +Vous pouvez configurer un cache dns (Caching Name Server) sur +votre firewall. Red Hat a un RPM pour mettre en +cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les +utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette +approche, +vous configurez votre système interne pour utiliser le firewall +lui même comme étant le seul serveur de nom primaire. Vous +pouvez utiliser l'adresse IP interne du firewall (10.10.10.254 dans +l'exemple) +pour l'adresse de serveur de nom. Pour permettre à vos +systèmes +locaux de discuter avec votre serveur cache de nom, vous devez ouvrir +le +port 53 (UDP ET  TCP) sur le firewall vers le réseau local; +vous ferez ceci en ajoutant les règles suivantes dans +/etc/shorewall/rules.

        +
      - +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      ACCEPT

      -       		+

      loc

      -       		+

      fw

      -       		+

      tcp

      -       		+

      53

      -       		+

       

      -       		+

       

      -
      +

      ACCEPT

      -       		+

      loc

      -       		+

      fw

      -       		+

      udp

      -       		+

      53

      -       		+

       

      -       		+

       

      -
      -
      +
      -

      Autres Connexions

      - -

      Les fichiers exemples inclus dans l'archive (two-interface) - contiennent les règles suivantes :

      - +

      Les fichiers exemples inclus dans l'archive +(two-interface) contiennent les règles suivantes :

      +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      ACCEPT

      -       		+

      fw

      -       		+

      net

      -       		+

      tcp

      -       		+

      53

      -       		+

       

      -       		+

       

      -
      +

      ACCEPT

      -       		+

      fw

      -       		+

      net

      -       		+

      udp

      -       		+

      53

      -       		+

       

      -       		+

       

      -
      -
      +
      - -

      Ces règles autorisent l'accès DNS à -partir de votre firewall et peuvent être enlevées si vous avez -dé commenté la ligne dans /etc/shorewall/policy autorisant +

      Ces règles autorisent l'accès DNS +à +partir de votre firewall et peuvent être enlevées si vous +avez +dé commenté la ligne dans /etc/shorewall/policy +autorisant toutes les connexions depuis le firewall vers Internet.

      -

      Les exemples contiennent aussi :

      - +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      ACCEPT

      -       		+

      loc

      -       		+

      fw

      -       		+

      tcp

      -       		+

      22

      -       		+

       

      -       		+

       

      -
      -
      +
      - -

      Cette règle vous autorise à faire tourner un - serveur SSH sur votre firewall et à vous y connecter depuis votre +

      Cette règle vous autorise à faire tourner +un serveur SSH sur votre firewall et à vous y connecter depuis +votre réseau local.

      - -

      Si vous voulez permettre d'autres connexions entre votre -firewall et d'autres systèmes, la forme générale est +

      Si vous voulez permettre d'autres connexions entre +votre +firewall et d'autres systèmes, la forme générale +est :

      - +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      ACCEPT

      -       		+

      <source zone>

      -       		+

      <destination zone>

      -       		+

      <protocol>

      -       		+

      <port>

      -       		+

       

      -       		+

       

      -
      -
      +
      - -

      Exemple - Vous voulez faire tourner un serveur Web sur votre - firewall :

      - +

      Exemple - Vous voulez faire tourner un serveur Web sur +votre firewall :

      +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      ACCEPT

      -       		+

      net

      -       		+

      fw

      -       		+

      tcp

      -       		+

      80

      -       		+

      #Permet l'accès Web

      -       		+

      depuis Internet

      -
      +

      ACCEPT

      -       		+

      loc

      -       		+

      fw

      -       		+

      tcp

      -       		+

      80

      -       		+

      #Permet l'accès Web

      -
      -       		+
      +

      depuis Internet

      -
      -
      +
      - -

      Ces deux règles bien sûr viennent s'ajouter -aux règles décrites précédemment dans "Vous pouvez - configurer un cache dns (Caching Name Server) sur votre firewall"

      - -

      Si vous ne savez pas quel port et quel protocole une application - particulière utilise, regardez ici.

      - -

      Important: Je ne vous recommande pas de permettre -le telnet depuis ou vers Internet car il utilise du texte en clair (même - pour le login et le mot de passe!). Si vous voulez un accès au shell - sur votre firewall depuis Internet, utilisez SSH :

      - +

      Ces deux règles bien sûr viennent +s'ajouter +aux règles décrites précédemment dans "Vous +pouvez configurer un cache dns (Caching Name Server) sur votre +firewall"

      +

      Si vous ne savez pas quel port et quel protocole une +application particulière utilise, regardez ici.

      +

      Important: Je ne vous recommande pas de +permettre +le telnet depuis ou vers Internet car il utilise du texte en clair +(même pour le login et le mot de passe!). Si vous voulez un +accès au shell sur votre firewall depuis Internet, utilisez SSH :

      +
      -
      +
      - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + +
      +

      ACTION

      -       		+

      SOURCE

      -       		+

      DESTINATION

      -       		+

      PROTOCOL

      -       		+

      PORT

      -       		+

      SOURCE PORT

      -       		+

      ORIGINAL ADDRESS

      -
      +

      ACCEPT

      -       		+

      net

      -       		+

      fw

      -       		+

      tcp

      -       		+

      22

      -       		+

       

      -       		+

       

      -
      -
      +
      -

      -     Maintenant éditez votre fichier /etc/shorewall/rules - pour ajouter ou supprimer les connexions voulues.

      - + align="bottom" width="13" height="13" border="0">     +Maintenant éditez votre fichier /etc/shorewall/rules pour +ajouter ou supprimer les connexions voulues.

      Lancer et Arrêter votre Firewall

      -

      Arrow -     La  procédure d'installation - configure votre système pour lancer Shorewall au boot du système, - mais pour les débutants sous Shorewall version 1.3.9, le lancement - est désactivé tant que la configuration n' est pas finie. -Une fois la configuration de votre firewall achevée, vous pouvez -permettre le lancement de Shorewall en enlevant le fichier /etc/shorewall/startup_disabled.

      - -

      IMPORTANT: Les utilisateurs -des paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.

      - -

      Le firewall est lancé en utilisant la commande "shorewall - start" et stoppé avec "shorewall stop". Lorsque le firewall est stoppé, - le routage est permis sur les hôtes qui sont dans le fichier/etc/shorewall/routestopped. Un - firewall fonctionnant peut être relancé en utilisant la commande - "shorewall restart". Si vous voulez enlever toutes les traces de Shorewall - dans votre configuration de Netfilter, utilisez "shorewall clear".

      - +    La  procédure +d'installation configure votre système pour lancer Shorewall +au boot du système, mais pour les débutants sous +Shorewall version 1.3.9, le lancement est désactivé tant +que la configuration n' est pas finie. +Une fois la configuration de votre firewall achevée, vous pouvez +permettre le lancement de Shorewall en enlevant le fichier +/etc/shorewall/startup_disabled.

      +

      IMPORTANT: Les +utilisateurs +des paquets .deb doivent éditer /etc/default/shorewall et mettre +'startup=1'.

      +

      Le firewall est lancé en utilisant la commande +"shorewall start" et stoppé avec "shorewall stop". Lorsque le +firewall est stoppé, le routage est permis sur les hôtes +qui sont dans le fichier/etc/shorewall/routestopped. +Un firewall fonctionnant peut être relancé en utilisant la +commande "shorewall restart". Si vous voulez enlever toutes les traces +de Shorewall dans votre configuration de Netfilter, utilisez "shorewall +clear".

      -     Les exemples (two-interface) supposent que vous voulez - permettre le routage depuis ou vers eth1 (le réseau local) -lorsque Shorewall est stoppé. Si votre réseau local n' est -pas connecté à eth1 ou si vous voulez permettre l'accès -depuis ou vers d'autres hôtes, changez /etc/shorewall/routestopped + align="bottom" width="13" height="13" border="0">     +Les exemples (two-interface) supposent que vous voulez permettre le +routage depuis ou vers eth1 (le réseau local) +lorsque Shorewall est stoppé. Si votre réseau local n' +est +pas connecté à eth1 ou si vous voulez permettre +l'accès +depuis ou vers d'autres hôtes, changez +/etc/shorewall/routestopped en conséquence.

      - -

      ATTENTION: Si vous êtes connecté à - votre firewall depuis Internet, n'essayez pas la commande "shorewall stop" - tant que vous n'avez pas ajouté une entrée pour votre adresse - IP depuis laquelle vous êtes connecté dans/etc/shorewall/routestopped. De - plus, je ne vous recommande pas d'utiliser "shorewall restart"; il est mieux - de créer une configuration - alternative et de l'essayer en utilisant la commandeATTENTION: Si vous êtes connecté +à votre firewall depuis Internet, n'essayez pas la commande +"shorewall stop" tant que vous n'avez pas ajouté une +entrée pour votre adresse IP depuis laquelle vous êtes +connecté dans/etc/shorewall/routestopped. +De plus, je ne vous recommande pas d'utiliser "shorewall restart"; il +est mieux de créer une configuration +alternative et de l'essayer en utilisant la commande"shorewall try".

      -

      Last updated 12/20/2002 - Tom Eastep

      - -

      Copyright 2002 Thomas - M. Eastep

      -
      -
      -
      -
      -
      -
      -
      -
      -
      -
      +

      Copyright 2002 +Thomas M. Eastep

      +
      +
      +
      +
      +
      +
      +
      +
      +
      +
      diff --git a/Shorewall-docs/upgrade_issues.htm b/Shorewall-docs/upgrade_issues.htm index 3d7fe7683..32cf343ff 100755 --- a/Shorewall-docs/upgrade_issues.htm +++ b/Shorewall-docs/upgrade_issues.htm @@ -1,471 +1,378 @@ - Upgrade Issues - - - - - - - - - - - - -
      - -

      Upgrade Issues

      -
      - -

      For upgrade instructions see the Install/Upgrade page.
      -

      - -

      It is important that you read all of the sections on this page where the - version number mentioned in the section title is later than what you - are currently running.
      -

      - -

      In the descriptions that follows, the term group refers - to a particular network or subnetwork (which may be 0.0.0.0/0 or it may - be a host address) accessed through a particular interface.
      -

      - + +

      Upgrade Issues
      +

      +

      For upgrade instructions see the Install/Upgrade +page.
      +

      +

      It is important that you read all of the sections on this page where +the version number mentioned in the section title is later than what +you are currently running.
      +

      +

      In the descriptions that follows, the term group refers +to a particular network or subnetwork (which may be 0.0.0.0/0 or it may +be a host address) accessed through a particular interface.
      +

      Examples:
      -    
      -     eth0:0.0.0.0/0
      -     eth2:192.168.1.0/24
      -     eth3:192.0.2.123
      -

      - -

      You can use the "shorewall check" command to see the groups associated - with each of your zones.
      -

      - +   
      +    eth0:0.0.0.0/0
      +    eth2:192.168.1.0/24
      +    eth3:192.0.2.123
      +

      +

      You can use the "shorewall check" command to see the groups +associated with each of your zones.
      +

      - +

      Version >= 1.4.8

      +
        +
      • The meaning of ROUTE_FILTER=Yes has changed. Previously this +setting was documented as causing route filtering to occur on all +network interfaces; this didn't work. Beginning with this release, +ROUTE_FILTER=Yes causes route filtering to occur on all interfaces +brought up while Shorewall is running. This means that it may be +appropriate to set ROUTE_FILTER=Yes and use the routefilter +option in /etc/shorewall/interfaces +entries.
        +
        • +

      Version >= 1.4.6

      -
        -
      • The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed -from shorewall.conf. These capabilities are now automatically detected by -Shorewall.
        • -
      • An undocumented feature previously allowed entries in the host -file as follows:
        -
        - zone    eth1:192.168.1.0/24,eth2:192.168.2.0/24
        -
        - This capability was never documented and has been removed in 1.4.6 to allow -entries of the following format:
        -
        - zone   eth1:192.168.1.0/24,192.168.2.0/24
        -
        • - -
      - -

      Version >= 1.4.4

      - If you are upgrading from 1.4.3 and have set the LOGMARKER variable -in /etc/shorewall/shorewall.conf, then -you must set the new LOGFORMAT variable appropriately and remove your setting - of LOGMARKER
      +
    • The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from shorewall.conf. These capabilities are now automatically +detected by Shorewall.
      • +
    • An undocumented feature previously allowed entries in the +host file as follows:

      - + zone    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      +This capability was never documented and has been removed in 1.4.6 to +allow entries of the following format:
      +
      + zone   eth1:192.168.1.0/24,192.168.2.0/24
      +
      • +

    +

    Version >= 1.4.4

    +If you are upgrading from 1.4.3 and have set the LOGMARKER variable +in /etc/shorewall/shorewall.conf, +then you must set the new LOGFORMAT variable appropriately and remove +your setting of LOGMARKER
    +

    Version 1.4.4
    -

    - If you have zone names that are 5 characters long, you may experience -problems starting Shorewall because the --log-prefix in a logging rule -is too long. Upgrade to Version 1.4.4a to fix this problem..
    - + +If you have zone names that are 5 characters long, you may experience +problems starting Shorewall because the --log-prefix in a logging rule +is too long. Upgrade to Version 1.4.4a to fix this problem..

    Version >= 1.4.2

    - There are some cases where you may want to handle traffic from a particular - group to itself. While I personally think that such a setups are ridiculous, - there are two cases covered in this documentation where it can occur:
    - +There are some cases where you may want to handle traffic from a +particular group to itself. While I personally think that such a setups +are ridiculous, there are two cases covered in this documentation where +it can occur:
      -
    1. In FAQ #2.
      2. -
    2. When running Squid as a -transparent proxy in your local zone.
      3. - +
    3. In FAQ #2.
      4. +
    4. When running Squid as a +transparent proxy in your local zone.
    - If you have either of these cases, you will want to review the current - documentation and change your configuration accordingly.
    - +If you have either of these cases, you will want to review the current +documentation and change your configuration accordingly.

    Version >= 1.4.1

    -
      -
    • Beginning with Version 1.4.1, traffic between groups in -the same zone is accepted by default. Previously, traffic from a zone -to itself was treated just like any other traffic; any matching rules -were applied followed by enforcement of the appropriate policy. With 1.4.1 -and later versions, unless you have explicit rules for traffic from Z -to Z or you have an explicit Z to Z policy (where "Z" is some zone) then -traffic between the groups in zone Z will be accepted. If you do have one -or more explicit rules for Z to Z or if you have an explicit Z to Z policy -then the behavior is as it was in prior versions.
      • - +
    • Beginning with Version 1.4.1, traffic between groups in +the same zone is accepted by default. Previously, traffic from a zone +to itself was treated just like any other traffic; any matching rules +were applied followed by enforcement of the appropriate policy. With +1.4.1 +and later versions, unless you have explicit rules for traffic from Z +to Z or you have an explicit Z to Z policy (where "Z" is some zone) +then +traffic between the groups in zone Z will be accepted. If you do have +one +or more explicit rules for Z to Z or if you have an explicit Z to Z +policy +then the behavior is as it was in prior versions.
    - -
    +
      -
    1. If you have a Z Z ACCEPT policy for a zone to allow traffic - between two interfaces to the same zone, that policy can be removed -and traffic between the interfaces will traverse fewer rules than previously.
      2. -
    2. If you have a Z Z DROP or Z Z REJECT policy or you have - Z->Z rules then your configuration should not require any change.
      3. -
    3. If you are currently relying on a implicit policy (one -that has "all" in either the SOURCE or DESTINATION column) to prevent -traffic between two interfaces to a zone Z and you have no rules for -Z->Z then you should add an explicit DROP or REJECT policy for Z to +
    4. If you have a Z Z ACCEPT policy for a zone to allow traffic +between two interfaces to the same zone, that policy can be removed +and traffic between the interfaces will traverse fewer rules than +previously.
      5. +
    5. If you have a Z Z DROP or Z Z REJECT policy or you have Z->Z +rules then your configuration should not require any change.
      6. +
    6. If you are currently relying on a implicit policy (one +that has "all" in either the SOURCE or DESTINATION column) to prevent +traffic between two interfaces to a zone Z and you have no rules for +Z->Z then you should add an explicit DROP or REJECT policy for Z to Z.
      -
      7. - +
    -
    - +
      -
    • Sometimes, you want two separate zones on one interface but - you don't want Shorewall to set up any infrastructure to handle traffic - between them.
      • - +
    • Sometimes, you want two separate zones on one interface but you +don't want Shorewall to set up any infrastructure to handle traffic +between them.
    -
    Example:
    - -
    + 
    /etc/shorewall/zones

    z1	Zone1	The first Zone
    z2	Zone2	The secont Zone

    /etc/shorewall/interfaces

    z2	eth1	192.168.1.255

    /etc/shorewall/hosts

    z1	eth1:192.168.1.3
    -
    - Here, zone z1 is nested in zone z2 and the firewall is not going - to be involved in any traffic between these two zones. Beginning with -Shorewall 1.4.1, you can prevent Shorewall from setting up any infrastructure -to handle traffic between z1 and z2 by using the new NONE policy:
    - -
    +
    +Here, zone z1 is nested in zone z2 and the firewall is not going to be +involved in any traffic between these two zones. Beginning with +Shorewall 1.4.1, you can prevent Shorewall from setting up any +infrastructure +to handle traffic between z1 and z2 by using the new NONE policy:
    + 
    /etc/shorewall/policy
    z1	z2	NONE
    z2	z1	NONE
    -
    - Note that NONE policies are generally used in pairs unless there - is asymetric routing where only the traffic on one direction flows through - the firewall and you are using a NONE polciy in the other direction. 
    - +
    +Note that NONE policies are generally used in pairs unless there is +asymetric routing where only the traffic on one direction flows through +the firewall and you are using a NONE polciy in the other +direction. 

    Version 1.4.1
    -

    - +
      -
    • In Version 1.4.1, Shorewall will never create rules to - deal with traffic from a given group back to itself. The multi - interface option is no longer available so if you want to route traffic -between two subnetworks on the same interface then I recommend that you -upgrade to Version 1.4.2 and use the 'routeback' interface or host option. 
      • - +
    • In Version 1.4.1, Shorewall will never create rules to deal with +traffic from a given group back to itself. The multi interface +option is no longer available so if you want to route traffic between +two subnetworks on the same interface then I recommend that you upgrade +to Version 1.4.2 and use the 'routeback' interface or host option. 
    -

    Version >= 1.4.0

    - IMPORTANT: Shorewall >=1.4.0 requires the - iproute package ('ip' utility).
    -
    - Note: Unfortunately, some distributions call this package - iproute2 which will cause the upgrade of Shorewall to fail with the +IMPORTANT: Shorewall >=1.4.0 requires the iproute +package ('ip' utility).
    +
    +Note: Unfortunately, some distributions call this package +iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:
    -
    -      error: failed dependencies:iproute is needed by shorewall-1.4.0-1 -
    -
    - This may be worked around by using the --nodeps option of rpm - (rpm -Uvh --nodeps <shorewall rpm>).
    -
    - If you are upgrading from a version < 1.4.0, then:
    - +
    +     error: failed dependencies:iproute is needed by +shorewall-1.4.0-1
    +
    +This may be worked around by using the --nodeps option of rpm (rpm -Uvh +--nodeps <shorewall rpm>).
    +
    +If you are upgrading from a version < 1.4.0, then:
      -
    • The noping and forwardping interface - options are no longer supported nor is the FORWARDPING option - in shorewall.conf. ICMP echo-request (ping) packets are treated just - like any other connection request and are subject to rules and policies.
      • -
    • Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate a Shorewall error at startup - (they always have produced warnings in iptables).
      • -
    • The MERGE_HOSTS variable has been removed from shorewall.conf. - Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone - contents are determined by BOTH the interfaces and hosts files when - there are entries for the zone in both files.
      • -
    • The routestopped option in the interfaces -and hosts file has been eliminated; use entries in the routestopped -file instead.
      • -
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules - is no longer accepted; you must convert to using the new syntax.
      • -
    • The ALLOWRELATED variable in shorewall.conf - is no longer supported. Shorewall 1.4 behavior is the same as 1.3 -with ALLOWRELATED=Yes.
      • -
    • Late-arriving DNS replies are now dropped - by default; there is no need for your own /etc/shorewall/common file - simply to avoid logging these packets.
      • -
    • The 'firewall', 'functions' and 'version' - file have been moved to /usr/share/shorewall.
      • -
    • The icmp.def file has been removed. If you - include it from /etc/shorewall/icmpdef, you will need to modify that - file.
      • - +
    • The noping and forwardping interface options are +no longer supported nor is the FORWARDPING option in +shorewall.conf. ICMP echo-request (ping) packets are treated just like +any other connection request and are subject to rules and policies.
      • +
    • Interface names of the form <device>:<integer> in +/etc/shorewall/interfaces now generate a Shorewall error at startup +(they always have produced warnings in iptables).
      • +
    • The MERGE_HOSTS variable has been removed from shorewall.conf. +Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone +contents are determined by BOTH the interfaces and hosts files when +there are entries for the zone in both files.
      • +
    • The routestopped option in the interfaces +and hosts file has been eliminated; use entries in the routestopped +file instead.
      • +
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer +accepted; you must convert to using the new syntax.
      • +
    • The ALLOWRELATED variable in shorewall.conf is no +longer supported. Shorewall 1.4 behavior is the same as 1.3 with +ALLOWRELATED=Yes.
      • +
    • Late-arriving DNS replies are now dropped by default; +there is no need for your own /etc/shorewall/common file simply to +avoid logging these packets.
      • +
    • The 'firewall', 'functions' and 'version' file have +been moved to /usr/share/shorewall.
      • +
    • The icmp.def file has been removed. If you include it +from /etc/shorewall/icmpdef, you will need to modify that file.
        • -
      -
    • If you followed the advice in FAQ #2 and call find_interface_address - in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
      -
      • - +
    • If you followed the advice in FAQ #2 and call +find_interface_address in /etc/shorewall/params, that code should be +moved to /etc/shorewall/init.
      +
    -
      -
    -

    Version 1.4.0

    -
      -
    • The 'multi' interface option is no longer supported. -  Shorewall will generate rules for sending packets back out the same - interface that they arrived on in two cases:
      • - +
    • The 'multi' interface option is no longer supported. + Shorewall will generate rules for sending packets back out the +same interface that they arrived on in two cases:
    - -
    +
      -
    • There is an explicit policy for the source zone -to or from the destination zone. An explicit policy names both zones -and does not use the 'all' reserved word.
      • - +
    • There is an explicit policy for the source zone to or +from the destination zone. An explicit policy names both zones and does +not use the 'all' reserved word.
    -
      -
    • There are one or more rules for traffic for the source -zone to or from the destination zone including rules that use the 'all' -reserved word. Exception: if the source zone and destination zone are -the same then the rule must be explicit - it must name the zone in both -the SOURCE and DESTINATION columns.
      • - +
    • There are one or more rules for traffic for the source zone to +or from the destination zone including rules that use the 'all' +reserved word. Exception: if the source zone and destination zone are +the same then the rule must be explicit - it must name the zone in both +the SOURCE and DESTINATION columns.
    -
    - +

    Version >= 1.3.14

    - -      Beginning in version 1.3.14, Shorewall treats entries - in /etc/shorewall/masq differently. - The change involves entries with an interface name in the SUBNET - (second) column:
    - + +     Beginning in version 1.3.14, Shorewall treats +entries in /etc/shorewall/masq differently. +The change involves entries with an interface name in the SUBNET +(second) column:
      -
    • Prior to 1.3.14, Shorewall would detect the FIRST - subnet on the interface (as shown by "ip addr show interface") - and would masquerade traffic from that subnet. Any other subnets that - routed through eth1 needed their own entry in /etc/shorewall/masq to - be masqueraded or to have SNAT applied.
      • -
    • Beginning with Shorewall 1.3.14, Shorewall uses -the firewall's routing table to determine ALL subnets routed through -the named interface. Traffic originating in ANY of those subnets is -masqueraded or has SNAT applied.
      • - +
    • Prior to 1.3.14, Shorewall would detect the FIRST subnet on the +interface (as shown by "ip addr show interface") and would +masquerade traffic from that subnet. Any other subnets that routed +through eth1 needed their own entry in /etc/shorewall/masq to be +masqueraded or to have SNAT applied.
      • +
    • Beginning with Shorewall 1.3.14, Shorewall uses the firewall's +routing table to determine ALL subnets routed through the named +interface. Traffic originating in ANY of those subnets is +masqueraded or has SNAT applied.
    - You will need to make a change to your configuration +You will need to make a change to your configuration if:
    -
      -
    1. You have one or more entries in /etc/shorewall/masq - with an interface name in the SUBNET (second) column; and
      2. -
    2. That interface connects to more than one subnetwork.
      3. - +
    3. You have one or more entries in /etc/shorewall/masq with an +interface name in the SUBNET (second) column; and
      4. +
    4. That interface connects to more than one subnetwork.
    - Two examples:
    -
    -  Example 1 -- Suppose that your current config -is as follows:
    -   
    - -
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    - -
    In this case, the second entry in /etc/shorewall/masq is no longer - required.
    -
    - Example 2-- What if your current configuration -is like this?
    - -
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    - -
    In this case, you would want to change the entry in /etc/shorewall/masq - to:
    -
    - -
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - -     Version 1.3.14 also introduced simplified ICMP echo-request - (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf - is used to specify that the old (pre-1.3.14) ping handling is to -be used (If the option is not set in your /etc/shorewall/shorewall.conf - then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting -the old handling indefinitely so I urge current users to migrate to using - the new handling as soon as possible. See the 'Ping' - handling documentation for details.
    - +Two examples:
    +
    + Example 1 -- Suppose that your current config is as +follows:
    +  
    +
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    +
    In this case, the second entry in /etc/shorewall/masq is no +longer required.
    +
    +Example 2-- What if your current configuration is like this?
    +
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    +
    In this case, you would want to change the entry in +/etc/shorewall/masq to:
    +
    +
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + +    Version 1.3.14 also introduced simplified ICMP +echo-request (ping) handling. The option OLD_PING_HANDLING=Yes in +/etc/shorewall/shorewall.conf is used to specify that the old +(pre-1.3.14) ping handling is to be used (If the option is not set in +your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes is +assumed). I don't plan on supporting the old handling indefinitely so I +urge current users to migrate to using the new handling as soon as +possible. See the 'Ping' handling documentation +for details.

    Version 1.3.10

    - If you have installed the 1.3.10 Beta 1 RPM and are -now upgrading to version 1.3.10, you will need to use the '--force' +If you have installed the 1.3.10 Beta 1 RPM and are +now upgrading to version 1.3.10, you will need to use the '--force' option:
    -
    - -
    - 
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    -
    - +
    +
    + 
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    +

    Version >= 1.3.9

    - The 'functions' file has moved to /usr/lib/shorewall/functions. - If you have an application that uses functions from that file, your - application will need to be changed to reflect this change of location.
    - +The 'functions' file has moved to /usr/lib/shorewall/functions. If you +have an application that uses functions from that file, your +application will need to be changed to reflect this change of location.

    Version >= 1.3.8

    - -

    If you have a pair of firewall systems configured for failover - or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall - versions >= 1.3.8. Beginning with version 1.3.8, - you must set NEWNOTSYN=Yes in your - /etc/shorewall/shorewall.conf file.

    - +

    If you have a pair of firewall systems configured for failover or if +you have asymmetric routing, you will need to modify your firewall +setup slightly under Shorewall versions >= 1.3.8. Beginning with +version 1.3.8, you must set NEWNOTSYN=Yes in your +/etc/shorewall/shorewall.conf file.

    Version >= 1.3.7

    - -

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf - will need to include the following - rules in their /etc/shorewall/icmpdef file (creating this - file if necessary):

    - +

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf will need to +include the following rules in their /etc/shorewall/icmpdef file +(creating this file if necessary):

    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
    - -

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" - command from that file since the icmp.def file is now empty.

    - -

    Upgrading Bering to Shorewall >= 1.3.3

    - -

    To properly upgrade with Shorewall version 1.3.3 and later:

    - +

    Users having an /etc/shorewall/icmpdef file may remove the ". +/etc/shorewall/icmp.def" command from that file since the icmp.def file +is now empty.

    +

    Upgrading Bering to Shorewall >= 1.3.3

    +

    To properly upgrade with Shorewall version 1.3.3 and later:

      -
    1. Be sure you -have a backup -- you will need -to transcribe any Shorewall configuration - changes that you have made to the new - configuration.
      2. -
    2. Replace the -shorwall.lrp package provided on - the Bering floppy with the later one. If you did - not obtain the later version from Jacques's site, - see additional instructions below.
      3. -
    3. Edit the /var/lib/lrpkg/root.exclude.list - file and remove the /var/lib/shorewall - entry if present. Then do not -forget to backup root.lrp !
      4. - +
    4. Be sure you have a backup -- you will need to transcribe any +Shorewall configuration changes that you have made to the new +configuration.
      5. +
    5. Replace the shorwall.lrp package provided on the Bering floppy +with the later one. If you did not obtain the later version from +Jacques's site, see additional instructions below.
      6. +
    6. Edit the /var/lib/lrpkg/root.exclude.list file and remove the +/var/lib/shorewall entry if present. Then do not forget to backup +root.lrp !
    - -

    The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions for setting up a two-interface - firewall plus you also need to add the following two Bering-specific - rules to /etc/shorewall/rules:

    - -
    +

    The .lrp that I release isn't set up for a two-interface firewall +like Jacques's. You need to follow the instructions +for setting up a two-interface firewall plus you also need to add +the following two Bering-specific rules to /etc/shorewall/rules:

    +
    # Bering specific rules:
    # allow loc to fw udp/53 for dnscache to work
    # allow loc to fw tcp/80 for weblet to work
    #
    ACCEPT loc fw udp 53
    ACCEPT loc fw tcp 80
    -
    - -

    Version 1.3.6 and 1.3.7

    - -

    If you have a pair of firewall systems configured for - failover or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall versions -1.3.6 and 1.3.7

    - +
    +

    Version 1.3.6 and 1.3.7

    +

    If you have a pair of firewall systems configured for +failover or if you have asymmetric routing, you will need to modify +your firewall setup slightly under Shorewall versions +1.3.6 and 1.3.7

      -
    1. - -

      Create the file /etc/shorewall/newnotsyn and in it add - the following rule
      -
      - run_iptables -A -newnotsyn -j RETURN # So that the connection tracking -table can be rebuilt
      -                                     -# from non-SYN packets after takeover.
      -  

      -
      2. -
    2. - -

      Create /etc/shorewall/common (if you don't already - have that file) and include the following:
      -
      - run_iptables -A -common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT -#Accept Acks to rebuild connection
      -                                                                     - #tracking table.
      - . /etc/shorewall/common.def

      -
      3. - +
    3. +

      Create the file /etc/shorewall/newnotsyn and in it +add the following rule
      +
      + run_iptables -A +newnotsyn -j RETURN # So that the connection tracking +table can be rebuilt
      +                                    +# from non-SYN packets after takeover.
      + 

      +
      4. +
    4. +

      Create /etc/shorewall/common (if you don't already +have that file) and include the following:
      +
      + run_iptables -A +common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT +#Accept Acks to rebuild connection
      +                                                                    +#tracking table.
      +. /etc/shorewall/common.def

      +
    -

    Versions >= 1.3.5

    - -

    Some forms of pre-1.3.0 rules file syntax are no longer - supported.

    - +

    Some forms of pre-1.3.0 rules file syntax are no longer +supported.

    Example 1:

    - -
    +
    	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
    -
    - +

    Must be replaced with:

    - -
    +
    	DNAT	net	loc:192.168.1.12:22	tcp	11111
    -
    - -
    +
    +

    Example 2:

    -
    - -
    +
    +
    	ACCEPT	loc	fw::3128	tcp	80	-	all
    -
    - -
    +
    +

    Must be replaced with:

    -
    - -
    +
    +
    	REDIRECT	loc	3128	tcp	80
    -
    - +

    Version >= 1.3.2

    - -

    The functions and versions files together with the 'firewall' - symbolic link have moved from /etc/shorewall to /var/lib/shorewall. - If you have applications that access these files, those - applications should be modified accordingly.

    - -

    Last updated 6/29/2003 - Tom +

    The functions and versions files together with the +'firewall' symbolic link have moved from /etc/shorewall to +/var/lib/shorewall. If you have applications that access these files, +those applications should be modified accordingly.

    +

    Last updated 10/30/2003 - Tom Eastep

    - -

    Copyright - © 2001, 2002, 2003 Thomas M. Eastep.
    -

    -
    -
    -
    +

    Copyright +© 2001, 2002, 2003 Thomas M. Eastep
    +

    diff --git a/Shorewall-docs/useful_links.html b/Shorewall-docs/useful_links.html index b55737d14..8a3357d3d 100644 --- a/Shorewall-docs/useful_links.html +++ b/Shorewall-docs/useful_links.html @@ -2,65 +2,39 @@ Useful Links - - - - - - - - - - - -
    -

    Useful Links
    -

    -
    -
    -     
    - + +

    Useful Links    

    NetFilter Site: http://www.netfilter.orgNetfilter Logo -

    - + height="33" hspace="4" align="middle" border="0">

    Linux Advanced Routing and Traffic Control Howto: http://ds9a.nl/lartc

    -

    Iproute Downloads: ftp://ftp.inr.ac.ru/ip-routing

    -

    LEAF Site: http://leaf-project.orgLeaf Logo -

    - + align="middle" hspace="4" border="0">

    Bering LEAF Distribution: http://leaf.sourceforge.net/devel/jnilo

    - + href="http://leaf.sourceforge.net/devel/jnilo"> +http://leaf.sourceforge.net/devel/jnilo

    Debian apt-get sources for Shorewall: http://security.dsi.unimi.it/~lorenzo/debian.htmlhttp://idea.sec.dico.unimi.it/%7Elorenzo/index.html#DebianOpen Logo - Debian Logo -
    -

    -
    - Last updated 9/16/2002 - Tom Eastep - -

    Copyright - © 2001, 2002 Thomas M. Eastep.

    -
    -
    -
    -
    -
    + align="middle" hspace="4" border="0"> Debian Logo
    + +
    +Last updated 11/20/2003 - Tom +Eastep +

    Copyright +© 2001, 2002, 2003 Thomas M. Eastep.

    +
    +
    +
    +
    +
    diff --git a/Shorewall-docs/whitelisting_under_shorewall.htm b/Shorewall-docs/whitelisting_under_shorewall.htm index 5dd7f367e..b23f190a7 100644 --- a/Shorewall-docs/whitelisting_under_shorewall.htm +++ b/Shorewall-docs/whitelisting_under_shorewall.htm @@ -1,309 +1,267 @@ - - - - Whitelisting under Shorewall - - - - - - - - - -
    -

    Whitelisting under Shorewall

    -
    - -

    For a brief time, the 1.2 version of Shorewall supported -an /etc/shorewall/whitelist file. This file was intended to contain a list -of IP addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist -file was implemented as a stop-gap measure until the facilities necessary -for implementing white lists using zones was in place. As of Version 1.3 -RC1, those facilities were available.

    - -

    White lists are most often used to give special privileges -to a set  of hosts within an organization. Let us suppose that we have the - following environment:

    - + +

    Whitelisting under Shorewall
    +

    +

    For a brief time, the 1.2 version of Shorewall +supported +an /etc/shorewall/whitelist file. This file was intended to contain a +list +of IP addresses of hosts whose POLICY to all zones was ACCEPT. The +whitelist file was implemented as a stop-gap measure until the +facilities necessary for implementing white lists using zones was in +place. As of Version 1.3 RC1, those facilities were available.

    +

    White lists are most often used to give special +privileges to a set  of hosts within an organization. Let us +suppose that we have the following environment:

      -
    • A firewall with three interfaces -- one to the internet, one -to a local network and one to a DMZ.
      • -
    • The local network uses SNAT to the internet and is comprised -of the class B network 10.10.0.0/16 (Note: While this example uses an RFC -1918 local network, the technique described here in no way depends on -that or on SNAT. It may be used with Proxy ARP, Subnet Routing, Static +
    • A firewall with three interfaces -- one to the internet, one to a +local network and one to a DMZ.
      • +
    • The local network uses SNAT to the internet and is comprised of +the class B network 10.10.0.0/16 (Note: While this example uses an RFC +1918 local network, the technique described here in no way depends on +that or on SNAT. It may be used with Proxy ARP, Subnet Routing, Static NAT, etc.).
      • -
    • The network operations staff have workstations with IP addresses +
    • The network operations staff have workstations with IP addresses in the class C network 10.10.10.0/24
      • -
    • We want the network operations staff to have full access to all +
    • We want the network operations staff to have full access to all other hosts.
      • -
    • We want the network operations staff to bypass the transparent +
    • We want the network operations staff to bypass the transparent HTTP proxy running on our firewall.
      • -
    - -

    The basic approach will be that we will place the operations - staff's class C in its own zone called ops. Here are the appropriate - configuration files:

    - +

    The basic approach will be that we will place the +operations staff's class C in its own zone called ops. Here are +the appropriate configuration files:

    Zone File

    - -
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE DISPLAY COMMENTS
    netNetInternet
    opsOperationsOperations Staff's Class C
    locLocalLocal Class B
    dmzDMZDemilitarized zone
    ZONE DISPLAY COMMENTS
    netNetInternet
    opsOperationsOperations Staff's Class C
    locLocalLocal Class B
    dmzDMZDemilitarized zone
    -
    - -

    The ops zone has been added to the standard 3-zone zones file -- -since ops is a sub-zone of loc, we list it BEFORE loc.

    - +
    +

    The ops zone has been added to the standard 3-zone zones +file -- since ops is a sub-zone of loc, we list it BEFORE +loc.

    Interfaces File

    - -
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0<whatever><options>
    dmzeth1<whatever>
    -
    -eth210.10.255.255 
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0<whatever><options>
    dmzeth1<whatever>
    +
    -eth210.10.255.255 
    -
    - -

    Because eth2 interfaces to two zones (ops and loc), -we don't specify a zone for it here.

    - +
    +

    Because eth2 interfaces to two zones (ops and loc), +we don't specify a zone for it here.

    Hosts File

    - -
    - +
    - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    ZONE HOST(S) OPTIONS
    opseth2:10.10.10.0/24
    -
    loceth2:0.0.0.0/0 
    ZONE HOST(S) OPTIONS
    opseth2:10.10.10.0/24
    +
    loceth2:0.0.0.0/0 
    -
    - -

    Here we define the ops and loc zones. When Shorewall is stopped, -only the hosts in the ops zone will be allowed to access the firewall -and the DMZ. I use 0.0.0.0/0 to define the loc zone rather than 10.10.0.0/16 -so that the limited broadcast address (255.255.255.255) falls into that -zone. If I used 10.10.0.0/16 then I would have to have a separate entry for - that special address.

    - +
    +

    Here we define the ops and loc zones. When Shorewall +is stopped, +only the hosts in the ops zone will be allowed to access the +firewall +and the DMZ. I use 0.0.0.0/0 to define the loc zone rather than +10.10.0.0/16 +so that the limited broadcast address (255.255.255.255) falls into that +zone. If I used 10.10.0.0/16 then I would have to have a separate entry +for that special address.

    Policy File

    - -
    - +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    opsallACCEPT  
    allopsCONTINUE  
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    opsallACCEPT  
    allopsCONTINUE  
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - -

    Two entries for ops have been added to the standard 3-zone policy -file.

    - +
    +

    Two entries for ops have been added to the standard 3-zone +policy file.

    Rules File

    - -
    - +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    REDIRECTloc!ops3128tcphttp  
    ...      
    ACTIONSOURCEDEST PROTODEST
    +PORT(S)    		SOURCE
    +PORT(S)    		ORIGINAL
    +DEST
    REDIRECTloc!ops3128tcphttp  
    ...      
    -
    - -

    This is the rule that transparently redirects web traffic to the transparent - proxy running on the firewall. The SOURCE column explicitly excludes the -ops zone from the rule.

    - +
    +

    This is the rule that transparently redirects web traffic to the +transparent proxy running on the firewall. The SOURCE column explicitly +excludes the ops zone from the rule.

    Routestopped File

    - -
    +
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + +
    INTERFACE
    -     		HOST(S)
    eth1
    -
    -
    eth2
    -     		10.10.10.0/24
    INTERFACE
    +     		HOST(S)
    eth1
    +
    +
    eth2
    +     		10.10.10.0/24

    -
    - -

    Updated 2/18/2003 - Tom Eastep -

    - -

    Copyright - © 2002, 2003Thomas M. Eastep.

    -
    -
    -
    +
    +

    Updated 2/18/2003 - Tom Eastep +

    +

    Copyright +© 2002, 2003Thomas M. Eastep.

    +
    +
    +