# Restricting apache access to outside IP's

## mariourk

We have a webserver with Joomla installed on it. This is used to display news and evens within the company on a central place, that can be accessed by everyone.

Right now, this webserver can only be accessed over the internal network. From the outside world, port 80 is closed. However, some people (mostly parttimers) would like to be able to access this "intranet" from their home.

I obviously won't just open port 80 and make this accessible by anyone. If I did, I want this website at least protected with a password. The problem is that, when I do that, everyone in the building will be prompted to enter a username and password. Regardless if they are inside the building or at their homes (or anywhere else...) and that is not what I want.

I want anyone accessing this site from the inside network to just get in, without any password promt. But as soon as someone from the outside tries to connect, he or she should be prompted to enter a name and password.

I know how to secure a vhost with a password. But I don't know how to split this, so a certain network won't be bothered with this, while other networks have to login. I don't even know if this is possible with Apache. 

I hope someone can help me out here  :Smile: 

----------

## static_k

Hi,

I'm not a pro but the only thing I can think of is by using the mod_access module. Something like this:

```

<Directory /docroot>

    Order Deny,Allow

    Deny from all

    Allow from network/netmask

    Allow from env=let_me_in

</Directory>

```

The use a special page that people use from the outside that runs a cgi script to set that environment variable, redirects them to the main page that now lets them in.

Reference this page: http://httpd.apache.org/docs/1.3/mod/mod_access.html

Hope it helps or gives you an idea.  :Very Happy: 

----------

## scherz0

http://httpd.apache.org/docs/2.2/mod/core.html#satisfy

Description: Interaction between host-level access control and user authentication

Example :

```

Satisfy any

Order allow,deny

Allow from ...

AuthType basic

AuthName "foo"

AuthUserFile /path/to/passwd

Require valid-user

```

There are many other auth methods.

----------

## overkll

@mariourk

You could split into two vhosts, one for internal and one for external.   Both vhosts can access the same /var/www/... directory or you could make seperate ones.

For externel you could use ssl with auth, then just limit the ip addresses that can access it with appache access lists.

External vhost access list:

```
  <Directory /var/www/path/to/dir>

    AllowOverride none

    Order deny,allow

    Deny from all

    Allow from ipaddress1 ipaddress2 ipaddress3 ...

  </Directory>
```

----------

## richard.scott

why not run a vpn server? you could keep port 80 closed then  :Smile: 

----------

## overkll

Forgot to mention that you could also use openvpn.  Then you don't have to worry about users with dynamic IP's.

----------

## Hu

A VPN is valuable for another reason.  Since you do not want to open this up to everyone on the Internet, I assume there is at least some material on the server that you would prefer remain confidential to the company.  Anyone who accesses it via password protected HTTP will still be transferring the data unencrypted over the Internet.  Intermediate parties could view the content in transit, and depending on your password scheme, might be able to obtain the credentials as well.  Even if you trust the regular ISPs of everyone involved, what happens when someone decides to use a free public wireless hotspot to check in?

For the sake of confidentiality, you should try to avoid unencrypted transfer of the data.  If maintaining a VPN is too much trouble, at least require outsiders to come in over HTTPS.

----------

## mariourk

We are allready using VPN (OpenVPN) But I don't want to use it for this, for several reasons.

First of all, I setup the VPN-server to run in bridged mode. This allows the clients to have an IP in the same range as the internal network and spares me the trouble of all kinds of routing tricks. The clients work the same as any other pc, directly hooked the the internal network. the downside is that all VPN-clients are using IP's in the same range. I'm short on IP's allready, so expanding this VPn thing will make this worse.

Second. When pc's at home connect through VPN, they are directly hooked into the network. I have no controll over these pc's and they are probably used by theis kinds. In other words, heavily infested with all kinds of spyware, mallware, virusses, etc. I think that I don't have to explain that I don't want those pc's in my network  :Wink: 

Thirdly. With direct access to our network, from all kids of pc's, that means a huge security breach. I don't want that either.

Simply opening port 80 and securing it with the tools, provided by Apache, is the best option, in my opinion.

I think I'n going to try the 2 vhosts solution. I anyone comes up with a beter idea, feel free to share it.

Thank for the help so far  :Smile: 

----------

## Hu

I see.  If you had more IP addresses to spare, you could place all the VPN clients into their own subnet and use a firewall to limit the damage done by infected systems.

I still think you ought to require HTTPS for external connections, but your reply shows you have given security much more thought than I initially realized.  Good luck, whichever method you try.

----------

## scherz0

 *mariourk wrote:*   

> Simply opening port 80 and securing it with the tools, provided by Apache, is the best option, in my opinion.
> 
> I think I'n going to try the 2 vhosts solution. I anyone comes up with a beter idea, feel free to share it.

 

Have you considered the "Satisfy" directive I mentionned before ?  Unless you want ssl only for external access, I think this is exactly what are looking for : grant access to a list of subnets, and set up an auth method for the rest of the world...

----------

