2539 lines
84 KiB
Plaintext
2539 lines
84 KiB
Plaintext
|
Firewall and Proxy Server HOWTO
|
|||
|
Mark Grennan, mark@grennan.com
|
|||
|
v0.80, Feb. 26, 2000
|
|||
|
|
|||
|
This document is designed to describe the basics of firewall systems
|
|||
|
and give you some detail on setting up both a filtering and proxy
|
|||
|
firewall on a Linux based system. An HTML version of this document is
|
|||
|
available at http://www.grennan.com/Firewall-HOWTO.html
|
|||
|
______________________________________________________________________
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
1.1 Feedback
|
|||
|
1.2 Disclaimer
|
|||
|
1.3 Copyright
|
|||
|
1.4 My Reasons for Writing this
|
|||
|
1.5 Further Readings
|
|||
|
|
|||
|
2. Understanding Firewalls
|
|||
|
|
|||
|
2.1 Firewall Politics
|
|||
|
2.1.1 How it create a security policy
|
|||
|
2.2 Types of Firewalls
|
|||
|
2.2.1 Packet Filtering Firewalls
|
|||
|
2.2.2 Proxy Servers
|
|||
|
2.2.3 Application Proxy
|
|||
|
2.2.4 SOCKS Proxy
|
|||
|
|
|||
|
3. Firewall Architecture
|
|||
|
|
|||
|
3.1 Dial-up Architecture
|
|||
|
3.2 Single Router Architecture
|
|||
|
3.3 Firewall with Proxy Server
|
|||
|
3.4 Redundent Internet Configuration
|
|||
|
|
|||
|
4. Setting up the Linux Filtering Firewall
|
|||
|
|
|||
|
4.1 Hardware requirements
|
|||
|
|
|||
|
5. Software requirements
|
|||
|
|
|||
|
5.1 Selecting a Kernel
|
|||
|
5.2 Selecting a proxy server
|
|||
|
|
|||
|
6. Preparing the Linux system
|
|||
|
|
|||
|
6.1 Compiling the Kernel
|
|||
|
6.2 Configuring two network cards
|
|||
|
6.3 Configuring the Network Addresses
|
|||
|
6.4 Testing your network
|
|||
|
6.5 Securing the Firewall
|
|||
|
|
|||
|
7. IP filtering setup (IPFWADM)
|
|||
|
|
|||
|
8. IP filtering setup (IPCHAINS)
|
|||
|
|
|||
|
9. Installing a Transparent SQUID proxy
|
|||
|
|
|||
|
10. Installing the TIS Proxy server
|
|||
|
|
|||
|
10.1 Getting the software
|
|||
|
10.2 Compiling the TIS FWTK
|
|||
|
10.3 Installing the TIS FWTK
|
|||
|
10.4 Configuring the TIS FWTK
|
|||
|
10.4.1 The netperm-table file
|
|||
|
10.4.2 The /etc/services file
|
|||
|
|
|||
|
11. The SOCKS Proxy Server
|
|||
|
|
|||
|
11.1 Setting up the Proxy Server
|
|||
|
11.2 Configuring the Proxy Server
|
|||
|
11.2.1 The Access File
|
|||
|
11.2.2 The Routing File
|
|||
|
11.3 Working With a Proxy Server
|
|||
|
11.3.1 Unix
|
|||
|
11.3.2 MS Windows with Trumpet Winsock
|
|||
|
11.3.3 Getting the Proxy Server to work with UDP Packets
|
|||
|
11.4 Drawbacks with Proxy Servers
|
|||
|
|
|||
|
12. Advanced Configurations
|
|||
|
|
|||
|
12.1 A large network with emphasis on security
|
|||
|
12.1.1 The Network Setup
|
|||
|
12.1.2 The Proxy Setup
|
|||
|
|
|||
|
13. Making Management Easy
|
|||
|
|
|||
|
13.1 Firewall tools
|
|||
|
13.2 General tools
|
|||
|
|
|||
|
14. Defeating a Proxy Firewall Just to spoil your day, and keep you on your toes about security, I'll describe how easy it is to defeat a proxy firewall. Now that you have done everything in this document and have a very secure server and network. You have a DMZ and no one can get into your network and you are logging every connection made to the outside world. You make all your users go through a proxy and no one can go directly to the Internet. Then one of your users, with a didacated connection of his own, finds out about
|
|||
|
|
|||
|
15. APPENDEX A - Example Scripts
|
|||
|
|
|||
|
15.1 RC Script useing GFCC
|
|||
|
15.2 GFCC script
|
|||
|
15.3 RC Script without GFCC This is the firewall rules set built my hand. It does not use GFCC.
|
|||
|
|
|||
|
16. APPENDEX B - An VPN RC Script for RedHat
|
|||
|
|
|||
|
|
|||
|
|
|||
|
______________________________________________________________________
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
David Rudder wrote this original version of this Firewall-HOWTO,
|
|||
|
these many moons ago, and I'd still like to thank him for allowing me
|
|||
|
to update his work.
|
|||
|
|
|||
|
I'd also like to thank Ian Gough for kindly assisting a this dislexic
|
|||
|
writer.
|
|||
|
|
|||
|
Firewalls have gained great popularity as the ultimate in Internet
|
|||
|
Security. Like most hot subject they are also often misunderstood.
|
|||
|
This HOWTO will go over the basics of what a firewall is and how to
|
|||
|
set one up.
|
|||
|
|
|||
|
I am using kernel 2.2.13 and RedHat 6.1 to develop this howto so the
|
|||
|
examples here are based on this distribution. If you find differences
|
|||
|
in your distribution, please email me and I'll update this howto.
|
|||
|
|
|||
|
|
|||
|
1.1. Feedback
|
|||
|
|
|||
|
Any feedback is very welcome. PLEASE REPORT ANY INACCURACIES IN THIS
|
|||
|
PAPER!!! I am human, and prone to making mistakes. If you find a fix
|
|||
|
for anything please send it to me. I will try to answer all e-mail,
|
|||
|
but I am busy, so don't get insulted if I don't.
|
|||
|
|
|||
|
My email address is mark@grennan.com <mailto:mark@grennan.com>
|
|||
|
|
|||
|
|
|||
|
1.2. Disclaimer
|
|||
|
|
|||
|
|
|||
|
I AM NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN
|
|||
|
BASED ON THIS DOCUMENT. This document is meant as an introduction to
|
|||
|
how firewalls and proxy servers work. I am not, nor do I pretend to
|
|||
|
be, a security expert. ;-) I am just some guy who has read too much
|
|||
|
and likes computers more than most people. Please, I am writing this
|
|||
|
to help people get acquainted with this subject, and I am not ready to
|
|||
|
stake my life on the accuracy of what is in here.
|
|||
|
|
|||
|
|
|||
|
1.3. Copyright
|
|||
|
|
|||
|
|
|||
|
Unless otherwise stated, Linux HOWTO documents are copyrighted by
|
|||
|
their respective authors. Linux HOWTO documents may be reproduced and
|
|||
|
distributed in whole or in part, in any medium physical or electronic,
|
|||
|
as long as this copyright notice is retained on all copies. Commercial
|
|||
|
redistribution is allowed and encouraged; however, the author would
|
|||
|
like to be notified of any such distributions.
|
|||
|
|
|||
|
All translations, derivative works, or aggregate works incorporating
|
|||
|
any Linux HOWTO documents must be covered under this copyright notice.
|
|||
|
That is, you may not produce a derivative work from a HOWTO and impose
|
|||
|
additional restrictions on its distribution. Exceptions to these rules
|
|||
|
may be granted under certain conditions; please contact the Linux
|
|||
|
HOWTO coordinator.
|
|||
|
|
|||
|
In short, we wish to promote dissemination of this information through
|
|||
|
as many channels as possible. However, we do wish to retain copyright
|
|||
|
on the HOWTO documents, and would like to be notified of any plans to
|
|||
|
redistribute the HOWTOs.
|
|||
|
|
|||
|
If you have any questions, please email me. (See Above)
|
|||
|
|
|||
|
|
|||
|
1.4. My Reasons for Writing this
|
|||
|
|
|||
|
Several years ago, while working for the State of Oklahoma as their
|
|||
|
"Internet Administrator" I was ask to "put the State on the Internet",
|
|||
|
with no budget. (Note: There was no such title at the time. I was
|
|||
|
just the guy doing all the work.) The best way to make this happen was
|
|||
|
to use as much free software and junk hardware as I could. Linux and
|
|||
|
a bunch of old 486s were all I had to work with.
|
|||
|
|
|||
|
Commercial firewalls are VERY over priced and the documentation on how
|
|||
|
they work is considered almost top secret. I found creating a firewall
|
|||
|
of my own was almost impossible.
|
|||
|
|
|||
|
At my next job, I was asked to put in a firewall. Linux had just
|
|||
|
added firewall code. So again with no budget I started building a
|
|||
|
firewall with Linux. Six months later my firewall was in place and
|
|||
|
this document was updated.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
1.5. Further Readings
|
|||
|
|
|||
|
|
|||
|
<20> The The Linux Networking Overview HOWTO
|
|||
|
<http://sunsite.unc.edu/mdw/HOWTO/Networking-Overview-HOWTO.html>
|
|||
|
|
|||
|
<20> The Ethernet HOWTO <http://sunsite.unc.edu/mdw/HOWTO/Ethernet-
|
|||
|
HOWTO.html>
|
|||
|
|
|||
|
<20> IPchains Firewalling made Easy! <http://ipchains.nerdherd.org/>
|
|||
|
|
|||
|
<20> Linux Network Address Translation
|
|||
|
<http://www.linas.org/linux/load.html>
|
|||
|
|
|||
|
<20> The Net-3 HOWTO <http://sunsite.unc.edu/mdw/HOWTO/NET-3-HOWTO.html>
|
|||
|
|
|||
|
<20> The NET-PPP HOWTO <http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html>
|
|||
|
|
|||
|
<20> The easiest way to create Virtual Tunnels over TCP/IP networks
|
|||
|
<http://vtun.netpedia.net/>
|
|||
|
|
|||
|
[ More URLS go here ]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2. Understanding Firewalls
|
|||
|
|
|||
|
A firewall is a structure intended to keep a fire from spreading.
|
|||
|
Building have firewalls made of brick walls completely dividing
|
|||
|
sections of the building. In a car a firewall is the metal wall
|
|||
|
separating the engine and passenger compartments.
|
|||
|
|
|||
|
Internet firewalls are intended to keep the flames of Internet hell
|
|||
|
out of your private LAN. Or, to keep the members of your LAN pure and
|
|||
|
chaste by denying them access the all the evil Internet temptations.
|
|||
|
;-)
|
|||
|
|
|||
|
The first computer firewall was a non-routing Unix host with
|
|||
|
connections to two different networks. One network card connected to
|
|||
|
the Internet and the other to the private LAN. To reach the Internet
|
|||
|
from the private network, you had to logon to the firewall (Unix)
|
|||
|
server. You then used the resources of the system to access the
|
|||
|
Internet. For example, you could use X-windows to run Netscape's
|
|||
|
browser on the firewall system and have the display on your work
|
|||
|
station. With the browser running on the firewall it has access to
|
|||
|
both networks.
|
|||
|
|
|||
|
This sort of dual homed system (a system with two network connections)
|
|||
|
is great if you can TRUST ALL of your users. You can simple setup a
|
|||
|
Linux system and give an account accounts on it to everyone needing
|
|||
|
Internet access. With this setup, the only computer on your private
|
|||
|
network that knows anything about the outside world is the firewall.
|
|||
|
No one can download to their personal workstations. They must first
|
|||
|
download a file to the firewall and then download the file from the
|
|||
|
firewall to their workstation.
|
|||
|
|
|||
|
BIG NOTE: 99% of all break-ins start with gaining account level access
|
|||
|
on the system being attacked. Because of this I don't recommend this
|
|||
|
type of firewall. It is also very limiting.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2.1. Firewall Politics
|
|||
|
|
|||
|
|
|||
|
You shouldn't believe a firewall machine is all you need. Set
|
|||
|
policies first.
|
|||
|
|
|||
|
Firewalls are used for two purposes.
|
|||
|
|
|||
|
|
|||
|
1. to keep people (worms / crackers) out.
|
|||
|
|
|||
|
2. to keep people (employees / children) in.
|
|||
|
|
|||
|
When I started working on firewalls I was surprised to learn the
|
|||
|
company I worked for were more interested in "spying" on their
|
|||
|
employees then keeping crackers out of their networks.
|
|||
|
|
|||
|
At least in my state (Oklahoma) employers have the right to monitor
|
|||
|
phone calls and Internet activity as long as they inform the employees
|
|||
|
they are doing it.
|
|||
|
|
|||
|
|
|||
|
Big Brother is not government. Big Brother = Big Business.
|
|||
|
|
|||
|
Don't get me wrong. People should work, not play at work. And I feel
|
|||
|
the work ethic has been eroding. However, I have also observed that
|
|||
|
management types are the biggest abusers of the rules they set. I have
|
|||
|
seen hourly workers reprimanded for using the Internet to looking for
|
|||
|
bus routesto get to work while the same manager used hours of work
|
|||
|
time looking for fine restaurants and nightclubs to take prospective
|
|||
|
customers.
|
|||
|
|
|||
|
My fix for this type of abuse is to publish the firewall logs on a Web
|
|||
|
page for everyone to see.
|
|||
|
|
|||
|
The security business can be scary. If you are the firewall manager,
|
|||
|
watch your back.
|
|||
|
|
|||
|
|
|||
|
2.1.1. How it create a security policy
|
|||
|
|
|||
|
I have seen some realy high folutin documentation on how to create a
|
|||
|
security policy. After many years of experence I know now say, don't
|
|||
|
believe a word of them. Create a security policy is simple.
|
|||
|
|
|||
|
|
|||
|
1. describe what you need to service
|
|||
|
|
|||
|
2. describe the group of people you need to service
|
|||
|
|
|||
|
3. describe which service each group needs access to
|
|||
|
|
|||
|
4. for each service group describe how the service should be keep
|
|||
|
secure
|
|||
|
|
|||
|
5. write a statment making all other forms of access a vialation
|
|||
|
|
|||
|
Your policy will become more complicated with time but don't try to
|
|||
|
cover to much ground now. Make it simple and clear.
|
|||
|
|
|||
|
|
|||
|
2.2. Types of Firewalls
|
|||
|
|
|||
|
There are two types of firewalls.
|
|||
|
|
|||
|
|
|||
|
1. Filtering Firewalls - that block selected network packets.
|
|||
|
|
|||
|
2. Proxy Servers (sometimes called firewalls) - that make network
|
|||
|
connections for you.
|
|||
|
|
|||
|
|
|||
|
2.2.1. Packet Filtering Firewalls
|
|||
|
|
|||
|
Packet Filtering is the type of firewall built into the Linux kernel.
|
|||
|
|
|||
|
A filtering firewall works at the network level. Data is only allowed
|
|||
|
to leave the system if the firewall rules allow it. As packets arrive
|
|||
|
they are filtered by their type, source address, destination address,
|
|||
|
and port information contained in each packet.
|
|||
|
|
|||
|
Many network routers have the ability to perform some firewall
|
|||
|
services. Filtering firewalls can be thought of as a type of router.
|
|||
|
Because of this you need a deep understanding of IP packet structure
|
|||
|
to work with one.
|
|||
|
|
|||
|
Because very little data is analyzed and logged, filtering firewalls
|
|||
|
take less CPU and create less latency in your network.
|
|||
|
Filtering firewalls do not provide for password controls. User can not
|
|||
|
identify themselves. The only identity a user has is the IP number
|
|||
|
assigned to their workstation. This can be a problem if you are going
|
|||
|
to use DHCP (Dynamic IP assignments). This is because rules are based
|
|||
|
on IP numbers you will have to adjust the rules as new IP numbers are
|
|||
|
assigned. I don't know how to automate this process.
|
|||
|
|
|||
|
Filtering firewalls are more transparent to the user. The user does
|
|||
|
not have to setup rules in their applications to use the Internet.
|
|||
|
With most proxy servers this is not true.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2.2.2. Proxy Servers
|
|||
|
|
|||
|
|
|||
|
Proxies are mostly used to control, or monitor, outbound traffic. Some
|
|||
|
application proxies cache the requested data. This lowers bandwidth
|
|||
|
requirements and decreases the access the same data for the next user.
|
|||
|
It also gives unquestionable evidence of what was transferred.
|
|||
|
|
|||
|
There are two types of proxy servers.
|
|||
|
|
|||
|
1. Application Proxies - that do the work for you.
|
|||
|
|
|||
|
2. SOCKS Proxies - that cross wire ports.
|
|||
|
|
|||
|
|
|||
|
2.2.3. Application Proxy
|
|||
|
|
|||
|
The best example is a person telneting to another computer and then
|
|||
|
telneting from there to the outside world. With a application proxy
|
|||
|
server the process is automated. As you telnet to the outside world
|
|||
|
the client send you to the proxy first. The proxy then connects to the
|
|||
|
server you requested (the outside world) and returns the data to you.
|
|||
|
|
|||
|
Because proxy servers are handling all the communications, they can
|
|||
|
log everything they (you) do. For HTTP (web) proxies this includes
|
|||
|
very URL they you see. For FTP proxies this includes every file you
|
|||
|
download. They can even filter out "inappropriate" words from the
|
|||
|
sites you visit or scan for viruses.
|
|||
|
|
|||
|
Application proxy servers can authenticate users. Before a connection
|
|||
|
to the outside is made, the server can ask the user to login first. To
|
|||
|
a web user this would make every site look like it required a login.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2.2.4. SOCKS Proxy
|
|||
|
|
|||
|
|
|||
|
A SOCKS server is a lot like an old switch board. It simply cross
|
|||
|
wires your connection through the system to another outside
|
|||
|
connection.
|
|||
|
|
|||
|
Most SOCKS server only work with TCP type connections. And like
|
|||
|
filtering firewalls they don't provide for user authentication. They
|
|||
|
can however record where each user connected to.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3. Firewall Architecture
|
|||
|
|
|||
|
There are lots of ways to structure your network to protect your
|
|||
|
systems using a firewall.
|
|||
|
|
|||
|
If you have a dedicated connections to the Internet through a router,
|
|||
|
you could plug the router directly into your firewall system. Or, you
|
|||
|
could go through a hub to provide for full access servers outside your
|
|||
|
firewall.
|
|||
|
|
|||
|
|
|||
|
3.1. Dial-up Architecture
|
|||
|
|
|||
|
You may be using a dialup service like an ISDN line. In this case you
|
|||
|
might use a third network card to provide provide a filtered DMZ. This
|
|||
|
gives you full control over your Internet services and still separates
|
|||
|
them from your regular network.
|
|||
|
|
|||
|
|
|||
|
__________
|
|||
|
_/\__/\_ | | _______________
|
|||
|
| | | Firewall | (LAN) | |
|
|||
|
/ Internet \----| System |--(HUB)--| Workstation/s |
|
|||
|
\_ _ _ _/ |__________| |_______________|
|
|||
|
\/ \/ \/ |
|
|||
|
(DMZ)
|
|||
|
(HUB)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.2. Single Router Architecture
|
|||
|
|
|||
|
If there is a router or cable modem between you and the Internet. If
|
|||
|
you own the router you could setup some hard filter rules in the
|
|||
|
router. If this router is owned by your ISP so you may not the have
|
|||
|
the needed controls. You can ask your ISP to put in filters.
|
|||
|
|
|||
|
|
|||
|
_________ __________
|
|||
|
_/\__/\_ | Router | | | _______________
|
|||
|
| | | or | (DMZ) | Firewall | (LAN) | |
|
|||
|
/ Internet \----|Cable Mdm|--(HUB)--| System |--(HUB)--| Workstation/s |
|
|||
|
\_ _ _ _/ |_________| | |__________| |_______________|
|
|||
|
\/ \/ \/ |
|
|||
|
(Outside)
|
|||
|
(Server)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.3. Firewall with Proxy Server
|
|||
|
|
|||
|
If you need to monitor where users of your network are going and your
|
|||
|
network is small, you can intergrate a proxy server into your
|
|||
|
firewall. ISP's some times do this to create interest list of their
|
|||
|
users to resell to marketing agencies.
|
|||
|
|
|||
|
|
|||
|
__________
|
|||
|
_/\__/\_ | Proxy / | _______________
|
|||
|
| | | Firewall | (LAN) | |
|
|||
|
/ Internet \----| System |--(HUB)--| Workstation/s |
|
|||
|
\_ _ _ _/ |__________| |_______________|
|
|||
|
\/ \/ \/
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You can put the proxy server on your LAN as will. In this case the
|
|||
|
firewall should have rules to only allow the proxy server to connect
|
|||
|
to the Internet for the services it is providing. This way the users
|
|||
|
can get to the Internet only through the proxy.
|
|||
|
|
|||
|
|
|||
|
__________
|
|||
|
_/\__/\_ | | _______________
|
|||
|
| | | Firewall | (LAN) | |
|
|||
|
/ Internet \----| System |--(HUB)--| Workstation/s |
|
|||
|
\_ _ _ _/ |__________| | |_______________|
|
|||
|
\/ \/ \/ | ______________
|
|||
|
| | |
|
|||
|
+----| Proxy Server |
|
|||
|
|______________|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.4. Redundent Internet Configuration
|
|||
|
|
|||
|
If you are going to run a service like YAHOO or maybe SlashDot you may
|
|||
|
want to make your system by using redundant routers and firewalls.
|
|||
|
(Check out the High Availability HowTo.)
|
|||
|
|
|||
|
By using a round-robin DNS techniques to provide access to multipule
|
|||
|
web servers from one URL and multiple ISP's, routers and firewalls
|
|||
|
using High Avaibility technics you can create a 100% uptime service.
|
|||
|
|
|||
|
|
|||
|
_/\__/\_ _/\__/\_
|
|||
|
| | | |
|
|||
|
/ ISP #1 \______ (WAN)_____/ Partners \
|
|||
|
\_ _ _ _/ | (HUB) \_ _ _ _/
|
|||
|
\/ \/ \/ | ___|____ \/ \/ \/
|
|||
|
__|___ |_______ |
|
|||
|
_/\__/\_ |_____ | |Firewall|| ______
|
|||
|
| | | || (DMZ) | System || (LAN) | |
|
|||
|
/ ISP #2 \--|Router||--(HUB)--| (VPN) ||--(HUB)--| WS/s |
|
|||
|
\_ _ _ _/ |______| | |________| | |______|
|
|||
|
\/ \/ \/ | | | ______
|
|||
|
| (Outside) (Shared) | | |
|
|||
|
------ | (Server) (Server) +----|Proxy |
|
|||
|
| WS/s | | |______|
|
|||
|
| VPN |-+
|
|||
|
|______|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
It is easy to let your network get out of hand. Keep control of every
|
|||
|
connection. It only takes a user with a modem to compromise your LAN.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4. Setting up the Linux Filtering Firewall
|
|||
|
|
|||
|
|
|||
|
4.1. Hardware requirements
|
|||
|
|
|||
|
|
|||
|
Filtering firewalls don't require fancy hardware. They are little more
|
|||
|
then simple routers.
|
|||
|
|
|||
|
All you need is:
|
|||
|
|
|||
|
|
|||
|
1. a 486-DX66 with 32 meg of memory
|
|||
|
|
|||
|
|
|||
|
2. a 250m hard disk (500 recommended)
|
|||
|
|
|||
|
3. network connections (LAN Cards, Serial Ports, Wireless?)
|
|||
|
|
|||
|
4. monitor and keyboard
|
|||
|
|
|||
|
With some systems by using a serial port console, you can even
|
|||
|
eliminate the monitor and keyboard.
|
|||
|
|
|||
|
If you need a proxy server that will handle lots of traffic, you
|
|||
|
should get the largest system you can afford. This is because for
|
|||
|
every user that connects to the system it will be creating another
|
|||
|
process. If you will have 50 or more concurrent users I'm guessing you
|
|||
|
will need:
|
|||
|
|
|||
|
|
|||
|
1. a Pentium II with 64meg of memory
|
|||
|
|
|||
|
2. a two gig hard disk to store all the logs
|
|||
|
|
|||
|
3. two network connections
|
|||
|
|
|||
|
4. monitor and keyboard
|
|||
|
|
|||
|
The network connections can be any type (NIC cards, ISDN, even
|
|||
|
modems).
|
|||
|
|
|||
|
|
|||
|
5. Software requirements
|
|||
|
|
|||
|
|
|||
|
5.1. Selecting a Kernel
|
|||
|
|
|||
|
|
|||
|
To create a filtering firewall, you don't need any special software.
|
|||
|
Linux will do. At the time of this writing I'm using RedHat 6.1.
|
|||
|
|
|||
|
The bilt in Linux firewall have changed several times. If you are
|
|||
|
using an old Linux kernel (1.0.x or older) geta new copy. These older
|
|||
|
used ipfwadm from http://www.xos.nl/linux/ipfwadm/ and is no longer
|
|||
|
supported.
|
|||
|
|
|||
|
If you are using 2.2.13 or newer you will be using ipchaining as
|
|||
|
developed by
|
|||
|
http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html
|
|||
|
<http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html>
|
|||
|
|
|||
|
If you are using the newer 2.4 kernal there is a new firewall utility
|
|||
|
with more feachers. I will write about this soon.
|
|||
|
|
|||
|
|
|||
|
5.2. Selecting a proxy server
|
|||
|
|
|||
|
If you want to setup a proxy server you will need one of these
|
|||
|
packages.
|
|||
|
|
|||
|
|
|||
|
1. Squid
|
|||
|
|
|||
|
2. The TIS Firewall Toolkit (FWTK)
|
|||
|
|
|||
|
3. SOCKS
|
|||
|
|
|||
|
|
|||
|
Squid is a great package and works with Linux's Transparent Proxy
|
|||
|
feature. I will be describing how to setup this server.
|
|||
|
AT the time of this writing, Network Associates
|
|||
|
<http://www.networkassociates.com/> and Trusted Information System's
|
|||
|
(TIS) , have merged. So keep watching their web sites for more
|
|||
|
information about changes. Mean while, the Tool Kit can still be had
|
|||
|
at. http://www.tis.com/research/software/
|
|||
|
<http://www.tis.com/research/software/>
|
|||
|
|
|||
|
Trusted Information System put out a collection of programs designed
|
|||
|
to facilitate firewalling. With this toolkit, you set up one daemon
|
|||
|
for each service (WWW, telnet ect.) you will be using.
|
|||
|
|
|||
|
|
|||
|
6. Preparing the Linux system
|
|||
|
|
|||
|
Install as little of the Linux system as you can. My installation
|
|||
|
started with a server configuration and then I turn off ever un-needed
|
|||
|
service in /etc/inetd.conf. For more security you should uninstall
|
|||
|
the unneeded service.
|
|||
|
|
|||
|
Because most distributions don't dome with a kernel usefull to your
|
|||
|
perpose. You will need to compile your own kernal. It is best if you
|
|||
|
do this on a computer other then the firewall. If you do install a C
|
|||
|
compiler and utilities on your firewall, remove them after you have
|
|||
|
completed comfiguring your kernel.
|
|||
|
|
|||
|
|
|||
|
6.1. Compiling the Kernel
|
|||
|
|
|||
|
|
|||
|
Start with a clean minimal installation of your Linux distribution.
|
|||
|
The less software you have loaded the less holes, backdoors and/or
|
|||
|
bugs there will be to introduce security problems in your server.
|
|||
|
|
|||
|
Pick a stable kernel. I am using kernel 2.2.13 kernel for my system.
|
|||
|
So this documentation is based on it's settings.
|
|||
|
|
|||
|
You well need to recompile the Linux kernel with the appropriate
|
|||
|
options. If you haven't recompiled your kernel before you should read
|
|||
|
the Kernel HOWTO, the Ethernet HOWTO, and the NET-2 HOWTO.
|
|||
|
|
|||
|
Here are the network related setting I know work. I have marked some
|
|||
|
with a ?. If you will be using this feature, turn it on as well.
|
|||
|
|
|||
|
I use "make menuconfig" to edit my kernel settings.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<*> Packet socket
|
|||
|
[ ] Kernel/User netlink socket
|
|||
|
[*] Network firewalls
|
|||
|
[ ] Socket Filtering
|
|||
|
<*> Unix domain sockets
|
|||
|
[*] TCP/IP networking
|
|||
|
[ ] IP: multicasting
|
|||
|
[*] IP: advanced router
|
|||
|
[ ] IP: kernel level autoconfiguration
|
|||
|
[*] IP: firewalling
|
|||
|
[?] IP: always defragment (required for masquerading)
|
|||
|
[?] IP: transparent proxy support
|
|||
|
[?] IP: masquerading
|
|||
|
--- Protocol-specific masquerading support will be built as modules.
|
|||
|
[?] IP: ICMP masquerading
|
|||
|
--- Protocol-specific masquerading support will be built as modules.
|
|||
|
[ ] IP: masquerading special modules support
|
|||
|
[*] IP: optimize as router not host
|
|||
|
< > IP: tunneling
|
|||
|
< > IP: GRE tunnels over IP
|
|||
|
[?] IP: aliasing support
|
|||
|
[*] IP: TCP syncookie support (not enabled per default)
|
|||
|
--- (it is safe to leave these untouched)
|
|||
|
< > IP: Reverse ARP
|
|||
|
[*] IP: Allow large windows (not recommended if <16Mb of memory)
|
|||
|
< > The IPv6 protocol (EXPERIMENTAL)
|
|||
|
---
|
|||
|
< > The IPX protocol
|
|||
|
< > Appletalk DDP
|
|||
|
< > CCITT X.25 Packet Layer (EXPERIMENTAL)
|
|||
|
< > LAPB Data Link Driver (EXPERIMENTAL)
|
|||
|
[ ] Bridging (EXPERIMENTAL)
|
|||
|
[ ] 802.2 LLC (EXPERIMENTAL)
|
|||
|
< > Acorn Econet/AUN protocols (EXPERIMENTAL)
|
|||
|
< > WAN router
|
|||
|
[ ] Fast switching (read help!)
|
|||
|
[ ] Forwarding between high speed interfaces
|
|||
|
[ ] PU is too slow to handle full bandwidth
|
|||
|
QoS and/or fair queueing --->
|
|||
|
|
|||
|
|
|||
|
|
|||
|
After making all the setting you need you should recompile, reinstall
|
|||
|
the kernel and reboot.
|
|||
|
|
|||
|
I use the command:
|
|||
|
|
|||
|
make dep;make clean;make bzlilo;make modules;make modules_install;init
|
|||
|
6 to accomplish all of this in one step.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
6.2. Configuring two network cards
|
|||
|
|
|||
|
|
|||
|
If you have two network cards in your computer, you may need to add an
|
|||
|
append statement to your /etc/lilo.conf file to describe the IRQ and
|
|||
|
address of both cards. My lilo append statement looks like this:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
append="ether=12,0x300,eth0 ether=15,0x340,eth1"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
6.3. Configuring the Network Addresses
|
|||
|
|
|||
|
|
|||
|
Now we arrive at the fun part of our setup. I'm not going to go deep
|
|||
|
into how to setup a LAN. Read the Networking-HOWTO to solve your
|
|||
|
problems here.
|
|||
|
|
|||
|
Your goal is to provide two network connection to your filtering
|
|||
|
firewall system. One on the Internet (unsecured side) and one on the
|
|||
|
LAN (secure side).
|
|||
|
|
|||
|
Anyway, you have a few decisions to make.
|
|||
|
|
|||
|
|
|||
|
1. Will you use Real IP number or Make some up for your LAN.
|
|||
|
|
|||
|
2. Will your ISP assign the number or will you be using static IP
|
|||
|
numbers?
|
|||
|
|
|||
|
Since you don't want the internet to have access to your private
|
|||
|
network, you don't need to use "real addresses". You could just
|
|||
|
makeup addresses for your private LAN. But this is not recommended. If
|
|||
|
data gets routed out of your LAN, it might end up at another systems
|
|||
|
port.
|
|||
|
|
|||
|
There are a number of Internet address ranges set aside for private
|
|||
|
networks. Of these, 192.168.1.xxx, is set aside and we will use it in
|
|||
|
our examples.
|
|||
|
|
|||
|
You will need to use IP masquerading to make this happen. With this
|
|||
|
process the firewall will forward packets and translate them into
|
|||
|
"REAL " " IP address to travel on the Internet.
|
|||
|
|
|||
|
Using these non-routable IP address makes your network is more secure.
|
|||
|
Internet routers will not pass packets with these addresses.
|
|||
|
|
|||
|
You may want to read the IP Masquerading HOWTO at this point.
|
|||
|
|
|||
|
|
|||
|
24.94.1.123 __________ 192.168.1.1
|
|||
|
_/\__/\_ \ | | / _______________
|
|||
|
| | \| Firewall |/ | |
|
|||
|
/ Internet \--------| System |------------| Workstation/s |
|
|||
|
\_ _ _ _/ |__________| |_______________|
|
|||
|
\/ \/ \/
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You must have a "real" IP address to assign to your Internet network
|
|||
|
card. This address can be permanently assigned to you. (A static IP
|
|||
|
address) or it can be assigned at network connect time by the PPP
|
|||
|
process.
|
|||
|
|
|||
|
You assign your inside IP numbers. Like 192.168.1.1 to the LAN card.
|
|||
|
This will be your gateway IP address. You can assign all the other
|
|||
|
machines in the protected network (LAN) a number in the 192.168.1.xxx
|
|||
|
range. (192.168.1.2 through 192.168.1.254)
|
|||
|
|
|||
|
I use RedHat Linux. To configure the network at boot time I added a
|
|||
|
ifcfg-eth1 file in the /etc/sysconfig/network-scripts directory. You
|
|||
|
may also find a ifcfg-ppp0 or ifcfg-tr0 in this directory. These
|
|||
|
'ifcfg-' files are used by RedHat to configure and enable your network
|
|||
|
devices at boot time. The are named after the connection type.
|
|||
|
|
|||
|
Here is the ifcfg-eth1 (second ehternet card) for our example;
|
|||
|
|
|||
|
DEVICE=eth1
|
|||
|
IPADDR=192.168.1.1
|
|||
|
NETMASK=255.255.255.0
|
|||
|
NETWORK=192.168.1.0
|
|||
|
BROADCAST=192.168.1.255
|
|||
|
GATEWAY=24.94.1.123
|
|||
|
ONBOOT=yes
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you are going to use a dialup connection you will need to look at
|
|||
|
the ifcfg-ppp0 and the chat-ppp0 file. These control your PPP
|
|||
|
connection.
|
|||
|
|
|||
|
This ifcfg file might look like;
|
|||
|
|
|||
|
|
|||
|
DEVICE="ppp0"
|
|||
|
ONBOOT="yes"
|
|||
|
USERCTL="no"
|
|||
|
MODEMPORT="/dev/modem"
|
|||
|
LINESPEED="115200"
|
|||
|
PERSIST="yes"
|
|||
|
DEFABORT="yes"
|
|||
|
DEBUG="yes"
|
|||
|
INITSTRING="ATZ"
|
|||
|
DEFROUTE="yes"
|
|||
|
HARDFLOWCTL="yes"
|
|||
|
ESCAPECHARS="no"
|
|||
|
PPPOPTIONS=""
|
|||
|
PAPNAME="LoginID"
|
|||
|
REMIP=""
|
|||
|
NETMASK=""
|
|||
|
IPADDR=""
|
|||
|
MRU=""
|
|||
|
MTU=""
|
|||
|
DISCONNECTTIMEOUT=""
|
|||
|
RETRYTIMEOUT="5"
|
|||
|
BOOTPROTO="none"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
6.4. Testing your network
|
|||
|
|
|||
|
|
|||
|
Start by using the ifconfig and route commands. If you have two
|
|||
|
network cards ifconfig should look something like:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
#ifconfig
|
|||
|
lo Link encap:Local Loopback
|
|||
|
inet addr:127.0.0.1 Mask:255.0.0.0
|
|||
|
UP LOOPBACK RUNNING MTU:3924 Metric:1
|
|||
|
RX packets:1620 errors:0 dropped:0 overruns:0
|
|||
|
TX packets:1620 errors:0 dropped:0 overruns:0
|
|||
|
collisions:0 txqueuelan:0
|
|||
|
|
|||
|
eth0 Link encap:10Mbps Ethernet HWaddr 00:00:09:85:AC:55
|
|||
|
inet addr:24.94.1.123 Bcast:24.94.1.255 Mask:255.255.255.0
|
|||
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|||
|
RX packets:1000 errors:0 dropped:0 overruns:0
|
|||
|
TX packets:1100 errors:0 dropped:0 overruns:0
|
|||
|
collisions:0 txqueuelan:0
|
|||
|
Interrupt:12 Base address:0x310
|
|||
|
|
|||
|
eth1 Link encap:10Mbps Ethernet HWaddr 00:00:09:80:1E:D7
|
|||
|
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
|
|||
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|||
|
RX packets:1110 errors:0 dropped:0 overruns:0
|
|||
|
TX packets:1111 errors:0 dropped:0 overruns:0
|
|||
|
collisions:0 txqueuelan:0
|
|||
|
Interrupt:15 Base address:0x350
|
|||
|
|
|||
|
|
|||
|
|
|||
|
and your route table should look like:
|
|||
|
|
|||
|
|
|||
|
#route -n
|
|||
|
Kernel routing table
|
|||
|
Destination Gateway Genmask Flags MSS Window Use Iface
|
|||
|
24.94.1.0 * 255.255.255.0 U 1500 0 15 eth0
|
|||
|
192.168.1.0 * 255.255.255.0 U 1500 0 0 eth1
|
|||
|
127.0.0.0 * 255.0.0.0 U 3584 0 2 lo
|
|||
|
default 24.94.1.123 * UG 1500 0 72 eth0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Note: 24.94.1.0 is the Internet side of this firewall and 192.168.1.0
|
|||
|
is the private (LAN) side.
|
|||
|
|
|||
|
You should start by making sure every computer on your LAN can ping
|
|||
|
the inside address of your firewall system. (192.168.1.1 in this
|
|||
|
example) If not, go over the NET-2 HOWTO again and work on the network
|
|||
|
some more.
|
|||
|
|
|||
|
Next, from the firewall, try to ping a Internet system. I use
|
|||
|
www.internic.net as my test point. If it doesn't work, try a server
|
|||
|
at your ISP. If this doesn't work some part of your Internet
|
|||
|
connection is wrong. You should be able to connect to the anywhere on
|
|||
|
the Internet from the firewall. Try looking at your default gateway
|
|||
|
setting. If you are using a dialup connection double check your user
|
|||
|
ID and Password. Reread the Net-2 HOWTO, and try again.
|
|||
|
|
|||
|
Now try to ping the outside address of the firewall (24.94.1.123) from
|
|||
|
a computer on your LAN. This shouldn't work. If it does, you have
|
|||
|
masquerading or IP Forwarding turned on, or you already have some
|
|||
|
packet filtering set. Turn them off and try again. You need to know
|
|||
|
the filtering is in place.
|
|||
|
|
|||
|
For kernels newer then 2.1.102 you can issue the command;
|
|||
|
|
|||
|
|
|||
|
echo "0" > /proc/sys/net/ipv4/ip_forward
|
|||
|
|
|||
|
If you are using an older kernel (WHY) you will need to re-compile
|
|||
|
your kernel with forwarding turned off. (Just upgrade.)
|
|||
|
|
|||
|
Try pinging the outside address of the firewall (24.94.1.123) again.
|
|||
|
It shouldn't work.
|
|||
|
|
|||
|
Now turn on IP forwarding and/or masquerading. You should be able to
|
|||
|
ping the anywhere on the Internet from any system on your LAN.
|
|||
|
|
|||
|
|
|||
|
echo "1" > /proc/sys/net/ipv4/ip_forward
|
|||
|
|
|||
|
|
|||
|
|
|||
|
BIG NOTE: If you are using "REAL" IP addresses on your LAN (not
|
|||
|
192.168.1.*) and you can't ping the internet but you CAN ping the
|
|||
|
Internet side of your firewall, make sure your ISP is routing packets
|
|||
|
for your private network address.
|
|||
|
|
|||
|
A test for this problem is to have someone else on the Internet (say a
|
|||
|
friend using a local provider) use traceroute to your network. If the
|
|||
|
trace stops at your providers router, then they are not forwarding
|
|||
|
your traffic.
|
|||
|
|
|||
|
It works? Great. The hard part is done. :-)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
6.5. Securing the Firewall
|
|||
|
|
|||
|
A firewall isn't any good if the system it is build on is left wide
|
|||
|
open to attacks. A "bad guy" could gain access to the through a non
|
|||
|
firewall service and modify it for their own needs. You need to
|
|||
|
turning off any unneeded services.
|
|||
|
|
|||
|
Look in your /etc/inetd.conf file. This file configures inetd also
|
|||
|
known as the "super server". It controls a bunch of the server
|
|||
|
daemons and starts them as they are requested by a packet arriving at
|
|||
|
a "well known" port.
|
|||
|
|
|||
|
You should turn off echo, discard, daytime, chargen, ftp, gopher,
|
|||
|
shell, login, exec, talk, ntalk, pop-2, pop-3, netstat, systat, tftp,
|
|||
|
bootp, finger, cfinger, time, swat and linuxconfig if you have one.
|
|||
|
|
|||
|
To turn a service off, put # as the first character of the service
|
|||
|
line. When your done, send a SIG-HUP to the process by typing "kill
|
|||
|
-HUP <pid>", where <pid> is the process number of inetd. This will
|
|||
|
make inetd re-read its configuration file (inetd.conf) and restart
|
|||
|
without taking your system down.
|
|||
|
|
|||
|
Test this by telneting to port 15 (netstat) on firewall. If you get
|
|||
|
any output you have not turned these services off.
|
|||
|
|
|||
|
telnet localhost 19
|
|||
|
|
|||
|
You can also create the file /etc/nologin. Put a few line of text in
|
|||
|
it like (BUZZ OFF). When this file exists, login will not allow user
|
|||
|
to logon. They will see the contents of this file and their logins
|
|||
|
refused. Only root can logon.
|
|||
|
|
|||
|
You can also edit the file /etc/securetty. If the user is root,
|
|||
|
then the login must be occurring on a tty listed in
|
|||
|
/etc/securetty. Failures will be logged with the syslog facility.
|
|||
|
With both of these controls in place the only way to logon to the
|
|||
|
firewall will be as root from the console.
|
|||
|
|
|||
|
NEVER EVER TELNET to a system and log IN AS ROOT. If you need remote
|
|||
|
root access SSH (Secure Shell). You might even turn off telnet.
|
|||
|
|
|||
|
If you are really paranoid you need to be using lids (Linux Intrusion
|
|||
|
Detect System). It is an intrusion detection system patch for the
|
|||
|
Linux kernel; it can protect important files from being changed. When
|
|||
|
it's in effect, no one (including root) can change the protected files
|
|||
|
or directories and their sub-directories. You have to reboot the
|
|||
|
system with a security=1 LILO setting to modify secure files. (I'd
|
|||
|
also boot into single user mode.)
|
|||
|
|
|||
|
|
|||
|
7. IP filtering setup (IPFWADM)
|
|||
|
|
|||
|
|
|||
|
If you are using kernel 2.1.102 or newer skip to the next section on
|
|||
|
IPCHAINS.
|
|||
|
|
|||
|
In older kernels IP Forwarding is turned on by default in the kernel.
|
|||
|
Because of this, your network should start by denying access to
|
|||
|
everything and flushing any ipfw rules in place from the last time it
|
|||
|
was run. This script fragment should go in your network startup
|
|||
|
script. (/etc/rc.d/init.d/network)
|
|||
|
|
|||
|
|
|||
|
#
|
|||
|
# setup IP packet Accounting and Forwarding
|
|||
|
#
|
|||
|
# Forwarding
|
|||
|
#
|
|||
|
# By default DENY all services
|
|||
|
ipfwadm -F -p deny
|
|||
|
# Flush all commands
|
|||
|
ipfwadm -F -f
|
|||
|
ipfwadm -I -f
|
|||
|
ipfwadm -O -f
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Now we have the ultimate firewall. Nothing can get through.
|
|||
|
|
|||
|
Now create the file /etc/rc.d/rc.firewall. This script should allow
|
|||
|
email, Web and DNS traffic through. ;-)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
#! /bin/sh
|
|||
|
#
|
|||
|
# rc.firewall
|
|||
|
#
|
|||
|
# Source function library.
|
|||
|
. /etc/rc.d/init.d/functions
|
|||
|
|
|||
|
# Get config.
|
|||
|
. /etc/sysconfig/network
|
|||
|
|
|||
|
# Check that networking is up.
|
|||
|
if [ ${NETWORKING} = "no" ]
|
|||
|
then
|
|||
|
exit 0
|
|||
|
fi
|
|||
|
case "$1" in
|
|||
|
start)
|
|||
|
echo -n "Starting Firewall Services: "
|
|||
|
# Allow email to got to the server
|
|||
|
/sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25
|
|||
|
# Allow email connections to outside email servers
|
|||
|
/sbin/ipfwadm -F -a accept -b -P tcp -S 192.1.2.10 25 -D 0.0.0.0/0 1024:65535
|
|||
|
# Allow Web connections to your Web Server
|
|||
|
/sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.11 80
|
|||
|
# Allow Web connections to outside Web Server
|
|||
|
/sbin/ipfwadm -F -a accept -b -P tcp -S 192.1.2.* 80 -D 0.0.0.0/0 1024:65535
|
|||
|
# Allow DNS traffic
|
|||
|
/sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 192.1.2.0/24
|
|||
|
;;
|
|||
|
stop)
|
|||
|
echo -n "Stooping Firewall Services: "
|
|||
|
ipfwadm -F -p deny
|
|||
|
;;
|
|||
|
status)
|
|||
|
echo -n "Now do you show firewall stats?"
|
|||
|
;;
|
|||
|
restart|reload)
|
|||
|
$0 stop
|
|||
|
$0 start
|
|||
|
;;
|
|||
|
*)
|
|||
|
echo "Usage: firewall {start|stop|status|restart|reload}"
|
|||
|
exit 1
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
NOTE: In this example we have the email (smtp) server running at
|
|||
|
192.1.2.10 that must be able to send and receive on port 25. The web
|
|||
|
server running at 192.1.2.11. We are allowing anyone on the LAN to get
|
|||
|
to outside web and DNS servers.
|
|||
|
|
|||
|
This is not perfectly secure. Because port 80 doesn't have to used as
|
|||
|
a web port, a smart hacker might use this port to create a virtual
|
|||
|
private network (VPN) through the firewall. The way around this is to
|
|||
|
setup a web proxy. and only allow the proxy through the firewall.
|
|||
|
Users on the LAN will have to go through the proxy to get to outside
|
|||
|
web servers.
|
|||
|
|
|||
|
You might also be interested in accounting for traffic going through
|
|||
|
your firewall. This script will count ever packet. You could add a
|
|||
|
line or two to account for packets going to just a single system.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
# Flush the current accounting rules
|
|||
|
ipfwadm -A -f
|
|||
|
# Accounting
|
|||
|
/sbin/ipfwadm -A -f
|
|||
|
/sbin/ipfwadm -A out -i -S 192.1.2.0/24 -D 0.0.0.0/0
|
|||
|
/sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 192.1.2.0/24
|
|||
|
/sbin/ipfwadm -A in -i -S 192.1.2.0/24 -D 0.0.0.0/0
|
|||
|
/sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 192.1.2.0/24
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If all you need is a filtering firewall you can stop here. Test it
|
|||
|
and Enjoy.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
8. IP filtering setup (IPCHAINS)
|
|||
|
|
|||
|
Linux ipchains is a rewrite of the Linux IPv4 firewalling code and a
|
|||
|
rewrite of ipfwadm, which was a rewrite of BSD's ipfw, I believe. It
|
|||
|
is required to administer the IP packet filters in Linux kernel
|
|||
|
versions 2.1.102 and above.
|
|||
|
|
|||
|
The older code doesn't deal with fragments, has 32-bit counters (on
|
|||
|
Intel at least), doesn't allow specification of protocols other than
|
|||
|
TCP, UDP or ICMP, can't make large changes atomically, can't specify
|
|||
|
inverse rules, has some quirks, and can be tough to manage (making it
|
|||
|
prone to user error). Or so the author says.
|
|||
|
|
|||
|
I'm not going to get real deep into how to control an IPChains
|
|||
|
firewall because there is a GREAT!! HOWTO on it at
|
|||
|
http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html
|
|||
|
<http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html>.
|
|||
|
I'd just end up duplicating it here. Here are the basics.
|
|||
|
|
|||
|
You work with chains by name. You start with three built-in chains
|
|||
|
input, output and forward which you can't delete. You can create
|
|||
|
chains of your own. Rules can then be added and deleted from these
|
|||
|
rule sets.
|
|||
|
|
|||
|
The operations to work on entire chains are;
|
|||
|
|
|||
|
|
|||
|
1. Create a new chain (-N).
|
|||
|
|
|||
|
2. Delete an empty chain (-X).
|
|||
|
|
|||
|
3. Change the policy for a built-in chain. (-P).
|
|||
|
|
|||
|
4. List the rules in a chain (-L).
|
|||
|
|
|||
|
5. Flush the rules out of a chain (-F).
|
|||
|
|
|||
|
6. Zero the packet and byte counters on all rules in a chain (-Z).
|
|||
|
|
|||
|
There are several ways to manipulate rules inside a chain:
|
|||
|
|
|||
|
|
|||
|
1. Append a new rule to a chain (-A).
|
|||
|
|
|||
|
2. Insert a new rule at some position in a chain (-I).
|
|||
|
|
|||
|
3. Replace a rule at some position in a chain (-R).
|
|||
|
|
|||
|
4. Delete a rule at some position in a chain (-D).
|
|||
|
|
|||
|
5. Delete the first rule that matches in a chain (-D).
|
|||
|
|
|||
|
There are a few operations for masquerading, which are in ipchains for
|
|||
|
want of a good place to put them:
|
|||
|
|
|||
|
|
|||
|
1. List the currently masqueraded connections (-M -L).
|
|||
|
|
|||
|
2. Set masquerading timeout values (-M -S).
|
|||
|
|
|||
|
There are some timing issues involved in altering firewall rules. If
|
|||
|
you are not careful, you can let packets through while you are half-
|
|||
|
way through your changes. A simplistic approach is to do the
|
|||
|
following:
|
|||
|
|
|||
|
|
|||
|
# ipchains -I input 1 -j DENY
|
|||
|
# ipchains -I output 1 -j DENY
|
|||
|
# ipchains -I forward 1 -j DENY
|
|||
|
|
|||
|
|
|||
|
|
|||
|
... make changes ...
|
|||
|
|
|||
|
|
|||
|
# ipchains -D input 1
|
|||
|
# ipchains -D output 1
|
|||
|
# ipchains -D forward 1
|
|||
|
#
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This drops all packets for the duration of the changes.
|
|||
|
|
|||
|
Here a duplicate of the above firewall rules in IPChains.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
#!/bin/sh
|
|||
|
#
|
|||
|
# rc.firewall
|
|||
|
#
|
|||
|
## Flush everything, start from scratch
|
|||
|
/sbin/ipchains -F input
|
|||
|
/sbin/ipchains -F output
|
|||
|
/sbin/ipchains -F forward
|
|||
|
|
|||
|
## Redirect for HTTP Transparent Proxy
|
|||
|
#$IPCHAINS -A input -p tcp -s 192.1.2.0/24 -d 0.0.0.0/0 80 -j REDIRECT 8080
|
|||
|
|
|||
|
## Create your own chain
|
|||
|
/sbin/ipchains -N my-chain
|
|||
|
# Allow email to got to the server
|
|||
|
/sbin/ipchains -A my-chain -s 0.0.0.0/0 smtp -d 192.1.2.10 1024:-j ACCEPT
|
|||
|
# Allow email connections to outside email servers
|
|||
|
/sbin/ipchains -A my-chain -s 192.1.2.10 -d 0.0.0.0/0 smtp -j ACCEPT
|
|||
|
# Allow Web connections to your Web Server
|
|||
|
/sbin/ipchains -A my-chain -s 0.0.0.0/0 www -d 192.1.2.11 1024: -j ACCEPT
|
|||
|
# Allow Web connections to outside Web Server
|
|||
|
/sbin/ipchains -A my-chain -s 192.1.2.0/24 1024: -d 0.0.0.0/0 www -j ACCEPT
|
|||
|
# Allow DNS traffic
|
|||
|
/sbin/ipchains -A my-chain -p UDP -s 0.0.0.0/0 dns -d 192.1.2.0/24 -j ACCEPT
|
|||
|
|
|||
|
## If you are using masquerading
|
|||
|
# don't masq internal-internal traffic
|
|||
|
/sbin/ipchains -A forward -s 192.1.2.0/24 -d 192.1.2.0/24 -j ACCEPT
|
|||
|
# don't masq external interface direct
|
|||
|
/sbin/ipchains -A forward -s 24.94.1.0/24 -d 0.0.0.0/0 -j ACCEPT
|
|||
|
# masquerade all internal IP's going outside
|
|||
|
/sbin/ipchains -A forward -s 192.1.2.0/24 -d 0.0.0.0/0 -j MASQ
|
|||
|
|
|||
|
## Deny everything else
|
|||
|
/sbin/ipchains -P my-chain input DENY
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Don't stop here. This is not a great firewall and I'm sure you have
|
|||
|
other services you will be providing. Again, read the IPCHAINS-HOWTO.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
9. Installing a Transparent SQUID proxy
|
|||
|
|
|||
|
The squid proxy is available at http://squid.nlanr.net/
|
|||
|
<http://squid.nlanr.net/>.
|
|||
|
|
|||
|
The SQUID developers provide RedHat and Debian packages. If you can,
|
|||
|
use one of these.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
10. Installing the TIS Proxy server
|
|||
|
|
|||
|
|
|||
|
|
|||
|
10.1. Getting the software
|
|||
|
|
|||
|
The TIS FWTK is available at http://www.tis.com/research/software/
|
|||
|
<http://www.tis.com/research/software/ >.
|
|||
|
|
|||
|
Don't make the mistake I did. When you ftp files from TIS, READ THE
|
|||
|
README's. The TIS fwtk is locked up in a hidden directory on their
|
|||
|
server.
|
|||
|
TIS requires you read their agreement at
|
|||
|
http://www.tis.com/research/software/fwtk_readme.html
|
|||
|
<http://www.tis.com/research/software/fwtk_readme.html > and then send
|
|||
|
email to fwtk-request@tislabs.com <mailto:fwtk-request@tislabs.com>
|
|||
|
with only the word accepted in the body of the message to learn the
|
|||
|
name of this hidden directory. No subject is needed in the message.
|
|||
|
Their system will then mails you back the directory name (good for 12
|
|||
|
hours) to download the source.
|
|||
|
|
|||
|
As of this writing, the current version of FWTK is 2.1.
|
|||
|
|
|||
|
|
|||
|
10.2. Compiling the TIS FWTK
|
|||
|
|
|||
|
|
|||
|
Version 2.1 of the FWTK compiles much easier then any of the older
|
|||
|
versions.
|
|||
|
|
|||
|
EXPLAIN HERE!!!
|
|||
|
|
|||
|
Now run make.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
10.3. Installing the TIS FWTK
|
|||
|
|
|||
|
Run make install.
|
|||
|
|
|||
|
The default installation directory is /usr/local/etc. You could change
|
|||
|
this (I didn't) to a more secure directory. I chose to change the
|
|||
|
access to this directory to 'chmod 700'.
|
|||
|
|
|||
|
All last is left now is to configure the firewall.
|
|||
|
|
|||
|
|
|||
|
10.4. Configuring the TIS FWTK
|
|||
|
|
|||
|
|
|||
|
Now the fun really begins. We must teach the system to call theses new
|
|||
|
services and create the tables to control them.
|
|||
|
|
|||
|
I'm not going to try to re-write the TIS FWTK manual here. I will show
|
|||
|
you the setting I found worked and explain the problems I ran into and
|
|||
|
how I got around them.
|
|||
|
|
|||
|
There are three files that make up these controls.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> /etc/services
|
|||
|
|
|||
|
<20> Tells the system what ports a services is on.
|
|||
|
|
|||
|
|
|||
|
<20> /etc/inetd.conf
|
|||
|
|
|||
|
<20> Tells inetd what program to call when someone knocks on a service
|
|||
|
port.
|
|||
|
|
|||
|
|
|||
|
<20> /usr/local/etc/netperm-table
|
|||
|
|
|||
|
<20> Tells the FWTK services who to allow and deny service to.
|
|||
|
|
|||
|
To get the FWTK functioning, you should edit these files from the
|
|||
|
bottom up. Editing the services file without the inetd.conf or
|
|||
|
netperm-table file set correctly could make your system inaccessible.
|
|||
|
|
|||
|
|
|||
|
10.4.1. The netperm-table file
|
|||
|
|
|||
|
|
|||
|
This file controls who can access the services of the TIS FWTK. You
|
|||
|
should think about the traffic using the firewall from both sides.
|
|||
|
People outside your network should identify themselves before gaining
|
|||
|
access, but the people inside your network might be allowed to just
|
|||
|
pass through.
|
|||
|
|
|||
|
So people can identify themselves, the firewall uses a program called
|
|||
|
authsrv to keep a database of user IDs and passwords. The
|
|||
|
authentication section of the netperm-table controls where the
|
|||
|
database is keep and who can access it.
|
|||
|
|
|||
|
I had some trouble closing the access to this service. Note the
|
|||
|
premit-hosts line I show uses a '*' to give everyone access. The
|
|||
|
correct setting for this line is '' authsrv: premit-hosts localhost if
|
|||
|
you can get it working.
|
|||
|
|
|||
|
|
|||
|
#
|
|||
|
# Proxy configuration table
|
|||
|
#
|
|||
|
# Authentication server and client rules
|
|||
|
authsrv: database /usr/local/etc/fw-authdb
|
|||
|
authsrv: permit-hosts *
|
|||
|
authsrv: badsleep 1200
|
|||
|
authsrv: nobogus true
|
|||
|
# Client Applications using the Authentication server
|
|||
|
*: authserver 127.0.0.1 114
|
|||
|
|
|||
|
|
|||
|
|
|||
|
To initialize the database, su to root, and run ./authsrv in the
|
|||
|
/var/local/etc directory to create the administrative user record.
|
|||
|
Here is a sample session.
|
|||
|
|
|||
|
Read the FWTK documentation to learn how to add users and groups.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
#
|
|||
|
# authsrv
|
|||
|
authsrv# list
|
|||
|
authsrv# adduser admin "Auth DB admin"
|
|||
|
ok - user added initially disabled
|
|||
|
authsrv# ena admin
|
|||
|
enabled
|
|||
|
authsrv# proto admin pass
|
|||
|
changed
|
|||
|
authsrv# pass admin "plugh"
|
|||
|
Password changed.
|
|||
|
authsrv# superwiz admin
|
|||
|
set wizard
|
|||
|
authsrv# list
|
|||
|
Report for users in database
|
|||
|
user group longname ok? proto last
|
|||
|
------ ------ ------------------ ----- ------ -----
|
|||
|
admin Auth DB admin ena passw never
|
|||
|
authsrv# display admin
|
|||
|
Report for user admin (Auth DB admin)
|
|||
|
Authentication protocol: password
|
|||
|
Flags: WIZARD
|
|||
|
authsrv# ^D
|
|||
|
EOT
|
|||
|
#
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The telnet gateway (tn-gw) controls are straight forward and the first
|
|||
|
you should set up.
|
|||
|
|
|||
|
In my example, I permit host from inside the private network to pass
|
|||
|
through without authenticating themselves. (permit-hosts 19961.2.*
|
|||
|
-passok) But, any other user must enter their user ID and password to
|
|||
|
use the proxy. (permit-hosts * -auth)
|
|||
|
|
|||
|
I also allow one other system (192.1.2.202) to access the firewall
|
|||
|
directly without going through the firewall at all. The two inetacl-
|
|||
|
in.telnetd lines do this. I will explain how these lines are called
|
|||
|
latter.
|
|||
|
|
|||
|
The Telnet timeout should be keep short.
|
|||
|
|
|||
|
|
|||
|
# telnet gateway rules:
|
|||
|
tn-gw: denial-msg /usr/local/etc/tn-deny.txt
|
|||
|
tn-gw: welcome-msg /usr/local/etc/tn-welcome.txt
|
|||
|
tn-gw: help-msg /usr/local/etc/tn-help.txt
|
|||
|
tn-gw: timeout 90
|
|||
|
tn-gw: permit-hosts 192.1.2.* -passok -xok
|
|||
|
tn-gw: permit-hosts * -auth
|
|||
|
# Only the Administrator can telnet directly to the Firewall via Port 24
|
|||
|
netacl-in.telnetd: permit-hosts 192.1.2.202 -exec /usr/sbin/in.telnetd
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The r-commands work the same way as telnet.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
# rlogin gateway rules:
|
|||
|
rlogin-gw: denial-msg /usr/local/etc/rlogin-deny.txt
|
|||
|
rlogin-gw: welcome-msg /usr/local/etc/rlogin-welcome.txt
|
|||
|
rlogin-gw: help-msg /usr/local/etc/rlogin-help.txt
|
|||
|
rlogin-gw: timeout 90
|
|||
|
rlogin-gw: permit-hosts 192.1.2.* -passok -xok
|
|||
|
rlogin-gw: permit-hosts * -auth -xok
|
|||
|
# Only the Administrator can telnet directly to the Firewall via Port
|
|||
|
netacl-rlogind: permit-hosts 192.1.2.202 -exec /usr/libexec/rlogind -a
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You shouldn't have anyone accessing your firewall directly and that
|
|||
|
includes FTP so don't put an FTP, server on you firewall.
|
|||
|
|
|||
|
Again, the permit-hosts line allows anyone in the protected network
|
|||
|
free access to the Internet and all others must authenticate
|
|||
|
themselves. I included logging of every file sent and received to my
|
|||
|
controls. (-log { retr stor })
|
|||
|
|
|||
|
The ftp timeout controls how long it will take to drop a bad
|
|||
|
connections as well as how long a connection will stay open with out
|
|||
|
activity.
|
|||
|
|
|||
|
|
|||
|
# ftp gateway rules:
|
|||
|
ftp-gw: denial-msg /usr/local/etc/ftp-deny.txt
|
|||
|
ftp-gw: welcome-msg /usr/local/etc/ftp-welcome.txt
|
|||
|
ftp-gw: help-msg /usr/local/etc/ftp-help.txt
|
|||
|
ftp-gw: timeout 300
|
|||
|
ftp-gw: permit-hosts 192.1.2.* -log { retr stor }
|
|||
|
ftp-gw: permit-hosts * -authall -log { retr stor }
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Web, gopher and browser based ftp are contorted by the http-gw. The
|
|||
|
first two lines create a directory to store ftp and web documents as
|
|||
|
they are passing through the firewall. I make these files owned by
|
|||
|
root and put the in a directory accessible only by root.
|
|||
|
|
|||
|
The Web connection should be kept short. It controls how long the user
|
|||
|
will wait on a bad connections.
|
|||
|
|
|||
|
|
|||
|
# www and gopher gateway rules:
|
|||
|
http-gw: userid root
|
|||
|
http-gw: directory /jail
|
|||
|
http-gw: timeout 90
|
|||
|
http-gw: default-httpd www.afs.net
|
|||
|
http-gw: hosts 192.1.2.* -log { read write ftp }
|
|||
|
http-gw: deny-hosts *
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The ssl-gw is really just a pass anything gateway. Be carefully with
|
|||
|
it. In this example I allow anyone inside the protected network to
|
|||
|
connect to any server outside the network except the addresses
|
|||
|
127.0.0.* and 192.1.1.* and then only on ports 443 through 563. Ports
|
|||
|
443 through 563 are known SSL ports.
|
|||
|
|
|||
|
|
|||
|
# ssl gateway rules:
|
|||
|
ssl-gw: timeout 300
|
|||
|
ssl-gw: hosts 192.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 }
|
|||
|
ssl-gw: deny-hosts *
|
|||
|
|
|||
|
Here is an example of how to use the plug-gw to allow connections to a
|
|||
|
news server. In this example I allow anyone inside the protected
|
|||
|
network to connect to only one system and only to it's news port.
|
|||
|
|
|||
|
The seconded line allows the news server to pass its data back to the
|
|||
|
protected network.
|
|||
|
|
|||
|
Because most clients expect to stay connected while the user read
|
|||
|
news, the timeout for a news server should be long.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
# NetNews Pluged gateway
|
|||
|
plug-gw: timeout 3600
|
|||
|
plug-gw: port nntp 192.1.2.* -plug-to 24.94.1.22 -port nntp
|
|||
|
plug-gw: port nntp 24.94.1.22 -plug-to 192.1.2.* -port nntp
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The finger gateway is simple. Anyone inside the protected network must
|
|||
|
login first and then we allow them to use the finger program on the
|
|||
|
firewall. Anyone else just gets a message.
|
|||
|
|
|||
|
|
|||
|
# Enable finger service
|
|||
|
netacl-fingerd: permit-hosts 192.1.2.* -exec /usr/libexec/fingerd
|
|||
|
netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I haven't setup the Mail and X-windows services so I'm not including
|
|||
|
examples. If anyone has a working example, please send me email.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
10.4.2. The /etc/services file
|
|||
|
|
|||
|
|
|||
|
This is where it all begins. When a client connects to the firewall it
|
|||
|
connects on a known port (less then 1024). For example telnet
|
|||
|
connects on port 23. The inetd deamon hears this connection and looks
|
|||
|
up the name of these service in the /etc/services file. It then calls
|
|||
|
the program assigned to the name in the /etc/inetd.conf file.
|
|||
|
|
|||
|
Some of the services we are creating are not normally in the
|
|||
|
/etc/services file. You can assign some of them to any port you want.
|
|||
|
For example, I have assigned the administrator's telnet port (telnet-
|
|||
|
a) to port 24. You could assign it to port 2323 if you wished. For the
|
|||
|
administrator (YOU) to connect directly to the firewall you will need
|
|||
|
to telnet to port 24 not 23 and if you setup your netperm-table file,
|
|||
|
like I did, you will only be able to this from one system inside your
|
|||
|
protected network.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
telnet-a 24/tcp
|
|||
|
ftp-gw 21/tcp # this named changed
|
|||
|
auth 113/tcp ident # User Verification
|
|||
|
ssl-gw 443/tcp
|
|||
|
|
|||
|
|
|||
|
|
|||
|
11. The SOCKS Proxy Server
|
|||
|
|
|||
|
|
|||
|
11.1. Setting up the Proxy Server
|
|||
|
|
|||
|
The SOCKS proxy server available from http://www.socks.nec.com/.
|
|||
|
|
|||
|
Uncompressed and untar the files into a directory on your system, and
|
|||
|
follow the instructions on how to make it. I had a couple problems
|
|||
|
when I made it. Make sure that your Makefiles are correct.
|
|||
|
|
|||
|
One important thing to note is that the proxy server needs to be added
|
|||
|
to /etc/inetd.conf. You must add a line:
|
|||
|
|
|||
|
|
|||
|
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
|
|||
|
|
|||
|
|
|||
|
|
|||
|
to tell the server to run when requested.
|
|||
|
|
|||
|
|
|||
|
11.2. Configuring the Proxy Server
|
|||
|
|
|||
|
|
|||
|
The SOCKS program needs two separate configuration files. One to tell
|
|||
|
the access allowed, and one to route the requests to the appropriate
|
|||
|
proxy server. The access file should be housed on the server. The
|
|||
|
routing file should be housed on every UNIX machine. The DOS and,
|
|||
|
presumably, Macintosh computers will do their own routing.
|
|||
|
|
|||
|
|
|||
|
11.2.1. The Access File
|
|||
|
|
|||
|
With socks4.2 Beta, the access file is called "sockd.conf".It should
|
|||
|
contain 2 lines, a permit and a deny line. Each line will have three
|
|||
|
entries:
|
|||
|
|
|||
|
|
|||
|
<20> The Identifier (permit/deny)
|
|||
|
|
|||
|
<20> The IP address
|
|||
|
|
|||
|
<20> The address modifier
|
|||
|
|
|||
|
The identifier is either permit or deny. You should have both a
|
|||
|
permit and a deny line.
|
|||
|
|
|||
|
The IP address holds a four byte address in typical IP dot notation.
|
|||
|
I.E. 192.168.1.0.
|
|||
|
|
|||
|
The address modifier is also a typical IP address four byte number. It
|
|||
|
works like a netmask. Envision this number to be 32 bits (1s or 0s).
|
|||
|
If the bit is a 1, the corresponding bit of the address that it is
|
|||
|
checking must match the corresponding bit in the IP address field. For
|
|||
|
instance, if the line is:
|
|||
|
|
|||
|
|
|||
|
permit 192.168.1.23 255.255.255.255
|
|||
|
|
|||
|
|
|||
|
|
|||
|
it will permit only the IP address that matches every bit in
|
|||
|
192.168.1.23, eg, only 192.168.1.3. The line:
|
|||
|
|
|||
|
|
|||
|
permit 192.168.1.0 255.255.255.0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
will permit every number within group 192.168.1.0 through
|
|||
|
192.168.1.255, the whole C Class domain. One should not have the
|
|||
|
line:
|
|||
|
|
|||
|
|
|||
|
permit 192.168.1.0 0.0.0.0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
as this will permit every address, regardless.
|
|||
|
|
|||
|
So, first permit every address you want to permit, and then deny the
|
|||
|
rest. To allow everyone in the domain 192.168.1.xxx, the lines:
|
|||
|
|
|||
|
|
|||
|
permit 192.168.1.0 255.255.255.0
|
|||
|
deny 0.0.0.0 0.0.0.0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
will work nicely. Notice the first "0.0.0.0" in the deny line. With
|
|||
|
a modifier of 0.0.0.0, the IP address field does not matter. All 0's
|
|||
|
is the norm because it is easy to type.
|
|||
|
|
|||
|
More than one entry of each is allowed.
|
|||
|
|
|||
|
Specific users can also be granted or denied access. This is done via
|
|||
|
ident authentication. Not all systems support ident, including
|
|||
|
Trumpet Winsock, so I will not go into it here. The documentation
|
|||
|
with socks is quite adequate on this subject.
|
|||
|
|
|||
|
|
|||
|
11.2.2. The Routing File
|
|||
|
|
|||
|
|
|||
|
The routing file in SOCKS is poorly named "socks.conf". I say "poorly
|
|||
|
named" because it is so close to the name of the access file that it
|
|||
|
is easy to get the two confused.
|
|||
|
|
|||
|
The routing file is there to tell the SOCKS clients when to use socks
|
|||
|
and when not to. For instance, in our network, 192.168.1.3 will not
|
|||
|
need to use socks to talk with 192.168.1.1, firewall. It has a direct
|
|||
|
connection in via Ethernet. It defines 127.0.0.1, the loopback,
|
|||
|
automatically. Of course you do not need SOCKS to talk to yourself.
|
|||
|
There are three entries:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> deny
|
|||
|
|
|||
|
<20> direct
|
|||
|
|
|||
|
<20> sockd
|
|||
|
|
|||
|
Deny tells SOCKS when to reject a request. This entry has the same
|
|||
|
three fields as in sockd.conf, identifier, address and modifier.
|
|||
|
Generally, since this is also handled by sockd.conf, the access file,
|
|||
|
the modifier field is set to 0.0.0.0. If you want to preclude
|
|||
|
yourself from calling any place, you can do it here.
|
|||
|
|
|||
|
The direct entry tells which addresses to not use socks for. These
|
|||
|
are all the addresses that can be reached without the proxy server.
|
|||
|
Again we have the three fields, identifier, address and modifier. Our
|
|||
|
example would have
|
|||
|
|
|||
|
|
|||
|
direct 192.168.1.0 255.255.255.0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Thus going direct for any on our protected network.
|
|||
|
|
|||
|
The sockd entry tells the computer which host has the socks server
|
|||
|
daemon on it. The syntax is:
|
|||
|
|
|||
|
|
|||
|
sockd @=<serverlist> <IP address> <modifier>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Notice the @= entry. This allows you to set the IP addresses of a
|
|||
|
list of proxy servers. In our example, we only use one proxy server.
|
|||
|
But, you can have many to allow a greater load and for redundancy in
|
|||
|
case of failure.
|
|||
|
|
|||
|
The IP address and modifier fields work just like in the other
|
|||
|
examples. You specify which addresses go where through these. 6.2.3.
|
|||
|
DNS from behind a Firewall
|
|||
|
|
|||
|
Setting up Domain Name service from behind a firewall is a relatively
|
|||
|
simple task. You need merely to set up the DNS on the firewalling
|
|||
|
machine. Then, set each machine behind the firewall to use this DNS.
|
|||
|
|
|||
|
|
|||
|
11.3. Working With a Proxy Server
|
|||
|
|
|||
|
|
|||
|
11.3.1. Unix
|
|||
|
|
|||
|
|
|||
|
To have your applications work with the proxy server, they need to be
|
|||
|
"sockified". You will need two different telnets, one for direct
|
|||
|
communication, one for communication via the proxy server. SOCKS
|
|||
|
comes with instructions on how to SOCKify a program, as well as a
|
|||
|
couple pre-SOCKified programs. If you use the SOCKified version to go
|
|||
|
somewhere direct, SOCKS will automatically switch over to the direct
|
|||
|
version for you. Because of this, we want to rename all the programs
|
|||
|
on our protected network and replace them with the SOCKified programs.
|
|||
|
"Finger" becomes "finger.orig", "telnet" becomes "telnet.orig", etc.
|
|||
|
You must tell SOCKS about each of these via the include/socks.h file.
|
|||
|
|
|||
|
Certain programs will handle routing and sockifying itself. Netscape
|
|||
|
is one of these. You can use a proxy server under Netscape by
|
|||
|
entering the server's address (192.168.1.1 in our case) in the SOCKs
|
|||
|
field under Proxies. Each application will need at least a little
|
|||
|
messing with, regardless of how it handles a proxy server.
|
|||
|
|
|||
|
|
|||
|
11.3.2. MS Windows with Trumpet Winsock
|
|||
|
|
|||
|
|
|||
|
Trumpet Winsock comes with built in proxy server capabilities. In the
|
|||
|
"setup" menu, enter the IP address of the server, and the addresses of
|
|||
|
all the computers reachable directly. Trumpet will then handle all
|
|||
|
outgoing packets.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
11.3.3. Getting the Proxy Server to work with UDP Packets
|
|||
|
|
|||
|
|
|||
|
The SOCKS package works only with TCP packets, not UDP. This makes it
|
|||
|
quite a bit less useful. Many useful programs, such as talk and
|
|||
|
Archie, use UDP. There is a package designed to be used as a proxy
|
|||
|
server for UDP packets called UDPrelay, by Tom Fitzgerald
|
|||
|
<fitz@wang.com>. Unfortunately, at the time of this writing, it is
|
|||
|
not compatible with Linux.
|
|||
|
|
|||
|
|
|||
|
11.4. Drawbacks with Proxy Servers
|
|||
|
|
|||
|
|
|||
|
The proxy server is, above all, a security device. Using it to
|
|||
|
increase internet access with limited IP addresses will have many
|
|||
|
drawbacks. A proxy server will allow greater access from inside the
|
|||
|
protected network to the outside, but will keep the inside completely
|
|||
|
inaccessible from the outside. This means no servers, talk or archive
|
|||
|
connections, or direct mailing to the inside computers. These
|
|||
|
drawbacks might seem slight, but think of it this way:
|
|||
|
|
|||
|
|
|||
|
<20> You have left a report you are doing on your computer inside a
|
|||
|
firewall protected network. You are at home, and decide that you
|
|||
|
would like to go over it. You can not. You can not reach your
|
|||
|
computer because it is behind the firewall. You try to log into
|
|||
|
firewall first, but since everyone has proxy server access, no one
|
|||
|
has set up an account for you on it.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> Your daughter goes to college. You want to email her. You have
|
|||
|
some private things to talk about, and would rather have your mail
|
|||
|
sent directly to your machine. You trust your systems
|
|||
|
administrator completely, but still, this is private mail.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> The inability to use UDP packets represents a big drawback with the
|
|||
|
proxy servers. I imagine UDP capabilities will be coming shortly.
|
|||
|
|
|||
|
FTP causes another problem with a proxy server. When getting or doing
|
|||
|
an ls, the FTP server opens a socket on the client machine and sends
|
|||
|
the information through it. A proxy server will not allow this, so
|
|||
|
FTP doesn't particularly work.
|
|||
|
|
|||
|
And, proxy servers run slow. Because of the greater overhead, almost
|
|||
|
any other means of getting this access will be faster.
|
|||
|
|
|||
|
Basically, if you have the IP addresses, and you are not worried about
|
|||
|
security, do not use a firewall and/or proxy servers. If you do not
|
|||
|
have the IP addresses, but you are also not worried about security,
|
|||
|
you might also want to look into using an IP emulator, like Term,
|
|||
|
Slirp or TIA. Term is available from ftp://sunsite.unc.edu, Slirp is
|
|||
|
available from ftp://blitzen.canberra.edu.au/pub/slirp, and TIA is
|
|||
|
available from marketplace.com. These packages will run faster, allow
|
|||
|
better connections, and provide a greater level of access to the
|
|||
|
inside network from the internet. Proxy servers are good for those
|
|||
|
networks which have a lot of hosts that will want to connect to the
|
|||
|
internet on the fly, with one setup and little work after that.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
12. Advanced Configurations
|
|||
|
|
|||
|
There is one configuration I would like to go over before wrapping
|
|||
|
this document up. The one I have just outlined will probably suffice
|
|||
|
for most people. However, I think the next outline will show a more
|
|||
|
advanced configuration that can clear up some questions. If you have
|
|||
|
questions beyond what I have just covered, or are just interested in
|
|||
|
the versatility of proxy servers and firewalls, read on.
|
|||
|
|
|||
|
|
|||
|
12.1. A large network with emphasis on security
|
|||
|
|
|||
|
Say, for instance, you are the leader of millisha and you wish to
|
|||
|
network your site. You have 50 computers and a subnet of 32 (5 bits)
|
|||
|
IP numbers. You need various levels of access within your network
|
|||
|
because you tell your followers different things. Therefore, you'll
|
|||
|
need to protect certain parts of the network from the rest.
|
|||
|
|
|||
|
The levels are:
|
|||
|
|
|||
|
|
|||
|
1. The external level. This is the level that gets shown to
|
|||
|
everybody. This is where you rant and rave to get new volunteers.
|
|||
|
|
|||
|
2. Troop This is the level of people who have gotten beyond the
|
|||
|
external level. Here is where you teach them about the evail
|
|||
|
government and how to make bombs.
|
|||
|
|
|||
|
3. Mercenary Here is where the real plans are keep. In this level is
|
|||
|
stored all the information on how the 3rd world government is going
|
|||
|
to take over the world, your plans involving Newt Gingrich,
|
|||
|
Oklahoma City, lown care products and what really is stored in that
|
|||
|
hangers at area 51.
|
|||
|
|
|||
|
|
|||
|
12.1.1. The Network Setup
|
|||
|
|
|||
|
The IP numbers are arranged as:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> 1 number is 192.168.1.255, which is the broadcast address and is
|
|||
|
not usable.
|
|||
|
|
|||
|
<20> 23 of the 32 IP addresses are allocated to 23 machines that will be
|
|||
|
accessible to the internet.
|
|||
|
|
|||
|
<20> 1 extra IP goes to a Linux box on that network
|
|||
|
|
|||
|
<20> 1 extra goes to a different Linux box on that network.
|
|||
|
|
|||
|
<20> 2 IP #'s go to the router
|
|||
|
|
|||
|
<20> 4 are left over, but given domain names paul, ringo, john, and
|
|||
|
george, just to confuse things a bit.
|
|||
|
|
|||
|
<20> The protected networks both have the addresses 192.168.1.xxx
|
|||
|
|
|||
|
Then, two separate networks are built, each in different rooms. They
|
|||
|
are routed via infrared Ethernet so that they are completely invisible
|
|||
|
to the outside room. Luckily, infrared ethernet works just like
|
|||
|
normal ethernet.
|
|||
|
|
|||
|
These networks are each connected to one of the Linux boxes with an
|
|||
|
extra IP address.
|
|||
|
|
|||
|
There is a file server connecting the two protected networks. This is
|
|||
|
because the plans for taking over the world involves some of the
|
|||
|
higher Troops. The file server holds the address 192.168.1.17 for the
|
|||
|
Troop network and 192.168.1.23 for the Mercenary network. It has to
|
|||
|
have different IP addresses because it has to have different Ethernet
|
|||
|
cards. IP Forwarding on it is turned off.
|
|||
|
|
|||
|
IP Forwarding on both Linux boxes is also turned off. The router will
|
|||
|
not forward packets destined for 192.168.1.xxx unless explicitly told
|
|||
|
to do so, so the internet will not be able to get in. The reason for
|
|||
|
turning off IP Forwarding here is so that packets from the Troop's
|
|||
|
network will not be able to reach the Mercenary network, and vica
|
|||
|
versa.
|
|||
|
|
|||
|
The NFS server can also be set to offer different files to the
|
|||
|
different networks. This can come in handy, and a little trickery
|
|||
|
with symbolic links can make it so that the common files can be shared
|
|||
|
with all. Using this setup and another ethernet card can offer this
|
|||
|
one file server for all three networks.
|
|||
|
|
|||
|
|
|||
|
12.1.2. The Proxy Setup
|
|||
|
|
|||
|
Now, since all three levels want to be able to monitor the network for
|
|||
|
their own devious purposes, all three need to have net access. The
|
|||
|
external network is connected directly into the internet, so we don't
|
|||
|
have to mess with proxy servers here. The Mercenary and Troop
|
|||
|
networks are behind firewalls, so it is necessary to set up proxy
|
|||
|
servers here.
|
|||
|
|
|||
|
Both networks will be setup very similarly. They both have the same
|
|||
|
IP addresses assigned to them. I will throw in a couple of
|
|||
|
parameters, just to make things more interesting though.
|
|||
|
|
|||
|
|
|||
|
1. No one can use the file server for internet access. This exposes
|
|||
|
the file server to viruses and other nasty things, and it is rather
|
|||
|
important, so its off limits.
|
|||
|
|
|||
|
2. We will not allow troop access to the World Wide Web. They are in
|
|||
|
training, and this kind of information retrieval power might prove
|
|||
|
to be damaging.
|
|||
|
|
|||
|
So, the sockd.conf file on the Troop's Linux box will have this line:
|
|||
|
|
|||
|
|
|||
|
deny 192.168.1.17 255.255.255.255
|
|||
|
|
|||
|
|
|||
|
|
|||
|
and on the Mercenary machine:
|
|||
|
|
|||
|
|
|||
|
deny 192.168.1.23 255.255.255.255
|
|||
|
|
|||
|
|
|||
|
|
|||
|
And, the Troop's Linux box will have this line
|
|||
|
|
|||
|
|
|||
|
deny 0.0.0.0 0.0.0.0 eq 80
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This says to deny access to all machines trying to access the port
|
|||
|
equal (eq) to 80, the http port. This will still allow all other
|
|||
|
services, just deny Web access.
|
|||
|
|
|||
|
Then, both files will have:
|
|||
|
|
|||
|
|
|||
|
permit 192.168.1.0 255.255.255.0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
to allow all the computers on the 192.168.1.xxx network to use this
|
|||
|
proxy server except for those that have already been denied (ie. The
|
|||
|
file server and Web access from the Troop network).
|
|||
|
|
|||
|
|
|||
|
The Troop's sockd.conf file will look like:
|
|||
|
|
|||
|
|
|||
|
deny 192.168.1.17 255.255.255.255
|
|||
|
deny 0.0.0.0 0.0.0.0 eq 80
|
|||
|
permit 192.168.1.0 255.255.255.0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
and the Mercenary file will look like:
|
|||
|
|
|||
|
|
|||
|
deny 192.168.1.23 255.255.255.255
|
|||
|
permit 192.168.1.0 255.255.255.0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This should configure everything correctly. Each network is isolated
|
|||
|
accordingly, with the proper amount of interaction. Everyone should
|
|||
|
be happy.
|
|||
|
|
|||
|
|
|||
|
13. Making Management Easy
|
|||
|
|
|||
|
|
|||
|
13.1. Firewall tools
|
|||
|
|
|||
|
There are several software packages that will make managing your
|
|||
|
firewall easier.
|
|||
|
|
|||
|
Be carefull, don't use these tools unless you can do without them.
|
|||
|
These scripts make it just as easy to make a misstake as they do to
|
|||
|
help you get it wright.
|
|||
|
|
|||
|
Both graphical and web based interfaces are being developed to work
|
|||
|
with the Linux filtering rules. Some companies have even create
|
|||
|
commercial firewalls based on Linux by putting it in their own box
|
|||
|
with their own management code. (nice)
|
|||
|
|
|||
|
I'm not realy a GUI guy. However, I have been using firewalls with
|
|||
|
GUI interfaces for some time. I've found they help by providing a nice
|
|||
|
report of all the rules in one easy glance.
|
|||
|
|
|||
|
gfcc (GTK+ Firewall Control Center) is a GTK+ application which can
|
|||
|
control Linux firewall policies and rules, based on ipchains package.
|
|||
|
Go to http://icarus.autostock.co.kr <http://icarus.autostock.co.kr/>
|
|||
|
and get your copy. This is a realy good tool.
|
|||
|
|
|||
|
I have included RC scripts in appendex A. These scripts work with and
|
|||
|
without gfcc.
|
|||
|
|
|||
|
|
|||
|
There a lots of scripts avaible to setup a firewall. One very complete
|
|||
|
script is avaible at
|
|||
|
http://www.jasmine.org.uk/~simon/bookshelf/papers/instant-
|
|||
|
firewall/instant-firewall.html
|
|||
|
<http://www.jasmine.org.uk/~simon/bookshelf/papers/instant-
|
|||
|
firewall/instant-firewall.html>. Another will done script is at
|
|||
|
http://www.pointman.org/ <http://www.pointman.org/>.
|
|||
|
|
|||
|
Kfirewall is a GUI frontend for ipchains or ipfwadm (depending on your
|
|||
|
kernel version). http://megaman.ypsilonia.net/kfirewall/
|
|||
|
<http://megaman.ypsilonia.net/kfirewall/>
|
|||
|
|
|||
|
FCT is an HTML based tool for the configuration of a firewall. It
|
|||
|
features automatic script-generation for IP-filtering commands
|
|||
|
(ipfwadm) on a firewall for multiple interfaces and any internet
|
|||
|
services. http://www.fen.baynet.de/~ft114/FCT/firewall.htm
|
|||
|
<http://www.fen.baynet.de/~ft114/FCT/firewall.htm>
|
|||
|
|
|||
|
|
|||
|
13.2. General tools
|
|||
|
|
|||
|
WebMin is a general system admin package. It will not help you manage
|
|||
|
the firewall rules but it will help you with turning on and off damons
|
|||
|
and processes. This program is VERY good, I'm hoping the J. Cameron
|
|||
|
will include a IPCHAINS module. http://www.webmin.com/
|
|||
|
<http://www.webmin.com/>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
14. Just to spoil your day, and keep you on your toes about security,
|
|||
|
I'll describe how easy it is to defeat a proxy firewall. Now that you
|
|||
|
have done everything in this document and have a very secure server
|
|||
|
and network. You have a DMZ and no one can get into your network and
|
|||
|
you are logging every connection made to the outside world. You make
|
|||
|
all your users go through a proxy and no one can go directly to the
|
|||
|
Internet. Then one of your users, with a didacated connection of his
|
|||
|
own, finds out abouthttptunnel <http://www.nocrew.org/software/http<74>
|
|||
|
tunnel.html>. httptunnel creates a bidirectional virtual data path
|
|||
|
tunnelled in HTTP requests. The HTTP requests can be sent via an HTTP
|
|||
|
proxy if so desired. Or, on their system they install a Virtual Pri<72>
|
|||
|
vate Network (vpn). See:http://sunsite.auc.dk/vpnd/ <http://sun<75>
|
|||
|
site.auc.dk/vpnd/> Or, Maybe this user simply puts a modem on their NT
|
|||
|
system and turns on routing. Finally, on the workstation, on the pri<72>
|
|||
|
vate LAN, change the default gateway to point to the new route to the
|
|||
|
Internet. Now, from this workstation, you can go anywhere. The only
|
|||
|
thing the firewall admin might see is one connect with nowill see is a
|
|||
|
really long DNS lookup. Now, take over the world! Defeating a Proxy
|
|||
|
Firewall
|
|||
|
|
|||
|
15. APPENDEX A - Example Scripts
|
|||
|
|
|||
|
|
|||
|
|
|||
|
15.1. RC Script useing GFCC
|
|||
|
|
|||
|
|
|||
|
|
|||
|
#!/bin/bash
|
|||
|
#
|
|||
|
# Firewall Script - Version 0.9.1
|
|||
|
#
|
|||
|
# chkconfig: 2345 09 99
|
|||
|
# description: firewall script for 2.2.x kernel
|
|||
|
# Set for testing
|
|||
|
# set -x
|
|||
|
#
|
|||
|
# NOTES:
|
|||
|
#
|
|||
|
# This script is written for RedHat 6.1 or better.
|
|||
|
#
|
|||
|
# Be careful about offering public services like web or ftp servers.
|
|||
|
#
|
|||
|
# INSTALLATION:
|
|||
|
# 1. place this file in /etc/rc.d/init.d (you'll have to be root..)
|
|||
|
# call it something like "firewall" :-)
|
|||
|
# make it root owned --> "chown root.root (filename)"
|
|||
|
# make it executable --> "chmod 755 (filename)"
|
|||
|
#
|
|||
|
# 2. use GFCC to create your firewall rules and export them to a file
|
|||
|
# named /etc/gfcc/rules/firewall.rule.sh.
|
|||
|
#
|
|||
|
# 3. add the firewall to the RH init structure --> "chkconfig --add (filename)"
|
|||
|
# next time the router boots, things should happen automagically!
|
|||
|
# sleep better at night knowing you are *LESS* vulnerable than before...
|
|||
|
#
|
|||
|
# RELEASE NOTES
|
|||
|
# 30 Jan, 2000 - Changed to GFCC script
|
|||
|
# 11 Dec, 1999 - updated by Mark Grennan <mark@grennan.com>
|
|||
|
# 20 July, 1999 - initial writing - Anthony Ball <tony@LinuxSIG.org>
|
|||
|
#
|
|||
|
|
|||
|
################################################
|
|||
|
|
|||
|
# Source function library.
|
|||
|
. /etc/rc.d/init.d/functions
|
|||
|
|
|||
|
# Source networking configuration.
|
|||
|
. /etc/sysconfig/network
|
|||
|
|
|||
|
# Check that networking is up.
|
|||
|
[ ${NETWORKING} = "no" ] && exit 0
|
|||
|
|
|||
|
# See how we are called
|
|||
|
case "$1" in
|
|||
|
|
|||
|
start)
|
|||
|
# Start providing access
|
|||
|
action "Starting firewall: " /bin/true
|
|||
|
/etc/gfcc/rules/firewall.rule.sh
|
|||
|
echo
|
|||
|
;;
|
|||
|
|
|||
|
stop)
|
|||
|
action "Stoping firewall: " /bin/true
|
|||
|
echo 0 > /proc/sys/net/ipv4/ip_forward
|
|||
|
/sbin/ipchains -F input
|
|||
|
/sbin/ipchains -F output
|
|||
|
/sbin/ipchains -F forward
|
|||
|
|
|||
|
echo
|
|||
|
;;
|
|||
|
|
|||
|
restart)
|
|||
|
action "Restarting firewall: " /bin/true
|
|||
|
$0 stop
|
|||
|
$0 start
|
|||
|
|
|||
|
echo
|
|||
|
;;
|
|||
|
|
|||
|
status)
|
|||
|
# List out all settings
|
|||
|
/sbin/ipchains -L
|
|||
|
;;
|
|||
|
|
|||
|
test)
|
|||
|
action "Test Mode firewall: " /bin/true
|
|||
|
/sbin/ipchains -F input
|
|||
|
/sbin/ipchains -F output
|
|||
|
/sbin/ipchains -F forward
|
|||
|
echo 1 > /proc/sys/net/ipv4/ip_forward
|
|||
|
/sbin/ipchains -A input -j ACCEPT
|
|||
|
/sbin/ipchains -A output -j ACCEPT
|
|||
|
/sbin/ipchains -P forward DENY
|
|||
|
/sbin/ipchains -A forward -i $PUBLIC -j MASQ
|
|||
|
|
|||
|
echo
|
|||
|
;;
|
|||
|
|
|||
|
*)
|
|||
|
echo "Usage: $0 {start|stop|restart|status|test}"
|
|||
|
exit 1
|
|||
|
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
15.2. GFCC script
|
|||
|
|
|||
|
This script was generated by the Graphical Firewall program (GFCC).
|
|||
|
This is not the working rule set. This is the exported rules set.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
#!/bin/sh
|
|||
|
# Generated by Gtk+ firewall control center
|
|||
|
|
|||
|
IPCHAINS=/sbin/ipchains
|
|||
|
|
|||
|
|
|||
|
localnet="192.168.1.0/24"
|
|||
|
firewallhost="192.168.1.1/32"
|
|||
|
localhost="172.0.0.0/8"
|
|||
|
DNS1="24.94.163.119/32"
|
|||
|
DNS2="24.94.163.124/32"
|
|||
|
Broadcast="255.255.255.255/32"
|
|||
|
Multicast="224.0.0.0/8"
|
|||
|
Any="0.0.0.0/0"
|
|||
|
mail_grennan_com="192.168.1.1/32"
|
|||
|
mark_grennan_com="192.168.1.3/32"
|
|||
|
|
|||
|
$IPCHAINS -P input DENY
|
|||
|
$IPCHAINS -P forward ACCEPT
|
|||
|
$IPCHAINS -P output ACCEPT
|
|||
|
|
|||
|
$IPCHAINS -F
|
|||
|
$IPCHAINS -X
|
|||
|
|
|||
|
# input rules
|
|||
|
$IPCHAINS -A input -s $Any -d $Broadcast -j DENY
|
|||
|
$IPCHAINS -A input -p udp -s $Any -d $Any netbios-ns -j DENY
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any netbios-ns -j DENY
|
|||
|
$IPCHAINS -A input -p udp -s $Any -d $Any netbios-dgm -j DENY
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any netbios-dgm -j DENY
|
|||
|
$IPCHAINS -A input -p udp -s $Any -d $Any bootps -j DENY
|
|||
|
$IPCHAINS -A input -p udp -s $Any -d $Any bootpc -j DENY
|
|||
|
$IPCHAINS -A input -s $Multicast -d $Any -j DENY
|
|||
|
$IPCHAINS -A input -s $localhost -d $Any -i lo -j ACCEPT
|
|||
|
$IPCHAINS -A input -s $localnet -d $Any -i eth1 -j ACCEPT
|
|||
|
$IPCHAINS -A input -s $localnet -d $Broadcast -i eth1 -j ACCEPT
|
|||
|
$IPCHAINS -A input -p icmp -s $Any -d $Any -j ACCEPT
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any -j ACCEPT ! -y
|
|||
|
$IPCHAINS -A input -p udp -s $DNS1 domain -d $Any 1023:65535 -j ACCEPT
|
|||
|
$IPCHAINS -A input -p udp -s $DNS2 domain -d $Any 1023:65535 -j ACCEPT
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any ssh -j ACCEPT
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any telnet -j ACCEPT
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any smtp -j ACCEPT
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any pop-3 -j ACCEPT
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any auth -j ACCEPT
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any www -j ACCEPT
|
|||
|
$IPCHAINS -A input -p tcp -s $Any -d $Any ftp -j ACCEPT
|
|||
|
$IPCHAINS -A input -s $Any -d $Any -j DENY -l
|
|||
|
|
|||
|
# forward rules
|
|||
|
$IPCHAINS -A forward -s $localnet -d $Any -j MASQ
|
|||
|
|
|||
|
# output rules
|
|||
|
|
|||
|
|
|||
|
|
|||
|
15.3. This is the firewall rules set built my hand. It does not use
|
|||
|
GFCC. RC Script without GFCC
|
|||
|
|
|||
|
|
|||
|
|
|||
|
#!/bin/bash
|
|||
|
#
|
|||
|
# Firewall Script - Version 0.9.0
|
|||
|
|
|||
|
# chkconfig: 2345 09 99
|
|||
|
# description: firewall script for 2.2.x kernel
|
|||
|
|
|||
|
# Set for testing
|
|||
|
# set -x
|
|||
|
|
|||
|
#
|
|||
|
# NOTES:
|
|||
|
#
|
|||
|
# This script is written for RedHat 6.0 or better.
|
|||
|
#
|
|||
|
# This firewall script should work for most routers, dial-up or cable modem.
|
|||
|
# It was written for RedHat distributions.
|
|||
|
#
|
|||
|
# Be careful about offering public services like web or ftp servers.
|
|||
|
#
|
|||
|
# INSTALLATION:
|
|||
|
# 1. This file planned for a RedHat system. It would work
|
|||
|
# on other distro's with perhaps no modification, but again...
|
|||
|
# Who knows?!!? These instructions apply to RedHat systems.
|
|||
|
#
|
|||
|
# 2. place this file in /etc/rc.d/init.d (you'll have to be root..)
|
|||
|
# call it something like "firewall" :-)
|
|||
|
# make it root owned --> "chown root.root <filename>"
|
|||
|
# make it executable --> "chmod 755 <filename>"
|
|||
|
#
|
|||
|
# 3. set the values for your network, internal interface, and DNS servers
|
|||
|
# uncomment lines further down to enable optional in-bound services
|
|||
|
# make sure "eth0" is your internal NIC (or change the value below)
|
|||
|
# test it --> "/etc/rc.d/init.d/<filename> start"
|
|||
|
# you can list the rules --> "ipchains -L -n"
|
|||
|
# fix anything that broke... :-)
|
|||
|
#
|
|||
|
# 4. add the firewall to the RH init structure --> "chkconfig --add <filename>"
|
|||
|
# next time the router boots, things should happen automagically!
|
|||
|
# sleep better at night knowing you are *LESS* vulnerable than before...
|
|||
|
#
|
|||
|
# RELEASE NOTES
|
|||
|
# 20 July, 1999 - initial writing - Anthony Ball <tony@LinuxSIG.org>
|
|||
|
# 11 Dec, 1999 - updated by Mark Grennan <mark@grennan.com>
|
|||
|
#
|
|||
|
|
|||
|
################################################
|
|||
|
# Fill in the values below to match your
|
|||
|
# local network.
|
|||
|
|
|||
|
PRIVATENET=xxx.xxx.xxx.xxx/xx
|
|||
|
|
|||
|
PUBLIC=ppp0
|
|||
|
PRIVATE=eth0
|
|||
|
|
|||
|
# your dns servers
|
|||
|
DNS1=xxx.xxx.xxx.xxx
|
|||
|
DNS2=xxx.xxx.xxx.xxx
|
|||
|
|
|||
|
################################################
|
|||
|
|
|||
|
# some handy generic values to use
|
|||
|
ANY=0.0.0.0/0
|
|||
|
ALLONES=255.255.255.255
|
|||
|
|
|||
|
# Source function library.
|
|||
|
. /etc/rc.d/init.d/functions
|
|||
|
|
|||
|
# Source networking configuration.
|
|||
|
. /etc/sysconfig/network
|
|||
|
|
|||
|
# Check that networking is up.
|
|||
|
[ ${NETWORKING} = "no" ] && exit 0
|
|||
|
|
|||
|
# See how we are called
|
|||
|
case "$1" in
|
|||
|
|
|||
|
start)
|
|||
|
# Start providing access
|
|||
|
action "Starting firewall: " /bin/true
|
|||
|
|
|||
|
##
|
|||
|
## Setup Envirement
|
|||
|
##
|
|||
|
# Flush all lists
|
|||
|
/sbin/ipchains -F input
|
|||
|
/sbin/ipchains -F output
|
|||
|
/sbin/ipchains -F forward
|
|||
|
|
|||
|
# Plug up everything
|
|||
|
/sbin/ipchains -I input 1 -j DENY
|
|||
|
|
|||
|
# set policy to deny (Default is ACCEPT)
|
|||
|
/sbin/ipchains -P input DENY
|
|||
|
/sbin/ipchains -P output ACCEPT
|
|||
|
/sbin/ipchains -P forward ACCEPT
|
|||
|
|
|||
|
# Turn on packet forwarding
|
|||
|
echo 1 > /proc/sys/net/ipv4/ip_forward
|
|||
|
|
|||
|
##
|
|||
|
## Install Modules
|
|||
|
##
|
|||
|
# Insert the active ftp module. This will allow non-passive ftp to machines
|
|||
|
# on the local network (but not to the router since it is not masq'd)
|
|||
|
if ! ( /sbin/lsmod | /bin/grep masq_ftp > /dev/null ); then
|
|||
|
/sbin/insmod ip_masq_ftp
|
|||
|
fi
|
|||
|
|
|||
|
##
|
|||
|
## Some Security Stuff
|
|||
|
##
|
|||
|
# turn on Source Address Verification and get spoof protection
|
|||
|
# on all current and future interfaces.
|
|||
|
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
|
|||
|
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
|
|||
|
echo 1 > $f
|
|||
|
done
|
|||
|
else
|
|||
|
echo
|
|||
|
echo "PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED."
|
|||
|
echo
|
|||
|
fi
|
|||
|
|
|||
|
# deny bcasts on remaining interfaces
|
|||
|
/sbin/ipchains -A input -d 0.0.0.0 -j DENY
|
|||
|
/sbin/ipchains -A input -d 255.255.255.255 -j DENY
|
|||
|
|
|||
|
# deny these without logging 'cause there tend to be a lot...
|
|||
|
/sbin/ipchains -A input -p udp -d $ANY 137 -j DENY # NetBIOS over IP
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY 137 -j DENY # ""
|
|||
|
/sbin/ipchains -A input -p udp -d $ANY 138 -j DENY # ""
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY 138 -j DENY # ""
|
|||
|
/sbin/ipchains -A input -p udp -d $ANY 67 -j DENY # bootp
|
|||
|
/sbin/ipchains -A input -p udp -d $ANY 68 -j DENY # ""
|
|||
|
/sbin/ipchains -A input -s 224.0.0.0/8 -j DENY # Multicast addresses
|
|||
|
|
|||
|
##
|
|||
|
## Allow private network out
|
|||
|
##
|
|||
|
# allow all packets on the loopback interface
|
|||
|
/sbin/ipchains -A input -i lo -j ACCEPT
|
|||
|
|
|||
|
# allow all packets from the internal "trusted" interface
|
|||
|
/sbin/ipchains -A input -i $PRIVATE -s $PRIVATENET -d $ANY -j ACCEPT
|
|||
|
/sbin/ipchains -A input -i $PRIVATE -d $ALLONES -j ACCEPT
|
|||
|
|
|||
|
##
|
|||
|
## Allow Outside Services into the firewall (if you dare)
|
|||
|
##
|
|||
|
# allow ICMP
|
|||
|
/sbin/ipchains -A input -p icmp -j ACCEPT
|
|||
|
# allow TCP
|
|||
|
/sbin/ipchains -A input -p tcp ! -y -j ACCEPT
|
|||
|
|
|||
|
# allow lookups to DNS (on firewall)
|
|||
|
/sbin/ipchains -A input -p udp -s $DNS1 domain -d $ANY 1023: -j ACCEPT
|
|||
|
/sbin/ipchains -A input -p udp -s $DNS2 domain -d $ANY 1023: -j ACCEPT
|
|||
|
# or (BETTER IDEA) run a caching DNS server on the router and use the
|
|||
|
# following two lines instead...
|
|||
|
# /sbin/ipchains -A input -p udp -s $DNS1 domain -d $ANY domain -j ACCEPT
|
|||
|
# /sbin/ipchains -A input -p udp -s $DNS2 domain -d $ANY domain -j ACCEPT
|
|||
|
|
|||
|
# uncomment the following to allow ssh in
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY 22 -j ACCEPT
|
|||
|
|
|||
|
# uncomment the following to allow telnet in (BAD IDEA!!)
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY telnet -j ACCEPT
|
|||
|
|
|||
|
# uncomment to allow NTP (network time protocol) to router
|
|||
|
# /sbin/ipchains -A input -p udp -d $ANY ntp -j ACCEPT
|
|||
|
|
|||
|
# uncomment to allow SMTP in (not for mail clients - only a server)
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY smtp -j ACCEPT
|
|||
|
|
|||
|
# uncomment to allow POP3 in (for mail clients)
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY 110 -j ACCEPT
|
|||
|
|
|||
|
# allow auth in for sending mail or doing ftp
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY auth -j ACCEPT
|
|||
|
|
|||
|
# uncomment to allow HTTP in (only if you run a web server on the router)
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY http -j ACCEPT
|
|||
|
|
|||
|
# uncomment to allow FTP in
|
|||
|
/sbin/ipchains -A input -p tcp -d $ANY ftp -j ACCEPT
|
|||
|
|
|||
|
##
|
|||
|
## Masquerading stuff
|
|||
|
##
|
|||
|
# masquerade packets forwarded from internal network
|
|||
|
/sbin/ipchains -A forward -s $PRIVATENET -d $ANY -j MASQ
|
|||
|
|
|||
|
##
|
|||
|
## deny EVERYthing else and log them to /var/log/messages
|
|||
|
##
|
|||
|
/sbin/ipchains -A input -l -j DENY
|
|||
|
|
|||
|
# Remove the Plug
|
|||
|
/sbin/ipchains -D input 1
|
|||
|
|
|||
|
;;
|
|||
|
|
|||
|
stop)
|
|||
|
action "Stoping firewall: " /bin/true
|
|||
|
echo 0 > /proc/sys/net/ipv4/ip_forward
|
|||
|
/sbin/ipchains -F input
|
|||
|
/sbin/ipchains -F output
|
|||
|
/sbin/ipchains -F forward
|
|||
|
|
|||
|
echo
|
|||
|
;;
|
|||
|
|
|||
|
restart)
|
|||
|
action "Restarting firewall: " /bin/true
|
|||
|
$0 stop
|
|||
|
$0 start
|
|||
|
|
|||
|
echo
|
|||
|
;;
|
|||
|
|
|||
|
status)
|
|||
|
# List out settings
|
|||
|
/sbin/ipchains -L
|
|||
|
;;
|
|||
|
|
|||
|
test)
|
|||
|
##
|
|||
|
## This is about as simple as it gets
|
|||
|
## (This is not secure AT ALL)
|
|||
|
action "WARNING Test Firewall: " /bin/true
|
|||
|
/sbin/ipchains -F input
|
|||
|
/sbin/ipchains -F output
|
|||
|
/sbin/ipchains -F forward
|
|||
|
echo 1 > /proc/sys/net/ipv4/ip_forward
|
|||
|
/sbin/ipchains -A input -j ACCEPT
|
|||
|
/sbin/ipchains -A output -j ACCEPT
|
|||
|
/sbin/ipchains -P forward DENY
|
|||
|
/sbin/ipchains -A forward -i $PUBLIC -j MASQ
|
|||
|
|
|||
|
echo
|
|||
|
;;
|
|||
|
|
|||
|
*)
|
|||
|
echo "Usage: $0 {start|stop|restart|status|test}"
|
|||
|
exit 1
|
|||
|
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
16. APPENDEX B - An VPN RC Script for RedHat
|
|||
|
|
|||
|
|
|||
|
|
|||
|
#!/bin/sh
|
|||
|
#
|
|||
|
# vpnd This shell script takes care of starting and stopping
|
|||
|
# vpnd (Vertual Privage Network connections).
|
|||
|
#
|
|||
|
# chkconfig: - 96 96
|
|||
|
# description: vpnd
|
|||
|
#
|
|||
|
|
|||
|
# Source function library.
|
|||
|
. /etc/rc.d/init.d/functions
|
|||
|
|
|||
|
# Source networking configuration.
|
|||
|
. /etc/sysconfig/network
|
|||
|
|
|||
|
# Check that networking is up.
|
|||
|
[ ${NETWORKING} = "no" ] && exit 0
|
|||
|
|
|||
|
[ -f /usr/sbin/vpnd ] || exit 0
|
|||
|
|
|||
|
[ -f /etc/vpnd.conf ] || exit 0
|
|||
|
|
|||
|
RETVAL=0
|
|||
|
|
|||
|
# See how we were called.
|
|||
|
case "$1" in
|
|||
|
start)
|
|||
|
# Start daemons.
|
|||
|
echo -n "Starting vpnd: "
|
|||
|
daemon vpnd
|
|||
|
RETVAL=$?
|
|||
|
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/vpnd
|
|||
|
echo
|
|||
|
;;
|
|||
|
stop)
|
|||
|
# Stop daemons.
|
|||
|
echo -n "Shutting down vpnd: "
|
|||
|
killproc vpnd
|
|||
|
RETVAL=$?
|
|||
|
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/vpnd
|
|||
|
echo
|
|||
|
;;
|
|||
|
restart)
|
|||
|
$0 stop
|
|||
|
$0 start
|
|||
|
;;
|
|||
|
*)
|
|||
|
echo "Usage: vpnd {start|stop|restart}"
|
|||
|
exit 1
|
|||
|
esac
|
|||
|
|
|||
|
exit $RETVAL
|
|||
|
|
|||
|
|
|||
|
|