Community: Unix tutorial. Linux and FreeBsd help

Although native Linux networking allows you to set up your Linux server as an Internet firewall and gateway for a number of machines on a network, utilizing a caching proxy server can help reduce your bandwidth usage, as well as give you enhanced logging and filtering capabilities. The Squid Web Proxy Cache is a popular, free implementation of such a server, and it runs on most Unix systems. The Squid homepage is at http://www.squid-cache.org/. Squid can cache HTTP, FTP, and DNS lookups, enhancing the sharing of an Internet connection by storing frequently accessed data on the local network.

Getting and Installing Squid Downloads are available from the Squid homepage, either as binary files or source tarballs. The stable version as of this writing is version 2.3. There is also a user guide at http://squid-docs.sourceforge.net/latest/html/book1.htm. If you build from source, the compilation is quite easy. A basic installation with the default options would go something like this: tar -xzf squid-2.3-200101270000-src.tar.gz cd squid-2.3-200101270000 ./configure make make install If you want to explore the options available at compile time, type: ./configure --help A number of switchable options are available to control where Squid installs itself, memory usage, and default language, among others. If you've installed Squid using the defaults, the configuration file can be found at /usr/local/squid/etc/squid.conf. The first option you will see in this file is http_port. By default, Squid uses port 3128. Otherwise you define your port(s) as follows: http_port 3128 Another important item is the amount of memory allocated to the cache. The directive must be defined in multiples of 4KB. The default is 8MB: cache_mem 8 MB Squid also caches DNS lookups, which can also save time and bandwidth. The default setting is 1024 entries, and is controlled by the following line: fqdncache_size 1024 By default, Squid stores the cached data in/usr/local/squid/bin/squid. This directive controls the filesystem type, the directory used, the allowed size in MB, and the number of first- and second-level subdirectories: cache_dir ufs /usr/local/squid/cache/ 100 16 256 Logging is done in /var/log/squid/access.log and /var/log/squid/cache.log. Other directives control where these logs are placed, and the level of logging: cache_access_log cache_log debug_options log_fqdn If Squid dies, e-mail is sent to the user defined under cache_mgr. This address is also appended to error pages the users might see. The default is webmaster, but you can set it appropriately: cache_mgr webmaster You should either create a "squid" user and group ID for the Squid server process, or assign it to another account with few system rights, like "nobody": cache_effective_user nobody cache_effective_group nobody You will also need to create the cache directory and change the ownership of both the cache and log directories to the squid user: cd /usr/local/squid mkdir cache chown nobody.nobody cache logs Access Control Finally, we get to access control. It allows you to limit where, when, and what machines can access certain sites. You can get really draconian here and severely restrict access, or drill down and address problem employees who would rather surf than work. A very basic set of control lines is the following: acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl all src 0.0.0.0/0.0.0.0 acl allowed_hosts src 192.168.192.0/255.255.255.0 http_access deny manager all http_access allow allowed_hosts http_access deny all icp_access allow allowed_hosts icp_access deny all The allowed_hosts line should correspond to your internal network configuration. Many things can be done with combinations of access control lists and access rules. For example, these lines would keep all internal IPs off the Web except during lunchtime: acl lunchtime MTWHF 12:00-13:00 http_access allow allowed_hosts lunchtime And the following would bar a problem user from the ebay domain: acl problem_user src 192.168.192.22/255.255.255.0 acl ebay dst ebay.com http_access deny problem_user ebay Starting Squid To start Squid, you'll need to run the following commands: /usr/local/squid/bin/squid -z /usr/local/squid/bin/squid The first pass creates the cache directories, and the second starts the daemon. The first command only needs to be run the first time the proxy is used. Testing Squid For initial testing, you can use the squid client program: /usr/local/squid/bin/client -h www.squid-cache.org -p 80 / /usr/local/squid/bin/client -h moe -p 3128 http://www.squid-cache.org/ The first command gets data directly from the Squid Web page, and the second goes through the proxy server, moe. The client program also has a number of options, which can be viewed with the -? command. You'll probably want to add a startup script to start Squid with the rest of the system daemons. The method will vary, depending on your OS and/or distribution. To set up your client browsers to use the proxy, set the HTTP and FTP proxy to point to the Squid proxy machine, port 3128. To force clients to use the proxy, you'll need to modify your firewall/masquerading setup. Under Linux, you'll need to enable an additional feature while compiling your kernel: IP: transparent proxy support This transparent proxy support will allow you to define a ruleset in ipchains to redirect all external HTTP requests to the proxy server's port: ipchains -A input -p TCP -d 127.0.0.1/32 www -j ACCEPT ipchains -A input -p TCP -d 192.168.192.1/32 www -j ACCEPT ipchains -A input -p TCP -d any/0 www -j REDIRECT 3128 These lines enable access to the local Web server, but redirect all other HTTP requests through the proxy. You could also add an additional rule for FTP requests. These ipchains commands should be added to the end of the rest of your firewall script, typically /etc/rc.d/rc.firewall. By using this procedure, you don't need to configure the client browsers to use the cache. Some additional squid.conf lines are needed to go with this setup: httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on Otherwise, the redirect will send the user to a Squid error page, noting the absence of the "http://" prefix on the request. You're still blocking direct access, but not as transparently or elegantly. Copyright, <2003> Jupitermedia All rights reserved. Reprinted with permission from http://www.internet.com

The original of this article you can find here.



DNS (Domain Name Service) Server is an important server for the Internet. It determines the name of
network-computer within the Internet. The main work of the DNS server is exchange IP address to the hostname,
hostname to the IP address. As mentioned in the Mail Server page, MX record is often required and is provided
by the DNS server.



In the FreeBSD System, the configuration file is distributed in the directory; /etc/namedb/. The important
files are:

There are two basic kinds of virtual hosts: those that are based on having a unique IP address, and those which share IP addresses but have different names. The latter are much more common on the Web these days, but the former are still in heavy use in organisations with relatively few sites being hosted per Web server. Vhosts which have their own IP addresses are called IP-Based virtual hosts, and those that share an address are called Name-Based virtual hosts.

IP-based virtual hosts use the IP address of the connection to determine the correct virtual host to serve. Therefore, you need to have separate IP address for each host. With the name-based virtual hosting, the server relies on the client to report the hostname as part of the HTTP headers. Using this technique, many different hosts can share the same IP address. Name-based virtual hosting is usually simplier, since you only need to configure your DNS server to map each hostname to the correct IP address and then configure Apache HTTP Server to recognize the different hostnames. This may sound great, but here are 3 problems with using name-based virtual hosting:

Using apache and OpenSSL you can create your own secure web server to keep authentication and other information private.

Having a secure web server is very necessity if you are doing on-line administration, banking and/or e-commerce. You may just have personal information you need to access over the web and wish to make secure. Using a secure web server is perfect for these implementations.

You must have the following packages installed:

Apache 1.3.12 or later
mod-ssl-2.2.6 or later
OpenSSL-0.9.5a or later

Yuo must compile the OpenSSL first

$ ./config
$ make
$ make test
$ make install

What we'd like to do is allow mail relaying from a selected group of IP addresses only. If you've just been reading the qmail newbie's guide to relaying, you know that we do this be setting the environment variable RELAYCLIENT in qmail-smtpd's environment only when the connection is coming from one of our IP addresses. Here's how to do it.

First, list in control/rcpthosts all of the domains that your server is hosting (i.e. those listed in control/locals and control/virtualdomains). Also list any domains for which your server is acting as secondary mail exchanger. The domains in control/rcpthosts are the domains for which your server will always accept incoming mail, no matter where it's coming from. You must have a rcpthosts file; otherwise your server will relay mail for anyone.

The purpose of this document is to describe the setup of the secure web application server on FreeBsd.

Get the distributions:

# su
# cd /usr/local/src
# wget http://www.apache.org/dist/httpd/httpd-2.0.39.tar.gz

Unpack distributions:

# tar xfz httpd-2.0.39.tar.gz

Build And Install Apache:

cd ../apache_2.0.39
./configure --prefix=/usr/local/apache --enable-module=all --enable-shared=max
make
make install

To configure Apache you should edit /usr/local/apache/conf/httpd.conf

Add the following line to the startup script to launch Apache at startup:
(for example, into /etc/rc.local file)

This article will explain how you can move your FreeBSD installation from one hard disk drive to another. I have done this many times using the dump/restore utility. Before you begin, be sure you have read this document carefully. Let's assume that our FreeBSD installation is on a 4 gigabyte drive (ide master ad0) and we would like to move it to a new 20 gig drive. What you need to do is remove the old hard disk, install the new [20G] drive as an ide master and perform a minimal clean install of FreeBSD, setting up the partitions exactly how you want them. Be se sure to set the drive as bootable and boot from it one time as a test. Next, put your old [4G] drive back in the system as an ide master and the new [20G] drive in as an ide slave. Boot the system on your old installation in single user mode.

The firewall configuration are located in the /etc/rc.firewall file. Since we told the firewall software that we are using it as a "simple" firewall, the active configuration are the one in the "simple" section. Usually the default configuration are enough, especially since we just buld a NAT firewall.

Port redirection

Normally, a firewall setup would include a DMZ, a third network interface, where publicly accesible servers should be located. One of these servers could be a mail-relay server, to handle and sort incoming mail before it reaches the central mail system - such as MS Exchange (known for it's non-existing features for relay control). Many corporate installations would include something for scanning, filtering and validating the inbound and outbound mail, like MailSweeper. This server would live on the DMZ.. There are two different approaches into solving this, one is port redirection - the other are address redirection. Let's just for arguments sake assume that the DMZ network have the address-space of 10.0.0.0 with a C-Class network (netmask 255.255.255.0), the DMZ interface is 10.0.0.1 and the MailSweeper machine are 10.0.0.2.

Most books talk about creating a database, but touch very lightly on setting appropriate permissions for the table. First, create the database that you wish to use:

# mysqladmin create my_new_database -u root -p

Now that you have the database, you need to set up some basic security permissions that govern how it can be accessed. Enter the mysql program and change to the mysql security database:

# mysql -u root -p
mysql> USE mysql

Now, we can get down to business. If you want to grant more than just the ability to select items, make the changes in the 'db' database. Otherwise you'll be granting access to other databases that you don't want the account to have access to.

MySQL is a fast, multi-threaded, multi-user and robust SQL (Structured Query Language) database server. It provides a nifty API which makes it easy to integrate into other applications, including PHP.

The most important configuration parameters include:

--without-bench Do not compile the set of benchmarking tests. Unless you will specifically be using these, using this option will speed up your build time.

--with-extra-charsets=none This builds a faster MySQL server by only using the ISO-8859-1 (Latin1) characterset. Unless you are using a language other than English, this is a good option to select.