Below is the code of what is probably useless but a functional IPv6 host scanner written in Python using threading.
To perform a regular (brute force) network scans in an IPv6 Network is almost impossible it can take over 5.000 years to finish.
This project was purely academic and I just wanted to learn about threading in Python.
This software is not recommended for general usage.....
This script will call the OS to actually perform the ping
This software receives two parameters:
a) Prefix to scan in the format 2001:db8::/64 (subnet, not host)
b) Number of simultaneous processes it can run (MAXPINGS)
One more time it was purely academic stuff but hopefully it can make your day
Finally, AFAIK nmap does not yet support IPv6 network scan.
The code written in python3:
--- cut here ---
#!/usr/bin/python3
import threading
import sys
import ipaddress
import subprocess
import time
CURRENTPINGS=0 # Number of simultaneous ping at a time
def DOPING6(IPv6ADDRESS):
global MAXPINGS, CURRENTPINGS
CURRENTPINGS+=1
CMD="ping6 -c 3 "+str(IPv6ADDRESS) + " 2> /dev/null > /dev/null"
return_code = subprocess.call(CMD, shell=True)
if return_code == 0: #If ping was succesful
print (IPv6ADDRESS," is alive")
CURRENTPINGS-=1
def main():
global MAXPINGS, CURRENTPINGS
if len(sys.argv) != 3: #Validate how many parameters we are receiving
print(" Not enough or too many parameter")
print(" Usage: ./scanipv6.py IPv6Prefix/lenght MAXPINGS")
print(" Example: ./scanipv6.py 2001:db8::/64 20")
print(" Prefix lenght can be between 64-128")
print(" MAXPINGS corresponds to how many pings will be running at the same time")
exit()
SUBNET,MASK=sys.argv[1].split("/")
MAXPINGS=int(sys.argv[2])
for addr in ipaddress.IPv6Network(sys.argv[1]): #Let's loop for each address in the Block
ping_thread=threading.Thread(target=DOPING6,args=(addr,))
while CURRENTPINGS >= MAXPINGS: # With this while we make it possible to run max simultaneous pings
time.sleep(1) # Let's wait one second before proceeding
#print ("Interrumping...., CURRENTPINGS > MAXPINGS") #Uncomment this line just for debugging
ping_thread.start()
main()
Site dedicated mainly to internetworking. The goal is to share experiences, teach IP, IPv6. Talk about Linux, IP services, servers, promote IPv6 adoption, routing protocols, security and in some cases just some thoughts. Keywords: linux, cisco, ospf, bgp, eigrp, ip, ipv6, sla, link, routers, routings, telco, telecommunications, security, ipv4
Monday, December 8, 2014
Monday, November 17, 2014
$GENERATE A records using BIND. Match forward and rDNS
Hi,
This post is very short but perhaps very useful. There is less documentation on the Internet than expected.
Objective:
a) Set the reverse DNS and forward DNS match for a / 24 in BIND9 using $GENERATE.
Requirements:
- A /24 network (of course, you can adapt the example to other networks)
- BIND9
- We will use A and PTR records
Example:
Network: 192.168.30.0/24
Domain: example.com
Let's make the rDNS for 192.168.30.X resolved to: X.client.example.com
Similarly, X.client.example.com to resolve to 192.168.30.X
It would be like this:
192.168.30.1 ---> 1.client.example.com
192.168.30.2 ---> 2.client.example.com
192.168.30.3 ---> 3.client.example.com
1.client.example.com ---> 192.168.30.1
2.client.example.com ---> 192.168.30.2
3.client.example.com ---> 192.168.30.3
(Etc)
Steps:
We create reverse zone in /etc/bind/named.conf.
a) The reverse zone:
zone "30.168.192.in-addr.arpa" {
type master;
file "30.168.192.in-addr.arpa.db";
allow-query {any; };
};
After that, then in file 30.168.192.in-addr.arpa.db place the following:
This post is very short but perhaps very useful. There is less documentation on the Internet than expected.
Objective:
a) Set the reverse DNS and forward DNS match for a / 24 in BIND9 using $GENERATE.
Requirements:
- A /24 network (of course, you can adapt the example to other networks)
- BIND9
- We will use A and PTR records
Example:
Network: 192.168.30.0/24
Domain: example.com
Let's make the rDNS for 192.168.30.X resolved to: X.client.example.com
Similarly, X.client.example.com to resolve to 192.168.30.X
It would be like this:
192.168.30.1 ---> 1.client.example.com
192.168.30.2 ---> 2.client.example.com
192.168.30.3 ---> 3.client.example.com
1.client.example.com ---> 192.168.30.1
2.client.example.com ---> 192.168.30.2
3.client.example.com ---> 192.168.30.3
(Etc)
Steps:
We create reverse zone in /etc/bind/named.conf.
a) The reverse zone:
zone "30.168.192.in-addr.arpa" {
type master;
file "30.168.192.in-addr.arpa.db";
allow-query {any; };
};
After that, then in file 30.168.192.in-addr.arpa.db place the following:
$TTL 86400 ; 24 hours, could have been written as 24h or 1d
@ 1D IN SOA localhost. hostmaster.example.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
; Name servers for the zone - both out-of-zone - no A RRs required
NS localhost.
$GENERATE 1-255 $ PTR $.client.example.com.
b) The forward DNS is doing the following in the client.example.com zone file:
$TTL 86400 ; 24 hours, could have been written as 24h or 1d
@ 1D IN SOA localhost. hostmaster.example.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
; Name servers for the zone - both out-of-zone - no A RRs required
NS localhost.
$GENERATE 1-255.client.example.com $ A 192.168.30.$
Testing:
#dig -x 192.168.30.3 (reverse dns)
#dig 3.cliente.ejemplo.com (forward dns)
#dig -x 192.168.30.3 (reverse dns)
#dig 3.cliente.ejemplo.com (forward dns)
P.S. As usual there can be more than way of doing this kind of things.
Saturday, October 18, 2014
Is there any relationship regarding the deployment of IPv6 between entities with ASNs of 16 and 32 bits?
Hi,
Today this came to my mind and fortunately I knew the data existed and to locate the answer was more or less simple. I've been reviewing some data from APNIC (* 1) for several weeks (always focused on the area of coverage Lacnic).
APNIC stores a percentage value per ASN called called ipv6capable, basically is a number that indicates what percentage of an ASN has capacity for IPv6. They have another variable called ipv6 preferred but we will not talk about it right now.
Going back to my micro study: I took a sample for three days: 11, 12 and October 15, 2014
My results (for ipv6capable) were:
Day October 15 (Wednesday)
1.34% in ASNs of 16 bits
1.12% in ASNs of 32 bits
1.26% in all ASNs
----
Day October 11 (Saturday)
1.34% in 16-bit ASN
1.15% in 32-bit ASN
1.27% all ASN
---
Day October 12 (Sunday)
1.35% in 16-bit
1.12% in 32-bit
1.27% all ASN (ASN 3313)
----
I evaluated about 2050 ASNs of 16-bits and 1200 ASN of 32 bits. The difference between ipv6capable ASNs 16 and 32 bits is about 0.2, it is certainly a very small number but when it comes to traffic and users on the Internet these numbers represent significant volume.
My humble finding for this study is simple: It seems that there is a *very* slight preference for the deployment of IPv6 in 16-bit ASN.
Regards,
(*1) http://labs.apnic.net/ipv6-measurement/AS/
Today this came to my mind and fortunately I knew the data existed and to locate the answer was more or less simple. I've been reviewing some data from APNIC (* 1) for several weeks (always focused on the area of coverage Lacnic).
APNIC stores a percentage value per ASN called called ipv6capable, basically is a number that indicates what percentage of an ASN has capacity for IPv6. They have another variable called ipv6 preferred but we will not talk about it right now.
Going back to my micro study: I took a sample for three days: 11, 12 and October 15, 2014
My results (for ipv6capable) were:
Day October 15 (Wednesday)
1.34% in ASNs of 16 bits
1.12% in ASNs of 32 bits
1.26% in all ASNs
----
Day October 11 (Saturday)
1.34% in 16-bit ASN
1.15% in 32-bit ASN
1.27% all ASN
---
Day October 12 (Sunday)
1.35% in 16-bit
1.12% in 32-bit
1.27% all ASN (ASN 3313)
----
I evaluated about 2050 ASNs of 16-bits and 1200 ASN of 32 bits. The difference between ipv6capable ASNs 16 and 32 bits is about 0.2, it is certainly a very small number but when it comes to traffic and users on the Internet these numbers represent significant volume.
My humble finding for this study is simple: It seems that there is a *very* slight preference for the deployment of IPv6 in 16-bit ASN.
Regards,
(*1) http://labs.apnic.net/ipv6-measurement/AS/
Tuesday, June 24, 2014
Subscribe to:
Posts (Atom)