2013. szeptember 10., kedd

ACK port scanning with nmap

I just found out about a very useful feature from the famous open-source port scanner, nmap. The ACK scan (-sA). When I want to find out what ports are blocked by the firewall or what ports are not, it comes in handy. At times you don't need to know whether the particular port is open or closed. You just want to know if it's reachable by any firewall (device or software firewall) along the network path. When it's unfiltered, it is reachable by the ACK packet. Both open and closed ports return an RST packet, filtered ones do not return anything. They are marked as 'filtered', we do not get any response from them, nmap is unable to determine their status, they give no response. The packet filter drops the port scanner discovery attempts. Scanning my internet router to demonstrate, here is a good example.

[qmi@localhost: ~]$
sudo nmap -sA 192.168.0.1
[sudo] password for qmi: 

Starting Nmap 6.00 ( http://nmap.org ) at 2013-09-10 18:11 BST
Nmap scan report for virginrouter (192.168.0.1)
Host is up (0.0027s latency).
Not shown: 994 filtered ports
PORT     STATE      SERVICE
23/tcp   unfiltered telnet
80/tcp   unfiltered http
443/tcp  unfiltered https
1900/tcp unfiltered upnp
5000/tcp unfiltered upnp
8080/tcp unfiltered http-proxy
MAC Address: XX:XX:XX:YY:YY:YY (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 4.96 seconds

Look at the ports above on the list as , 'unfiltered'. They mean that they are either open or closed. Another quick port scan reveals those ports' real status.

[qmi@localhost: ~]$ sudo nmap -F 192.168.0.1

Starting Nmap 6.00 ( http://nmap.org ) at 2013-09-10 18:21 BST
Nmap scan report for virginrouter (192.168.0.1)
Host is up (0.0050s latency).
Not shown: 94 filtered ports
PORT     STATE  SERVICE
23/tcp   closed telnet
80/tcp   open   http
443/tcp  closed https
1900/tcp closed upnp
5000/tcp open   upnp
8080/tcp closed http-proxy
MAC Address: XX:XX:XX:YY:YY:YY (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.69 seconds

So simple. Job done. 

2013. szeptember 4., szerda

Web content providers: plan on serving content via IPv6 asap

As I was searching through the internet archives during my studies towards IPv6, I found an undeniable, unquestionable proof by the expert community that the transition to IPv6 cannot be postponed any longer. Look at the DEFCON18 YouTube video titled as, 'DEFCON 18: IPv6: No Longer Optional 3/4'. It has a 'Call to Action' banner to all web content providers saying, '(...) Plan on serving content via IPv6 in addition to IPv4 as soon as possible.'  The video was uploaded on 5 Oct, 2010 according to YouTube. This is contrary to Chris Skretowski Linux Specialist, who said in early 2013 (!) that introducing IPv6 protocol was not necessary yet. It was a completely wrong, professionally mistaken statement. In fact, the opposite is true! Introducing IPv6 is no longer optional. Watch the video and believe it, if you did not believe me. I told you! :)