[ Pobierz całość w formacie PDF ]
77
Access to directories can also be controlled easily, Apache supports the defining and
placement of files (usually referred to as htaccess files) that can control access based on
username and password, IP of origin, and so forth. This is defined in srm.conf:
AccessFileName .htaccess
The format of this file is covered in the Apache documentation, and is identical to directives
you would place in access.conf (well almost). User authentication via username and password
is also covered in depth at: http://www.apacheweek.com/features/userauth/.
You will also want to prevent people from viewing the .htaccess file(s), place this in your
srm.conf:
order allow,deny
deny from all
This will disallow the viewing of any file called '.htaccess'.
You can download Apache from http://www.Apache.org/, and you can download Apache-
SSL from http://www.Apache-ssl.org/, you will also need OpenSSL software available from:
http://www.openssl.org/. Please note the use of Apache-SSL is illegal in the USA due to
patents held on RSA. The cheapest commercial Apache-SSL server available is Red Hat
Secure Server at $100 US.
HTTP runs on port 80, tcp, and if it is for internal use only (an Intranet, or www based control
mechanism for a firewall server say) you should definitely firewall it.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 80
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 80
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 80
or in ipchains:
ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 80
ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 80
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 80
HTTPS runs on port 443, tcp, and if it is for internal use only (an Intranet, or www based
control mechanism for a firewall server say) you should definitely firewall it.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 443
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 443
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 443
or in ipchains:
ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 443
ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 443
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 443
78
Red Hat Secure Server
Red Hat Secure Server is an Apache based product from (guess who) Red Hat software.
Essentially it is stock Apache with RSA cryptographic modules (which is what you are paying
for essentially) and can also serve standard non cryptographic http requests. It can only be
sold in the USA and Canada, and is the best option (in my opinion) as far as secure www
servers that are legal to use in the US go (due to RSA patents). As far as security goes read the
previous section on Apache / Apache-SSL, it all applies. Red Hat Secure Server costs $100
US and you get a $25 discount on your Thawte site certificate (so the site certificate only
costs $100 US). I personally like it a lot as it is based on software that runs over half the www
sites in the world and as such getting support/updates/etc. is easy. You can buy Red Hat
Secure Server from: http://store.redhat.com/commerce/.
Roxen
Roxen is another commercial www server capable of https and is GPL licensed. You can
freely download it if you are in the European Union or Australia, Canada, Japan, New
Zealand, Norway, USA, or Switzerland. A version with weak (40 bit) crypto can be
downloaded without any problems to any country. Roxen is an extremely solid product and is
available from: http://www.roxen.com/.
79
SQUID
SQUID is a powerful and fast object cache server. It proxies FTP and WWW sessions,
basically giving it many of the properties of an FTP and a WWW server, but it only reads and
writes files within it's cache directory (or so we hope), making it relatively safe. Squid would
be very hard to use to actually compromise the system and runs as a non root user (typically
'nobody'), so generally it's not much to worry about. Your main worry with Squid should be
improper configuration. For example, if Squid is hooked up to your internal network (as is
usually the case), and the internet (again, very common), it could actually be used to reach
internal hosts (even if they are using non-routed IP addresses). Hence proper configuration of
Squid is very important.
The simplest way to make sure this doesn't happen is to use Squid's internal configuration and
only bind it to the internal interface(s), not letting the outside world attempt to use it as a
proxy to get at your internal LAN. In addition to this, firewalling it is a good idea. Squid can
also be used as an HTTP accelerator (also known as a reverse proxy), perhaps you have an
NT WWW Server on the internal network that you want to share with the world, in this case
things get a bit harder to configure but it is possible to do relatively securely. Fortunately
Squid has very good ACL's (Access Control Lists) built into the squid.conf file, allowing you
to lock down access by names, IP s, networks, time of day, actual day (perhaps you allow
unlimited browsing on the weekends for people that actually come in to the office).
Remember however that the more complicated an ACL is, the slower Squid will be to respond
to requests.
Most network administrators will want to configure Squid so that an internal network can
access www sites on the Internet. In this example 10.0.0.0/255.255.255.0 is the internal
network, 5.6.7.8 is the external IP address of the Squid server, and 1.2.3.4 is a www server we
want to see.
80
Squid should be configured so that it only listens for requests on it s internal interface, if it
were listening on all interfaces I could go to 5.6.7.8 port 3128 and request http://10.0.0.2/, or
any internal machine for that matter and view www content on your internal network. You
want something like this in your squid.conf file:
tcp_incoming_address 10.0.0.1
tcp_outgoing_address 5.6.7.8
udp_incoming_address 10.0.0.1
udp_outgoing_address 5.6.7.8
This will prevent anyone from using Squid to probe your internal network.
On the opposite side of the coin we have people that use Squid to make internal www servers
accessible to the Internet in a controlled manner. For example you may want to have an IIS
4.0 www server you want to put on the Internet, but are afraid to connect it directly. Using
Squid you can grant access to it in a very controlled manner. In this example 1.2.3.4 is a
random machine on the Internet, 5.6.7.8 is the external IP address of the Squid server,
10.0.0.1 is it s internal IP address, and 10.0.0.2 is a www server on the internal network
running IIS 4.0.
[ Pobierz całość w formacie PDF ]