Do you have rogue Internet gateways in your network? Check it with nmap

Published: 2013-07-20
Last Updated: 2013-07-20 21:57:43 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
1 comment(s)

Many people feels calm when the network perimeter of their companies is secured by solutions like firewalls, Network Access Control (NAC) and VPN. However, mobility has changed the perspective and now the users can find alternate ways to access the internet without restriction while still connected to the corporate network. Examples of this are 3G/4G modems and cellphones sharing internet access to laptop or desktop devices. You can even find small boxes like Raspberry PI that any attacker can plug to the network and get insider access from the outside.

How can you tell if there is a device that is allowing access to the Internet other than your company official internet gateway? You need to find out which devices have IP Forwarding enabled. There is an easy way to perform this task using nmap. the only prerequisite needed is for the analyzed box to accept ICMP requests. The following is an example of the scan:

nmap IP Forwarding detection

The arguments used are:

  • -sn: Tell nmap to perform ping scan and disables portscan.
  • 192.168.0.0/24: This is a network range to perform the scan. You can use your own range or single ip address.
  • --script ip-forwarding: This script comes with all nmap installations. Sends a special icmp echo-request packet to any external device assuming that it's the default gateway.

IP Forward query packet

This packet is sent to every device that answered previously the ping scan. If any of those devices have IP Forward enabled, will answer the following packet:

IP Forward answer packet

  • --script-args="target=www.google.com": This is the external target for the echo-request packet.

I will write more about nmap scripts in my next diaries. Feliz día de la independencia para los Colombianos! (Happy independence day to Colombian people!)

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

1 comment(s)

Where is my data? When hosting providers go away

Published: 2013-07-20
Last Updated: 2013-07-20 11:19:43 UTC
by Mark Hofman (Version: 1)
4 comment(s)
Most of us host part or maybe even all of our infrastructure at hosting providers.  They provide you with floor space, rack space, or in cloud environments with platforms and software for you to use.  As with all of these solutions there are pros and cons to having your hardware hosted. In cloud environments the hardware and often software typically belongs to the provider and only the data belongs to you.  What could go wrong?
 
As security professionals we get to discuss the risks of these kinds of arrangements and most of us will raise the risk of the provider going south or the data being unavailable for other reasons.  The answer we often get is along the lines of “oh that never happens and we have backups”. Unfortunately that doesn’t always help and losing data isn’t the only issue as has been aptly demonstrated this week when a number of datacentres Belgium and the Netherlands closed up shop. 
http://tweakers.net/nieuws/90104/belgische-tak-datahouse-is-failliet-verklaard.html
http://datanews.knack.be/ict/nieuws/datahouse-belgium-failliet-verklaard/article-4000351627180.htm
http://www.ispam.nl/archives/33702/datahouse-belgium-failliet-verklaard-op-verzoek-van-scarlet-business/
http://www.intall.nl/onderwerp/2818-Datahouse_Belgie_failliet_Is_Datahouse_NL_de_volgende
 
In a nutshell the provider was declared bankrupt, the doors closed and connections were cut. As the articles state customers were denied access to their servers whilst the bankruptcy processes were established. In a number of cases connectivity to servers was cut, denying access to the data.  So what risks are there when a hosting provider goes bust?
  • Denied access to physical servers – In many hosting situations the line between who owns what is difficult and often physical access will be denied until ownership can be demonstrated.  In the mean time you may have expensive equipment sitting in a datacentre that you can no longer access. 
  • Denied access to data (internet) – This can happen a number of ways.  The Internet connection may be removed which obviously cuts your and anyone else’s access.  Sometimes machines are shut down.  Whilst many administrators may decide to keep things running, after all earning some money is better than none, to cut cost supporting services may be reduced and if something breaks it is unlikely to get fixed.  
  • Denied access to data (Local) – You may decide to go pick up your data, but getting access may not be that easy.  So unless you can retrieve it remotely you may have to kiss that good bye. 
  • Backups – Any backups taken by the hosting provider are unlikely to be accessible.  Depending on the systems used to manage backups it may be quite a task to get them.  Even if you get the physical tapes (if used) you are unlikely to get the backup catalogue, so retrieving data will be difficult.  
  • Disclosure of data – Physical access usually trumps most of the controls many of us place on our hosted environment and in the cloud we do not have any control.  So it is quite likely that you will not be able to deny access of third parties to your data.  
Least of all you will be left with the cost of moving operations to an alternate location and as most of use who have been involved with datacentre moves know that is not a trivial task. 
 
It would be mean to just leave it there, so what can be done about this to mitigate the risks?  
  • Denied Access – If denied access to your servers or data a DR environment is probably your best bet.  Being able to run up services elsewhere provides processing capabilities whilst lawyers sort out getting physical assets back. However tempting it may be it is probably not a great idea to have the production environment and your DR environment hosted by the same organisation. 
  • Backups – Make your own.  Do not rely on the hosting provider to do all the backups.  Alternatively make sure that backups are stored elsewhere, including the catalogue so you can readily identify the data on the tapes, if needed.  
  • Disclosure of data – This is probably the most difficult one and makes you wish that the mission impossible slogan (this message will self-destruct in …) is an actuality. Not many of us are in the habit of full disk encryption on servers, but that may be the only way and won’t help in a PAAS or SAAS situation.
Some of you may have been in this situation and others can no doubt learn from your experience so if you are able to I’d love to see your experiences or additional risks and controls I may have missed. 
 
Mark 
 
 
Keywords:
4 comment(s)

Comments


Diary Archives