Assurance that a web application is only internally accessible

teancum144

I'm trying to obtain proof that a company web application (that contains sensitive data) is not accessible externally. We used nslookup to verify the webserver's domain name resolves (using our internal DNS server) to an internal IP address. Also, using public DNS server 4.2.2.2, we verified that the webserver's domain name could not be found.

How good is this assurance? How do I know a proxy server is not being used? Should I **** the NAT tables and search for the internal IP address? Any suggestions on additional steps to prove this webserver is not externally accessible?

ptilsen

I would want to see the firewall configuration to ensure that it is properly ACLed and, if NAT is used, no NAT rule makes it accessible. DNS records are neither sufficient nor necessary proof that it is externally inaccessible.

JDMurray

Can the server the intranet Web app is running on access the Internet? If so, it can be compromised by it connecting to a malicious Internet host. The server would need to be in a fire-walled enclave that has no route to the Internet to be secure.

teancum144

This is very helpful and I will modify my approach based on both of your feedback. Thanks!

JDMurray wrote: »

Can the server the intranet Web app is running on access the Internet? If so, it can be compromised by it connecting to a malicious Internet host. The server would need to be in a fire-walled enclave that has no route to the Internet to be secure.

Although someone can access the web from the hosting server, that doesn't necessarily mean that someone from the web can access the hosting server, right?? Firewall rules can allow only inbound traffic that is "in state", right?? I understand what you are saying, but I'm just trying to anticipate pushback from IT (I represent IT audit). Thanks in advance for any additional feedback/clarification.

LeifAlire

Show me the firewall rule with a "deny" statement.

emerald_octane

If I were an auditor, i'd want to see the following:

ACL for app port being filtered on whatever network segment at or before the router.
NMAP scan of the host for opened ports
Traceroute to/from host on the core router.

voodoo26

you can check for stateful inspection. this will let you know if any perimeter is in use or not. if the result show as "filtered" means stateful security perimeter is in use. Most firewalls and proxies are using state table.

>nmap -Pn -sA -p <portnumber> targetipaddr after this command you will see result of PORT/STATE/SERVICE status.

teancum144

voodoo26 wrote: »

>nmap -Pn -sA -p <portnumber> targetipaddr after this command you will see result of PORT/STATE/SERVICE status.

Here are the results from an internal IP to the server:

Host is up (0.00031s latency).
PORT      STATE        SERVICE
80/tcp    unfiltered   HTTP

I got the same results for port 443. However, this is not passing through a perimeter firewall, so how can this tell me if "stateful security perimeter" is in use?

voodoo26

your result shows no stateful security perimeter is in use from internal path. You should try from external path to see if there is any. Another test maybe to send packets with SYN/ACK and RST flag

>nmap --scanflags SYN targetipaddr
>nmap --scanflags ACK targetipaddr
>nmap --scanflags RST targetipaddr

If state status is shown as "Filtered" it means stateful inspection is in place. I made test to my company's web server and we have stateful sec. perimeter.

Host is up (0.037s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
80/tcp filtered http
443/tcp filtered https

NovaHax

teancum144 wrote: »

Here are the results from an internal IP to the server:

Host is up (0.00031s latency).
PORT      STATE        SERVICE
80/tcp    unfiltered   HTTP

I got the same results for port 443. However, this is not passing through a perimeter firewall, so how can this tell me if "stateful security perimeter" is in use?

You are correct, if you are scanning the system internally without passing through the firewall, this isn't going to tell you anything about whether it is blocked. You need to scan from the good ol' www to get any kind of decent feedback from Nmap.

That being said...I would personally prefer to see the ACLs/Firewall rules, as they are going to be more reliable. The underlying assumptions of this scan are mostly accurate, but not always. This type of scan in Nmap does the following.

SYN ==> Target:Port
ACK ==> Target:Port

If reply from SYN is either SYN+ACK or RST+ACK, and no reply from ACK...Statefully Filtered.

If reply from ACK is RST, and no reply from SYN...Statefully Filtered.

If no reply from either...host is either non-statefully filtered or down.

If reply from SYN is either SYN+ACK or RST+ACK, and reply from ACK is RST...Unfiltered

sojourn

You need to be looking at the NAT rules. Even if a device has no route to the Internet, it will still be able to reach the Internet if NAT permits it, and vice versa.

Anything internal is on RFC1918 private addressing is not going to be reachable from the Internet unless there are NAT rules set up to handle the translation from public to private addressing, simply because the addresses are unrouted on the Internet.

The obvious exception to this, is if someone has exploited a vulnerability to gain access to another host on the internal network, and then accesses the host you are concerned about via this exploited host.

EG Firewall is set up permit http access to 200.1.1.1, which translates to 10.1.1.1 on port 80. Someone has exploited a vulnerability in the webserver on 10.1.1.1, they gain access to this server, and then can browse to the host you care about 10.1.1.2 via the internal network.

SkeyeLlama

There should be physical, logical, and data flow network diagrams containing that server. Auditing the proper configuration should be as simple as viewing these three documents and then verifying the physical setup is as described, the logical segmentation actually exists, and the router and firewall ACLs exist to enforce the data flow restrictions. Data flow should consider both ingress, incoming traffic, and egress, outgoing traffic.

If these basic network documentation don't exist then that should be pointed out. If you don't know what the proper configuration you are auditing is, how can you audit it?

JD Murray is on the money here with the proper configuration.

Can the server the intranet Web app is running on access the Internet? If so, it can be compromised by it connecting to a malicious Internet host. The server would need to be in a fire-walled enclave that has no route to the Internet to be secure.

Regarding your follow up:

Although someone can access the web from the hosting server, that doesn't necessarily mean that someone from the web can access the hosting server, right?? Firewall rules can allow only inbound traffic that is "in state", right?? I understand what you are saying, but I'm just trying to anticipate pushback from IT (I represent IT audit). Thanks in advance for any additional feedback/clarification.

If there is an egress path (someone from the web server can get to the internet) there is a risk. The real question here is where is the sensitive data coming from? A database? A flat file? Is it on the same computer? Has that machine been audited if different?

Additionally, there is no reason to have back and forth with IT. They should be able to tell you what security controls they put in place without you having to try and sleuth it out. Then you need only test them and look for things they didn't anticipate.

teancum144

Great insights! Thanks all!

SkeyeLlama wrote: »

Additionally, there is no reason to have back and forth with IT. They should be able to tell you what security controls they put in place without you having to try and sleuth it out. Then you need only test them and look for things they didn't anticipate.

I wish it were that easy. When it comes to auditing, some in our IT department are very defensive/resistive. Some tend to take it like I don't trust them and that I'm questioning their expertise. They are very busy and act very put out that they have to take time for auditors. They feel like they are the expert and that we should trust them. It can be challenging.