Do you have rogue Internet gateways in your network? Check it with nmap
by Manuel Humberto Santander Pelaez (Version: 1)
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:
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.
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:
- --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
Where is my data? When hosting providers go away
- 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.
- 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.
Comments