Overblog Suivre ce blog
Administration Créer mon blog
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 )


Here is the test setup :




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 :




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 :

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




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 :




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 :




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




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





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




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




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
8 août 2013 4 08 /08 /août /2013 13:40

We'll see a few methods of Firewall Testing, with a special focus over IPv6. We see too some considerations over Edge Network design in the perspective of Testing / Monitoring and Security.



Simple Firewall Testing


A basic way of performing Firewall Testing is to have one PC perform a ZENMAP/NMAP network scan, and the other PC a Wireshark Network Monitoring in promoscious mode. It is easy to see which packets managed to pass the Firewall :





The first scan is directed toward PC2. This is a focused scan.

The second scan sweeps the first IP addresses of the PC2 subnet ( hosts 0 to 2FF = 768 hosts ). This is a mild-focused scan.

There is no point scanning the whole subnet, due to the scope of an IPv6 subnet ( 2^64 = 16 billion billion hosts ).


The use of filters in Wireshark eases the monitoring task. Here are the two most important filters :


ipv6                                    Displays only IPv6 Traffic :




ipv6.src == [IP]              Displays only the IPv6 Traffic whose source is [IP]           ( [IP] is PC1 IP here ) :




We can now check if any packet that isn't allowed to manages to pass the firewall


Inbound Firewall Testing


To test the Edge Network Firewall, an outside scan is needed, as we can't place our scanner between the CPE and the Phone plug/Optical plug :



Some Tunnel Brokers do allow their registred custommers to scan their own subnet from the outside. Hurricane Electric, as an exemple, does provide an outside NMAP web interface to their registered IPv6 tunnel users.






Internet Gateway/Firewall Decoupling



A better network architecture security-wise is to separate the Internet Gateway ( ie CPE modem ) role and the Firewall role. Doing so, we have full control over the Firewall model, functionnalities, settings. Further more, we can insert ourselves between the CPE and the Firewall, for intensive testings :





Here is the a full network map, with Inner/Edge Networks and testing/monitoring spot :




Please note that beside a perfect testing point, we did created a great monitoring point too.




Additional things to test


There are more things to check beside simple firewall pass-through :


. Ingress / Egress filtering

. Dos / DDoS resistance

. UPnP behaviour / disabling

. WPS behaviour / disabling


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

The Structure of the IPv6 Packet and its Extension Headers.


The IPv6 Packet is made of three part :

. A fixed mandatory header
. Optional extensions headers
. A payload ( TCP, UDP, ICMP, ... )





The extension headers are optional. They should only appear once, except for the Destination Options header, which may appear twice.

The fixed and extensions headers each hold a Next Header field, that identifies the next header by its IP protocol number ( ICMP=1, ICMPv6=58, TCP=6, UDP=17, GRE=47 ... ). Thus they are linked together, from the fixed header to the optional headers to the payload. Here are the IPv6 Extension Headers, in the recommended order :





Here are some examples of Extension Headers chaining :









Please note that the Hop-by-Hop Extension header MUST be placed first. This is because Intermediate nodes don't have to examine headers, except Hop-by-Hop Extension header. So the Routers just have to check the first Extension header. This is to improve Routers performance.


Here are some Fixed and Extension Headers with details :




Do note that the Fixed header's Payload length field = Extension headers length + upper layer length








One thing to note :


. Header Ext Length is the Extension Length minus 8 octets




The IPv6 Packet metrics





The Fixed header is 40 octets in size, and each Extension header is a multiple of 8 octets.

Thus, the IPv6 packet size is ( in octets ) : 40 + n1*8 + n2*8 + .... + p


Routers can't perform fragmentation over IPv6 packets they forward, they return a ICMPv6 packet too big error message. Hosts are supposed to discover the network path MTU through the use of Path MTU Discovery. All links on the network are supposed to be capable to forward IPv6 packets of at least 1280 octets without fragmentation.


If the Host's software upper-layer-protocol doesn't perform Path MTU Discovery, the IP layer can use the IPv6 Fragment Extension header and perform fragmentation by itself.


Finally, let's re-check the Fixed header payload length :






The Mobile IPv6 Header


The Mobile IPv6 header is like an IPv6 Extensions headers, placed after an IPv6 Fixed header. There are a few differences :




Payload Protocol is the same as the Next Header field.

Header Length is the same as Ext Header Length ( ie length minus 8 octets )


The Mobile IPv6 header is still a multiple of 8 octets in size.


Repost 0
Published by computer outlines - dans IPv6
commenter cet article
31 juillet 2013 3 31 /07 /juillet /2013 16:47

I'll briefly outline Windows Server 2008 R2 Password recovery in a special context, where the password has been saved by the RDP client but is forgotten/lost.

It can so that we are able to login as an administrator, but can't recover the password.

here is the basic solution. Do take notice that some datas will be lost in the process ( encrypted files, saved passwords, ... ) :


1. Login using an administration account

2. Create a second administrator account+password

3. Allow this second administrator account in RDP access.

4. Login using this new administrator account

5. Change the first administrator password :


            Computer Management ) Local Users and Groups ) Users


            Right click on the the first andministrator account ) set password





Some datas will be definitively unuseable : Encrypted files, Web Browser saved passwords ....


To avoid this, a password recovery key needs to have been created before.

Repost 0
Published by computer outlines - dans Windows Server 2008 R2
commenter cet article
31 juillet 2013 3 31 /07 /juillet /2013 10:18

We'll see here the Reverse DNS delegation mechanism in full details, the practical Reverse DNS implementation, as well as the debugging techniques. Please be sure to have read the first two parts, as they lay som basic principles : part1 part2 .We'll only see some Reverse DNS Specifics here.





The Reverse DNS authority delegation




The Reverse DNS authority delegation follows the IP scopes address delegation. The IANA gives a scope of addresses to a RIR. This RIR handles a subset of this scope to an ISP or Tunnel Broker. Finally, the ISP / Tunnel Broker handles a sub-subset of that scope the custommer. [ The scope portions depicted here are fictionnary and illustrative only ) :






Reverse DNS Practical Delegation


In a case of a single public IP, either IPv4 or ' IPv6 WAN ' ( CPE WAN or IPv6 Tunnel Endpoint ), the ISP/Tunnel Broker usually only allows settings through its management interface ( webpage ).


In case of a full scope ( which is quite common with IPv6 ), the ISP/Tunnel Broker may allow external control of the Reverse DNS through a DNS Servers duo. The requierments are the same as with domain zone delegation ( link ) :


. 2 NS Records in the ISP DNS Servers

. at least 1  Glue record related to these 2 NS Records at the ISP DNS Servers

. 2 Network-topologically distinct DNS Servers with the same zone record :

      . 1 SOA Record

      . 2 NS records

      . A or AAAA records for the Name Servers :






Reverse DNS NSLOOKUP verifications




( to be completed )


Repost 0
Published by computer outlines - dans Windows Server 2008 R2
commenter cet article
30 juillet 2013 2 30 /07 /juillet /2013 17:08

Here we'll see precisely and completely the domain name delegation mechanism. We'll see how to setup the domain NS records, how to setup public authoritative DNS Servers, and how to check NS records throughout the Internet DNS hierarchy. We'll focus especially over IPv6


In the usual way of naming, NS ( Name Server ) and DNS Server have the same meaning, although the right naming is Name Server.

Likewise, domain name are zone have the same meaning, althought the right naming is zone.



The Domain Name Authority Delegation



Here is the Domain Name authority chain :





While granting authority over a domain name, access to the associated NS records is granted.
The access to the NS records is granted by means of the NS records access in the TLD ( top level domain ). These NS records state which NS servers are authoritative for this domain name.

Please notice that the Registrar is acting as a proxy : He is delagated the authority over the domain example.com to handle it to the custommer. The custommer has acces to the TLD example.com NS settings through the registrar management page. The registrar is a proxy :




The other setting in the TLD records that is accessible to the custommer is the glue records ( A or AAAA records : example.com DNS Servers hostname to IP address résolution ).


There are at least 2 authoritative DNS Servers for a zone ( ie domain name or subdomain name) : A primary Name Server ( Master ) and a Secondary Name Server.



The DNS servers which are given authority over this example.com domain must comply to a set of rules. They are :

. 2 distinct DNS Servers ( one primary and one secondary), located on topologically distinct networks ( ie different origin automomous system in the BGP routing table )

. they each contain one SOA record, 2 NS records, and the A/AAAA records coresponding to the two NS records.

. The SOA records and NS records are identical throughout the zone ( zone = domain name )


. At least 1 glue record must be on the TLD records

Here is the basic DNS Servers implementation :






3 possibilities of DNS Servers Delegations


There are 3 possibilities for DNS Delegation :


1. Registrar hosted DNS :


In this case, the registrar hosts a DNS server that the custommer has acces to. Only one DNS server is represented here :





2. Third-party hosted DNS

In this case, the DNS hosting is performed by a third party. The NS records point to this third-party DNS servers.

Only one DNS server is represented here :




3. Locally hosted Public DNS Servers :


In this case, the DNS Servers are hosted locally. Only one DNS Server is represented here :




Here is the full Network Map, with the minimum 2 DNS Server set required :







A Public DNS Servers set Setup




a few notes :

There is one primary server and at least 1 secondary server.
The secondary servers automatically update to the primary server.
They all contain the same basic information :

. same SOA record
. same NS records
. same A or AAAA records for the NS records hostnames resolution
. TCP and UDP ports 53 must be accessible ( DNS querries and Servers sync )




please note that all Name Servers have records that list all Name Servers for that zone ( ie ns1 has both ns1 and ns2 NS records, ns2 has both ns1 and ns2 records)

The SOA record

The SOA record states authoritative informations about a DNS zone.

. primary name server
. email of domain admin
. domain serial number
. timers related to zone refresh.

here is a typical SOA record :

example.com SOA 86400 ns1.example.com hostmater.example.com
2013072004 3600 600 86400 3600

here is the meaning :

[zone] SOA [Primary NameServer] [E.mail of domain admin]
[Serial Number] [T1] [T2] [T3] [T4]

[zone] is the domain name ( or subdomain )

[TTL] is the zone records time to live for outside DNS servers

[Primary NameServer] is the FQDN of the primary Name Server of the zone

[E.mail of domain admin] is noted with a dot instead of a '@'

[Serial Number] is an incremental number, upped at each of the Primary NameServer record change.It states to the secondary Name Servers of the zone the records have changed, and that they should sync.
It is written in the form [Year][Month][Day][Number]

[T1] Refresh time : time before the Secondary Name Servers recheck the Zone Serial Number ( in seconds )
[T2] Retry time : time before a Secondary Name Servers retries a zone transfert after a failed one ( in seconds )
[T3] Expire time : time of failed zone transfert, before a Secondary Name Servers expires its zone file, and stop answering querries ( in seconds )
[T4] minimum TTL : how long outside DNS servers should keep the zone datas in their caches.

NSLOOKUP and Name Servers Querries

To check the Name Servers records, we can use the NSLOOKUP command.
It is especially usefull, to check the contend of the TLD records, as well as differences between the TLD records and the authoritative Name Servers records.

let's check the example.com NS records :

nslookup -q=ns .

nslookup -q=ns com a.[root NS]

nslookup -q=ns example.com [.com NS]

explaination :

first, we check the querry for the NS records of the root zone :

nslookup -q=ns .

we get answered with a list of valid NS records. Let's call [root NS] one of these answers.

then, we ask one of the returned root servers the authoritative NS records for the .com TLD :
nslookup -q=ns com [root NS]

we get answered with a list of valid NS records for the .com TLD.
Let's call [com NS] one of these answers

finally, we querry one of the returned .com name server for the example.com record :

nslookup -q=ns example.com [com NS]

This is the complete sequence. A shorter, and less prefect one, might be :

nslookup -q=ns com
nslookup -q=ns example.com [com NS]

We can compare it with our local [NS] records, making a direct querry :
nslookup -q=ns [Primary Name Server IP]

Repost 0
Published by computer outlines - dans Windows Server 2008 R2
commenter cet article
27 juillet 2013 6 27 /07 /juillet /2013 15:52

The Internet is a great architecture, with two basis : IP addresses and Host Names.
The way these two aspects connect may seem complexe, but it is quite simple. Let's
go with simple steps.




The IANA ( Internet Assigned Numbers Authority ) oversees :
. the root zone of the DNS
. the Global IP addresses allocation
. The Autonomous Systems numbering allocation




The IANA and the Domain Name authority delegation


from the root zone of the DNS, domain name authority is delagated downward by the IANA, to the gtld level ( general topl level domain : .com, .net, .org, ...


from the gtld level, a domain name authority is delagated to a requiring registrar :
ex: example.com is delegated by the .com gtld to the registrar
the authority is then handed by the registrar to the customer.

example of authority delegation of the example.com domain :







The IANA and the Reverse DNS authority delegation


DNS-wise, the IANA oversees the delegation of IP address pools to the RIRs ( Regional Internet Registries : ARIN, RIPE NCC, APNIC, AFRINIC and LACNIC ).

The authority over subsets of these IP address pools is then delagated to ISPs or Tunnel Brokers.

Lastly, the authority over a sub-subset IP address pool is delagated to the customer by the FAI or the Tunnel Broker.
example of IP address authority delegation to a customer of the [G]:/48 IPv6 subnet :






Here is the whole picture :




Of course, in the case of a customer of both the example.com domain and the [G]:/48 IPv6 subnet, there is a one only customer ( ie box at the bottom of the picture ), so the picture is actually this :




But it's important to outline the fact that the domain name authority and the IP addresse pool authority delegation follow different paths.

Authority delegation from the Registrar to the Customer

First, a domain name is registered.

having registered it, we have authority over this domain. this authority is this :
you can set the (NS) records. The NS records specify which DNS Servers are responsible for a domain. We setup these NS records at the registrar's level ( Registrar's management webpage for this domain name ).
we have three options :

1. We let them pointed to a name server hosted by the Registrar. We will then manage the example.com domain from the Registrar's management page. This is the default setup, and the most usual.

2. We set them up to point to a third-party, hosted DNS server. There are free and non-free hosted DNS services on the Internet. We will manage our DNS records at this DNS host management page.

3. We set them up to point to our own, locally hosted, DNS servers. This is the rarest, and less easy to deal with case. ( See this posts for explainations about why local and authoritative DNS server is not the best choice : post 1 post 2 post 3 )

on these DNS servers ( at least 2 for redundancy ), we will register different things :

. NS records : they refer to the DNS server itself. It is a confirmation. It says ' I AM resposible for this domain. There is no error here '.
. A and AAAA records : they reply with IP addresses to name queries
. PTR records : they reply with FQDNs to IP addresses queries
. MX record, CNAME record, Ressource record, ....


Authority delegation from the ISP/Tunnel Broker to the Customer

At the ISP/Tunnel Broker level, we may get the reverse DNS delegation.
The ISP ( or Tunnel Broker ) holds too NS records. These NS records point to the Name Servers authoritative over an IP address or address scope.
Here too, we have three options :

1. We let them pointed to a name server hosted by the ISP/Tunnel Broker. We manage the [G]:/48 IPv6 scope from the ISP/Tunnel Broker management page. This is the default setup, and the most usual

2. We set them up to point to a third-party, hosted DNS server. There are free and non-free hosted DNS services on the Internet. We manage our PTR ( reverse DNS ) records from here

3. We set them up to point to our own, authoritative and locally hosted, DNS servers. This is the rarest, and less easy to deal with case. ( See this post and the two following )

This DNS server will only contain PTR records ( Reverse DNS ).




The Glue Record

In the case of a locally hosted authoritative Name Server, a question arises. Look at this sequence :

( Client ) :                            . Hello, I am from the outside world. What is the IP address of  host1.example.com ?
( Registrar ) :                      . Ask ns1.example.com
( Client ) :                            . What is the IP address of ns1.example.com ?
( Registrar ) :                      . I don't know. ask ns1.example.com ...

we're in a loop here ! And the solution is glue record. A glue record, located at the registrar's level, contains the IP of the nameserver ns1.example.com. So this happens now :

( Client ) :                            . Hello, I am from the outside world. What IP is host1.example.com ?
( Registrar ) :                      . Ask ns1.example.com. It's IP address [IP]
( Client ) :                            . Hello [IP], what is the IP address of host1.example.com ?
( ns1.example.com ) :      . host1.example.com is at [IP2]




A few more notes

In the case of IPv4, you probably have one only public IPv4 address. So delegation is useless. Eventually, you may be able to customize this Reverse DNS record at the ISP admin page.

In the case of IPv6, things get more complexe. The endpoint IPv6 address ( CPE WAN IP address, or IPv6 tunnel endpoint ) is managed the same way as the IPv4 public IP : It is at the ISP ( or tunnelbroker ) level. You may be able to customise it.

The subnet ( /64 or /48 as an example ) IPv6 addresses reverse DNS may be delagated, depending on the FAI. Hurricane Electric allows /64 or /48 IPv6 addresses Reverse DNS delegation. To have the subnet Reverse DNS delegated, you fill two (NS) records at the ISP/Tunnel Broker admin page, pointing to our DNS Server ( either hosted or local ).

Managing PTR records benefit is that your reverse DNS records are reachable fom the outside, which is necessary in some situations ( for managing an internal mail server : it's a security feature )

Usually, we don't need locally delegated DNS authority, so we keep :

DNS Server at the registrar level, or using a third-party DNS hosting.
rDNS ( Reverse DNS ) authority at the ISP level, or using a third-party DNS hosting.

Please notice that DNS delegation and rDNS delegation are separate things. We can get one delagated, and leave the other to its originating authority ( Registrar or ISP/Tunnel Broker in this case ).
Notice too that as they follow a different authority path and apply to different fields, we can use distinct third-party hosted DNS servers for the domain name and for the ISP/Tunnel Broker ( ie different NS records at the Registrar and at the ISP/Tunnel Broker's level ).

A good option for full DNS authority delegation is to use a hosted DNS. We then get the benefits of full DNS Server control, without the weights ( managing physical and IT security : Server redundency, DNS flooding and poisoning issues .... )

All said and understood, the easiest and most logical way of doing things is to have a locally-authoritative DNS server for the private subnets, and to use the Registrar DNS and the ISP/Tunnel Broker rDNS for public access services ( Web Server, FTP Server, ... )

Repost 0
Published by computer outlines - dans Windows Server 2008 R2
commenter cet article
25 juillet 2013 4 25 /07 /juillet /2013 16:42

We'll see here how to setup a lightweight mail server ( hMailServer ), with public access. We'll see the networking and DNS setup, with a special focus over IPv6. I'm installing the hMailServer on a Windows Server 2008 R2, but hMailServer works with any Windows OS ( Client or Server ).
Here is the network map :


hMailServer can't provide both IPv4 and IPv6 service. So here, we'll only see an IPv6 setup.
hMailServer doesn't support starttls, but it does support SSL/TLS. As we don't want to use and plain-text logging ( no encryption of password exchange, no encryption of mail exchanges ) which is totally insecure, we'll use SSL/TLS.


Previous post is about Creating a Self Signed SSL certificate, it takes just 15 minutes to install the software and generate the couple Certificate/Private Key : How to create a self-signed SSL certificate


We'll be using a self-signed certificate, so we'll have to use temporary or permanent exceptions when there are Thunderbird or Antivirus warnings.



hmail server installation and setup

hMailServer is very easy to install, leaving the default options. A password is created to access the management interface.


once installed, we login into the management interface, and first add a domain :




we add the domain example.com

( the Names tab is optionnal, it creates an alias for dual internal/external domain and loging, like example.net/example.com network design. we can add name example.net here :



We then add e.mail accounts :




( accounts : add )

We have to setup the Server IP/port servicing :


SMTP                 2001:db8:4b17:1::200          port : 465
POP3                 2001:db8:4b17:1::200          port : 995






We set the hMailServer own IP ( ::1 ) :




We next have to change the allowed client IP address range, to allow IPv6 :






( This is a allow all, so the Mail Server is accessible by anybody on the Internet. To limit the Mail Server use to our /48 subnet hosts only, we can narrow it down to 2001:db8:4b17:2:0:0:0:0             2001:db8:4b17:ffff:ffff:ffff:ffff:ffff :


we allow logging ( usefull at the beginning, for troubleshooting ) :




We finally copy our SSL Private Key / Public Certificate in the folder :


C:\Program Files (x86)\hMailServer\Externals\CA\


and add these certificates in hMailServer management interface :






We're done to the hMailServer Setup for now. We'll see the SPAM-prevention further down this post



Windows OS and Network Routers Firewall settings



We have to create two incoming rules in our Windows OS Firewall, using the Advanced Firewall :





We have to create too the same incoming rules in our Internet Gateway IPv6 Firewall :




The :: is a 'allow-all'.



Mail Clients setup


Using Thunderbird, the clients configuration is very easy and straightforward.

We just add a new account using this settings :




The username has to be the full something@example.com, for the logging to work. Here are the POP3 and SMTP settings for reference :






And we're done with the Email Client setup



DNS Setup


For our hMailServer to be accessible from the outside, we need to have it registered in the Internet DNS.

We have to create a two AAAA records :


2001:db8:4b17:1::200                      pop3.example.com

2001:db8:4b17:1::200                      smtp.example.com


We too have to create a MX record ( Mail Exchange record ) pointing to our smtp server :


smtp.example.com                           preference=1


why do we need a MX record ? Because someone mailing to john@example.com doesn't know what is is Mail Server FQDN or IP address. So he first queries the example.com domain for a MX record, which returns smtp.example.com.

He can then make a DNS querry to smtp.example.com to get its IP.


So we have to make these three DNS records, at our registrar's level :




( for why we do it at the registrar's level, see this posts on this blog : post1 post2 post3 )


we have to wait for the DNS changes to propagate, checking out :

nslookup pop3.example.com

nslookup smtp.example.com


until we get the right answer ( ie 2001:db8:4b17:1::200 here )



Reverse DNS for inter-domain mail exchanges


If we want to have our hMailServer able to exchange mails with Mail Servers from other domains ( ISPs webmails, etc ...) we need to have a working reverse DNS to smtp.example.com : this is a security feature.


for this, we have to make a PTR record ( ie a Reverse DNS record ) at the ISP / Tunnel Broker level. Not all ISPs allow to do this, or to have the reverse DNS delegated. The Network / DNS map looks like this then :




to test the good working reverse DNS, type :

nslookup 2001:db8:4b17:1::200


you should get smtp.example.com as answer


please make sure to read the last part of this post, about SPAM prevention settings, for a working inter-domains mails exchange, with example.com e.mails being accepted by other domains mail servers



SPAM prevention settings


We want our hMailServer to be protected from outside SPAM, and we want other domains Mail Servers to accept our e.mails as legitimate. Here is how we do this :


To prevent out hMailServer to receive SPAM, we can tick the ' Use SPF ' and ' Check that senders has DNS-MX records' :



This provides a basic SPAM prevention.


To have other domains Mail Servers to accept our e.mails as legitimate, we need :

. a DNS-MX record

. a working reverse DNS of our Server IPv6 address pointing to smtp.example.com

. a DNS-SPF record.


The first two have been explained higher on this post, so we just have the DNS-SPF record left to see.


SPF ( SPAM Prevention Framework ) is a DNS record, aimed at avoiding the use of spoofed domain names by SPAMs.

It is registered at the domain name DNS ( example.com in this case ) and clarifies which Mail Servers have to be considered as validly acting in the name of this domain name ( example.com here ).


Let's say our hMailServer received an e.mail written by john@example.com and sent to tim@example.org


example.com Mail Server contacts example.org Mail Server

example.org Mail Server checks for any example.com SPF record in the Internet DNS

if a SPF record is found, example.org Mail server checks if there is a valid entry for Example.com Mail Server IP address in the SPF record

if so, Example.com Mail Server is considered valid, and the e.mail is accepted by example.org Mail Server


here are some basics SPF records here :


record :                          example.com in spf "v=spf1 -all"

effect :                            no mail should be accepted by other domains Name Servers


record :                          example.com in spf "v=spf1 ip6:2001:db8:4b17:1::200/128 -all"

effect :                            only mail originating from IP address 2001:db8:4b17:1::200 should be accepted by other

                                        domains Mail Servers


here is the the network / DNS map using the second example :




a few more notes about the SPF records :


1. historically, a TXT record was used before a SPF record was specified and RFCed. Some Mail Servers still check for TXT 'SPF' records, so the best practice is to register both a TXT and a SPF record. ex :


example.com in txt "v=spf1 ip6:2001:db8:4b17:1::200/128 -all"

example.com in spf "v=spf1 ip6:2001:db8:4b17:1::200/128 -all"


2. the SPF record syntax is quite subtle. Please see www.openspf.org/SPF_Record_Syntax for complete details.

As an example : the SPF record can refer to FQDNs or MX records instead of plain IP addresses for more flexibility, they'll get resolved to IP addresses.

Or you can explicit a looser policy.


3. registering the TXT ' SPF ' and the SPF records prevents our domain name to be spoofed, and thus considered dubious and blacklisted by other domains Mail Servers.


4. There are some scripted SPF records generation tools on the Internet. Microsoft's one is interesting. Just google ' Sender ID framework SPF Recor wizard '



hMailServer tips


e.mail folder location :

C:\Program Files (x86)\hMailServer\Data




client mail messages deletion :


if thunderbird settings are right, deleted messages are deleted at the next pop3/smtp request



to clear all messages of an account in the server :


hMailServer Manager ) account ) advanced ) empty account



to screen a particular port communication using Wireshark, type in the filter box :

tcp.port eq 995        filters tcp port 995
tcp.port eq 465        filters tcp port 465


Repost 0
Published by computer outlines - dans Windows Server 2008 R2
commenter cet article
25 juillet 2013 4 25 /07 /juillet /2013 16:21

We're going to see here how to create a self-signed SSL certificate, so that we can use it for various tasks ( Remote Desktop Connection, Web Server, EMail Server, etc ... )

We will use OpenSSL for this task. I'll explain the software installation and the certificate creation tasks using a Windows 7 x64 OS

As it is self-signed, it is cryptographically strong (AES256 / RSA4096 ), but can be compromised by a high-grade attack ( needing either physical access to the server or Man in the middle attack ).
So purchasing a real authored certificate may be a good professionnal choice, if such a level of attack is to be feared.

Installing OpenSSL

If you don't want to build OpenSSL yourself, there are some ready binaries.
I use this one :




which is linked from the official www.openssl.org webpage.

For a little ease of mind, a virus total scan is possible.

We only need the Light version, and it has an installer.
The latest version for x64 is Win64OpenSSL_Light-1_0_1e at the time of this writing.
We probabaly need the Windows 2008 redistributable, so we get it too, the link is on the same webpage( vcredist_x64 here )

If you get a warning trying to install OpenSSL, first install the 2008 Redistributable

Creating a certificate and private key with OpenSSL

we launch the command line with admin rights

we navigate to the OpenSSL bin folder ( likely C:\OpenSSL-Win64\bin\ )

we generate the Private Key :

type :
openssl genrsa -des3 -out certificate.key 4096

take good note of your passphrase ( let's call it [passphrase1] )

we create the Certificate Signing Request :

type :

openssl req -new -key certificate.key -out certificate.csr
the first question about [passphrase1]

we create the certificate :
type :

openssl x509 -req -days 365 -in certificate.csr -signkey certificate.key -out certificate.crt
the first question is about [passphrase1]

if we want to remove the password from the Private Key :
type :

openssl rsa -in certificate.key -out certificate.key

( the asked password is [passphrase1] )

We can now go to the \OpenSSL-Win64\bin\ folder and get :

the Certificate ( certificate.crt )
the Private key ( certificate.key )

We're using Self Signed Certificates, so softwares and antivirus will rightfull try to make us not using them. So we have to use temporary or permanent exceptions to deal with this.

Repost 0
Published by computer outlines - dans Windows Server 2008 R2
commenter cet article


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