Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
PHP Web Host - Quality Web Hosting For All PHP Applications

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Surveys

Features
HOWTOs
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 66 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  

HOWTO Home

Current HOWTO: Linux Bridge+Firewall Mini-HOWTO version 1.2.0


Linux Bridge+Firewall Mini-HOWTO version 1.2.0: FIREWALLING Next Previous Contents

4. FIREWALLING

4.1 Software and reading

You should read the Firewall-HOWTO.

That will tell you where to get ipfwadm if you don't already have it. There are other tools you can get but I made no progress until I tried ipfwadm. It is nice and low level! You can see exactly what it is doing.

4.2 Preliminary checks

You have compiled IP-forwarding and masquerading into the kernel so you will want to check that the firewall is in its default (accepting) state with

ipfwadm -I -l ipfwadm -O -l ipfwadm -F -l 

That is respectively, "display the rules affecting the .." incoming or outgoing or forwarding (masquerading) ".. sides of the firewall". The "-l" means "list".

You might have compiled in accounting too:

ipfwadm -A -l 

You should see that there are no rules defined and that the default is to accept every packet. You can get back to this working state anytime with

ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -f 

The "-f" means "flush". You may need to use that.

4.3 Default rule

I want to cut the world off from my internal net and do nothing else, so I will want to give as a last (default) rule that the firewall should ignore any packets coming in from the internal net and directed to outside. I put all the rules (in this order) into /etc/rc.d/rc.firewall and execute it from /etc/rc.d/rc.local at bootup.

ipfwadm -I -a reject -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0 

The "-S" is the source address/mask. The "-D" is the destination address/mask.

This format to is rather long-winded. Ipfwadm is intelligent about network names and some common abbreviations. Check the man pages.

It is possibly more convenient to put some or all of these rules on the outgoing half of the firewall by using "-O" instead of "-I", but I'll state the rules here all formulated for the incoming half.

4.4 Holes per address

Before that default rule, I have to place some rules that serve as exceptions to this general denial of external services to internal clients.

I want to treat the firewall machines address on the internal net specially. I will stop people logging in to the firewall machine unless they have special permission, but once they are there they should be allowed to talk to the world.

ipfwadm -I -i accept -S 192.168.2.100/255.255.255.255 \
 -D 0.0.0.0/0.0.0.0 

I also want the internal clients to be able to talk to the firewalling machine. Maybe they can persuade it to let them get out!

ipfwadm -I -i accept -S 192.168.2.0/255.255.255.128 \
 -D 192.168.2.100/255.255.255.255 

Check at this point that you can get in to the clients from outside the firewall via telnet, but that you cannot get out. That should mean that you can just about make first contact, but the clients cannot send you any prompts. You should be able to get all the way in if you use the firewall machine as a staging post. Try rlogin and ping too, with tcpdump running on one card or the other. You should be able to make sense of what you see.

4.5 Holes per protocol

I went on to relax the rules protocol by protocol. I want to allow pings from the outside to the inside to get an echo back, for instance, so I inserted the rule:

ipfwadm -I -i accept -P icmp -S 192.168.2.0/255.255.255.128 \
 -D 0.0.0.0/0.0.0.0 

The "-P icmp" works the protocol-specific magic.

Until I get hold of an ftp proxy I am also allowing ftp calls out with port-specific relaxations. This targets ports 20 21 and 115 on outside machines.

ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
 -D 0.0.0.0/0.0.0.0 20 21 115 

I could not make sendmail between the local clients work without a nameserver. Rather than set up a nameserver right then on the firewall, I just lifted the firewall for tcp domain service queries precisely aimed at the nearest existing nameserver and put its address in the clients /etc/resolv.conf ("nameserver 123.456.789.31" on a separate line).

ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
 -D 123.456.789.31/255.255.255.255 54 

You can find which port number and protocol a service requires with tcpdump. Trigger the service with a an ftp or a telnet or whatever to or from the internal machine and then watch for it on the input and output ports of the firewall with tcpdump:

tcpdump -i eth1 -e host client04 

for example. The /etc/services file is another important source of clues. To let telnet and ftp IN to the firewall from outside, you have to allow the local clients to call OUT on a specific port. I understand why this is necessary for ftp - it's the server that establishes the data stream in the end - but I am not sure why telnet also needs this.

ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 ftp telnet \
 -D 0.0.0.0/0.0.0.0 

There is a particular problem with some daemons that look up the hostname of the firewalling machine in order to decide what is their networking address. Rpc.yppasswdd is the one I had trouble with. It insists on broadcasting information that says it is outside the firewall (on the second card). That means the clients inside can't contact it.

Rather than start IP aliasing or change the daemon code, I mapped the name to the inside card address on the clients in their /etc/hosts.

4.6 Checks

You want to test that you can still telnet, rlogin and ping from the outside. From the inside you should be able to ping out. You should also be able to telnet to the firewall machine from the inside and the latter should be able to do anything.

That is it. At this point you probably want to learn about rpc/Yellow Pages and the interaction with the password file. The firewalled network wants to run without its unprivileged users being able to log on to the firewall - and thus get out. Some other HOWTO!


Next Previous Contents

The Linux Tutorial completely respects the rights of authors and artists to decide for themselves if and how their works can be used, independent of any existing licenses. This means if you are the author of any document presented on this site and do no wish it to be displayed as it is on this site or do not wish it to be displayed at all, please contact us and we will do our very best to accommodate you. If we are unable to accommodate you, we will, at your request, remove your document as quickly as possible.

If you are the author of any document presented on this site and would like a share of the advertising revenue, please contact us using the standard Feedback Form.


  
Show your Support for the Linux Tutorial

Purchase one of the products from our new online shop. For each product you purchase, the Linux Tutorial gets a portion of the proceeds to help keep us going.


Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
The Linux Tutorial can use your help.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.34 Seconds