How Can You Identify Your Internet-Facing Applications?
Written By: SC Advisory
Share this post
Can you secure your organization if you aren’t aware of which internet or public-facing applications you own?
There are many organizations that have never gone through a security audit. They know which network ranges they own. However, they have no idea what their actual internet-facing exposure is.
There are some documented systems, but people have been building and publishing applications on the internet for years and forgotten about them.
In a situation like this, your first task should be to discover or identify all internet-facing applications. But how can you do that? Let’s find out.
Identifying Internet-Facing Applications
When you have to take up a task that involves going back in time, it almost, always requires some communication skills and teamwork.
The process may not necessarily be difficult, but it becomes an involved and continuous process to maintain up-to-date knowledge of your systems inside your organization.
To help you identify the internet-facing applications in your organization, we’re breaking down this post into five steps:
Know yourself : Identify the assets important to the business.
Know your team : Identify where the assets sit on your network and other services provided by your organization through information gathered from other departments.
Know what the world knows : Attempt to find your public-facing systems. We will discuss the DNS reconnaissance and network scanning techniques in this blog.
Know how to keep it all together : Organize the information obtained from the previous steps.
Know what lies in the cloud: Determine your responsibility with respect to external assets and information hosted by a third party.
1. Know yourself
Start this process by talking with different business groups in the organizations, and establish what your assets are.
What does the company do? What is their main source of revenue?
This exercise will not only help you to identify and prioritize key assets but will also open a communication channel with other groups not usually involved in ensuring software security.
2. Know your team
Once you have the assets you would like to investigate, find your organization’s Network Engineer. They can help you answer various questions such as:
How many nodes/devices do you have on the network?
Does your network segregate traffic from your servers and workstations?
If so, how is it implemented? I.E. with virtual local area networks (VLANs)?
What is your current routing setup?
What is your current domain name (DNS) setup?
Do you have any firewalls or intrusion detection/prevention systems in place? If yes, what are your current policies for them?
How are you keeping track of device information, especially on routers?
How are you logging all that information?
Are you implementing Simple Network Management Protocol (SNMP) to monitor the network? If so, what information are you logging?
There are more questions that could be asked, but this gives you a rough idea of what information you should be aiming to obtain. Specifically details around routing information, number of devices/nodes on the network, and a rough idea of the network flow.
Again a discussion like this offers multiple benefits. You are getting to know the colleagues you will be working with to help implement your security policies and also creating a communication channel for when you do send a request to modify a firewall policy, request SNMP log information regarding open services, or have certain network traffic monitored.
The next individual or group in your organization to talk to would be your System Administrator. If you now have a rough idea of how many devices are on your network and how the traffic flow should be, your System Administrator can help you determine what services are running on those systems and what servers and clients you may have on the network.
Things you may consider asking your System Administrator:
Do you have Windows servers, Linux servers, Solaris servers, etc.?
Which services/applications do you have running on these servers?
How are you managing these servers?
Are you recording the information anywhere?
As usual, there are many more questions that could be asked and discussed with your System Administrator, but the main concerns are what operating systems you are running, what possible services may be installed, and how they are managed.
This type of information is not only useful for the initial external scanning but will be helpful when implementing solutions to any issues that may come up in the future.
3. Know what the world knows
Now let’s get into the technical aspect of investigating your organization’s external network. This consists of basic domain name system (DNS) reconnaissance, host discovery, and port discovery.
One of the initial public-facing systems you should check on is DNS; how are your organization’s IP addresses getting resolved?
To properly answer this question, you need to investigate your DNS servers externally. A few things you might want to investigate are:
What initial information do you obtain from a DNS lookup on the domain name of your organization?
Can you request a zone transfer remotely?
What are the mail servers, websites, or addresses associated with your name, and are they yours?
With the set of IP ranges provided and information gathered through tools like fierce, you may conduct a host detection scan with tools like Nmap.
Nmap is a Network Mapper utility that performs network discovery and security auditing. Nmap uses crafted IP packets to solicit a response from a target in various ways to determine: if the host is up, what ports are open and, in most cases, what services are listening on those ports.
A recommended option would be to establish a dedicated external server to scan the network from. If you have any Firewalls or IDS in place, consider whitelisting the target IP. If your IP range is large or the subnet is larger than a class C subnet, consider breaking the scans up — maybe half the ranges for one day, and the other half another day. Consider setting up a scanning policy.
Now that you have a list of possible targets that may be up, you may conduct a more involved scan using Nmap to determine what ports and services are running on the hosts that are listed as “up”.
Keep in mind that these scans may take from several minutes to several days, depending on the transport protocol you select, the number of hosts on the network being scanned, and the number of ports to be scanned.
With the knowledge obtained from communicating with your Network Administrators and System Administrators, you may want to scan the ports you think will be open first, for confirmation, then do a thorough and prolonged scan for verification and completeness.
Ideally, you may want to run four sets of scans, one to determine what TCP ports are open and maybe apply a simple banner grabbing technique to determine possible port information. You also want to perform UDP port scanning even though it takes noticeably longer because it is a connectionless protocol. The ports to scan will depend on previous knowledge obtained from your Network and System Administration teams.
These types of scans allow you to confirm the information provided in the “Knowing your team” exercise and review the output, keeping in mind questions such as:
If this is your main web server, do you really need to have these many services running on it?
Do these services need to be public facing?
If you can’t immediately turn off those services, can you talk to the Network Administration team to update the current Ingress and Egress rules in the Firewall policy?
After those scans, you can conduct a more involved scan by running Nmap’s basic scripts for host detection and further port analysis. These types of scans may be directed at a specific port to learn more about what information an attacker could obtain about the service.
An example would be the command: nmap –sV –A <host/hostrange> -p 80,8180
These ports were identified as web service or “unknown” in the previous scan.
With this information, you can now confirm that both are indeed web services and with the Apache version information listed, you can determine if the services are following proper patch management security policies.
Further analysis could be done with web-specific vulnerability scanners and by manually investigating the application.
In this section, we applied technical techniques to map our internet-facing network but it is just as important to have this information organized in some scalable form. It is important to ensure the changes are recorded as scanning continues — either weekly or bi-weekly or however your policy deems fit.
4. Know how to keep it all together
Meaningfully logging and tracking information about your public-facing servers is just as important as discovering what the world knows. There are multiple ways to do this.
One of the ways that’s effective for small data sets is to parse the information in Comma Separated Values (CSV) format and add it to a spreadsheet with various pages based on scan date. You may need to do some scripting to parse the information in a way that is meaningful to you.
An example would be to use PowerShell (Microsoft scripting language) to parse the xml output of an Nmap scan and convert it to CSV format with meaningful headers.
An alternative way is to utilize the Zenmap tool, the Graphical User Interface (GUI) to Nmap. Multiple methods can be used to keep track of your scans — just ensure that the data is easily retrievable and presentable when the moment requires it.
5. Know what lies in the cloud
Understand your relationship with your cloud provider. This means:
Identify what type of cloud service your organization is running.
Ensure you are aware of the relationship your cloud service provider has with you.
Determine whose responsibility it is to apply a proper security policy for the application or service.
A lot of organizations utilize the cloud in some way. The external service or application is still considered a public-facing entity of your organization.
The level of responsibility you have for those services changes based on the type of service you are using. For example: are you using Infrastructure as a Service (IaaS), Software as a Service (SaaS), or Platform as a Service (PaaS)?