From aaa0331ecf95ced1e913ac9be50168cf0e7cbb82 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:21:07 +0000 Subject: [svn-upgrade] Integrating new upstream version, strongswan (2.8.2) --- doc/src/quickstart-firewall.html | 187 --------------------------------------- 1 file changed, 187 deletions(-) delete mode 100644 doc/src/quickstart-firewall.html (limited to 'doc/src/quickstart-firewall.html') diff --git a/doc/src/quickstart-firewall.html b/doc/src/quickstart-firewall.html deleted file mode 100644 index 53c27b5af..000000000 --- a/doc/src/quickstart-firewall.html +++ /dev/null @@ -1,187 +0,0 @@ - - - - Quick FreeS/WAN installation and configuration - - - - -

FreeS/WAN quick start on firewalling

-

This firewalling information supplements our -quickstart guide.

-

It includes tips for firewalling:

- -

and a list of helpful resources.

-

Firewalling a standalone system

-

Firewall rules on a standalone system doing IPsec can be very simple.

-

The first step is to allow IPsec packets (IKE on UDP port 500 plus - ESP, protocol 50) in and out of your gateway. A script to set up - iptables(8) rules for this is:

-
# edit this line to match the interface you use as default route
-# ppp0 is correct for many modem, DSL or cable connections
-# but perhaps not for you
-world=ppp0
-#
-# allow IPsec
-#
-# IKE negotiations
-iptables -A INPUT  -p udp -i $world --sport 500 --dport 500 -j ACCEPT
-iptables -A OUTPUT -p udp -o $world --sport 500 --dport 500 -j ACCEPT
-# ESP encryption and authentication
-iptables -A INPUT  -p 50 -i $world -j ACCEPT
-iptables -A OUTPUT -p 50 -o $world -j ACCEPT
-

Optionally, you could restrict this, allowing these packets only to - and from a list of known gateways.

-

A second firewalling step -- access controls built into the IPsec - protocols -- is automatically applied:

-
-
Pluto -- the FreeS/WAN keying - daemon -- deals with the IKE packets.
-
Pluto authenticates its partners during the IKE negotiation, and - drops negotiation if authentication fails.
-
KLIPS -- the FreeS/WAN kernel - component -- handles the ESP packets.
-
-
-
KLIPS drops outgoing packets
-
if they are routed to IPsec, but no tunnel has been negotiated for - them
-
KLIPS drops incoming unencrypted packets
-
if source and destination addresses match a tunnel; the packets - should have been encrypted
-
KLIPS drops incoming encrypted packets
-
if source and destination address do not match the negotiated - parameters of the tunnel that delivers them
-
if packet-level authentication fails
-
-
-
-

These errors are logged. See our - troubleshooting document for details.

-

As an optional third step, you may wish to filter packets emerging from - your opportunistic tunnels. - These packets arrive on an interface such as ipsec0, rather than - eth0, ppp0 or whatever. For example, in an iptables(8) - rule set, you would use:

-
-
-i ipsec+
-
to specify packets arriving on any ipsec device
-
-o ipsec+
-
to specify packets leaving via any ipsec device
-
-

In this way, you can apply whatever additional filtering you like to these -packets.

-

The packets emerging on ipsec0 are likely - to be things that a client application on your machine requested: web - pages, e-mail, file transfers and so on. However, any time you initiate - an opportunistic connection, you open a two-way connection to - another machine (or network). It is conceivable that a Bad Guy there - could take advantage of your link.

-

For more information, read the next section.

-

-

Firewalling incoming opportunistic - connections

-

The basic firewalling for IPsec does not change when you support - incoming connections as well as connections you initiate. You must - still allow IKE (UDP port 500) and ESP (protocol 50) packets to and - from your machine, as in the rules given - above.

-

However, there is an additional security concern when you allow - incoming opportunistic connections. Incoming opportunistic packets - enter your machine via an IPSec tunnel. That is, they all appear as - ESP (protocol 50) packets, concealing whatever port and protocol - characteristics the packet within the tunnel has. Contained - in the tunnel as they pass through ppp0 or eth0, - these packets can bypass your usual firewall rules on these interfaces. -

Consequently, you will want to firewall your ipsec interfaces - the way you would any publicly accessible interface.

-

A simple way to do this is to create one iptables(8) table with - all your filtering rules for incoming packets, and apply the entire table to - all public interfaces, including ipsec interfaces.

- -

Firewalling for opportunistic gateways

-

On a gateway, the IPsec-related firewall rules applied for input and - output on the Internet side are exactly as shown -above. A gateway - exchanges exactly the same things -- UDP 500 packets and IPsec packets - -- with other gateways that a standalone system does, so it can use - exactly the same firewall rules as a standalone system would.

-

However, on a gateway there are additional things to do:

- -

You need additional rules to handle these things. For example, adding - some rules to the set shown above we get:

-
# edit this line to match the interface you use as default route
-# ppp0 is correct for many modem, DSL or cable connections
-# but perhaps not for you
-world=ppp0
-#
-# edit these lines to describe your internal subnet and interface
-localnet=42.42.42.0/24
-internal=eth1
-#
-# allow IPsec
-#
-# IKE negotiations
-iptables -A INPUT  -p udp -i $world --sport 500 --dport 500 -j ACCEPT
-iptables -A OUTPUT -p udp -o $world --sport 500 --dport 500 -j ACCEPT
-# ESP encryption and authentication
-iptables -A INPUT  -p 50 -i $world -j ACCEPT
-iptables -A OUTPUT -p 50 -o $world -j ACCEPT
-#
-# packet forwarding for an IPsec gateway
-# simplest possible rules
-$ forward everything, with no attempt to filter
-#
-# handle packets emerging from IPsec
-# ipsec+ means any of ipsec0, ipsec1, ...
-iptables -A FORWARD -d $localnet -i ipsec+ -j ACCEPT
-# simple rule for outbound packets
-# let local net send anything
-# IPsec will encrypt some of it
-iptables -A FORWARD -s $localnet -i $internal -j ACCEPT
-

On a production gateway, you would no doubt need tighter rules than - the above.

-

Firewall resources

-

For more information, see these handy resources:

- -Back to our quickstart guide. - - - - - -- cgit v1.2.3