6

I would like to set up a security barrier to my test/dev environments. I'm under a more or less typical LAMP on dedicated servers.

Thing is, I have some facebook apps, a widget for other devices, and other apps that need to connect to my site via an API(also, ajax calls!). But I want my test/dev sites not accessible from the outside. Hence, how could I better set up some protection here?

The first ideas that come to me are:

  • Remove DNS entries.
    • You can only access via IP, and set up /etc/hosts entries wherever I want to test. But it would need referring via IP in other external apps like a FB app.
  • Apache http auth
    • Pros: you need the u/pw to access, so kind of secure. But: how can you set up automated access? E.g. widgets, FB apps, ajax calls... (I actually don't know)
  • robots.txt entry to avoid search engine exposure - but not enough to actually block a site.

Ideas please? Thank you!

Co Lega
  • 61
  • 1
  • 2
  • 1
    I am confused as to what traffic you wish to allow and what traffic you wish to block. Could you be more specific? Can you move the apps and widgets to a machine other than your test and development machine? Will you only be accessing your test/development machine locally (not remotely)? – this.josh Oct 07 '11 at 08:15
  • I wish to allow my services to be available from outside (e.g. a test FB app running on FB). I can control the code of the apps that will connect, but not where they will connect from. I want to limit exposure of the system, not that much protect it against attacks, but protect it from webpage access e.g. from misguided clients, or people coming from a bad link found on a search engine, etc. – Co Lega Oct 07 '11 at 09:20

5 Answers5

4

Put the test server behind a router/firewall, and don't expose it on the outside. As long as everyone who needs to access the test server is behind the same router, everything is fine (provided you trust the local network); the outside world won't even know the machine exists.

If you need access from outside, VPN or SSH-tunnel into the local network.

tdammers
  • 1,776
  • 9
  • 14
  • The service needs to be available to outside services for the purpose of integration via HTTP(S). – yfeldblum Oct 07 '11 at 10:05
  • Then why does the question say "But I want my test/dev sites not accessible from the outside."? – tdammers Oct 07 '11 at 12:20
  • 3
    That's a colloquial and not a technical explanation of the wanted behavior. He wants people in general to have a very hard time of finding and messing with the dev/test sites - not because of data security concerns for keys or other people's private information, but because it would be annoying if people complained by email or twitter that the site was broken when what happened is they went to the dev site. – yfeldblum Oct 07 '11 at 12:55
  • Yes, pretty much that Justice, thanks for explaining better than I did. Still, I'd add that it would be desirable some kind of security(e.g. password based) if it comes at a relatively low cost. – Co Lega Oct 07 '11 at 13:59
  • 1
    "The service needs to be available to outside services for the purpose of integration via HTTP(S)"

    Which can be done over a VPN/SSH tunnel, it's a common way to do secure VOIP with a provider. Any company wanting to be on your dev/test server should have the quite low IT competence needed to plug into these tunnels.

     – StrangeWill Oct 07 '11 at 19:24
3
  • Remove DNS entries.

This will not help you. Anyone finding and scanning you from the outside is almost certainly blindly scanning IP space, not looking up names and trying them, and removing yourself from DNS won't impact them a bit.

  • Apache http auth

This will help, but as you've pointed out, making it work with all your widgets may end up being a pain.

  • robots.txt entry to avoid search engine exposure

This will not help very much. It might cut down on honest search engines indexing you, but only stops well behaved crawlers. And the chances that you opponent is stumbling across you via a web search are very, very low - see above, they're probably blindly scanning IP space and hitting you.

Update to respond fully to @Co Lega's comment

Oh, you want solutions, too? Crap, that's the hard stuff! 8)

One solution that might work for you is to temporarily grant IP-based access based on authentication. This is similar to port knocking or POP-before-SMTP. It sounds like you want to test apps on the dev server, and therefore can't add application layer authentication to the dev server without conflicting with applications which may already have their own authentication. You don't want to maintain firewall rules because your users may not be predictable in their source IP, or because you don't want to maintain a shifting set of rules.

The idea, then, is that people perform an authentication to the dev server for the sole purpose of opening up access from their IP for a limited amount of time - like a dynamic and temporary firewall rule. Because you're altering IP access, their browser and/or application don't need to be maintaining credentials, the application server doesn't need to maintain state for that level of access, etc. etc. They browse to the server auth page, authenticate, and their IP is cleared for access to the rest of the site for 30 minutes, 2 hours, 2 days, whatever you want. They test the apps without any need to allow for wrapping that access in authentication, because their IP has been granted access based on that out-of-band (e.g., not the application) authentication.

One downside is that IP source is not always as secure; if they're behind a proxy at the library anyone else behind that proxy is granted access too. At that point you want to look at a VPN solution.

Looking at your question, I'm not sure how well that fits your original goal. It's aimed at more of a dev crowd than end users, and it sounds like you may be thinking end users. In that case, perhaps the answer is to harden the applications to survive Internet exposure - which is a good idea anyway.

Good luck!

gowenfawr
  • 72,893
  • 17
  • 165
  • 200
  • So... do you have some other idea? Robots actually are OK since I don't want it to crawl my test/dev sites, just my prod site. For my purposes is OK - but only a part of it. – Co Lega Oct 07 '11 at 14:03
2

Set up unguessable DNS.

$ openssl rand -hex 16
dbfbd61101a137242e6f1e1149923e20

$ host instance-dbfbd61101a137242e6f1e1149923e20.myapp.com
instance-dbfbd61101a137242e6f1e1149923e20.myapp.com has address 128.64.32.16
yfeldblum
  • 2,837
  • 22
  • 14
  • 1
    Great! Until someone links to it and Google finds out, or another bot... It makes it impossible to guess, but it's no guarantee that it will stay hidden. – SPRBRN May 01 '14 at 08:44
2

Set up a firewall. Start with a policy that blocks all access to your machine from the outside. Then punch a few holes through the firewall just for the destination ports that need to be exposed, but limit them by source IP according to the IP address of the external service that needs to contact you.

This is not perfect, because IP addresses can be spoofed. However, it is probably good enough for setting up a test/dev environment for a little while. Just don't leave it up forever: when you're done, shut it down.

D.W.
  • 99,525
  • 33
  • 275
  • 596
  • I don't know the source IPs, so I cannot limit the fw by that. My goal is not to prevent attacks, but prevent access. – Co Lega Oct 07 '11 at 09:22
0

I won't repeat the other answers. You want a Facebook app to access your site, if it's behind a login. You can give that app the option to login I guess. I never built a FB app, so I don't know the limitations, but I guess you won't be the first to need something like this. The same goes for any app, PHP or whatever language you use. It should be possible.

SPRBRN
  • 7,529
  • 6
  • 38
  • 38