5

I am developing an intranet application using Apache/MySQL. The server hosting it does not have a public IP address itself, but can access the internet through a router. There is not any sensitive information involved, but for good practice for future projects that may be more sensitive, I would like to make sure it is completely unaccessible externally.

Currently, the application can be accessed internally using either the internal IP address (192.168.etc.etc) of the server, or the NetBIOS name. I could not find any way to access it externally to the network it exists on, but I'm sure some potential invaders would have more resources/attacks to try.

Granted this is a very low sensitivity application for a small business, but I don't want to be satisfied with "security through obscurity". What things should I check so that I (and the business owner) can be absolutely certain that this application (including its web-based front-end, apache server, and mysql server) can only be accessed from the internal network?

Improve this question
6
  • 4
    You don't want absolutely. You want robust to potential attacks. Absolute involves things like filling your USB ports with epoxy. Higher security often comes with a loss of usability.
    – this.josh
    Aug 16, 2011 at 22:14
  • @josh - thanks, yes that's basically what I meant. Like I said, it's a low sensitivity application and a small business that would certainly notice the physical presence of somebody who didn't belong, but a network intrusion would probably go unnoticed to most here. There would be no practical reason to target the application, but that doesn't mean I don't want it as secure as reasonably possible. If for nothing else, my own education.
    – Joe M.
    Aug 16, 2011 at 23:26
  • And to be more clear, I realize if this was something sensitive like a defense company or utility, they would isolate the internal app from the public internet. I'm asking, given the low sensitivity and the fact that the internal network will remain connected to the internet, how can I best ensure the intranet app will be reasonably inaccessible?
    – Joe M.
    Aug 16, 2011 at 23:28
  • Thanks for the clarification. It is still difficult for me to suggest measures in the absence of other bounding parameters. I could assume for example that latency and throughput for every existing system must not degrade by a noticable amount (roughly 50ms latency, and 5% less throughput). And that the cost of extra security measures must be less than $500 with minimal or no onging maintenance and support costs. Or I could suggest your reorganize the network so every machine connected to the server is in an isolated enclave bridged to the network by RS-232 at 115.2 kbps
    – this.josh
    Aug 16, 2011 at 23:44
  • I understand.. I figured I would get fairly general responses to my fairly general question. I asked this way because although the current application has low security requirements, I can reasonably anticipate future projects with this company that might have stricter requirements and without significantly more security budget. So basically I'm looking at what can I do as far as configuring what's already in place (Apache, MySQL, the server, the router, etc.). Thanks for your response!
    – Joe M.
    Aug 17, 2011 at 6:12

8 Answers 8

Reset to default
10

Some configurations that come in my mind:

  • Don't place the server in a DMZ
  • Accept connections on 192.168.0.0 addresses in the Apache configuration.
  • Place a deny from all + accept from with the correct range of IP in your apache configuration
  • Deny forwarding of VPN connections (?) in your firewall (if applicable).
Improve this answer
5

Your web application, is much like any other service (file sharing, printing) that you've got running on your internal network.

Usually Internet routers will perform firewall functions, which block traffic from the Internet to any internal IP address, unless specifically told otherwise (via Static NAT or port forwarding), so direct access from the Internet to an internal service like your website would not be possible.

If you want to check this you can port scan your Internet facing firewall. A simple way to get started with this would be to use something like Shields Up from a machine on the same network, which will perform a port scan of your external IP address (this is assuming a relatively small network with a single external IP address).

In terms of indirect access to your website, it's possible that someone could get access via malware on a machine on the same network or some other indirect path, but that's a bit of a different topic altogether.

Improve this answer
1
  • Thanks a lot for the Shields Up suggestion! Very cool link..
    – Joe M.
    Aug 18, 2011 at 17:28
3

First thing to check would be the firewall rules, to make sure that there are no rules allowing direct external access to the various services on the host. Check both "port forwarding" as well as "static address translation" rules to be sure.

Then, check the security of all hosts/services that ARE accessible from the Internet. If an attacker can compromise a different host on your network, once they are behind the firewall, they can "pivot" and gain access to other hosts on the network, including your app.

Improve this answer
3

If you want to be absolutely sure, then you need to airgap your Intranet server. Would probably be overly burdensome to use though.

Bout what I can think of off hand is to make sure that you use RFC1918 addressing scheme and you make sure that internal addresses are dropped on the external interface of your firewall.

Improve this answer
3

Being absolutely certain is very hard here. For example, any machine on internal network can run HTTP proxy at random port, sometimes even by taking SSH connection to outside network and bridging traffic over it. Unless the HTTP port is the only port open in your firewall to both directions and your Apache is the only machine in the network that is allowed to accept/initiate connections to outside world, it's hard to be 100% sure.

This is also not just a theoretical scenario; I have done setups like this (ie. HTTP proxy+SSH tunnel) on purpose, to access corporate intranet when working home. You just need to be aware of the security implications when doing it.

In my opinion an intranet service that needs to be really secure should not solely depend on being in private network - it must use SSL, user accounts and account-specific permissions to control the access to be even remotely secure.

Improve this answer
3

With the assumption that you will likely be undertaking similar endeavors in the near future I think a different approach is required than what has been proposed in previous answers. I would like to suggest that you outline and establish a strategy for "securing" future applications/systems. By using a strategy you can ensure consistency, delegate responsibility and improve your practice over time.

I believe that securing a server shouldn't be done in an ad-hoc type fashion, but rather methodologically and consistently. It should be a repeatable process with as little room for mistakes as possible. Us humans are notoriously bad at remembering details, often blending bits of information into something entirely different.

In the scenario you describe above using a perspective of Availability seem to be mostly relevant and useful. Begin by describing establishing system dependencies. What other systems are required to be accessible in order for the application to function? Do you depend on an external user directory? Dependencies are important because they help to better understand potential "avenues", or vectors, of attack.

Next flesh out details of exactly who should have access to the system and the primary access "terminal" (remote desktop, workstation, laptop, mobile phone etc). By doing this you'll have begun to establish your frame of reference, or system boundary if you like.

It's very likely that there are organizational limitations that you simply need to obey. These might include company mandated authentication methods, encryption algorithms and such, describe and document these limitations. You might also have to consider legal requirements, and now might be a good time to find out.

Once you've established the more "fundamental" building blocks of your system, it's time for some creative brainstorming. Try and describe all potential avenues through which you (or an attacker) could access the system using the above system description as a sort of limitation.

What you'll have to do next is determine what security controls would assure the most appropriate protection. Yes, I know, this is where things get complicated because it's a somewhat subjective process but regardless necessary. Every countermeasure you determine is necessary will be associated with a certain cost (time to install, configure, maintain and eventually retire).

You'll also want to try and describe with some sort of quantitative measure how "well" a collection of countermeasures mitigate a particular risk, or "limit" an avenue of attack. I believe this to be important especially for "upper management", speak a numbers language. For example, a "good" implementation of salted passwords will entirely eliminate the threat of precomputed hashtables and could hence be described as a "high assurance" countermeasure.

In short:

  1. Determine primary security goal/target (confidentiality, integrity and availability)
  2. Establish system dependencies
  3. Who, how and when?
  4. Detail organizational and/or legal requirements/limitations/constraints
  5. Brainstorm attack vectors (guess you could call this a lightweight threat analysis)
  6. Choose countermeasures appropriate to the system in question
  7. Make rainbows, colorful charts and unicorns.
Improve this answer
3
  • 1
    I almost want to -1 on this, but I won't - simply because it's pretty much correct. The problem with this is, it is correct - but not relevant, and as such it is counter-productive. The OP came with a low-sensitivity system, and declared it as low priority overall. While your answer would be appropriate for sensitive systems, it is inappropriate and a (mostly and apparantly) bad tradeoff. Smart security is sometimes about saying "This is not worth doing", according to a business-context-based risk analysis.
    – AviD ♦
    Aug 21, 2011 at 15:53
  • 1
    @AviD: +1 to your comment. Think I would have to concede to your argument. The reason of why I suggested the above "strategy" was due to his last comment about "... reasonably anticipate future projects with this company...". In light of that comment I thought it was the most appropriate thing to do. But I do agree that perhaps one can reasonably assume that he wanted a quick fix.
    – Christoffer
    Aug 22, 2011 at 7:00
  • May also have point out that I'm damaged from working in the g-sector where there view of time/money is somewhat different from that of the p-sector.
    – Christoffer
    Aug 22, 2011 at 7:05
2

One way to ensure that packets originating from your application does not reach outsiders, is by mangling the ttl value using iptables. I assume you are using linux to host your application.

In a TCP handshake, an attacker would be able to reach your web server with a SYN packet, but your router will drop packets that are destined outside your internal network.

An example of this is avahi-daemon. It will ignore all packets which does not have the IP TTL set to 255, meaning it has to originate from your own network segment.

On a linux system, you can choose to either modify outgoing ttl for specific ports, or globally through sysctl.

This solution is not fool-proof, and will probably introduce some availability issues such as: clients connecting through VPN, multiply routes with unqual network hops to border gateways.

Iptables:

The iptables tutorial for TTL target explains how to build a rule for this problem. This is also covered here How to set ttl.

Sysctl:

echo "1" > /proc/sys/net/ipv4/ip_default_ttl

Improve this answer
1

Even if the server is not accessible directly from the outside, the users connecting to the server have a link to the outside.

Isnt it a possibility that some malware gets installed on a users system, which is then used to access the server?

For example, (a non malware example, but still gives the idea)

Teamviewer is installed on a users PC

Someone connects to Teamviewer from outside

Outsider uses the users PC to connect to the server

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .