Overblog Suivre ce blog
Administration Créer mon blog
3 octobre 2013 4 03 /10 /octobre /2013 02:18

This post will explain how to setup a PPTP server that is able to transport both IPv4 and IPv6, using Raspbian as the server, and how to setup a Debian or Windows 8 client.

( The setup is the same for Debian or Ubuntu as the server ).

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

The tunnel will use the 10.0.0.0/8 IPv4 private address range and the 2001:db8:0:10::/64 IPv6 global unicast address range.

 

Tested using :

PPTP Server : RASPBIAN version June 2014

PPTP Client : Debian 7.5 and Windows 8

 

Last Edited July 1 2014

 

1. PPTP Server setup

The main difficulty is about the radvd service : We need radvd, for IPv6 default gateway advertising to the client. But if the radvd service is running before the tunnel is up, it will spill false router-advertisements to other interfaces, misleading other network clients. ( Is this a radvd bug ?! ).

The solution is to have the radvd service removed from autostart, and activated once the tunnel is up. Likewise, it is stopped when the tunnel is down.

The solution presented here is simple, but only support one IPv6 connection. See Part 4 for solutions that support multiple simultaneous clients.

 

We first update our server :

sudo apt-get update

sudo apt-get upgrade

 

We make sure the pptp server is set with static IPs. We'll be using here :

192.168.1.40 for IPv4

2001:db8:0:1::40 for IPv6

 

We reboot the OS :

sudo reboot

 

We install the pptp server :

sudo apt-get install pptpd

 

We edit the pptp server configuration :

sudo nano /etc/pptpd.conf
We uncomment the localip and remoteip lines and change them to :

-------------------------------------------------------------------------------------
localip 10.0.0.1
remoteip 10.0.0.10-14
-------------------------------------------------------------------------------------

 

We setup the pptp server options :

sudo nano /etc/ppp/pptpd-options

We uncomment the ms-dns lines and change them our DNS choice :
---------------------------------------------------------------------------------------
ms-dns 208.67.222.222
ms-dns 208.67.220.220
---------------------------------------------------------------------------------------
In this example, we use OpenDNS’s servers.

We enable IPv6 by adding to the end :
---------------------------------------------------------------------------------------
ipv6 ::1,::2
----------------
-----------------------------------------------------------------------

 

 

We create users and passwords , using this syntax :

user<tab>*<tab>password<tab>*

sudo nano /etc/ppp/chap-secrets

--------------------------------------------------------------------------------------
john    *    secret1      *

tom     *    secret2      *
--------------------------------------------------------------------------------------

 

We adjust the ipv4 MTU :

sudo nano /etc/ppp/ip-up

( We add this line to the end of the file ) :
----------------------------------------------------------------------------------------
ifconfig $1 mtu 1400
----------------------------------------------------------------------------------------

 

We enable IPv4 and IPv6 forwarding :

sudo nano /etc/sysctl.conf

( we uncomment IPv4 and IPv6 forwarding ) :
-----------------------------------------------------------------------------------------
net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1

-----------------------------------------------------------------------------------------
 

we apply the networking changes :

sudo sysctl -p

 

we finally create IPv4 NAT, to allow IPv4 clients full connectivity :

sudo iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.1.40
sudo iptables-save

 

We create a NAT boot-time script :

sudo bash -c "iptables-save > /etc/iptables.conf"
sudo nano /etc/network/if-pre-up.d/iptables
-------------------------------------------------------------------------------------------
#!/bin/sh
iptables-restore < /etc/iptables.conf
-------------------------------------------------------------------------------------------

sudo chmod +x /etc/network/if-pre-up.d/iptables

 


IPv6 Specifics

 

We install radvd :

sudo apt-get install radvd

 

We edit radvd.conf :

sudo nano /etc/radvd.conf
---------------------------------------------------------------------------------------------

interface ppp0 {
AdvSendAdvert on;
AdvDefaultPreference high;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:db8:0:10::/64 {
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 2620:0:ccc::2 2620:0:ccd::2 {
};
};

 

---------------------------------------------------------------------------------------------

( We'll be using OpenDNS IPv6 addresses. You may use Google Public DNS, Comodo Secure DNS, ... )

we stop radvd, and remove it from boot-time autostart :

sudo service radvd stop

sudo update-rc.d -f radvd remove

 

We create the PPTP server tunnel up / tunnel down IPv6 RADVD scripts :

sudo nano /etc/ppp/ipv6-up.d/radvd
---------------------------------------------------------------------------------------------
#!/bin/bash
sudo ip -6 addr add 2001:db8:0:10::1/64 dev ppp0
sudo service radvd start
exit 0
---------------------------------------------------------------------------------------------
sudo chmod 755 /etc/ppp/ipv6-up.d/radvd

sudo nano /etc/ppp/ipv6-down.d/radvd
---------------------------------------------------------------------------------------------
#!/bin/bash
sudo pkill radvd
exit 0
----------------------------------------------------------------------------------------------
sudo chmod 755 /etc/ppp/ipv6-down.d/radvd

 


 we restart the pptp server :

/etc/init.d/pptpd restart

 

Local network IPv6 routing / Internet Gateway setup

Whereas IPv4 is using NAT, and thus doesn't need any special routing care, IPv6 does need some static IPv6 routes on the local network of the PPTP Server, for the 2001:db8:0:10::/64 network to be reachable.

Likewise, some port forwarding is needed on the Internet Gateway to allow Wan access of the PPTP server.

See Part 5 : Network IPv6 Routing, for the required IPv6 static routes for different network topologies, and a port forwarding exemple.

 

 

2. PPTP Client Setup

Windows 8

The Windows 8 PPTP client supports PPTP transport of IPv4 and IPv6 natively. Nothing special to setup here.

The VPN IPv4 DNS addresses get setup OK. The only glitch is the lack of Windows support for RDNSS, thus no VPN IPv6 DNS addresses set. Static IPv6 DNS needed here.

 

Debian 7.5

 

As the network manager doesn't allow to setup PPTP transport of IPv6, we will have to setup and up/down the tunnel manually. It is actually very simple.

 

We update the Debian client, and install the pptp-linux package :

sudo apt-get update

sudo apt-get upgrade

sudo apt-get install pptp-linux

 

we install the rdnss listener, needed as we're not using the network manager :

sudo apt-get install rdnssd

 

We set our user and password :

We create users and passwords , using this syntax :

user<tab>*<tab>password<tab>*

sudo leafpad /etc/ppp/chap-secrets

--------------------------------------------------------------------------------------
john    *    secret1      *

--------------------------------------------------------------------------------------

 

We create a config file for the tunnel, that we'll name MYVPN :

sudo leafpad /etc/ppp/peers/MYVPN

--------------------------------------------------------------------------------------

pty "pptp 192.168.1.40 --nolaunchpppd"
name john
remotename PPTP
require-mppe-128
require-mschap-v2
usepeerdns
noauth
file /etc/ppp/options.pptp
ipparam MYVPN

---------------------------------------------------------------------------------------

 

We enable IPv6 in the pptp client options by adding to the end :

sudo leafpad /etc/ppp/options.pptp

---------------------------------------------------------------------------------------
+ipv6
ipv6cp-accept-local
ipv6cp-use-ipaddr

---------------------------------------------------------------------------------------

 

 

We create a script for client to have the default route replaced when teh tunnel is up :
sudo leafpad /etc/ppp/ip-up.d/MYVPN
----------------------------------------------------------------------------------------------
#!/bin/sh

sudo ip route change default via 10.0.0.1 dev ppp0

----------------------------------------------------------------------------------------------
sudo chmod +x /etc/ppp/ip-up.d/MYVPN

 

We create a script for client to replace default route when the tunnel is down.

( replace eth1 with your interface name ) :
sudo leafpad /etc/ppp/ip-down.d/MYVPN
----------------------------------------------------------------------------------------------
#!/bin/sh

#sudo ip route del default
sudo ip route add default via 192.168.1.1 dev eth1
----------------------------------------------------------------------------------------------
sudo chmod +x /etc/ppp/ip-down.d/MYVPN

 

You may have to use scripts for the IPv6 tunnel up/down too. As an example, althrough my tunnel RAs ( Router Advertisements ) have a priority set to high, they get unpreferred because of a strange metric 1 route to the default gateway ( under investigation ... ).

So I use this to get rid of it :

sudo leafpad /etc/ppp/ipv6-up.d/MYVPN

---------------------------------------------------------------------------------------------------------------

#!/bin/sh

sudo ip route del default via fe80::8cde:48ff:fe00:0080 dev eth1  proto static  metric 1

sudo service rdnssd restart

---------------------------------------------------------------------------------------------------------------

sudo chmod +x /etc/ppp/ipv6-up.d/MYVPN

 

So do the debugging of your personal situation, using :

ip -6 route show

 

Tunnel start/stop

The tunnel is up'ed and down'ed using these commands :

to create the tunnel :

sudo pon MYVPN

to delete the tunnel :

sudo poff MYVPN

To troubleshoot tunnel creation problems, use this debug syntax :

sudo pon MYVPN debug dump logfd 2 nodetach

 

4. Multiple simultaneous clients with IPv6 support

The problem with multiple clients comes from the fact that each client creates a distinct ppp interface ( ppp0, ppp1, ppp2 ). Thus, the server script that starts radvd must be aware of the ppp interface used, requiring some scripting.

source 1

source 2

 

5. Network IPv6 Routing

Let's quickly check the IPv6 extra network routing needs, depending on the topology, for some different scenarios. Remember to adapt your client Scripts, depending on the topology.

 

Case 1 : client on the same LAN as the PPTP Server

This is the simplest case. I detail it to outline the need for Internet Gateway to have a static route to the 2001:db8:0:10::/64 network ( the tunnel IPv6 network ) via 2001:db8:0:1::40 ( the PPTP server ) :

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6
VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

Case 2 : client goes LAN-WAN through a local router

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

Nothing more to do, as the client only has and IPv4 connection with the PPTP server. It remains the need for a route for the Internet Gateway :

2001:db8:0:10::/64 through 2001:db8:0:1::40

 

 

Case 3 : Client goes Wan-Lan through a local Router

 

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

Here we have three IPv6 static routes needed :

Internet Gateway                                    2001:db8:0:10::/64 through 2001:db8:0:1::40

                                                               2001:db8:0:2::/64 through 2001:db8:0:1::40

 

DIR 626-L                                               2001:db8:0:10::/64 through 2001:db8:0:2::40

 

Case 4 : Client uses Wan Access

 

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6

Nothing complicated here. We need a static route :

Internet Gateway 2001:db8:0:10::/64 through 2001:db8:0:1::40

and a port forwarding :

Internet Gateway TCP 1723 forwarded to 182.168.1.40 port 1723

VPN 4 : Debian PPTP Server w/ IPv4 and IPV6
Repost 0
Published by computer outlines - dans vpn ipv6
commenter cet article
24 septembre 2013 2 24 /09 /septembre /2013 08:14


Four things that change when going IPv6, which make IPv6 a paradigm shift.


From one public IP to 'All public IP'

most IPv4 users used to have one only public IP, and managed their needs through NAT and Port Forwarding. The first great shift when going IPv6 is to realize we're each given a least 16+ billion billion public IPs. That's the size of a /64 subnet, which is the minimum.
This means that all nodes ( network equipements, computers, appliances, ... ) get a unique, globally reacheable, public IP. That is the first great shift : All public IPs. ( Public IPs everywhere )

 

 

 

From NAT 'pseudo-firewall' to IPv6 pure firewalling

NAT provided for a default closed inbound pseudo-firewall . The NAT functionning, needing a port forwarding rule to forward anything in, made that a fresh, un-changed, firewall was secure regarding inbound connections.


IPv6 is 'all public IP', no NAT is used or needed. This means that a misconfigured firewall easily allows all computers in a network to be reachable from the Internet. The firewall becomes extra-important. Beside, we get back to a pure firewall functionning. That is the second great shift : Pure firewalling

 

 

 

From NAT zero-routing to IPv6 mandatory routing

Nat functionning maid that chaining up routers didn't need any routes management.
We just had to take care to use appropriate subnet numberings.
Let's look at this network :

O3e

 

using IPv4, Router1 doesn't need a route to subnet 2, because of NAT.
Neither did Server 1 need  a route to subnet 2.


using IPv6, Router1 does need a route to subnet 2. And Server1 does too. The more complexe the network gets, the more routes need to be added in each network node.
It's the change when going IPv6 : Routes definition are mandatory, as long as we use more than 1 router/modem-router/CPE. It could promise RIPng a brillant future. This is the third great shift : Pure network routing.


from ICMP fencing to ICMPv6 freeway and obscurity

In IPv4, ICMP was a mere diagnostic tool, that was default inbound denied at each internet
gateway ( CPE, modem-router ). Beside, NAT made no internal network scanning possible, as a forwarding rule would be needed.
In IPv6, ICMP is considered mandatory for the good functionning of the network. Some ICMPv6 messages are inbound-allow by default ( ping request ). On the other side, the size of a IPv6 /64 subnet ( 16+ billion billion hosts ) PLUS the use of the IPv6 Privacy extentions ( DHCPv6 randomization, SLAAC temporary and randomized outbound address, one-time randomized 'server' address ) make this ICMPv6 easy living less of a security concern, as hosts are ' hidden ' inside this great /64 subnet. That is ' Security by Obscurity '. This is the fourth great shift : from ICMPv4 fencing to ICMPv6 freeway and obscurity.

 

 

 

Four great shift that make a paradigm shift


from 1 public IP to 'All public IP'
from NAT zero routing to IPv6 mandatory routing
from NAT 'pseudo-firewall' to IPv6 pure firewalling
from the ICMP fence to the ICMPv6 freeways and obscurity

we can take an IPv4 network representation :

 

O3e.gif

 

as we're ' all public IPs ' we could represent it this way in IPv6 :

 

O3b.gif

 

let's add in our IPv6 firewall :

 

O3c.gif

 

we can represent the different layers of security ( core network / edge network ) :

O3d.gif

 

IPv6 brings back the internet in its pristine original state : All public IPs, pure routing, pure firewalling, full-function ICMP.

 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article
16 septembre 2013 1 16 /09 /septembre /2013 16:26

We'll see here the use of a Syslog Server and Mail Notifications to enhance the security of a network, with a special focus over IPv6.

We'll be using a Dlink DIR-626L and a Cisco Small Business RV110W to see their settings and possibilities in this field.

 

 

 

Using an IPv6 Syslog Server

Using a Syslog Server is an invaluable tool for the security of a network.
The Syslog Server will centrally collect and log datas from the network routers, including system activity, computers joining Lans ( including Wifi ), packets dropped by firewalls, logins to the admin webpage of any of the routers, debugging informations, ...

Unauthorised access to the Lan ( including a neighbor unlawfully using a mistakenly un-protected wifi ) are saved in the Syslog Server Log, so trace-cleaning for intruders is really hardened ( it would need them accessing the Syslog Server Computer ).

Let's see a free, lightweight, Syslog Server software : TFTPD32

 

 

TFTPD32

TFTPD32 is free, lightweight, IPv6 compatible and portable ( no installation ). Its homepage is here ( http://tftpd32.jounin.net/ ). There is a service version too.

 

S9a.gif

 

Virustotal lists this software with a 4-6/47 risk. I believe this is because being so leightweight, the binaries have been used by viruses. TFTP32 is often labeled as a 'riskware' or 'PUP' ( Potentially unwanted program ). Anyway, use it with mind.


Here are the basic step of TFTP32D Syslog Server setup :

1. uncheck the unneeded services :

 

S9b.gif

 

 

 

 

2. enable logging :

 

S9c.gif

 

3. select the listening interface in the drop-down menu :

 

S9d

 

This is it!

You can view real-time syslog messages, or you can browse to check the recorded log ( syslog.txt, located in the installation folder ). Please note that the recorded log ( syslog.txt ) is appended with time, as tftpd32 is running, so you can go back in time.
Do notice too that when the software isn't running, the logging is suspended. When the software is restarted, it restarts appending to the syslog.txt file. That's why for a real 24H protection, we need to run this on a 24H machine ( a light server ... or a RaspberryPI running Linux... ? )

 

 

 

DIR-626L Syslog service

Setting up the syslog server on the DIR-626L is pretty straightforward.

First, we enable syslog server logging and enter the IPv4 address of the server ( Yes, IPv4 Syslog Server only ) :

S9h



Then, in Status/Logs check the fields you want to be logged :

 

S9i.gif


( Do tick Debug Information only temporary, for debugging of a particular situation, because it is way too verbose for daily use ). Here is the Syslog Server in action :

 

S9k.gif


This is quite all there is to know about the DIR-626L Syslog Server functionning. Do notice that we have to use an IPv4 address for the Syslog Server, and that IPv6 dropped packets are not logged, so on the IPv6 side we're pretty limited to IPv6 Wifi access / System functionning / Admin login logging. But this is still a valuable security asset.

 

 

 

DIR-626L EMail notifications

The DIR-626L do allow email notifications. A few things to note :

. The 626L uses IPv4 only for email notifications.
. The 626L doesn't support SSL ( so using a WebMail like Gmail or Outlook.com may prove impossible )
. The email notification can be triggered either/both on schedule or log full. No cycling notifications ( daily, hourly, ... ) or triggered notifications ( Syslog warning, ... )

Here is an example setup, using hMail Server ( See this post, for hMail Server tutorial ) :

 

S9o.gif


Here is the Hmail Server Setup, with SSL unchecked for SMTP :

S9n.gif


Here is a sum up of the DIR-626L capabilities :

 

S9s.gif

 


RV110W Syslog Server

Setting up the RV110W Syslog service is very easy.

We just have to :

 

. enable logging

. set the Log Severity for Local Log and Email

. add a row in the Remote Log Server Table, with a Log Severity Level

 

S9l.gif


Three things to note :

 

. The RV110W can only log to an IPv4 Syslog Server
. Only Wifi join is fully logged ( MAC address ), Lan join only logs physical ports connect/disconnect
. Several Rows, thus several Syslog Server with distinct Severity Levels can be set up :

 

S9m.gif

 

 

 

RV110W EMail Notifications

The RV110W do allow Email notifications too.

Here is a basic setup, using hMail Server with SSL ( see this post for a hMail Server tutorial ) :

 

S9q.gif


A few things to note :

. The RV110W uses only IPv4 for EMail notifications
. The RV110W does support SSL
. The RV110W Email Notification can be triggered either/both cycling ( hourly, daily ), scheduled or triggered ( syslog-level triggered )

. There is a very convinient ' Test ' to easily test the mail good delivery

. As for now, I haven't yet managed to trigger an Email notification ( either having Firewall dropping packets, Intensive Zenmap scan over the RV110W Wan Interface or unplugging the its Wan port, no Email was sent ).

Here is a sum up of the RV110W capabilities :

 

S9t.gif

 

 

Professionnal Syslog Servers softwares

Pro-grade Syslog Servers softwares offer lots of functionnalities :
. syslog messages filters can trigger email notifications
. log messages can be sorted by source IP, severity, ...

They offer free, personnal licences, with some limitations ( number of source IPs, daily messages volume, ... ).

Here are some interesting one you may want to check :

. Syslog Watcher 4
. Kiwi Syslog Server
. Splunk
. Logzilla

 

 

 

A few conclusion notes

First, here is a comparaison chart of the DIR-626L and RV110W capabilities ( although they don't belong to the same audience profile and price-zone ) :

 

S9r.gif

 

The Syslog Server is an invaluable tool for a network security, and works very well with these two models.

As for email notifications, the options offered by these two entry-level routers ( DIR-626L and RV110W ) don't allow real-time security, they only automate the logs transferts.basic remote logging. The use of a professionnal syslog server is the only way to have real-time email notifications of network events.
As for IPv6 support, we're still at the dawn of ages : no IPv6 dropped packets for the DIR-626L, no logging to an IPv6 Syslog Server for both, no IPv6 email notification for both. There is still a long way to go for full IPv6 Support.

 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article
16 septembre 2013 1 16 /09 /septembre /2013 15:52

This post will review the question of anonymity and stealthiness in regard to IPv6.
We'll see the available SLAAC and DHCPv6 options, as well as the implications of the size of an /64 subnet.

IPv6 relies on ICMPv6 for its good functionning, when ICMPv4 is mere a diagnostic tool.
Furthermore, IPv6 Simple Security ( RFC6092 ) expects some ICMPv6 traffic to pass freely and unrestricted ( notablally outbound Echo request, inbound Echo reply, Time Exceeded and Parameter problem ).

Let's review the mechanisms implemented to provide some privacy, and evaluate the implications of the size of a /64 subnet

 

You may want to read first this post about Windows IPv6 Privacy Extentions.

 

 

 

Privacy mechanisms

IPv6 addresses should be choosen in a non-linear, unpredictable way, for obvious reasons.
this can be done by three means :

. Static IP, using a random-IP generator

. DHCPv6, when the DHCPv6 Server can randomize addresse pool leases :

. SLAAC, by :

    . using a random, temporary, outgoing IP address
    . using a fixed, one-time randomized, IP address for Server inbound requests


please note that DHCPv6 randomization is implemented on the DHCPv6 server,
where SLAAC randomization is implemented on the client PC.

the outbound address used by SLAAC is re-randomized at each reboot or off/on cycle of the IPv6 stack ( disable / enable )
the inbound address host-ID used by SLAAC seems one-time randomized at the OS installation, and won't change unless a full OS re-install is performed



a few exemples of privacy implementations

DLink DIR-626L DHCPv6 :

        is linear
        only the last 4 nibbles of the subnet are leaseable ( 0000 -) FFFF )
        = 65 536 possibilities

 

 

CSB RV110W :

 

           does full randomize over a whole /64 subnet

           allows the creation of address pools

 

 

WS 2008 R2 DHCPv6 Server :

 

          does full randomize over a whole /64 subnet



the /64 subnet size and privacy implications

as a /64 subnet holds over 16 billion billion IP, let's try to estimate how well a randomized IP is hidden among these ( that's security by obscurity )

let's take as a basis a fast ping scan that can reache 100 IP/s :

 

A nibble-quad (Quad Hex ) can be scanned in 11 minutes

A full /64 subnet will need 5.8+ billion years. That is pretty safe.

A full /64 half-time ( 50% hit probability ) is thus 2.9+ billion years. This is still pretty safe.

The scanning speed is limited to the smallest bandwidth during the travel, so no performance increase may be expected here by improving the scanning appliance bandwidth.

Let's imagine we manage to design a very clever algorithm than provides a 1000 fold increase in scanning speed, we're still 2.9+ million years for a 50% probability.

Here is a chart to provide some scale orders :

 

S8b.gif

 

Conclusion

Doing the due effort of using randomized IP addresses, and carefully using the Privacy options that come with IPv6 provides for a good anonymity and stealthiness, thanks to the size of a /64 subnet.

 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article
10 septembre 2013 2 10 /09 /septembre /2013 15:39

We'll see here and discuss RFC6092 ( Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service ) and RFC4890 ( Recommendations for Filtering ICMPv6 Messages in Firewalls ) in details, as they provide the fundations for baseline IPv6 security, especially at consummer level.


RFC6092 - IPv6 Simple Security

RFC 6092 is labeled : Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
It defines a set of baselines for network appliances to provide homes and small offices Lans with a simple, default, perimeter IPv6 security.

They lay on users expectations and habits about IPv4 NAT, whose statefull nature de-facto created a pseudo-firewall functionning : Default allow out, default deny in, allow ( statefull ) traffic back in.

Here are IPv6 Simple Security basic foundations :

. Basic sanitation

. Statefull Firewalling

. Firewall exceptions management

. IPSEC allowed in

. Mobile IPv6 allowed in

. Some genuine inbound ICMPv6 traffic allowed in


Here is a map of RFC 6092 50 recomentations :

S7a.gif

Here is a detailed map :

 

S7b.gif

 

Let's review the different topics.


Basic Sanitation

Here are the packets to be dropped :

. Packets with a multicast source address
. Packets with a multicast destination address over or equal to the router multicast scope
. Packets non-Internet Routable : bogon address, unspecified address, loopback address, ORCHID address, documentation address, ULA, Link-local, Site-local, IPv4-mapped, IPv4-compatible, 6to4 martian and Teredo Martian.
. Packets with a deprecated extension header before the upper-layer payload ( routing extension header type 0, ... )
. Packets that fail the Ingress filtering
. Inbound DNS queries should not by resolved by the CPE ( by default )
. Inbound DHCPv6 queries should not be resolved or relayed by the CPE
. Inbound ICMPv6 Destination Unreachable and Packet Too Big error messages that do not belong to a previous outgoing state

Please note that regarding ICMPv6, RFC 4890 recommendations apply, with the addition of the discard of inbound, non-state related, Destination Unreachable and Packet Too Big error messages. The third part of this post deals with RFC 4890 + IPv6 Simple Security result

This implies that incomming echo request, time exceeded and parameter error are allowed in by default, even if unrelated to any current firewall state.

 

 

 

Statefull Firewalling

IPv6 Simple Security expects a classic statefull firewall functionning.
inbound ICMPv6 error messages related to current firewall states are allowed in.
There are provisions for simultaneous-open mode ( RFC 0793 ) for TCP and SCTP.
Special precisions are provided for state timeouts.

 

 

VPN and IPSEC

by default outbound VPN is allowed and inbound VPN is denied.

 

IPSEC is allowed in by default. Precisely :

AH and ESP allowed in by default
Dest 500 port ( IKE ) allowed in by default
HIP allowed in by default

Inbound ICMPv6 Destination Unreachable and Packet Too Big error messages related to current ESP firewall states allowed in by default.


Mobile IPv6

Mobility is a standard feature of IPv6. Here are the IPv6 Simple Security baselines :

Unsolicited inbound Mobility Header messages that are not the subject of an IPsec security policy are expected to be dropped.

Statefull 'mobile' must be allowed in

Inbound ICMPv6 Destination Unreachable and Packet Too Big error messages related to current Mobility Header flow states records are allowed.



General user's experience

CPE firmware update :
. automatic or manual updates
. pre-configuration of the download URL
. a mean of validating the firmware ( ex by a certificate )

Transparent mode :
. an easy option to cancel IPv6 Simple Security

Wan management of the CPE not allowed by default


A few notes

The question of ' Passive Listeners ' have not been settled yet. Technics like UPnP-IGD or NAT-PMP ( without NAT ), or some new emerging protocol may be used. The REC-49 states :

" REC-48: Internet gateways with IPv6 simple security capabilities
   SHOULD implement a protocol to permit applications to solicit inbound
   traffic without advance knowledge of the addresses of exterior nodes
   with which they expect to communicate. "



RFC 4890

RFC 4890 is labeled ' Recommendations for Filtering ICMPv6 Messages in Firewalls '

Basically, RFC 4890 allows unexpected inbound :

. echo request

. some ICMPv6 error messages

. some mobile IPv6 messages

. authenticated headers

 

 

Let's look into the details


First, let's assume we use a statefull firewall, with default allow out, as it is the most common situation, and as it's RFC 6092 functionning.

So allow out rules won't be listed, neither allow in to previous outbound requests.

The third part of this post deals with the complete listing of RFC 4890.

 

 

Must Not Be Dropped :

   o  Destination Unreachable
   o  Packet Too Big
   o  Time Exceeded ( Hop limit only )
   o  Parameter Problem ( Codes 1 and 2 only )

   o  Echo Request

Should Not Be Dropped :

   o  any ICMPv6 Error message

   o  Echo Request

   o  Home Agent Address Discovery Request (Type 144) if the firewall is a Home Agent
   o  Mobile Prefix Solicitation (Type 146) if the firewall is a Home Agent


Delivery-authenticated messages (eg IPsec AH header or ESP header with authentication ) may be
subject to less strict policies than messages that cannot be authenticated.


Should be site confined :

Router Renumbering Messages

Node Information Query and Reply


in general : scopes should match

 

 

Consequences of RFC 4890 upon IPv6 Simple Security

As RFC 6092 builds upon RFC 4890 about ICMPv6 messages, here is the final RFC 6092 result about ICMPv6 :


Must Not Be Dropped :

   o  Time Exceeded ( Hop limit only )
   o  Parameter Problem ( Codes 1 and 2 only )

   o  Echo Request

Should Not Be Dropped

   o  Time Exceeded
   o  Parameter Problem

   o  Echo Request

   o  Home Agent Address Discovery Request (Type 144) if the firewall is a Home Agent
   o  Mobile Prefix Solicitation (Type 146) if the firewall is a Home Agent


Delivery-authenticated messages (eg IPsec AH header or ESP header with authentication ) may be
subject to less strict policies than messages that cannot be authenticated.


site confined :

Router Renumbering Messages

Node Information Query and Reply

in general : scopes should match

 

 

Complete RFC 4890

 

Here is the precise RFC 4890 :

 

Must Not Be Dropped :

   o  Destination Unreachable
   o  Packet Too Big
   o  Time Exceeded ( Hop limit only )
   o  Parameter Problem ( Codes 1 and 2 only )

   o  Echo Request
   o  Echo Response


Should Not Be Dropped

   o  any ICMPv6 Error message

   o  Echo Request
   o  Echo Response

   o  Home Agent Address Discovery Request (Type 144)
   o  Home Agent Address Discovery Reply (Type 145)
   o  Mobile Prefix Solicitation (Type 146)
   o  Mobile Prefix Advertisement (Type 147)

Delivery-authenticated messages (eg IPsec AH header or ESP header with authentication ) may be
   subject to less strict policies than messages that cannot be
   authenticated.


site confined :

Router Renumbering Messages

Node Information Query and Reply



in general : scopes should match
             address match ( ingress filtering )

Section A.14 suggestions for a more fine-grained IPv6 Mobile ICMPv6 Filtering

 

For Home Agents, the firewall must allow :

 

incoming Home Agent Address Discovery Request

Incoming Mobile Prefix Solicitation

Outgoing Home Agent Address Discovery Reply

Outgoing ICMP Mobile Prefix Advertisement


Advice : " It may be desirable to limit the destination addresses for the incoming messages to links that are known to support home agents "

 

For roaming mobile nodes hosting , the firewall must allow :

 

outgoing Home Agent Address Discovery Request

outgoing Mobile Prefix Solicitation

incoming Home Agent Address Discovery Reply

incoming ICMP Mobile Prefix Advertisement

 

For Administrators :

 

Advice : " Administrators may find it desirable to prevent static nodes that are normally resident on the site from behaving as mobile nodes by dropping Mobile IPv6 messages from these nodes. "

 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article
4 septembre 2013 3 04 /09 /septembre /2013 15:37

For this post, we're going to get deeper into Firewall Analys, with a special focus over IPv6.


This post relies heavily on two previous posts : IPv6 Simple Security and IPv6 Statefull Firewall. Please have a look at them for basis.

 

 

Why Firewall Analysis

Where Firewall Testing just aims to check the results of a particular model / configuration ( open IP and ports, ingress/egress filtering, resistance to DoS, security features ), Firewall Analysis goal is to understand how a particular model functions, its inner functionning.


Here is an example : As most Network Routers have a Statefull Firewall, it is dubious to say if an incomming traffic has been allowed in by virtue of the inbound policy, or because a statefull permission has been created by a previous outgoing flow. Think of an ICMPv6 Echo Reply : Does it get in because an outbound Echo Request has been initiated ?
Or an inbound ICMPv6 Time Exceeded triggered by an outbound TCP with a too short TTL.


Firewall Analysis aims at discovering the inner functionning of a Firewall.
We're going to see some ways to study an IPv6 Firewall ICMPv6 functionning.

 

 

Practical Test Lab

 
We're going to trigger five types of ICMPv6 messages : ICMPv6 Echo Reply, ICMPv6 Time Exceeded ( hop limit exceeded ) created by an echo request, ICMPv6 Time Exceeded ( hop limit exceeded ) created by an outbound TCP 80 request, Destination Unreachable ( No route to destination ) created by an echo request and Destination Unreachable ( No route to destination ) created by an outbound TCP request.

Here is the setup :

S6e.gif

 

Router1 is our tested-router. PC1 will issue requests and monitor replies using Wireshark network monitor. OS router is an OS IPv6 Router, with a WIreshark network monitor and a Packet Replay software ( Ostinato ).


Please read this post for an example of turning a Windows OS into an IPv6 Router.


To trigger ICMPv6 Echo Reply, we'll just need PC1 to ping OS Router :

ping [OS Router IPv6 Lan Address ]


To trigger ICMPv6 Time Exceeded ( hop limit exceeded ), we'll have PC1 to ping OS Router with a too short TTL :

ping -i 2 [ OS Router IPv6 Lan Address ]


To trigger ICMPv6 Time Exceeded ( hop limit exceeded ) created by an outbound TCP 80 request, we'll setup PC1 hop limit to 2 :

netsh int IPv6 set int [Idx] currenthoplimit=2

and open a web browser on PC1, using the Web Server IPv6 address in the address bar. Please note two things :
. We use the IPv6 address of the web server, to bypass any DNS resolution.
. The currenthoplimit command in Windows seems volatile ( 5s ). A script is needed in Windows OS to perform the command in a 2s loop. Here is a short batch file for this :


for /L %%n in (1,1,100) do (
netsh int ipv6 set int 12 currenthop=2
timeout 2
)
@ECHO [ Press a Key to Close ]
@PAUSE

To trigger ICMPv6 Destination Unreachable ( No route to destination ) we can just plug Router 2 into our CPE, but keep the CPE unpowered. Then, we'll ping an internet IPv6 address and open a web browser on PC1, using an Internet Web Server IPv6 address in the address bar.

We'll be generating Genuine ICMPv6 Traffic from PC1, and monitor the inbound passing packets reaching back PC1 using WIreshark on PC1 :

 

S6f.gif

We'll then do it again, but record on OS Router the five ICMPv6 error messages replies while they are emmited :

 

S6g.gif

 

We'll then be able to replay these 5 error messages at will, from OS Router, without any previous Firewall State ( record ) having been created :

 

S6h.gif

 

By using Packet Replay, we can be sure we're issuing carbon-copy packets, wich are perfectly well crafted. For this we replay them using ' raw mode ' in Ostinato ( no packet dissection / analysis / crafting )

 

Finally, we can use Packet Crafting ( Ostinato packet crafter ) to try to generate all types of ICMPv6 messages that may be difficult to genuinely trigger :

 

S6a.gif

 

Although conclustions based upon messages generated by pure packet crafting have to be considered with precaution, as they may be mis-crafted. It's less reliable than raw-packet replay

 

 

Tests Results and Analysis

 

By comparing outbound genuine traffic with replay traffic, we can see what the firewall allows in by virtue of a state and what is allowed in by virtue of an inbound policy.

We can check the statefull nature of a firewall, as well as the way it treats state-related traffic ( ex : an inbound ICMP message in response of an outbound TCP request )

By using pure packet-crafting, we can wide-shower the firewall wan side, to see for passing messages types.

 

A few practical tips

 

To replay raw packets using Wireshark and Ostinato :

 

Using wireshark, export the packets :

. Edit ) Mark Packet

. File ) Export Specified Packets ....

. format : Wireshark/tcpdump/.... -libpcap ( second choice )

. packet range : Marked packets

 

Using Ostinato, import the wireshark-saved packet :

. File ) Open Streams

. uncheck intelligent import

 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article
19 août 2013 1 19 /08 /août /2013 14:45

We're going to fully test the IPv6 Firewall of an entry-level small business IPv6 Router : Cisco Small Business RV110W

Where the DLink DIR-626L is a very neat, 40$/€ full featured IPv6 Router, with NAS and media streamming functions, great for IPv6 learners and consummers, the Cisco Small Business RV110W belongs to another category :

Its price tag for a beginning : 80$/€.
Its features : RIPng, PPTP/IPSEC VPN Server, SNMPv3, ...
It belongs to the RV serie, which is professionnal-oriented, although its inner hardware is not at the same level as its greater sibblings ( RV220W, .. ).

We're going to fully test here its Ipv6 Firewall.

 

RV110W IPv6 Firewall first contact

 

 

The CISCO RV110W Firewall is very different from the DLink DIR-626L.
First, the firewall management is common to both IPv4 and IPv6, they are not managed in separate zones.

Here is the main management page :

 

S5a.gif

 

Here is the Access Rules tab :

 

S5b.gif

 


Secondly, it is very 'Service Oriented'. In the Service Management tab, we have a set of preset services ( HTTP, FTP, ... ) defined by name / protocol / ports. We can add some custome services ( Secure_POP and ICMP here ) :

 

S5c.gif

 

 

We then use these defined services in the Access Rules tab, granting or denying accesses :

 

S5d.gif

 

 

To diferenciate IPv4 and IPv6 traffic rules, IP Addresses or scopes need to be used in Access Rules.

 

 

RV110W IPv6 Firewall functionning in details

 

 

( Complete details about IPv6 Firewall Testing Methodology here )

 

 

The RV110W is a classic Statefull Firewall.

 

First, the default Outbound policy can be choosen between ' ALLOW ' and ' DENY '.

The default Inbound policy is ' DENY ' and can't be changed :

 

S5e.gif

 

Here are the results of the tests :

 

 

Outbound policy

 

The outbound policy behaves in a very logical and predictible way :

. If ' Default Outbound : Allow ' mode is used, all outgoing traffic is allowed, except if some specific deny out rules have been defined.
. If ' Default Outbound : Deny ' mode is used, all outgoing traffic is dropped, except is some specific allow out rules have been defined.

 

 

Inbound policy

 

The inbound policy, to my surprise, is quite confusing.
Nor is an ' allow in ' rule usefull or needed to allow incomming traffic ( a web server as an exemple ).
Curiously, all is needed and compulsory for incomming traffic is a port forwarding. Two questions arise to my mind then :
. A port forwarding rule to allow an IPv6 Incomming connection ? Or is it a Sheldon Cooper joke ?
. Why then tempting you with the option to create an 'allow in rule' if it is useless, unneeded, and without any effect ?

I'll try to investigate this and post more informations here later.

 

 

ICMPv6 Filtering

It seems that ICMPv6 Filtering triggers a great bug, openning the inbound firewall.

Here is a screenshot of the bug triggering config. First, we need to setup an ICMP service :

 

S5f.gif

 

We then use this ICMP service in a rule :

 

S5g.gif

 

The result : The Inbound IPv6 TCP Firewall gets wide open, letting any IPv6 TCP packet in.

This happens, wether the Default Outbound Mode is Allow or Deny, and wether the Connectiontype is Outbound or Inbound.

This pretty ends here the ICMPv6 testing part.

 

Ingress / Egress Filtering :

 ( more infos about Ingress / Egress filtering here )

 

There is no IPv6 Ingress or Egress Filtering performed by the RV110W.

 

 

Logging

 

IPv6 dropped packets are logged both in the RV110W logs or to an external Syslog Server.

The RV110W logging option allow to setup different logging levels for internal log and Syslog Server.

 

 

 

Final thoughts

 

While integrating the IPv4 and IPv6 sides of the firewall kinds of brightens up the firewall management, it is to a cost of idependence lost for this functions. Beside that, the IPv6 Integration is very complete, with IPv6 packets logging.

Still, two quirks ( Inboud rules / IPv6 port forwarding and ICMPv6 ) need more study, before the picture can be complete.

 

 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article
13 août 2013 2 13 /08 /août /2013 16:58

We'll see here what is a Stateless Firewall, a Statefull Firewall,  and how to use the IPv6 Statefull Firewall in manual mode ( ie without IPv6 Simple Security ), using the DLink DIR-626L.
This will be the occasion to test the DLink DIR-626L Statefull Firewall.



What is a Stateless Firewall

 

Let's start by describing the ancestor of the Statefull Firewall : the Stateless Firewall.


This early type of firewall used ACLs ( Access Control Lists ) : this is a list of static rules, stating which trafic type is allowed or denied for a particular direction ( eg Lan > Wan or Wan > Lan ).


Here is an exemple :

 

S4a.gif

 

imagine we want PC1 to acces any internet web server. We need two rules :


. Allow all TCP 80 traffic out
. Allow all TCP 80 traffic in

 

As you can see it, 2 rules are needed. Authorizing TCP 80 out doesn't automatically allow the replies back in : The two directions are memory-less and unrelated. Each time a packet reaches the firewall, it is checked against the ACLs ( Rules lists ). A Stateless Firewall is memoryless.
This type of firewalling obviously gets quit tedious very quick. And what happens if we want to block all unsolicited incomming TCP 80 traffic ?

 

 

 

What is a Statefull Firewall

 

 

A Statefull Firewall keeps track of what is happening.
Let's take the same example :

 

S4a

 

 

Imagine we want PC1 to acces any internet web server. We need one rules :

 

. Allow all TCP 80 traffic out

 

Here is how it works :

 

If PC1 tries to connect to an internet web server, the Statefull Firewall sees an outboud connection is initiated, checks its rule list, and sees the matching allow rule.
The Statefull Firewall then creates a state ( ie a log ) for this connection, noting source and destination IPs, Ports, and TCP sequence number.
Then, when the reply comes back in, although there is no incoming rule, it can check that there is a log for this connection and allows it back in.

To sum it up : Reply traffic is implicitely allowed.

 

 

 

The Statefull Firewall with more details

 

The Statefull Firewall performs DPI ( Deep Packets Inspection ), checking more than just IP addresses and ports numbers. It does check the CONTENT of the layer 4, and even sometimes looks at layer 7. But it does this only for the first packet of a connection or stream, eventually allowing the connection / stream and creating the state ( log ) for this connection / stream.

Statefull Firewall functionning is easy with TCP, as TCP is a connection-protocol, whith clear start and end signals ( SYN / FIN-ACK )
For a TCP connection, the first state is created when the initial three-way handshake is done .The state is closed when the two-way connection-end is done is sent.

For UDP, which is connectionless, the state is created with the first SYN, and closed using timers.
For ICMP, which is connectionless and even one-way messages sometimes, things get even more tricky to manage for the Statefull Firewall.
But Statefull Firewalls are very wit things, that are learned in protocols and can manages many layer > 4 types.

One Final note : Statefull Firewalls are a little CPU-intensive at the first packet inspection / state creation for a connection, but very light and fast for the following packets, as they only keep track of the state of the connections ( IP addresses, Ports, and states ).


Stateless Firewalls are more CPU intensive, as the rule matching lookup has to be redone for each packet.

The other type of filtering, Proxy, is more CPU intensive than Statefull FIrewall too.

 

 

An IPv6 Statefull Firewall practical implementation


We'll use our trustfull DLink DIR-626L to perform the tests. Please see this post about Firewall Testing methodology.
First, we uncheck IPv6 Simple Security ( and Ingress Filtering ) :

 

S4b.gif

 

Here is the result of the tests :

S4c.gif

 

Everything behaves as expected, in a very logical way.
We can check the Statefull Nature of this firewall, as a simple ' allow out ' rule does allow the reply trafic back in.
One thing to note, that doesn't show in the table, is that ICMPv6 traffic is affected by the rules in a strict way ( whereas using IPv6 Simple Security, ICMPv6 traffic is allowed, overiding the allow mode restrictive ways. See last post ).
 
Lets now try some real-life configurations :

 

S4d.gif

 

We want our internal network computers to be able to freely access the Internet, we want our Web ServerPC1  to be accessible from the outside, and all other inbound ports to be closed.

 

We can do it either using the allow mode, with two rules :
. Allow everything Lan > Wan
. Allow TCP 80 Wan > Lan

Or using the deny mode, using 3+1 rules :
. Deny TCP 1-79 Wan > Lan
. Deny TCP 81-61535 Wan > Lan
. Deny UDP Wan > Lan
. Deny ICMPv6 Wan > Lan ( Optional )

Here is the tests result :

 

S4e.gif

 

It looks like there is a problem with the deny mode implementation. Further investigations show that using TCP port 1 or TCP port 65535 in a deny rule totally crashes the TCP Statefull Firewall engine.
Further testings shows some others such bugs in the ' deny mode '.


The DIR-626L firmware is very fresh and new, at its third occurence at the time of this writing ( firmware version 1.03 ). Furthermore, as an entry-level router, testing and fixing such things may be less of a priority for DLink engineers than higher-grades entreprises hardware, that rightfully deserve a top notch service. I'll try to investigate and test more, and update the infos here.
As for now, the deny mode is useless for me, and only the allow mode is usefull.

 

 

Screenshots of bug-triggering configurations

 

 

Case1

 

Case2

 

Case3

 

 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article
13 août 2013 2 13 /08 /août /2013 16:01

We'll study here IPv6 Simple Security, and test an IPv6 Router implementation of this feature.

The tests will be performed using a D-link DIR-626L, which is a 40 $/€ neat, feature-full IPv6 Router.


IPv6 Simple Security

IPv6 Simple Security refers to RFC 6092, whose aim is to provide IPv6 Consumer equipments with a default setup that copies the behaviour of an IPv4 NAT Router :

 

To allow everything out
To deny everything in
To allow in replies to recent outgoing requests

IPv4 NAT has proven to be a simple, secure default setup for most of the consumers, notwithstanding the troubles it did create for less typical uses ( need for port forwarding, IPSec problems, VoIP problems, ... ).
The goal of IPv6 Simple Security is to provide people with a default, secure, zero-setup firewall mode.

 

IPv6 Simple Security has some specifications about default IPSEC and Mobile IPv6 firewall ingoing pass-through.

 

Practical Implementation and test

Please refer to this previous post for firewall testing metodology.

We'll :

    . Scan the firewall from both sides
    . Scan the router firewall using the ISP network scanner
    . Do some live internet use to check this IPv6 Simple Security behaviour.

Here is the checkbox to enable IPv6 Simple Security. Notice that ticking it automatically ticks ' IPv6 Ingress Filtering ' ( See Previous Post )

S3a.gif

Here is the test setup :

 

S3b.gif

 

The Server is running a Web Server and a Mail Server. It has 7 open ports, including port 80.
We'll scan the Server Through the Router, and then switch sides ( Wan Server / Lan PC1 ) and rescan.
We'll add a rule about TCP port 80, and test it in each combinaison, to see its effects.

Both the Zenmap results and the Wireshark log will be checked, for finding open ports and passing packets.
Here is the resulting table :

 

S3c.gif

 

This shows a certain number of things :

1. IPv6 Simple Security is functionning as expected, allowing trafic out, trafic back in, but not original out trafic in.

2. Using IPv6 Simple Security, the Wan side is closed, whether the firewall is set to off, ' allows rules listed ' or ' deny rules listed '.

3. IPv6 Simple Security allows by default some ICMPv6 traffic through, unless a specific deny rule is created. This is by design ( RFC 4890 )

4. Using IPv6 Simple Security, setting the firewall to ' allows rules listed ' shuts down the Lan > Wan traffic. This leads to a kind of eerie conclusion :

    ' deny rules listed ' mode is not restrictive : it doesn't cancel the IPv6 Simple Security wan block
    ' allow rules listed ' is restrictive : it cancels the IPv6 Simple Security outflow
 
    This leads to the fact that if we want to open an incomming port ( web server hosting as an exemple ), we have to use the 'allow rules listed' mode, and thus have to create an outgoing rule for normal internet outgoing traffic, effectively quitting IPv6 Simple Security to the realm of manual statefull firewalling. IPv4 NAT usually allows to create an incomming rule, while keeping the automatic mode. Here is how an incomming port opening has to be done on the Dlink DIR-626L :
(S3f.gif)


We then test the Firewall online, using the ISP online scanner :

S3d.gif

 

 

The result are in-line with the preeceding test, and confirm it.


Finally, a few Web surfing tests confirm the Dlink IPv6 Simple Security well behaving.


A few final notes about the Dlink DIR 626-L IPv6 Simple Security Firewall :

 

o As stated on the previous post, linking up two DIR 626-L using Ingress Filtering results in the inner Router traffic being dropped by the Internet Gateway :

 

S3e.gif

 

and ticking IPv6 Simple Security automatically ticks Ingress Filtering. An ' allow all out ' rule has to be created on the Internet Gateway Router.

This is kind of new compared to IPv4 Routers easy link-up ( cascading ).

 

 

o Throughout the test, never any dropped packet was ever logged, although the right logging options were set, and the logs were checked using both the Router's admin webpage, and the Router connected to a Syslog Server.

o A quite curious bug in the firewall settings :

Although the code for 'any IP' is :: ( comma comma ), once saved, it gets blank. Let's say you create rule 1 with any IP to any IP addresses scopes. When saved, the :: get replaced by a blank space. Everything works OK thus. But, while making some changes to say rule 3, you need to refill rule 1 IP scopes with the needed ::. Leaving the blank space will give you an ' Invalid IP address ' message. Not easy to guess at the beginning.

 

 

RFC 4890

 

The RFC 4890 clarifies the ICMPv6 recommended filtering rules on Firewalls. Some content states that :

 

. ICMPv6 is required for good IPv6 functionning, so only some types of ICMPv6 traffic should be dropped.

. Due to the large IPv6 host ID scopes, and in case a non-predictible host ID scheme is used ( temporary or one-time-randomized addresses ), network scanning ceases to be a concern.

 

So it is to be expected, that pings and tracerts pass the IPv6 Firewalls by default. A deny rule has to be used to explicitely block them :

 

(S3g.gif )

 



 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article
9 août 2013 5 09 /08 /août /2013 14:16

We'll see here what is an Edge Network, ' IPv6 Ingress Filtering ', and the IPv6 Ingresse Filtering RFCs.
I'll uses a DLink DIR-626 L for this study, so we'll be able see its IPv6 Firewall Implementation.

 

 

Edge Network

An Edge Network is the part of a network that makes the connection to others external networks : ISP or partner organisations for an enterprise, other ISPs and customers for an ISP.


It can be a single Router, or a complexe zone built with redundancy, load balancing, etc ...
Its hosts too the public-access services : Web Servers, FTP Servers, etc ...

 

The Edge Network is a single point of failure for a network, and a partly-open zone security-wise. A second layer of security ( ie Firewall ) usually separate the Edge Network from the Inner Network ( Core Network ).

 

Here is a basic entreprise Edge Network :

 

S2a.gif

 

Here is an enterprise Edge Network built with Redundancy ( the Inner Network is built with redundancy here too ) :

 

S2b.gif

 



IPv6 Ingress Filtering

 

Ingress Filtering with a short definition :
" IPv6 Ingress Filtering is a special rule, implemented in routers, that only allow incoming packets that have a valid source address. Valid packets are allowed to be routed, non-valid packets are either dropped or bounced back. The purpose of Ingress Filtering is to strongly reduce source-spoofed packets traffic which is used by DoS. "


Ingress filtering is a set of rules, aimed at curtaining spoofed IP addresses to enter or cross a network. The goal is to prevent DDoS, as well as to provide traceability to the source of these DDoS.

 

Another benefit of Ingress Filtering is an enhanced security, as no exterior host can spoof an internal address to access management interfaces.

 

Ingress filtering is typically implemented at edge networks, of an organisation ( endpoint network ) or of an ISP ( transit network ).

 

Ingress filtering at transit networks can filter too the so called ' Martian Addresses ', ie non internet-routable addresses ( 1::, fc00::/7, ::/128, ... )

 

It may be implemented using different ways. The simplest implementation, found in consumer equipments,  only allow incoming packets that have a source address in the subnet of the router receiving interface.
Ingress Filtering is described in RFC 2827 and RFC 3704.

 

 

Practical implementation and test of Ingress Filtering

Our D-Link DIR-626L does offer an ' Enable IPv6 Ingress Filtering ' checkbox, in the IPv6 Firewall menu. Here is how it looks, in an open-firewall setting ( which is not advisable except for testing purpose ) :

 

S2c.gif

 

 

The test consist in sending spoffed address packets through the router, and monitoring with Wireshark network monitor on the other side if they manage to get through. The test has to be done in both directions, and try all of the RFC 3704 implementations ( no route presence, matching route presence, non-matching route presence, default route presence )

 

The test shows that  it does enable a basic ingress filtering : It compares the subnet prefix of a reveived packet source address to the receiving interface subnet prefix, and discards non-matching packets.


Please note that while this works, this is not the exact RFC 2827 / RFC 3704 implementation which is found in more complex equipements ( ISP and enterprise-grade routers )

 

Another thing to note is that the DLink only filters outgoing packets ( from Lan to Wan ), and lets all incomming packets get in. So this is more of an egress filtering in my opinion. It curtains spoof packets to pass the router, leave the network, and enter the ISP network.
Maybe this misnommer confusion comes from the ' Ingress Filtering ' term that has become a generic word for Ingress and Egress Filtering techniques.

 

One last detail to note : As the DIR-626L ingress filtering is based on the receiving interface prefix, the link-up of two DIR-626L will result in the 'Inner Network' subnet traffic being dropped by the first Router ( Internet gateway ) :

 

S2a

 

The solution to this problem is to create an ' allow everything out ' rule for the Internet Gateway. Doing this will override the ingress filter :

 

S2e.gif

 

RFC 2827 / RFC 3704 Ingress Filtering Implementation

 

Theses RFCs describe 5 types of Ingress Filtering :

 

Ingress Access Lists : a static list of valid prefix is manually maintained for each interface. This is the original RFC 2827 implementation

 

Strict RPF ( reverse Path Forwarding ) : the subnet prefix of the received packet must be in the routing table of the router, and must point to the receiving interface.


Loose RPF Ignoring Default Routes :  the subnet prefix of the received packet must be in the routing table of the router, without concern about the receiving interface match.


Loose RPF :  a route must exist in the routing table for the subnet prefix of the received packet, even if it is only a default route


Feasible Path RPF : Is a Strict RPF-evolved, which can manage assymetrical routing ( the path is different for the two travel directions of a network link ), using BGP as an exemple.

 

These implementations are more complexe than consumer-equipements implementation. For an example, notice Strict RPF : by checking a reverse route existence on the receiving interface instead of just a prefix match, it allows to do ingress filtering through multi-hops, not just on the local-link.



 

Repost 0
Published by computer outlines - dans IPv6
commenter cet article

Présentation

  • : Computer Outlines Blog
  • : Blog mainly focused over IPv6, Windows Server, and Networking in general.
  • Contact

Recherche

Liens