Need help setting up hardware firewall/router

[Psion 0]

I've just finished installing Fedora Core 1 (minimum install only) on an old 400MHz PC. My objective is to use this unit as a Linux Firewall and router for my office network to share the net. Because Fedora installed only the required componants to do this task, there is no graphic desktop or any other fancy stuff. I am very new to Linux but do have experiance in setting up Windows networks, my own including a W2K server (main data storage) and a laptop running XP - used for tested. My printer is also connected via a 10/100 ethernet running through a 7 way hub.

 

I need help or at least pointing in the right direction with the following matters:

 

1. setting up the dial-up to call my ISP.

2. setting up IP numbers and default routing for the network.

3. setting the firewall rules.

4. getting the router working properly.

 

As I said, the Linux code is completely new to me (took me 2 hours last night to get pass the host login), so all advice is welcome...

[Psion 0]

OK - I've discovered some basic stuff about the pppd program and how to launch it but I am not getting connected yet. Also, how do I create a 'script' file to run instead of having to type the code every time?

 

Can someone please help?

[zorba4 0]

Sorry, but what is the problem with the script file ?

If you are able to type the commands (like ifconfig en0 up etc...)

then you are able to put them in a file named mypreferredthing.sh

and fire mypreferredthing.sh directly, or automatically from /etc/inittab ?

Or is your problem different ?

Regards

Zorba

[valmont 0]

this webby may solve some problems of yours. (i'm settin up a vmware router , so i'm sourcing out some 'how-to's as well)

 

Credits to this person who set up this website of this router set up: http://www.stanford.edu/~fenn/linux , thanks alot for continuin the spirit of open source.

 

Linux gateway/router - (another) HOWTO

Fri Jun 4 10:51:28 PDT 2004

(Update dhcpd.conf, named.conf, fix daemon load order)

 

Quick jump:

 

* Intro

* Hardware/prior necessities

* Network block selection

* Summary

* Configuring port forwarding

* Firewall config

* DHCPD setup

* BIND setup

* Enabling the firewall

* Epilogue

* future development: WAP setup (when I get a wireless card)

* suggest additional howtos

 

Intro

 

A hot item on the market nowadays is the "all-in-one" router+WAP+switch. This allows one to split a net connection across a number of computers. However, I've used these with less than successful results (router would inexplicibly drop connections at periodic intervals), and thusly now use a Linux box as my gateway to the internet. Not only can it do the router/WAP/switch combo, but (typically) for less cost and with far greater usability, as the gateway can also be used as a file server, print server, DNS server, NIS server, web server, mail server, SSH server, etc, etc. This web page is to help those who would like to set up a configuration that will allow for this, plus get a firewall up to keep it secure. The information here is pretty much general for any DHCP based ethernet connection to the internet (e.g. cable modems, most DSL services, etc.).

Hardware/prior necessities

 

Here are a few things I'm assuming before we get started:

 

* Cheapo/free linux box (hint: hang around near/in dumpsters.)

* 2 ethernet cards in linux box (Make sure one matches the duplex settings on the LAN cards to avoid potential problems, use mii-tool to check this)

* hub or switch of some kind (I scored a netgear FS108 for 20 bucks, ebay style)

* Fedora Core 1/2 install, or at least DHCP distribution (dhclient/dhcpd) and netfilter (aka iptables) available

* eth0 is the exterior (internet) interface, eth1 is the interior (LAN) interface

* eth0 is configured (via dhclient) and linux box can access internet

 

Network block selection

 

The computers on your LAN will need to be assigned IP addresses, so thats the first thing: pick a block of reserved addresses for private address space. As per the IANA standards set forth (see here, RFC1918, or RFC3330), this means you can use anything in the blocks:

 

* 10.0.0.0/8 (class A)

* 172.16.0.0/12 (class

* 192.168.0.0/16 (class C)

 

as you can see from the masks, each one has a decreasing number of allotable addresses. So unless you have over 64,000 computers at home, go with the 192.168 block. I use a single class C network (network 3), and thusly use 192.168.3.x below.

 

Summary

 

Here's a summary of the necessary files you'll want to edit:

 

* /etc/sysctl.conf

* /etc/dhclient-exit-hooks

* /etc/dhclient-eth0.conf

* /etc/dhcpd.conf

* /var/named/chroot/etc/named.conf

* /var/named/chroot/var/named/192.168.3.db

* /var/named/chroot/var/named/ventura.c.db

 

Note: you MUST *at least* edit the following:

 

dhcpd.conf:

 

option domain-name-servers 192.168.3.1, ns2.yourisp.com,

ns3.yourisp.com;

 

named.conf:

 

forwarders{

ns1.yourisp.com;

ns2.yourisp.com;

};

 

192.168.3.db:

 

NS ns2.yourisp.com.

 

ventura.c.db:

 

NS ns2.yourisp.com.

 

put in values for any additional backup nameservers (e.g. those provided by your ISP) in the above lines!!! (Remember: redundancy good)

 

here are the rpms you'll probably need:

 

* dhclient

* dhcp

* bind

* bind-utils

* bind-chroot

 

remember: FC1/2 is yum-friendly, so its a simple one liner to install the necessary goods:

 

$ yum install dhclient dhcp bind bind-utils bind-chroot

 

Configure linux for port forwarding

 

Now we need to enable packet forwarding on the kernel level (more on what the hell this means later). Edit your /etc/sysctl.conf so it contains the following:

 

# Controls IP packet forwarding

net.ipv4.ip_forward = 1

 

Since most people have dynamic IP's, you'll probably also want:

 

# Enable dynamic-ip address hacking

net.ipv4.ip_dynaddr = 1

 

For other potentially worthwhile settings, you can check out my whole sysctl.conf file.

 

Now set the eth1 interface up, which we'll manually assign as 192.168.3.1 on our internal network. This is done by editing /etc/sysconfig/network-scripts/ifcfg-eth1 like so:

 

DEVICE=eth1

ONBOOT=yes

BOOTPROTO=none

# (put your correct value below)

HWADDR=XX:XX:XX:XX:XX:XX

IPADDR=192.168.3.1

 

Firewall configuration

 

Now for my favorite part. Before we bring up eth1, we'll want to protect our internal LAN. Further, we've only told the linux kernel to allow packet forwarding. It won't actually do so until we provide it with some configuration parameters. Enter iptables, the userspace command to interface with the kernel firewalling subsystem. The concept is a simple one: filter packets as they arrive via eth0 and perform NAT (network address translation) for the LAN.

 

Most stock linux installs (nowadays) include a pre-configured and already running configuration of iptables. However, the Redhat/Fedora stock scripts aren't dynamic - i.e. we can't change certain parameters that may be set/unset during the DHCP lease negotiation process for our IP, or do so in a device-dependent manner. For example, I like to set my firewall to block reserved IP addresses (like those discussed above for internal networks), but sometimes my DHCP server is on a specific reserved address - which most likely is unknown before acquiring an IP or may likely change at some point. Also, I like to block my *own* IP address from trying to connect to my gateway - just as an extra precaution, but again is unknown information before the IP has actually been assigned. The one handy feature of dhclient (the DHCP client keeping track of your IP lease) is that it can run scripts at various parts of the lease negotiation process and provide all kinds of handy variables (like the assigned IP address or DHCP server). The punchline is, I ditch the the builtin iptables service in Fedora:

 

$ service network stop # (since we don't want our network up until we reconfigure iptables)

$ chkconfig --levels 2345 iptables off

$ service iptables stop

 

And, as per the manpage of dhclient, provide a /etc/dhclient-exit-hooks script. This script will be executed during all stages of the lease negotiation process (which is extra useful, since a firewall will be established *before* an IP is assigned), and even provide information as to which stage the process is at. (The script should be executable, of course.)

 

Now to rundown the various parts of the script, since its the main part of setting up and understanding the gateway.

 

 

 

#!/bin/sh

# firewall.mules - created by levy.pl on Mon Sep 10 11:35:04 2001

# this is a -skeleton- ruleset-- adapt as needed.

 

This script is derived from the neato perl script levy, available here.

 

 

 

# setup response based on dhclient input

logger -t iptables reason: ${reason}

 

if [ "x${reason}" = "xBOUND" -o "x${reason}" = "xREBIND" ]; then

 

staticaddr=${new_ip_address}/32

dhcpgate=${new_dhcp_server_identifier}

 

elif [ "x${reason}" = "xRENEW" -o "x${reason}" = "xREBOOT" ]; then

 

if [ "x${new_ip_address}" != "x${old_ip_address}" -o \

"x${new_dhcp_server_identifier}" != "x${old_dhcp_server_identifier}" ]; then

 

staticaddr=${new_ip_address}/32

dhcpgate=$new_dhcp_server_identifier

 

else

# don't want to _always_ run this script

exit 0

fi

 

else

 

staticaddr=

dhcpgate=

 

fi

 

logger -t iptables IP is ${staticaddr}

logger -t iptables DHCP gateway is ${dhcpgate}

 

This set of shell code interprets the dhclient call and determines if anything needs to be done. For example, if we're just renewing our lease and the IP and DHCP server are the same, then there's no point in re-running the rest of the script. The logger -t stuff logs the important information, which probably ends up in /var/log/messages.

 

 

 

# other definitions

IFext="eth0"

IFint="eth1"

lannet="192.168.3.0/16"

 

logger -t iptables Setting default policies

# chain policies

# drop everything and open stuff as necessary

/sbin/iptables -P INPUT DROP

/sbin/iptables -P FORWARD DROP

/sbin/iptables -P OUTPUT DROP

 

logger -t iptables Flushing tables

/sbin/iptables -F

/sbin/iptables -F INPUT

/sbin/iptables -F OUTPUT

/sbin/iptables -F FORWARD

/sbin/iptables -F -t mangle

/sbin/iptables -F -t nat

/sbin/iptables -X

/sbin/iptables -Z

 

This chunk of the script initializes some variables (they should be relatively self-explanatory), sets the default policies to DROP (i.e. drop all packets) and cleans out any existing rules.

 

 

 

logger -t iptables Creating user tables + rules

# create DUMP table

/sbin/iptables -N DUMP

/sbin/iptables -F DUMP

# limited logs

/sbin/iptables -A DUMP -p icmp -m limit --limit 1/m --limit-burst 5 -j LOG --log-prefix "IPT ICMPDUMP: "

/sbin/iptables -A DUMP -p tcp -m limit --limit 1/m --limit-burst 5 -j LOG --log-prefix "IPT TCPDUMP: "

/sbin/iptables -A DUMP -p udp -m limit --limit 1/m --limit-burst 5 -j LOG --log-prefix "IPT UDPDUMP: "

 

/sbin/iptables -A DUMP -p tcp -j REJECT --reject-with tcp-reset

/sbin/iptables -A DUMP -p udp -j REJECT --reject-with--icmp-port-unreachable

/sbin/iptables -A DUMP -j DROP

 

Now to create (-N to create, -F to flush) and setup the DUMP table, which is where packets will be sent if they get dropped. First the packet is logged (up to a limit) based on the type of packet (icmp, tcp or udp) and a return packet is sent to indicate the error to the violating host. Finally, the packet is dropped.

 

 

 

# Stateful table

/sbin/iptables -N STATEFUL

/sbin/iptables -F STATEFUL

/sbin/iptables -I STATEFUL -m state --state ESTABLISHED,RELATED -j ACCEPT

/sbin/iptables -A STATEFUL -m state --state NEW -i ! ${IFext} -j ACCEPT

/sbin/iptables -A STATEFUL -j DUMP

 

This second table will be used to make sure connections are allowed based on the state of the connection (thusly, a stateful table), and also shows off some of the power of iptables and the linux kernel firewalling code. We can use this table to allow connections *only* of if the connection has already been established (ESTABLISHED) or is associated with a connection that has already been started (RELATED) or is a new connection coming from an interface other than the external interface. Therefore, connections can only be initiated from *inside* the LAN. Otherwise, they're sent to the DUMP table we made above.

 

 

 

# SYN protection table

/sbin/iptables -N SYN-FLOOD

/sbin/iptables -F SYN-FLOOD

/sbin/iptables -A SYN-FLOOD -m limit --limit 1/s --limit-burst 4 -j RETURN

/sbin/iptables -A SYN-FLOOD -j DROP

 

/sbin/iptables -A INPUT -i ${IFext} -p tcp --syn -j SYN-FLOOD

/sbin/iptables -A INPUT -p tcp -i ${IFext} ! --syn -m state --state NEW -j DROP

 

# watch out for fragments

/sbin/iptables -A INPUT -i ${IFext} -f -j LOG --log-prefix "IPT FRAGMENTS: "

/sbin/iptables -A INPUT -i ${IFext} -f -j DROP

 

Now to set up some tables to attempt avoiding SYN-floods and fragmented packets, both of which are Bad. The syn-flood table allows us to only accept 4 connections per second. If the packet falls under the limit, the -j RETURN flag allows it to "jump" back to the call to this chain. Otherwise, start dropping packets - don't even send them to the DUMP table.

 

The next two lines either call the SYN-FLOOD table if the SYN flag is set (jumping back to this rule and continuing if its under the connection attempt limit), or dump the packet if its a new connection and the SYN flag *isn't* set (note the ! --syn -m state --state NEW statement). The final two lines drop any fragmented packets (-f), caused by missing parts of the TCP/IP header.

 

 

 

logger -t iptables Setting input/output rules

# allow loopback in

/sbin/iptables -A INPUT -i lo -j ACCEPT

# allow loopback and LAN out

/sbin/iptables -A OUTPUT -o lo -j ACCEPT

/sbin/iptables -A OUTPUT -p ALL -s ${lannet} -j ACCEPT

# don't allow our own IP *in*

if [ "x${staticaddr}" != "x" ] ; then

/sbin/iptables -A INPUT -p ALL -s ${staticaddr} -j DUMP

fi

 

Now to start letting connections in. Anything coming in or out on the loopback interface is certainly OK. We also trust anything going out from the LAN. Finally, we block any packets claiming to be from our own IP address (if defined), which is nonsense.

 

 

 

logger -t iptables Setting ISP specific rules

# needs to be defined before reserved addresses,

# since our ISP typically uses a reserved address for a DHCP server (sigh)

if [ "x${dhcpgate}" != "x" ] ; then

/sbin/iptables -A INPUT -i ${IFext} -s ${dhcpgate} -j ACCEPT

fi

 

This is something you may not need, but be sure to check. I had to add this rule to prevent my ISP from being blocked by my firewall. Quite simply, the DHCP server was given a reserved address. In order to let it in, we have to explicitly declare it before blocking all the reserved addresses (see below). That way, this rule is matched first by the packet and the connection is allowed. Again, we only set this rule up if the DHCP server is defined by the script.

 

 

 

logger -t iptables Preventing reserved addresses

# drop reserved addresses incoming as per IANA listing

/sbin/iptables -A INPUT -i ${IFext} -s 0.0.0.0/8 -j DUMP

<snip>

/sbin/iptables -A INPUT -i ${IFext} -s 240.0.0.0/8 -j DUMP

 

This is pretty self explanatory. Just dump any connection purporting to be from a reserved IP address. You may want to remove this block of rules, but I try to be extra-cautious.

 

 

 

logger -t iptables Setting ICMP rules

# allow certain inbound ICMP types

/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type echo-reply -j ACCEPT

/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type destination-unreachable -j ACCEPT

/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type source-quench -j ACCEPT

/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type echo-request -j ACCEPT

/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type time-exceeded -j ACCEPT

/sbin/iptables -A INPUT -i ${IFext} -p icmp --icmp-type parameter-problem -j ACCEPT

 

Now to set up protocol specific rules. We'll allow certain ICMP connections which tend to be used for critical network functions. Filtering some of this stuff may screw up your connection. However, you may need to change these for your specific settings.

 

 

 

logger -t iptables Setting TCP/UDP rules

# opened ports

/sbin/iptables -A INPUT -p tcp -i ${IFext} --dport ssh -j ACCEPT

/sbin/iptables -A INPUT -p udp -i ${IFext} --dport ssh -j ACCEPT

/sbin/iptables -A INPUT -p tcp -i ${IFext} --dport sftp -j ACCEPT

/sbin/iptables -A INPUT -p udp -i ${IFext} --dport sftp -j ACCEPT

/sbin/iptables -A INPUT -p tcp -i ${IFext} --sport bootps --dport bootpc -j ACCEPT

/sbin/iptables -A INPUT -p udp -i ${IFext} --sport bootps --dport bootpc -j ACCEPT

/sbin/iptables -A INPUT -p tcp -i ${IFext} --dport auth -j ACCEPT

/sbin/iptables -A INPUT -p udp -i ${IFext} --dport auth -j ACCEPT

# accept all other public ports

/sbin/iptables -A INPUT -p tcp -i ${IFext} --dport 1024: -j ACCEPT

/sbin/iptables -A INPUT -p udp -i ${IFext} --dport 33434: -j ACCEPT

 

Next is TCP/UDP - I allow in SSH, authorization requests via INETD, and requests from bootp servers to the bootp client (which we'll need to get our IP lease). Also, public port connections are allowed. You'll probably want to change these settings, depending on which services you want available from outside the LAN. Of course, one should always keep in mind the terms of service (TOS) set forth by your ISP (which most likely won't appreciate nor allow web servers, for example).

 

 

 

logger -t iptables Turning on NAT

# masquerade from internal network

/sbin/iptables -t nat -A POSTROUTING -s ${lannet} -o ${IFext} -j MASQUERADE

 

This single line is the _real_ reason we called this script - to get NAT up and running. Anything coming from the LAN that is destined for the internet is masqueraded as coming from IFext before being sent out (i.e. postrouting). All in one line. Damnit, I love iptables.

 

 

 

logger -t iptables Finish up

# push everything else to state table

/sbin/iptables -A INPUT -j STATEFUL

/sbin/iptables -A FORWARD -j STATEFUL

/sbin/iptables -A OUTPUT -j STATEFUL

 

Finally, anything else we haven't covered is pushed to the STATEFUL table we made above.

 

Also of interest in regards to iptables is port forwarding, which is a cinch to do. There are some commented out lines in the provided script that should help getting started with this if you need it.

 

There are some helper modules associated with iptables that can be used for protocols that require a second connection of some sort (e.g. a UDP and a TCP connection), such as FTP or IRC. To get these modules to load with iptables, add the following to /etc/modules.conf:

 

add above ip_conntrack ip_conntrack_ftp ip_conntrack_irc

add above iptable_nat ip_nat_ftp ip_conntrack_ftp ip_nat_irc ip_conntrack_irc

 

to find other modules, look in /lib/modules/<kernel_version>/kernel/net/ipv4/netfilter

 

Assigning IPs to the LAN

DHCPD

 

The next step is to assign IP addresses to each machine on the LAN. A simple way to do this is just setup aliases in the /etc/hosts file of all the machines, but thats slightly time consuming depending on the size of the network. I prefer using a DHCP server, which comes with the dhclient package from ISC, but is packaged separately by RedHat/Fedora. Setting it up is a cinch - just download my dhcpd.conf file. Some more salient points of this file:

 

* ddns-update-style interim: Dynamic DNS is employed, which additionally requires the BIND package. This further allows us to simply use the gateway as a nameserver for all the LAN machines.

* deny client-updates: Clients don't provide DNS updates, the server will take care of it (more on this below).

* ddns-domainname "ventura.c": In order to assign names, a "fake" top-level domain is used (the ".c" in ventura.c) - this is to avoid conflicts with any real TLD's. So, any client will have the FQDN of ".ventura.c". Of course, you can set this to whatever you'd like - just be sure to be consistent throughout.

* option domain-name-servers 192.168.3.1, ns1.yourisp.com, ns2.yourisp.com: This sets the name servers to send to the clients - be sure to change these values to suit your ISP (or, if you'd rather, just rely on the internal nameserver configured below).

* range 192.168.3.10 192.168.3.100: Clients will be assigned addresses in the 192.168.3.(10-100) range.

 

ddns-hostname = pick (option fqdn.hostname, option host-name,

concat ("dhcp-",

binary-to-ascii (10, 8, "-", leased-address)));

option host-name = config-option server.ddns-hostname;

 

* These two entries will allow the client to either specify a host name or be given one by the dhcp server in the form "dhcp-192-168-3-98.ventura.c" if a host name isn't requested. You can tweak this to your needs.

 

include "/etc/rndc.key";

 

zone ventura.c. {

primary 127.0.0.1;

key rndckey;

}

 

zone 3.168.192.in-addr.arpa. {

primary 127.0.0.1;

key rndckey;

}

 

* This chunk allows the DHCP server to update the nameserver using an HMAC-MD5 encoded key (more info below). The /etc/rndc.key comes with the Fedora install, so you don't need to generate one, unless you'd like to, of course. This will be handy in that clients can dictate their hostname, and the nameserver will append the domain name. So if a client requests the hostname "foo", it will have a FQDN on the LAN of foo.ventura.c without having to manually muck with the nameserver.

 

You'll probably want to change some of these settings (lease time, domain name, etc), but note this will affect the nameserver configuration as well.

 

One thing to keep in mind is dhcpd should only be visible from our LAN interface (eth1 in our examples so far). This is easy to do with the dhcpd command line switch "eth1". However, since we want dhcpd to start every time we boot the gateway, we'll need to add the flag to the Fedora start up script. This is specified in /etc/sysconfig/dhcpd, like so:

 

DHCPDARGS=eth1

 

Finally, we need to tell Fedora to turn on dhcpd at boot time:

 

$ chkconfig --levels 345 dhcpd on

 

BIND

 

Ok, now lets configure the nameserver so it will work for all the LAN machines as well as store all the dynamic names (thanks to our DHCP server). First is the named.conf file, which I like to have set up in a chrooted jail under /var/named/chroot (this is conveniently included as part of the bind-chroot package). I'll just highlight the important parts:

 

 

 

options {

directory "/var/named";

/*

* If there is a firewall between you and nameservers you want

* to talk to, you might need to uncomment the query-source

* directive below. Previous versions of BIND always asked

* questions using port 53, but BIND 8.1 uses an unprivileged

* port by default.

*/

// query-source address * port 53;

 

forwarders{

ns1.yourisp.com;

ns2.yourisp.com;

};

allow-transfer{

none;

};

allow-query {

192.168.3/24;

localhost;

};

listen-on {

127.0.0.1;

192.168.3.1;

};

};

 

These options set up the nameserver to listen on and allow queries from the LAN. They also set up some "backup" nameservers (the "forwarders", configure these to your settings) but do *not* allow zone transfers, which we don't need (and if we did, we could override this setting on a zone basis anyway).

 

 

 

zone "ventura.c" IN {

type master;

file "ventura.c.db";

allow-update { localhost; key rndckey; };

};

 

zone "3.168.192.in-addr.arpa" in {

type master;

file "192.168.3.db";

allow-update { localhost; key rndckey; };

};

 

include "/etc/rndc.key";

 

This sets up both the forward and reverse master zones for our LAN, and specifies the files to use to configure those zones (detailed below). It also allows either the localhost or a key validated server to update those zones, which is important given our DHCPD setup. Note the keys match for both daemons.

 

logging {

category dnssec { security_log; };

category update { security_log; };

category security { security_log; };

 

channel security_log {

file "dns_security.log" versions 4 size 10m;

print-time yes;

print-category yes;

print-severity yes;

severity info;

};

};

 

This last bit sets up some additional logging from named, but you can remove this part if you'd like.

 

Here's the skeleton ventura.c.db and 192.168.3.db files, which only defines the nameserver (192.168.3.1 in our case) and any aliases you'd like for it. Be sure to change any of the lines labelled "ns2.yourisp.com" to match additional nameservers available for your clients. (If you'd like to understand the specifics of these files, check out the BIND ARM or get a copy of O'Reilly's DNS and BIND, both of which are great resources for everything you'll want to know about DNS and the configuration files provided here.)

 

Upon assigning IPs, the DHCP server will update these files periodically for you - you'll know its working if you see .jnl files, which correspond to zone journal files from any updates.

 

Now that we have the nameserver configured, its important to make sure the linux box knows to use it. The list of nameservers (in order of preference) is contained in /etc/resolv.conf. dhclient generates this file, and can be told to prepend nameservers and domain names for resolving by editing /etc/dhclient-eth0.conf as such:

 

# NOTE: the space at the end "ventura.c " is significant!!!

prepend domain-name "ventura.c ";

prepend domain-name-servers 127.0.0.1;

 

So our homemade nameserver is queried first, with our fake domain name appended to any host name query.

 

Now to enable the named service at boot time:

 

$ chkconfig --levels 345 named on

 

Enabling the firewall

 

Ok, now to light this candle either type in the following or reboot the machine:

 

$ sysctl

$ service network start

$ service named start

$ service dhcpd start

 

(Its important to start named first, so its ready to receive name requests from the dhcp daemon) Check for errors in /var/log/messages. If none, setup the LAN machines to configure using DHCP. Reboot the LAN network interfaces, and watch the fun!!! To check things out, take a look at the logged packets in /var/log/messages under the subtext "IPT (TCP|UDP|ICMP)DUMP:", which might look something like this:

 

Jan 16 23:32:36 localhost kernel: IPT TCPDUMP: IN=eth0 OUT= MAC=xx SRC=xx DST=xx LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=39764 DF PROTO=TCP SPT=3415 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0

 

Aha! someone (my isp server in this case, but I've blocked stuff out to protect the innocent) is attempting to make a TCP connection (note the SYN flag is set) on port 80 (DPT=80), which is typically where web servers reside. Since we didn't open up a hole on port 80 (nor do we allow new connections from eth0), this packet passes through the stateful table and ends up being dropped.

 

To further check the firewall, there are several options. The file /proc/net/ip_conntrack shows all current, active connections. To view all the tables rules, try the following script:

 

#!/bin/sh

 

tables=$(cat /proc/net/ip_tables_names 2>/dev/null)

 

for i in $tables ; do

echo table $i

iptables -t $i -L

echo

done

 

which will show all the current rules and gory details. Further, Fedora has the logwatch analyzer running by default, so expect mailings in the root inbox detailing daily activities involving iptables (run as part of the kernel services script).

[valmont 0]

hi again,

 

i've manage to up the router and of course with lots of patchin to do.. some info to share.

 

How to use yum

==============

by Thomas Chung <tchung@linuxinstall.org>

2003-11-09

 

Introduction - What is yum?

 

Yum is an automatic updater and package installer/remover for rpm systems.

It automatically computes dependencies and figures out what things should occur to install packages.

It makes it easier to maintain groups of machines without having to manually update each one using rpm.

 

Reference: http://linux.duke.edu/projects/yum/

 

1. Before you use yum for the first time, type following command to download headers.

 

# yum check-update

 

It will take about 5 minutes to download a complete set of headers for base packages for Fedora Core

as well as any released updates for Fedora Core.

 

2. To install a package which is not installed already, use "install" option with yum.

For example, ncftp is missing by default for workstation class.

 

# yum install <package-name>

 

Example:

[root@localhost root]# yum install ncftp

Gathering header information file(s) from server(s)

Server: Fedora Core 1 - i386 - Base

Server: Fedora Core 1 - i386 - Released Updates

Finding updated packages

Downloading needed headers

Resolving dependencies

Dependencies resolved

I will do the following:

[install: ncftp 2:3.1.6-2.i386]

Is this ok [y/N]: y

Getting ncftp-3.1.6-2.i386.rpm

ncftp-3.1.6-2.i386.rpm 100% |=========================| 491 kB 00:04

Running test transaction:

Test transaction complete, Success!

ncftp 100 % done 1/1

Installed: ncftp 2:3.1.6-2.i386

Transaction(s) Complete

[root@localhost root]#

 

3. To remove a package which installed already, use "remove" option with yum.

 

# yum remove <package-name>

 

Example:

[root@localhost root]# yum remove ncftp

Gathering header information file(s) from server(s)

Server: Fedora Core 1 - i386 - Base

Server: Fedora Core 1 - i386 - Released Updates

Finding updated packages

Downloading needed headers

Resolving dependencies

Dependencies resolved

I will do the following:

[erase: ncftp 2:3.1.6-2.i386]

Is this ok [y/N]: y

Running test transaction:

Test transaction complete, Success!

Erasing: ncftp 1/1

Erased: ncftp 2:3.1.6-2.i386

Transaction(s) Complete

[root@localhost root]#

 

4. To install any updates available, use "update" option with yum.

 

# yum update

 

Example:

[root@localhost root]# yum update

Gathering header information file(s) from server(s)

Server: Fedora Core 1 - i386 - Base

Server: Fedora Core 1 - i386 - Released Updates

Finding updated packages

Downloading needed headers

No Packages Available for Update

No actions to take

[root@localhost root]#

 

5. To serach a package by name (wildcard ok), use "search" option with yum.

 

# yum search <any-name>

 

Example:

[root@localhost root]# yum search ??ftp

Gathering header information file(s) from server(s)

Server: Fedora Core 1 - i386 - Base

Server: Fedora Core 1 - i386 - Released Updates

Finding updated packages

Downloading needed headers

Looking in available packages for a providing package

Available package: vsftpd.i386 0:1.2.0-5 from base matches with

vsftpd - Very Secure Ftp Daemon

Available package: vsftpd.i386 0:1.2.0-5 from base matches with

vsftpd

2 results returned

Looking in installed packages for a providing package

Installed package: ncftp.i386 2:3.1.6-2 matches with

ncftp

1 results returned

[root@localhost root]#