Overblog Suivre ce blog
Administration Créer mon blog
1 octobre 2013 2 01 /10 /octobre /2013 02:02

We'll see here how to setup PPTP for real use, covering issues like Wan access, port forwarding, and PPTP passthrough. We'll use a Cisco Small Business RV110W as a VPN server, Debian 7.5 LXDE as VPN client, and a DLink DIR-626L to test PPTP Passthrough.

 

[ Last Edited June 21 2014 ]

 

1. Debian PPTP Client Setup

We first install the required packages :

sudo apt-get update
sudo apt-get upgrade

sudo apt-get install pptp-linux
sudo apt-get install network-manager-pptp
sudo apt-get install network-manager-pptp-gnome

 

( If you're not using LXDE or gnome, the network-manager packages might be different )

 

2. Simple Lan PPTP Setup

We'll first see the simplest topology, a local Lan Access :

 

VPN 3 : PPTP setup

We setup the RV 110-W for PPTP :

Menu Tab : VPN Client TAB

. Allow the PPTP Server

. Choose VPN Server IP and leased IP range if needed

. Allow MPPE encryption

. Create client with password

[ reminder : use a real 128 bits entropy password, ie 20 characters long using numbers, lower-case letters, higher-case letters, special characters ]

VPN 3 : PPTP setup

We then setup the VPN tunnel in Debian by left-clicking on the network-manager :

VPN 3 : PPTP setup

We fill-in the gateway, user/password, and enable MPPE in advanced options.

IPv4 settings can be left on automatic ( VPN ) :

VPN 3 : PPTP setup

Here we have our VPN tunnel set :

VPN 3 : PPTP setup

3. Simple Lan PPTP Setup with exit router

Here we have a little more complexe situation, where PC1 ( Client ) has to exit through a first router ( DIR 626 L ) before reaching the VPN Server :

 

VPN 3 : PPTP setup

There is nothing new to actually setup here, as the DIR 626-L handles the situation quite brilliantly. No firewall-opening needed, neither the need to tick the DIR 626-L PPTP Pass-through.

The DIR 626-L PPTP Pass-through option will only be needed if multiple concurrent PPTP sessions are initiated from the DIR 626-L Lan.

 

4. Lan PPTP Setup with entry Router

Here we have to pass-in a first router ( DIR 626-L ) before reaching the PPTP server :

 

 

VPN 3 : PPTP setup

Things get a little more complicated here, but still quite easy : we just need the DIR 626-L to forward TCP port 1723 to the VPN Server :

VPN 3 : PPTP setup

5. PPTP Server reachable from Wan

The last topology will allow access from Wan :

 

VPN 3 : PPTP setup

We need our Internet Gateway to handle-in the PPTP protocol ( ie TCP port 1723 and GRE protocol ). We have three options here :

1. The Internet Gateway is PPTP friendly

We just have to forward port 1723 ( and protocol GRE = IP protocol 47 eventually ).

2. The Internet gateway can be bridged

If the Internet Gateway can be bridged ( ie its router can be deactivated, so that it performs like a bridge ), any protocol / port will freely flow-by

3. We put the PPTP Server in a DMZ

We setup our Internet gateway so that the PPTP Server IP is in DMZ

Repost 0
Published by computer outlines - dans VPN
commenter cet article
29 septembre 2013 7 29 /09 /septembre /2013 12:32

We'll review here PPTP VPN, how it works, and its current security state.

 

VPN2c.gif


For the basis knowledges and theory of VPN, see this post

Last edit : June 30 2014

 

 

PPTP theory
 

PPTP ( Point-to-Point Tunelling Protocol ) is the oldest type of VPN protocol. It is versatile ( it can encapsulate other layer 3 protocol than IP ), widely implemented ( most computer OS and mobile OS support PPTP ), and manage to traverse firewall quite easily.

Moreover, it is fast and light for the CPU.

 

Here is the PPTP encapsulation used to build the tunnel :
 

VPN2b.gif

 

VPN2d.gif

 

 

 

 

The tunnel is initiated and maintained with a control channel using TCP 1723
The tunnel itself uses GRE ( IP protocol 47 )
So two connections are used to maintain the tunnel, a control channel and the GRE tunnel itself.

Here is the PPTP tunnel, in a host-to-site configuration. The host initiates the connection :

 

VPN2e.gif

 

 

Important to note is that the GRE tunnel, using PPP, is able to tunnel other layer 3 protocols than IP.

 

 

 

PPTP IP networking

At the IP level, the PPTP Server creates a private subnet, on a different range than its native lan subnet, and starts routing this two subnets. It assigns itself one IP, and readies to leases to VPN clients IP addresses in this range, advertising itself as a gateway :

 

VPN2f.gif

 

 

To be noted is that PPTP creates a virtual network interface, both on the PPTP server and on the PPTP clients.

The DHCP advertisements are advertised with a minimal metric, so that all the client's traffic will use this gateway, and not its local lan gateway.

If PC1 traffic is not directed to Subnet B, The VPN Gateway will route it to the Internet using its WAN interface. Here is the path of a client's outbound connection to the Internet :
 

VPN2g.gif

 

 

A few final notes :

Subnets A, B and C have to be different, for the VPN routing to function. This may lead to the need to renumber the Home Lan Subnet ( Subnet B ) to a rarely used subnet range ( example : 192.168.197.0 / 8 )

SIte-to-site PPTP VPN or Host-to-Host  PPTP VPN behave in a similar way.

 

 

 

PPTP and NAT


PPTP uses a GRE tunnel, and GRE uses no ports. This creates a difficulty for the IPv4 NAT Router to identify PPTP VPN sessions and direct to the right LAN host. This scenarios may happen :

 

1. The IPv4 NAT Router doesn't understand what is happening, and drops the traffic.

 

2. The IPv4 NAT Router manage to handle a unique PPTP VPN session, linking the GRE tunnel to the last outbound GRE LAN host. But it can't handle multiple simultaneous or fast switching PPTP VPN sessions.

 

3. The IPv4 NAT Router performs Deep Packet Inspection and keep states, to bind GRE WAN IPs and LAN hosts.

Or the IPv4 NAT Router understand GREv2, which adds an ID tag.

In this case, multiple simultaneous or fast switching PPTP VPN sessions will function seamlessly

 

The ' PPTP VPN Passthrough ' option may need to be ticked on the IPv4 NAT Router.

 

( I have an experiment going on, to poll-out Wifi Hotspot PPTP VPN functionning. I'll post results here )

 

 

 

PPTP Security

PPTP provides authentication. Beside, MPPE ( Microsoft Point to Point Encryption ) can provide encryption, and MPPC ( Microsoft Point to Point Compression ) can provide compression.

Here are the available authentication methods with their security features :


PAP                         Clear text authentication
                                No MPPE support

CHAP                     Good, protection from replay attack, no password sent
                                No MPPE support

MSCHAPv1           Trivial to crack, using a XOR compute
                                MPPE support

MSCHAPv2           Dictionnary attack
                                Brute force attack ( 23 hours )
                                Retro-protocol attack ( towards MSCHAPv1 )
                                MPPE support

EAP-TLS                Secure, but requires public key infrastructure
                                 SSL encryption


PAP is obviously unsecure. CHAP doesn't support MPPE. MSCHAPv1 is unsecure.
So we only have MSCHAPv2 and EAP-TLS left from a security standpoint.

MPPE supports 40 bits and 128 bits encryption. 40 bits is totally insecure, so 128 bits is mandatory.
Beside, the authentication and encryption protocols are just as secure as the password length, so using a 128 bits password is mandatory too.

note : MPPE is subject to bit flipping attacks. There is no Data Integrity here.

note 2 : MS-CHAPv2 strength is equivalent to a single DES ( 56 bits )

Here is a chart to sum-up the Data leaks of each option :

 

VPN2i.gif

 

( IPs is for source and destination IPs encryption, not tunnel endpoints encryption of course ).

( The EAP-TLS line will be completed soon )

 

It is to be noted that two options ( if available ) somehow makes brute-forcing attacks a little more difficult :

 

. Stateless encryption : Key is changed in each packet ( vs Statefull encryption, where key is changed every 256 packets )

. Compression

 

PPTP data Leaks

PPTP has several issues with data leaks. Let's review them one by one.

Tunnel stability : If the tunnel gets down for whatever reason, this will remain unnoticed for a lapsetime that will allow data to freely flow through the unprotected path. This issue is difficult to mitigate. Solutions to this issue :

. Using firewall rules

. Subtly changing the OS routing tables+using all static IPs ( Ex : Set all static IPs, enter a bogus default gateway, and add a static route for the PPTP Server IP : No packet will leave the LAN, except towards the PPTP server. The PPTP server will then set itself as a default gateway all through the tunnel life. When the tunnel gets down, packets are again trapped in teh LAN).

 

IPv4 DNS leaks : When using DHCP, the registered DNS server may be the local router wich acts as a DNS proxy ( ex : 192.168.1.1 ). This address may be kept while creating the tunnel ( Using Windows mainly ). In this case, the DNS requests might not take the VPN path : 192.168.1.1 being a local network, the VPN might get bypassed .

Another case may be the VPN DNS being a little too long to respond, the OS may failover to the regular registered DNS.

The simplest solution to this problem is to use static DNS IP of a trusted third-party provider ( ex : OpenVPN, Google Public DNS, Comodo Secure DNS, ... ) on all network interfaces ( normal or VPN ).

 

IPv6 leaks : PPTP tunnels almost never support the transport of IPv6 packets. Modern OS being set to prefer using IPv6 over IPv4, if there is an available IPv6 connectivity, the unprotected path will get preferred. The simple solution to this is to disable IPv6 on the network interfaces.

 

 

PPTP Security Conclusions

In the end, the two PPTP useable options are :

. MSCHAPv2 ( with 128 bits encryption/128 bits entropy password, and optionally stateless encryption+compression )
. EAP-TLS

First, let's state that PPTP is always way better than nothing while using a public wifi hotspot.

MSCHAPv2, while vulnerable, may be enough in many cases assuming a complexe password is used. You need to evaluate if cracking this PPTP is of any interest for someone, and worth the time and money spent. Still, CPU, GPGPU and ASICS crunching power is on a ever upslope, so these 23 hours of brute-force resistance are allready weakened as we're writing here.

Finally, there are the stability and leaking issues the really need some extra-care.

If we want a real secure VPN, L2TP, IPSEC or SSL VPN is needed.

 

Repost 0
Published by computer outlines - dans VPN
commenter cet article
24 septembre 2013 2 24 /09 /septembre /2013 08:47

We'll lay down here some basis for fully understanding and using VPN technologies.

This post will be augmented, if some new basis are needed.

 

 

VPN

 

Basically, VPN makes use of tunnels, to join together several distinct networks, or to allow a remote user to join a network. As the datas have to cross the public Internet, the VPN tunnel allows to keep that data private and to control access to the private network. Here is a site-to-site VPN :

 

VPN1d.gif

 

VPN can be site-to-site, host-to-site or host-to-host.

 

VPN relies on three ideas : Tunnelling, Authentication, Encryption
These three aspects must not be confused :

Tunelling is the fact of putting a network stream inside another network stream.
Authentication allows each endpoint of the VPN tunnel to authenticate, as well as guarentee data integrity.
Encryption does encrypt the payload of the stream, ie the content

 

 

 

VPN Security

 

For a VPN to be fully secure, we need :

a secure authentication


    . authenticated
    . not spyable ( sniffing the traffic does not allow to get the VPN login password )
    . not replayable ( sniffing and replaying the VPN login traffic does not work )
    . integrity verified ( the message has not been tampered with or changed )

a secure encryption

 

    . encrypted
    . using a good encryption scheme ( neither subject to brute-force attack or cryptographic weakness )
       
 
This is to make clear the difference between authentication and encryption.

Please do note the difference between data integrity and data encryption : Data integrity prevents from writing the datas ( changing them ), Data encryption prevents to read the data ( unencrypting them )

Data integrity may be challenged by bit-flipping attacks as an exemple.

Data encryption may be challenged by brute-force attacks as an exemple.

 

 

 

Tunelling
 

Here is a network representation of a site-to-site tunnel :

 

VPN1c.gif

 

The native IP packets are added with a tunnel headers, and encapsulated into transport IP packets. A protocol manages the tunnel seamless functionning. At the tunnel endpoint, the IP packets are uncapsulated, stripped from the tunnel headers, and routed to the remote network.
Tunelling is not only used with VPN, it is used for 6in4 or 4in6 tunelling as an exemple.

OSI-wise, encapsulation can be represented this way :
 

VPN1a.gif

 

Here is the more OSI-wise network representation of our site-to-site VPN :

 

VPN1b.gif

 

 

 

Password entropy / Password strength

Password entropy, also named password strenght, is a representation of the number of attemps necessary to exhaust all the combinaisons of a password, and thus find it with certainty.
It is usually represented in bits, where number of combinaisons=2^entropy.
the entropy value can be rounded down.

exemple : a password made of 8 numbers = 8x10 = 80 combinaisons
80 ( decimal ) = 101 0000 ( binary ) = 7 bits
entropy is <7 bits ( 6,3219... )

exemple 2 : a password made of 8 higher case letters = 8x26 = 208 combinaisons
208 ( decimal ) = 1101 0000 ( binary ) = 8 bits
entropy is <8 bits ( 7,700439... )

exemple 3 : a password made of 8 high case and low case letters = 8x52 = 416 combinaisons
416 ( decimal ) = 1 1010 0000 ( binary ) = 9 bits
entropy is <9 bits ( 8,700439... )


As we can see, the biggest the data pool used, the highest the entropy for the same password length.

The exact formula for entropy with L=password length and N=Pool complexity :

VPN 1 : Basis and theory

Other aspects weaken actual entropy :

. character repetition ( 4444 vs 1423 )
. character patern ( 1234 vs 1423 )
. dictionnary presence ( home vs hmeo )
. keyboard topological pattern ( qwerty, number keys symbols, ... )
. language specificites ( In english q is mostly followed by u, qu is weaker than qz )
. other ( common expressions, personnal informations, ... )

One other metric that is often used is the number of attempts necessary to try half of the possible combinaisons, as it is this value that goes over 50% hit chance.

One interesting note is the importance of a good RNG ( random number generator ) for keeping a good entropy : either using a true RNG ( hardware chip, dices, ... ) or a good-enough pseudo-RNG ( Linux OS offers a good OS pseudo-RNG that mixes-in lots of system values for good-enough randomness )

Repost 0
Published by computer outlines - dans VPN
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

Présentation

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

Recherche

Liens