Welcome to the Shroomery Message Board! You are experiencing a small sample of what the site has to offer. Please login or register to post messages and view our exclusive members-only content. You'll gain access to additional forums, file attachments, board customizations, encrypted private messages, and much more!
I've been given a secondary computer (500Mhz 128mb ram 12gb HD) And I would like to set it up as a firewall. I am really confused so I will probably have to go read a bunch of websites, but Im asking here.. Can I set up a free operating system, like linux or freebsd on this computer If my main computer is running XP? Is that the best choice?
Thanks..
-------------------- at this point i think we can be relatively certain seperation exists as a fallacy of finite perception, and the only barrier to infinite creativity is a preimposed notion of certainty and artificial conditioning. nothing is without origin
yup, i use FreeBSD for firewall/gateway, its pretty simple after installing there are only a few steps to take to make it a damned secure firewall.
1) install OS 2) recompile kernel with: options IPDIVERT //enable divert required for NAT options IPFIREWALL // enable ipfw options IPFIREWALL_VERBOSE // enable logging options IPFIREWALL_VERBOSE_LIMIT=25 //prevent log DoS options IPFIREWALL_FORWARD // allow ipfw to forward packets
5) setup rc.conf: needed: defaultrouter="your gateway at the ISP" ifconfig_ep1="inet YOUR_IP netmask YOUR_NETMASK" //outside interface ifconfig_rl0="inet INT_IP netmask INT_NETMASK" //inside // the ep1 and rl0 will corispond to the name your network card driver names the device
gateway_enable="YES" //needed to send packets from the internal to //external adapter natd_enable="YES" //enable address translation natd_interface="ep1" // set to the outside interface
firewall_enable="YES" // enable the firewall firewall_script="/etc/rc.firewall" //and use this script for the firewall
//and if you want to be able to access the computer sshd_enable="YES"
//once your up and running and get the box all setup how youd like you can disable this and noone could log in at all remotly.
4) Setup firewall script... i use state-full rules come up with by someone else that works exellant, ill post it if anyone is interested.
If there are any questions or comments, please direct them to walt@erudition.net. The newest copy of this HowTo can always be retrieved from www.freebsd-howto.com. All rights for the reproduction of this document are reserved.
Summary.
1. General Introduction to Packet Filters 2. Enabling Ipfirewall(4)
2.1. rc.firewall and OPEN firewalls 2.2. Loading Rulesets
Ipfw(8), the command frontend to ipfirewall(4), is the most common IP filtering and traffic shaping facility in FreeBSD, and the one for which FreeBSD is ready to handle by default (although the firewall itself is disabled by default in the kernel). The logical operation if its rules is similar to many other packet filters, with the exception of IPFilter, whose default operation in handling rules is rather less efficient and requires greater care to tune it (if you're familiar with it, note the 'quick' keyword required for ipf(8) not to traverse the entire ruleset every time, etc). This is not to minimize the power of ipf(8), which has its own advantages. The ultimate decision as to which packet filtering facility one uses is a personal choice, unless one requires particular functionality not available in one or the other, although, we will delve into a rough comparison of the two later on.
As indicated above, ipfirewall(4) is a packeting filtering firewall, which means that it acts by inspecting connexions on a packet-by-packet basis, and as of FreeBSD 4.0, can also perform rudimentary connexion oriented (stateful) filtering. On either count, it acts by filtering packets through one or more network interfaces. This behaviour is always transparent, that is, one will probably not be aware that a firewall is present until something is blocked.
Firewall designs take on many shapes, but all can be broken down into two general policies: open and closed. The open firewall approach lets all packets through by default and only blocks that which is NOT desired, while on the other hand, the closed approach blocks all packets by default, and only lets through was IS desired. The latter allows for a much tighter firewall configuration, but is much trickier to setup because one can easily block out traffic that one's net requires, but one isn't aware of.
2. Enabling Ipfirewall(4)
Ipfirewall(4) can be enabled in two ways: add the appropriate options into your kernel configuration file and rebuild the kernel, or use kldload(8) to dynamically load the basic ipfw.ko module into the kernel. Either approach works well for enabling basic ipfirewall(4) operations, however, only the former allows you to add additional configuration options, such as logging.
To dynamically load ipfw one can simply issue the following command:
(root@nu)~># kldload ipfw (root@nu)~>#
Enabling ipfirewall(4) statically, the equivalent would be to add the following line into your kernel configuration file:
options IPFIREWALL
Then, rebuilding and rebooting would enable ipfirewall(4) in the kernel statically.
However, things are not as simple as they may seem; one can only do things exactly as above when one is in front of the console. Additional options are necessary to make the box usable. If you recall the discussion above concerning firewall policies (open and closed), you will understand why things can get very messy when you realize that the default firewall policy is closed. As such, if you simply enable ipfirewall(4) without any further actions, all network traffic will be blocked. This can become a nightmare when enabling ipfirewall(4) remotely. Diasaster can be avoided, although, it is never recommened to remotely enable ipfirewall(4), either dynamically or statically.
If you wish to dynamically load ipfirewall(4) remotely, anyhow, the follow command is recommended:
(root@nu)~># kldload ipfw && \ ipfw -q add 65000 allow all from any to any (root@nu)~>#
This will automatically set a rule to allow all traffic instead of blocking it, so you don't cut yourself off from your remote box. Likewise, this is recommended on local boxes as well if they are connected to a network and you don't want to lose your connexion.
Enabling ipfirewall(4) in the kernel statically in a remote box takes a little extra work. Once one has added the kernel option specified earlier, in the kernel configuration file, and rebuilt the kernel, one has to then set at least two ipfirewall(4) options in rc.conf so that when the box reboots, it will not be locked out by its own firewall with the default-to-close policy.
firewall_enable="YES" firewall_type="OPEN"
There are other firewall types defined in /etc/rc.firewall, but we will concern ourselves with those later. For now, a default open policy is good practice for the beginner. Alternatively, one can enable a default open policy for ipfw(8) in the kernel, instead, by also adding the following option into the kernel configuration file:
options IPFIREWALL_DEFAULT_TO_ACCEPT
In this case, the rc.conf options noted above will not be *necessary* as we will not *need* to use /etc/rc.firewall to enable an open policy because it will be enabled by default in the kernel. However, even if one chooses to enable this in the kernel, it is good practice to enable the /etc/rc.conf options anyhow, because later we will be using /etc/rc.firewall to load custom rulesets. This also applies if one loads the kernel dynamically, because eventually one will reboot, and the kernel ipfw.ko module will not be automatically loaded. The /etc/rc.conf firewall enabling functions allow for a convenient place to load the ipfw.ko module.
With the additional options for ipfirewall(4) that are available for enabling statically in the kernel, one soon realizes this is the better method for enabling ipfirewall(4) in earlier versions of FreeBSD. Aside from IPFIREWALL_DEFAULT_TO_ACCEPT, we also have:
IPFIREWALL_VERBOSE allows one to log traffic with ipfirewall(4) by verbosely printing packet activity to syslogd(8) for every rule that has the "log" keyword. This will be more clearly explained later.
IPFIREWALL_FORWARD allows one to forward packets to other hosts with the 'fwd' command for ipfirewall(4), which will be dealt with in more depth later.
IPFIREWALL_VERBOSE_LIMIT=# specifies a limit to logging packets from a particular rule. With this, syslogd(8) and one's console (unless disabled in /etc/syslog.conf, as will be shown later) will not be overwhelmed with messages from ipfirewall(4) activity. The "#" is replaced with the number of consecutive times one wishes to log a given rule being activated.
For the most recent 4.x builds of FreeBSD, additional sysctl variables have been added which makes enabling ipfirewall(4) options with sysctl more practical. For the corresponding options enabled above in the kernel configuration file, one can issue the following sysctl commands:
Note that there are no sysctl variables for controlling inet6 ipfirewall(4) verbosity.
There are additional options associated with ipfirewall(4) that can be enabled in the kernel, but will not be discussed at this moment as they are not necessary for the basic firewall activities, and involve more complex routing situations.
2.1. rc.firewall and OPEN firewalls
Whether one specifies a firewall type or not, once firewall_enable="YES" is put into rc.conf and the system reboots, /etc/rc.firewall is started from rc.conf, and the following two commands are issued to ipfw(8) from within it:
${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8
{fwcmd} is defined early on in the rc.firewall script, depending on whether one specified that ipfw(8) run quietly (with the -q option) or not. The first rule allows all traffic via the loopback device (lo0) to pass, and the second rule blocks all traffic aimed at the localhost (127.0.0.0) network. The first rule is necessary to allow local IPC (inter-process communication) traffic, and the second rule is necessary so that no external packets can ever be allowed to reach the localhost address, which is the address on the loopback device, thus protecting one's local traffic. If these rules are missing, and the firewall defaults to a closed policy, you will see RPC(3) services break during startup, among other things.
Next, when one specifies a firewall type of "OPEN" in rc.conf, the following line in rc.firewall is activated:
${fwcmd} add 65000 pass all from any to any
This allows all external traffic in (except to the localhost), and all internal traffic out. It fulfills the same task as enabling the IPFIREWALL_DEFAULT_TO_ACCEPT in the kernel. If the open policy is enabled in the kernel, then rule # 65535 will be automatically set to "allow ip from any to any" instead of "deny ip from any to any," thus making rule # 65000 as set in rc.firewall for the open policy redundant. As such, it is more apropos to indicate firewall type "UNKNOWN" if one enables an open policy in the kernel, and does not wish to enable any other rules. For one wishes to, for instance, simply enable the firewall to play with and see how it work,s or simply block packets from a single host, then leaving the firewall type open like this is sufficient and one can safely skip to section 3.
However, if one wishes to use one of the pre-built rulesets in rc.firewall, or create one's own custom rulesets, then neither options (OPEN or UNKNOWN) are sufficient.
2.2. Loading Rulesets
There are two generally different things that can be done concerning rulesets: use one of the pre-built ones in rc.firewall, or create your own. The author recommends the latter for two reasons:
- You can customize the firewall rules to your liking and needs without touching rc.firewall, which can be kept as a general reference.
- You will be forced harder to become familiarized with ipfw(8) syntax, and as such, will become more comfortable with using ipfw(8).
2.2.1. Pre-defined Firewall Types
Of course, the final decision is the administrator's. If one wishes to use one of the pre-built rulesets, then one should read through each of them in rc.firewall to become familiar with them before activating any of them. Which ruleset is loaded is controlled by the firewall_type="" option in rc.conf. Aside from the "OPEN" type, there are three more predefined types available:
"CLIENT" This ruleset enables some basic rules. It allows all traffic from the local network (which could be a private network behind NAT) to itself. It blocks fragmented packets. It allows mail, DNS and NTP packets in and out of the network, and does not allow any host outside the private network to initiate TCP connexions with internal hosts. This would already be impossible if the network was behind a vanilla NAT configuration without any special proxies. This configuration will work with both a default open or closed policy.
"SIMPLE" This ruleset is somewhat of any oxymoron - it is more complex than the CLIENT configuration and requires some knowledge of internet RFCs to make sense of at first glance. It will attempt to stop spoofing by not allowing in external packets that have return addresses the same as that of any internal host. It will block all private-net-addressesed packets as defined by RFC 1918 from leaking in or out, and will block all additional non-routable networks as defined in the Manning internet draft (http://www.ietf.org/internet-drafts/draft-manning-dsua-03.txt). It will allow mail, www, DNS, NTP traffic and fragmented packets to pass through, and will not only block attempts for connexions to be initiated by outside hosts, like CLIENT, but will also log these attempts.
"CLOSED" This is technically not a rulest, because it does not enable any rules. In fact, it does everything we've been warning not to do: allow the default closed policy to take hold over all traffic (except for traffic via lo0 as controlled by the rules explained earlier). It will essentially disable all IP services, unless, one enabled the default open policy in the kernel. Don't do this.
2.2.2. Custom Firewall Types
If one has decided to instead load one's oen ruleset(s), then one should specify a file instead of one of the above types in the firewall_type option in rc.conf. For instance, one might have the following in their rc.conf:
This will allow one to define one's custom ipfirewall(4) ruleset in /etc/rc.firewall.rules and have it run everytime during bootup. Furthermore, if one wanted to have the rules start quietly, one could also include the following in rc.conf:
firewall_quiet="YES"
The format of the ruleset in this file will be slightly different from that which is encountered in rc.firewall. This is because rc.firewall is an sh(1) script designed to run on its own. The ipfirewall(4) rule file is there solely to be processed by ipfw(8). The primary difference will be that where the shell variable {fwcmd} is invoked in rc.firewall, you will see nothing corresponding to it invoked in the ipfirewall(4) rule file - simply the rules on their own. Later on, when we construct a sample rule file, we will go through this step by step.
3. Basic Ipfw(8) Rule Syntax
The rule syntax for ipfw(8) is pretty simple. Any rule can be enabled from the console with the ipfw(8) command. Before we delve into the rule syntax, however, we will quickly overview how to list the ipfirewall(4) rules that have been activated.
3.1. Listing Rules
In its simplest form, we can list the rules with:
ipfw list
This will list all of the rules ordered by their rule number. To also list the timestamp of the last moment a packet was matched on a specific rule, the following command will accomplish this:
ipfw -t list
Finally, if we wish to list the packet count for matched rules along with the rules themselves, we can issue the following:
ipfw -a list
OR
ipfw show
Both will display the same information in the same way. The first column is the rule number, followed by the number of outgoing matched packets, followed by the number of incoming matched packets, and finally followed by the rule itself.
3.2. Basic Commands and Actions
We will now gradually go through the various options available for the construction of a stateless filtering ruleset. In our examples we will only state the rule not including the firewall control utility (/sbin/ipfw) which must precede each one if we're manually setting these rules from the command prompt; otherwise, if we're construction a rule file to be passed to ipfw(8) we can use the sample lines as-is.
add 1000 allow all from any to any
This is the most benign example of a rule. We have already encountered the same rule, except for the rule #, in section 2.1 when discussing the OPEN firewall type. Note: the "pass" parameter used in that rule, as written in rc.firewall, is synonym for "allow" and "permit" - they are interchangable. In this rule, "all" packets from "any" source to "any" destination are allowed to pass.
With ipfirewall(4), under most circumstances, the moment a rule matches a particular packet, then ruleset examination halts there.
As we see, the simplest syntax for ipfw(4) is:
[] from to
The important commands are "add" and "delete." They are self-explanatory. Rule numbers start count at 0 and end at 65535. The last rule number is always defined by the default firewall policy in the kernel. Even if you have an open policy defined in rc.conf, the last rule will always reflect the kernel policy. This is fine because ruleset search halts at the first matching rule (usually), so if the penultimate (second to last) rule is number 65000 and defined by rc.firewall to allow all packets, all packets will be allowed by default even if the last rule (65535) defines a closed kernel firewall policy, because the last rule will never be reached.
"action" can be one of a number of things:
"allow" | "pass" | "permit" - Any packets matching a rule with this action are allowed to pass through the firewall, and search of ruleset terminates.
"deny" | "drop" - Any packets matching a rule with this action are silently blocked by the firewall and search of ruleset terminates.
add 1100 deny all from any to any
This would deny all packets from anywhere to anywhere.
"reset" - Any packets matching a rule with this action are blocked and the ipfirewall(4) attempts to send a TCP reset (RST) notice to the source. The ruleset search is terminated. Naturally, because this only applies for TCP packets, the protocol must be "tcp," which matches only TCP packets, and not "all," which matches all IP packets.
This action is sometimes useful for fooling network scanners that would otherwise be able to detect a service behind a filtered port. On the other hand, it can become a liability if one is flooded at a particular IP and port for which ipfirewall(4) is set to reply with a RST packet, thus doubling the usage of your bandwidth.
add 1200 reset tcp from any to any
This would deny all TCP packets from any to anywhere, and sent a TCP RST responce packet to the source for each.
"count" - Any packets matching a rule with this action will prompt ipfirewall(4) to increment its packet counter. Search through the ruleset continues.
add 1300 count all from any to any
This would increment the packet counter for this rule, which matches all packets coming from anywhere and going anywhere.
"skipto " - Any packets matching a rule with this action will prompt ipfirewall(4) to continue its search through the ruleset starting with the rule number equal to or greater than that which is indicated by .
add 1400 skipto 1800 all from any to any
This would skip ruleset search to rule 1800 for any packets that matched this rule in the first place.
3.3. Specifying Protocols
The "proto" is the protocol that is desired to be matched. The keywords "ip" or "all" are catch-alls that match all protocols. The commonly matched packet procotols are icmp, udp, and tcp, although, that is by no means an exhaustive list. For the complete list of possible protocols one can match, 'more /etc/protocols'.
3.4. Specifying the Source and Destination Addresses
The "source" and "destination" both take on the same format. They can be a name, as defined in /etc/hosts or through DNS, an IP address, a network address with bitmask (or netmask), and can be optionally followed by one or more ports numbers if the protocol is udp or tcp. Using names or IPs is straightforward, for instance:
add 1000 allow all from myhost to hishost add 1100 deny all from 10.0.0.5 to any
The first rule will allow all traffic from "myhost" to "hishost," and the second rule will deny all traffic from 10.0.0.5 to any host. Once a packet matches one of these, ruleset examination for that packet ceases, and it is either passed or dropped, according to the action specified in the rule it matched. This is a simple example of host-based filtering; that is, of filtering according to which hosts a packet is destined for, or arriving from. Network-based filtering works similarly, and the network notation there utilizes either bitmasks or netmasks, for instance:
add 2000 allow all from 192.168.0.0/16 to any add 2100 deny all from any to 10.0.0.0:255.0.0.0
The first rule allows all traffic from the network whose IP range is 192.168.0.0-192.168.255.255. It uses a bitmask to indicate this. A bitmask specifies how many bits from the network address (192.168.0.0) should remain the same for matching packets. In this instance, the first 16 bits out of the 32 bit address will remain the same, and as the first 16 bits happen to be the first two octets, 192.168, all addresses whose source addresses have the first two octets as 192.168 will be matched by this rule. The second rule accomplishes a similar thing using netmasks. The netmask indicate how many bits from the indicated network address should be used for rule matching. In the above example, for rule two, the netmask is 255.0.0.0. Its first octet is set with high bits; in other words, the first 8 bits are set high. This indicates to ipfw(8) that only packets with the first 8 bits of the network address (10.0.0.0) should be matched. As the first 8 bits of the network address equal 10, then all packets whose destination address have a 10 for the first octet (all addresses between 10.0.0.0 and 10.255.255.255) will be matched by this rule, and then dropped, as indicated by the action.
Rule matches can also be inverted with the "not" keyword. For instance, in the following ipfw(8) commands, all packets not from 192.168.0.3 are dropped:
add 1000 deny all from not 192.168.0.3
3.4.1. Introduction to Bitmasks and Netmasks
The principle behind bitmasks and netmasks is simple, but often confusing to new users, as it requires knowledge of binary numbers. It makes far more sense if one worked with IP addresses in their binary form, however, the confounding of decimal and binary concepts easily throws newcomers off. For a quick reference, the following table illustrates what network ranges are indicated by the corresponding bitmasks/netmasks up to a default class C netmask and a couple quick examples of additional bitmask/netmask entries for larger networks:
As you can see, there is a definite pattern. The number if total IPs always doubles, and the number of usable IPs is always total - 2. This is because for every IP network/subnet there are two IPs reserved for the network and broadcast addresses. The netmask's last octet starts at 255 and constantly decreases by multiples of 2, while the bitmask decreases by multiples of 1, because in binary, each shift over to the left halves the number, not divides by ten, like in the decimal number system. This same pattern goes for all possible netmasks and bitmasks.
For a quick example in using the above table/pattern, let us figure out the IP range for the subnet indicated by:
172.16.100.32/28
First we notice that the network address is 172.16.100.32, so we know that the subnet begins with this address. Second, we notice that the bitmask of 28 indicates that the last 4 bits (32-28) are set low and 28 bits set high. Because there are far less bits set low, it'll be easier to compute this using them. Because each bit has two possible values, 2^4 indicates how many hosts are referenced by this bitmask. In this case, 16. 172.16.100.32 + 16 = 172.16.100.48, so the IP range is 172.16.100.32 - 172.16.100.48. Looking at the table, we see that 16 IPs correspond to a bitmask of 28, so we could've used that to add to our network address and avoided the other math, but it's so much better to know how to do it all on your own - learn once and use always.
3.4.2. Specifying Ports and Port Ranges
One can also do port-based filtering along with host and network-based filtering. Ports can be simply specified following the address of either a source of destination. Port ranges can be specified with a dash, be comma-separated, or use a bitmask to specify a range. Most importantly, one can not use the "all" protocol when specifying ports because not all protocols are port-sensitive.
add 1000 allow tcp from any to 172.16.0.5 25 add 1100 allow tcp from any to 172.16.0.5 1021-1023 add 1200 allow tcp from any to 172.16.0.5 21,22,23 add 1300 deny udp from any to 192.168.0.5 1024:8
In the first rule all TCP packets which are destined for port 25 on 172.16.0.5 are matched. In the second rule, all TCP packets which are destined for ports 1021 through 1023, inclusive, on host 172.16.0.5 are matched. In the third rule, all TCP packets which are destined for ports 21, 22 or 23 on host 172.15.0.5 are matched; and finally, in the fourth rule, all UDP packets which are destined for ports 1024 through 1028 on host 172.16.0.5 are matched. The last rule can be tricky as it uses a bitmask on the port to make matches. The port 1024 contains 10 bits. The bitmask indicates that all hosts matching the last 8 bits on that port, destined for host 192.168.0.5, are matched. 10 - 8 gives one 2 bits which can be anything. 2^2 = 4, so we have 4 port numbers, starting with 1024, that can be the destination ports for packets aiming for that host, and will result in a match.
Bitmasks for ports are rarely used and are even trickier than bitmasks or netmasks for IP addresses, because the number of bits in a port varies depending on the port specified before the mask. As such, it is recommended that one stick to specifying port ranges with a dash ( - ) or separate the list of ports with commas.
4. Advanced ipfw(8) Rule Syntax
Although the above overview of ipfw(8) rule creation will cover many of the simple scenarios, it sorely falls short for many more complex situations, such as when a system has more than one network interface, one wishes to make special responces to certain matches, or one wants more control over the direction of traffic flow. We will first expand the template for the ipfw(8) syntax to the follow:
[] [log [logamount ]] from to [] []
Everything in brackets comprises new functionality we will discuss in this section. We will also cover an additional "action" that was not covered earlier. The syntax may suddenly seem daunting, but we will take it slowly, and add each part as we go along, so as not to overwhelm you.
4.1. "unreach" Action
Firstly, we will introduce a new "action:"
"unreach " - Any packet which matches a rule with this action will reply with an ICMP unreach code, after which time the ruleset search will terminate. The possible unreach codes can be indicated by number or name. The following is a quick list of ICMP unreach codes and corresponding names. If you don't know what these are used for, you won't have a reason to use them:
One important functionality missing from the basic description of ipfw(8) syntax in part 3 was interface and flow control; that is, the ability to match packets according to which interface (if you have a multihomed system) packets are moving through, and in which direction they're moving. Up until now, direction was only loosely gauged by using the source and destination addresses, but using just them to guesstimate whether a packet is really coming or going when it moves through the firewall is unreliable. If you wish to match packets only coming in or going out, the keywords "in" and "out" can be used. Both correspond to the "interface-spec" area of the syntax template given earlier, and therefore, are placed near the end of every rule, prior to any posible options. For instance, if we wish to match all packets coming in from anywhere and going anywhere, we could have:
add 1000 allow all from any to any in
To match packets going through a particular interface, use the "via" option followed by the interface name. For instance, if you are using a PCI 3Com 3c59x, then your interface device will be xl0. To match all packets coming in through that interface specifically, sourced from anywhere and destined anywhere, the following would suffice:
add 1100 allow all from any to any in via xl0
Or, perhaps, if one has a multihomed system and wishes to match any packets coming from anywhere and going anywhere at least moving outside through *some* interface, he can do the following:
add 1200 allow all from any to any out via any
One will notice, when listing firewall rules, that when using either "in" or "out" in combination with "via" the rule as it actually looks does not contain a "via" but either "recv" or "xmit," depending on whether an "in" or "out" was specified, respectively. For instance:
(root@nu)~># ipfw add 7000 allow all from any to any out via xl0 (root@nu)~># ipfw list | grep 7000 07000 allow ip from any to any out xmit xl0 (root@nu)~>#
Indeed, one can use either "recv" or "xmit" in place of "via" when using "in" or "out," however, doing so is not required, and can add to some confusion for the newcomer.
In all, these options allow a lot more control over network traffic on a multihomed system and any system in general, by allowing one to filter packets specifically coming into the firewall, exiting it, and moving through a specified interface.
4.3. Matching specific ICMP and TCP Packet Types
ICMP, TCP, and IP packets come in various types. These types are defined by the various flags that each of those packets sets. We can match each of those types by using one of the following ipfw(8) options at the end of our rules.
4.3.1. icmptypes
"icmptypes " - This will match the specified ICMP packet , and conversely, if a '!' is put before the then all ICMP packets that are not of this type are match. There are currently 15 different ICMP packet types that can be matched; each is specified by the correct number. Ranges can be specified with dashes or be comma-separated. The 15 possible ICMP types are:
If one is curious how these ICMP type, specifically type 3, correspond with the Unreach codes that can be generated with the "unreach" action, then, simply type 3 matches any of those Unreach codes. Filtering ICMP packet types can be very useful for controlling ping; specifically, for allowing internal hosts to ping out while blocking outside hosts from pinging the gateway or any other host. The following three rules can accomplish this easily:
1000 allow icmp from any to any out icmptypes 8 1100 allow icmp from any to any in icmptypes 0 1200 deny icmp from any to any in icmptypes 8
The first rule allows all icmp packets of type 8 (echo request) to go out. The second rule allows all icmp packets of type 0 (echo reply) in, and the final rule blocks all icmp packets of type 8 from entering. In short, it allows echo requests to go out and echo replies to come in, but blocks echo requests from coming in. As such, hosts behind the firewall can ping anyone on the outside, while hosts on the outside can't ping anyone behind the firewall. Naturally, this option can only be specified when the indicated procotol is "icmp."
4.3.2. tcpflags, setup and established
"tcpflags " - This will match any TCP packet whose header contains one of the following flags, or conversely, if '!' is presented before the , match all TCP packets that do not have the set:
fin - Request for connexion termination syn - Request for connexion initiation rst - Reset Connexion psh - Push Flag ack - Acknowledgement urg - Indicate Urgent OOB data
The SYN flag is of most interest as it is sent for initiation of TCP connecions. Because it is so important, there is a separate ipfw(8) option dedicated specifically for matching TCP packets with the SYN flag set. This is called "setup." Naturally, this option can only be specified when the indicated protocol is "tcp."
"setup" - Any rule containing this option will match any TCP packet with the SYN flag set. For instance, if we wished to deny all incoming TCP SYN packets, we coul issue the following:
add deny tcp from any to any in tcpflags syn
OR
add deny tcp from any to any in setup
On either count, the same action is performed: all TCP SYN packets from "any" destined to "any" will be matched, and denied. As stated above for "tcpflags", this option can only be used for rules when the indicated protocol is "tcp."
"established" - Just as there is a special option for indicating the request for TCP connexion initiation ("setup") there is a special option for matching an already established TCP connexion. Because it is of paramount important to easily control TCP connexions, "established" and "setup" are available for quick rule formation. Given these options (or their corresponding "tcpflags" incarnations) we can have some simplistic control of TCP connexion activity. This is the very base of stateful firewall functionality, which shall be dealt with in more detail later.
4.3.3. ipoptions
"ipoptions " - Finally, we can match for some specific IP packet flags, namely, for SSRR (Strict Source Route), LSRR Loose Source Route, RR Record Packet Route, and TS (Timestamp) flags. If you do not know what any of these IP options do then you will not need to match for them specifically.
4.4. Catching Fragmented Packets
Fragmented packets are matched with the "frag" ipfw(8) option. Under most circumstances fragmented packets should be blocked. Receiving many fragmented packets may indicate a DoS (Denial of Service) attack, although FreeBSD and most other UNIX and UNIX-like systems will not be phased by such attacks, Windows systems are often quite vulnerable. As such, if one has one or more Windows systems on their network behind the firewall, it is avisable to block fragmented packets.
When using the "frag" option to match [and block] fragmented packets, there are a couple guidelines that must be followed. Firstly, one can not use the "frag" option when also specifying "tcpflags." Secondly, one can not use "frag" if also specifying any TCP or UDP ports. Given these guidelines, we can easily issue a rule to block all incoming fragmented packets:
add deny all from any to any in frag
4.5. UID and GID Based Filtering
One powerful function that IPFilter does not have is UID/GID-based filtering. Ipfirewall(4) is able to filter packets according to the UID and/or the GID of the process from which they are arriving. Naturally, this can only be used to match packets which originate from processes on the local host, however, it still offers a powerful functionality. The options to be used are "uid" and "gid" followed by the UID/GID or name of the user or group by which we will be filtering.
One potential use is to restrict the use of IP vhosts on a shell server. If one wants to ensure that one or more vhosts can not be used by anyone else, one can easily use UID-based filtering to block everyone's but one's own traffic from that vhost:
add allow tcp from any to 172.16.0.10 in add allow tcp from 172.16.0.10 to any out uid george add deny tcp from 172.168.0.10 to any
With the above rules, only user george would be able to use the aliased IP (IP vhost) 172.168.0.10 to establish TCP connexions to the outside. No one else would be able to bind bots, IRC chat clients, or what have you, to that IP and establish connexions with anything that required TCP (most things). Likewise, the UDP protocol can be used with UID/GID-based filtering, however, no other protocol can be.
Another possible use of UID/GID-based filtering would be to enable bandwidth limiting on a per-user basis, as opposed to per-host or per-network basis. As such, one could, for example, have a group of users that all have fast FTP accounts, and only moderately limit their GID, while on the other hand, have another group of shell users, who don't require much bandwidth, and therefore significantly cap the bandwidth on the GID they all belong to. Such GID-based bandwidth capping will be illustrated later, once we cover the traffic shaping facilities of ipfirewall(8).
For security purposes, one may wish to log the traffic of a particular user, and here too UID-based filtering would come in handy. In short, whenever one would wish to conduct firewall behaviour differently for one or more users, UID/GID-based filtering would come in handy. Because, in general, once a rule is matched, search through the ruleset stops, UID/GID matching rules must be invoked before other sweeping rules can match the traffic. So, when creating one's ruleset, one must take this into careful account if one wishes to enable UID/GID-based filtering.
5. Logging
5.1. Logging Issues
The virtues of logging are obvious. The ability to go back and see what what connexions had been dropped, what addresses they came from, where they were going, whether they were composed of many fragmented packets (indicative of many DoS attacks), and so on gives you a significant edge in both knowing where connexions are being made, by whom, and when. Especially in the case of tracking down crackers and the like, firewall logs may give one the all-important edge.
Logging also has a down-side. If you're not careful, you can both lose yourself in the abundant data (for lack of proper log analyzing strategies) and lose your HD space to growing log files. DoS attacks that fill up HDs are one of the oldest around, and still just as dangerous to the imprudent administrator. Although, they more often strike the poorly configure email server, they are just as much a threat to any system keeping extensive log data. It is important that you have sufficient HD space and rotate logs prudently, so they do not grow indefinitely.
On the other hand, what many newcomers experience that once they enable ipfirewall(4) logging their terminal is overwhelmed with messages concerning packet activity. This is the result of any combination of:
- logging too many often-matched rules - not disabling logging to console & root terminals (bad idea!) - not controlling logging with the IPFIREWALL_VERBOSE_LIMIT
5.2. System Logging Configuration
5.2.1. Kernel Options
To Enable ipfirewall(4) logging in FreeBSD, one has to include at least the following option in the kernel (don't forget to reboot after you build the new kernel):
options IPFIREWALL_VERBOSE
In addition, one may wish to enable the following option:
options IPFIREWALL_VERBOSE_LIMIT=#
We have already mentioned this option early on when reviewing firewall activation. This kernel option limits the number of consecutive messages sent to the system logger, syslogd(8), concerning the activation of a given rule. When this option is enabled in the kernel, the number of consecutive messages concerning a particular connexion are capped to the number specified. For instance, consider the following:
options IPFIREWALL_VERBOSE_LIMIT=10
With this, only 10 consecutive messages concerning a particular connexion would be logged to syslogd(8), with the remainder being subsumed under a general statement like:
Jan 29 03:26:55 myserver last message repeated 45 times
These messages are generally logged to /var/log/messages in addition to the console. If one wishes to modify this behaviour, one will have to edit the /etc/syslog.conf. syslog.conf(5) offers considerable flixibility in how syslogd(8) will deal with system messages. The limit which one defines for IPFIREWALL_VERBOSE_LIMIT is up to the administrator, but values above 10 or so on a busy server may still sorely populate the console. On the other hand, if one wishes to disable kernel messages to the console altogether and log everything to a separate file (not the default /var/log/messages) this can be done also. Indeed, in this configuration, one need not specify IPFIREWALL_VERBOSE_LIMIT at all if one is certain that HD space is sufficient and log rotation will keep things tidy.
5.2.2. Configuring syslog(8) for Logging
One can setup syslogd(8) to log ipfirewall(4) messages to a separate file in three relatively simple steps:
1) Create your log file, and alternative, log directory. For instance, if you wish to have all of your ipfirewall(4) logs in /var/log/ipfw/ , create the directory, and then inside, create the log file. You may call it ipfw.log, for instance. You can easily do this with the touch(1) command:
Make sure the directory and file are not world-readable so other users can not poke around.
2) Configure syslog.conf(5) to send ipfirewall(4) messages to /var/log/ipfw/ipfw.log. In its most basic configuration, this can be done easily by added the following two lines to the bottom of syslog.conf(5).
!ipfw *.* /var/log/ipfw/ipfw.log
Make sure that you use tabs and not spaces in this file. Although tabs are not required in FreeBSD for syslog.conf, it is good practice in case you work with other UNIX systems, which may not accept spaces in their syslog.conf(5). So, eventhough you can ignore the scary message at the top of /etc/syslog.conf, it is wiser to obide by it for the sake of maintaining a safe habit.
One should note that the "last messages repeated #" messages will be logged to this file and also any other file that is specified in syslog.conf(5) to log *.err, kern.debug, *.notice messages, and so on. In addition, the console will always receive these messages as defined by:
Remember, the the console is ttyv0 (ALT + F1). Messaging to virtual and pseudo terminals will behave differently. Virtual and psudeo terminals are controlled by the following lines in the default syslog.conf(5):
Both lines that contain *.err and *.notice will log kernel messages concerning rule matches to the terminal on which the user specified to the right is logged in. Notice that this user is root; the best way to avoid annoying messages is to not log in as root constantly. Logging in as root and su'ing will not save you from the messages, either. It is strongly recommended that these lines not be commented out - having such messages logged to any terminal in which root is logged in is very useful as a quick notification of something possibly wrong happening. Indeed, you may wish to log these or other messages to other UIDs that you use often. Instead setup your rules appropriately so only important rule matches are logged and log in with your personal account, not root. Keep a spare virtual terminal logged in as root and check it occasionally.
To sum up, when dealing with syslog.conf(5) configuration and terminal notification:
- Add the two aforementioned lines in syslog.conf(5) to log rule matching messages to a separate file for easy examination at a later time. - Do not worry about root terminal messages, instead do not do your normal activity as root. This is a good all-around piece of security advice. Instead, keep a spare terminal logged in as root and check it occasionally.
3) Send a Hangup signal to the syslogd(8) process. The easiest way is with the following command:
(root@nu)~># killall -HUP syslogd (root@nu)~>#
5.2.3. Configuring newsyslog(8) for Log Rotation
Now that ipfirewall(4) logging is enabled, one should consider configuring newsyslog.conf(5) so that newsyslog(8) rotates your ipfirewall(4) logs; or, alternatively, use some other log rotation mechanism. For a full explanation of all possibler configuration options one should consult the newsyslog.conf(5) man page, however, the following entry should suffice for most occasions (in this example, we are using the example log file name as was presented earlier):
/var/log/ipfw/ipfw.log 600 10 * $W0D2 Z
This entry can be added to the bottom of newsyslog.conf(5). The first part is self-explanatory. The second comprises the permission bits for the rotated file The third the number of log files to keep rotating back until the oldest is deleted. The fourth is a wildcard instead of a specific size which to use as a signal to rotate the files. The fifth part is the time at which to rotate the logs, and the sixth is a special option. As one may have already surmised, log rotation can be done by one of two criteria: size, and time/date. We can specify to rotate a certain log based on when it reaches a particular size, or instead, based on what time/date it is. In the above entry, we used the time/date criterion. We specified to rotate the log at 2 AM every sunday morning, and then to gzip(1) the archive (the Z option), only allowing for a 10 archive history (10 weeks). If one wishes to hold their logs longer than this, one need only change the third parameter from 10 to whatever they like.
Once newsyslog.conf(5) has been configured, log rotation is all done. Because newsyslog(8) is a program run from cron(8) there is no daemon that needs to be sent the Hangup signal as was necessary for syslogd(8). There are other ways of enabling log rotation. One can write and run one's own log-rotation script, or use a friend's that you've been impressed with. Either way, it is important that on such potentially large log files, there be some method of archiving and controlling their growth.
5.3. Rule Logging Configuration
Once the system is fully configured to handle the ipfirewall(4) logging, we can begin specifying which rules, when matched, should be logged. There are two simple parameters to be used in conjunction with rule formation to enable logging for the given rule; they are:
"log" - Logs everytime the rule containing this keyword is matched by a packet. The keyword, if present, must follow the "action". Make sure you do NOT put this in wide sweeping rules such as:
add 0500 allow log all from any to any
Unless there is some extensive filtering occuring prior to this rule, most traffic will be matched to it and one's log files will grow very large very fast. On the other hand, it could well be safe to enable logging on a sweeping deny rule such as:
add 65000 deny log all from any to any
This rule is much safer because it is both near the end (rule # 65000 versus 500) and in rulesets that fulfill a closed firewall policy, there are generally many rules prior to the last deny rule that allow through important traffic, which should comprise much of the total traffic experienced, except in unusual circumstances - although it can still be risky. Take careful consideration into which rules should be logged and which shouldn't.
"logamount " - This parameter, following the "log" parameter, specifies the maximum number of matches that a rule can experience before logging halts. This gives the administrator some extra control over logging. If, for instance, he enables 10000 matches for a given rule, and then reset the counter once a day, he can alleviate potentially large logs if someone tries to flood the server and is blocked by the given rule. After 10000 matches, the logging for that rule will stop, and the flooder's attack will not swell the log file. Alternatively, one may wish to log *everything* and not use this parameter. In FreeBSD 4.x, 3.4+, and 2.2.x this is allowed, however, in earlier versions of FreeBSD 3.x, if this keyword is not used, a default "logamount" is set to 10.
When rules are logged, the following information will be saved:
- Date & Time - Rule number - Action - Source & Destination IP addresses - Source & Destination Port numbers - Direction flow - Device over which this occured
For instance, a firewall log line may look like this:
Jun 12 13:55:59 mybox1 /kernel: ipfw: 65000 Deny TCP 172.16.0.1:62307 192.168.0.1:23 in via xl0
6. Introduction to Stateless and Stateful Filtering
Stateful and stateless filtering are two terms often encountered in debates between proponents of ipfilter and ipfirewall(4). Stateless filtering treats each packet going through it as an individual that has no association with the other traffic going through the given interface. This type of filtering is easier to implement and can be used effectively to:
- filter corrupt (fragmented) packets - filter particular protocol packets (icmp, udp, igmp, etc) - do host-based filtering (filtering according to where a packet is destined, or where it came from)
Stateful filtering is more complex to implement. It treats traffic not as an aggregate of individual, independent packets, but as composed of connexions. All communication via any of the protocols uses sequence numbers to indicate in which order packets should be read on a socket(2). A stateful firewall would be aware of these sequence numbers. Connexion oriented protocols such as TCP also have special packets which indicate connexion initation (SYN) and termination (FIN), and a stateful firewall would also be aware of these. In short, it would:
- know what state a connexion is in - be able to determine if a connexion is following valid proceedure, or is breaking the rules, and would be able to filter the packets in these connections accordingly.
Stateful firewalls create dynamic rules for live connexions, and clear out these rules when the connexions time out. All of this allows for a more intelligent awareness of the higher level activity of network traffic by the firewall. On the downside, statefull firewalls are unable to treat each packet individually, because special dynamic rules are built to allow entire connexions through, precluding the examination of packets in those rules except in the context of whether they are behaving properly in the overall connexion. As such, it is wise to mix and match stateful and stateless rules in any firewall configuration, so one is able to benefit from both.
Almost all of the example rules that have been given so far have been stateless. The only exceptions are the rules concerning the option "tcpflags," "setup," and "established" which allow one to check the state of a TCP connexion. Indeed a combination of these will be used in the first stateful ruleset examples shortly. Using these options to make primitive stateful rulesets has been functionality that has been available in ipfirewall(4) for a long time, however, because of its very limited stateful capabilities, ipfirewall(4) has long been regarded as a stateless firewall, with IPFilter the stateful alternative. Starting with FreeBSD 4.0, ipfirewall(4) has been enabled with more extensive stateful functionality, with more promised to come.
6.1. Basic Stateful Configuration
For our first example, we will use the older, more basic, stateful capabilities of ipfirewall(4). Many people, following after the example in ~rc.firewall, where all of the pre-defined rulesets use this most basic of stateful functionality, make heavy use of the "setup" and "established" keywords for controlling TCP connexions. Indeed, this can only be used to control TCP connexions in a stateful manner, showing its limiting nature on at least one count. In our example, we will create a simple stateful firewall rulest that only allows ssh connexions through:
add 1000 allow tcp from any to any established add 2000 allow tcp from any to any 22 in setup
Presuming a closed firewall policy (firewall_type is NOT "OPEN" and kernel does NOT have IPFIREWALL_DEFAULT_TO_ACCEPT set) the above two lines will first allow all established TCP connexions to pass through. Specifically, any packets part of an established TCP connexion will match rule 1000 and then ruleset searching will cease for those packets. If, on the other hand, any packet is not part of an established TCP connexion, rule 1000 will not match it, and ruleset analysis will move to rule 2000, where, if the packet is a SYN TCP packet destined for port 22 (port for ssh), the rule will match it and and let pass. Subsequent packets for that connexion will be passed with rule 1000. In this manner, the above rules are stateful as they are aware of the existence of a TCP connexion at large and not just individual packets. One could have easily accomplished the same with stateless rules; for instance:
add 1000 allow tcp from any to any out add 2000 allow tcp from any to any 22 in
In this example, all packets moving out from any to anywhere are allowed to pass through the firewall, and all packets moving to port 22 of anywhere from anywhere in, are passed through. In this case, the rules are not aware of the TCP connexions - they do not test for initiation and established TCP connexions, but instead, let all TCP packets move out, no matter what they are, and let all TCP packets in to port 22, no matter what they are.
This is the essence of stateful behaviour in ipfirewall(4) using the "setup" and "established" flags: pass through TCP setup requests to specified addresses:ports and then let these established connexions through.
Let us look at a more involved example that handles ssh, email, FTP, and DNS queries for network 172.16.0.0/27:
add 1000 allow tcp from any to any established add 2000 allow tcp from any to 172.16.0.0/27 21,22,25 setup add 3000 allow udp from 172.16.0.0/27 to any 53 add 3100 allow udp from any 53 to 172.16.0.0/27
In this example, setup of TCP connexions is allowed for ports 21, 22, 25 - FTP, ssh, and email respectively, when packets are destined for the 172.16.0.0 network. Afterwards, all established TCP connexiond are allowed to pass. Rules 3000 and 3100 pass UDP packets to port 53 on other hosts and allow UDP packets from port 53 on other hosts to pass in through the firewall. Both of these rules are stateless. Port 53 is the port on which DNS servers run. Rule 1000 must have "from any to any" because TCP packets for established connexions must be allowed to both originate from anywhere and to arrive at anywhere.
If one was to write a similar ruleset which was completely stateless, one would have to keep most TCP ports between 1024 and 65000 open for FTP connexions. FTP is definitely a wild protocol as it randomly binds to non-reserved ports across a wide range. Allowing active FTP through a firewall is always difficult; only stateful firewalls offer a really clean approach to it, without opening massive ranges of ports. Most notably the shortcoming of opening the ports with a stateless firewall is that anyone can attempt to connect to any port within that range. With our setup, only TCP connexions that had been initiated through rule 2000 can be let through with the "established" option in rule 1000, effectively limiting random and uncontrolled connexions to the wide range of ports needed for clean active FTP operation.
6.2. Advanced Stateful Configuration
As has been stated before, stateful firewall configuration with just the "setup" and "established" options is very limiting. Aside from only allowing stateful control over TCP connexions, this stateful control is simplistic at best. Starting with FreeBSD 4.0 the stateful capabilities of ipfirewall(4) have been greatly augmented. Now, ipfirewall(4) can be configured for stateful handling of TCP, UDP, ICMP and other packets types with use of dynamic rules.
Dynamic rules are another new addition to ipfirewall(4) in FreeBSD 4.0. Dynamic rules, as the name suggests, are dynamically generated for individual connexions. Each dynamic rule, after lack of use past a period of time, times out. The specific timeout period for TCP connexions can be controlled by several(8) sysctl variables. This allows control of not only connexion initiation, but connexion termination; that is, in a manner of speaking, a ruleset can be designed which is aware of the beginning end ending of a particular connexion, and that adjusts it
> cat /etc/rc.firewalls/rc.firewall # Simple stateful network firewall rules for IPFW with NAT v. 1.01 # See bottom of file for instructions and description of rules # Created 20001206206 by Peter Brezny, pbrezny@purplecat.net (with a great # deal of help from freebsd-security@freebsd.org). Specific questions # about the use of ipfw should be directed to freebsd-ipfw@freebsd.org or # more general security questions to freebsd-security@freebsd.org. # Use this script at your own risk. # # if you don't know the a.b.c.0/xx notation for ip networks the ipsubnet # calculator can help you. /usr/ports/net/ipsc-0.4.2 # ########################### # # Brief Installation instructions # # Name this script /etc/rc.firewall.current # Edit /etc/rc.conf to include # gateway_enable="YES" # firewall_enable="YES" # firewall_script="/etc/rc.firewall.current" # natd_enable="YES" # natd_interface="***" #replace with your external ifX # natd_flags="-dynamic" # Make sure your kernel is configured to handle ipfw and natd # See the FreeBSD handbook on how to do this. # ############################ # # Define your variables # fwcmd="/sbin/ipfw" #leave as is if using ipfw oif="out" #set to outside interface name onwr="IP:SM" #set to outside network range oip="IP" #set to outside ip address
iif="in" #set to internal interface name inwr="IP:SM" #set to internal network range iip="IP" #set to internal ip address
ns1="4.2.2.1" #set to primary name server best if = oif #ntp="i.j.k.l" #set to ip of NTP server or leave as is
# # End of required user input if you only intend to allow ssh connections to # this box from the outside. If other services are required, edit line 96 # as necessary. # # Rules with descriptions # # # Force a flush of the current firewall rules before we reload $fwcmd -f flush
# Allow your loop back to work $fwcmd add allow all from any to any via lo0 # # Prevent spoofing of your loopback $fwcmd add deny log all from any to 127.0.0.0/8 # # Stop spoofing of your internal network range $fwcmd add deny log ip from $inwr to any in via $oif # # Stop spoofing from inside your private ip range $fwcmd add deny log ip from not $inwr to any in via $iif # # Stop private networks (RFC1918) from entering the outside interface. $fwcmd add deny log ip from 192.168.0.0/16 to any in via $oif $fwcmd add deny log ip from 172.16.0.0/12 to any in via $oif $fwcmd add deny log ip from 10.0.0.0/8 to any in via $oif $fwcmd add deny log ip from any to 192.168.0.0/16 in via $oif $fwcmd add deny log ip from any to 172.16.0.0/12 in via $oif $fwcmd add deny log ip from any to 10.0.0.0/8 in via $oif # # Stop draft-manning-dsua-01.txt nets on the outside interface $fwcmd add deny all from 0.0.0.0/8 to any in via $oif $fwcmd add deny all from 169.254.0.0/16 to any in via $oif $fwcmd add deny all from 192.0.2.0/24 to any in via $oif $fwcmd add deny all from 224.0.0.0/4 to any in via $oif $fwcmd add deny all from 240.0.0.0/4 to any in via $oif $fwcmd add deny all from any to 0.0.0.0/8 in via $oif $fwcmd add deny all from any to 169.254.0.0/16 in via $oif $fwcmd add deny all from any to 192.0.2.0/24 in via $oif $fwcmd add deny all from any to 224.0.0.0/4 in via $oif $fwcmd add deny all from any to 240.0.0.0/4 in via $oif
$fwcmd add deny any from 66.216.74.58 to any # # Divert all packets through natd $fwcmd add divert natd all from any to any via $oif # # Allow all established connections to persist (setup required # for new connections). $fwcmd add allow tcp from any to any established # # Allow incoming requests to reach the following services: # To allow multiple services you may list them separated # by a coma, for example ...to $oip 22,25,110,80 setup $fwcmd add allow tcp from any to $oip 22 setup # the above line is the line that allows you to open ports to connect to your box, in this example port 22 is open for connections (SSH port) # # NOTE: you may have to change your client to passive or active mode # to get ftp to work once enabled, only ssh enabled by default. # 21:ftp # 22:ssh enabled by default # 23:telnet # 25:smtp # 110:pop # 143:imap # 80:http # 443:ssl # # Allow icmp packets for diagnostic purposes (ping traceroute) # you may wish to leave commented out. # $fwcmd add allow icmp from any to any # # Allow required ICMP $fwcmd add allow icmp from any to any icmptypes 3,4,11,12 # # Allow DNS traffic from internet to query your DNS (for reverse # lookups etc). $fwcmd add allow udp from any 53 to $ns1 53 # # Allow time update traffic # $fwcmd add allow udp from $ntp 123 to $oip 123 # # Checks packets against dynamic rule set below.
$fwcmd add check-state # # Allow any traffic from firewall ip to any going out the # external interface $fwcmd add allow ip from $oip to any keep-state out via $oif # # Allow any traffic from local network to any passing through the # internal interface $fwcmd add allow ip from $inwr to any keep-state via $iif # # Deny everything else $fwcmd add 65435 deny log ip from any to any # ##################################################### # # End firewall script.
I use my gateway as a central storage device, it dosnt have as much space as id like with only 130G but its currently doing a fine job of holding every episode of southpark, family guy, quite a few futarama eps, around 8 classic movies (office space, fear and loathing) and over 7500 mp3's (soon to be adding another 65 full cds). Ive got NFS and samba (for my brothers machines) to share the above, samba is an awsoem bit of software enabling almost all of the windows networking features like PDC's and now active directory.
A home load on a freebsd box is nothing, ive been up for almost 100 days (the only thing impressive about this uptime is the power grid going this long without a problem =P) with no problems (except the power around here sucks and i dont have the cash to spend on a UPS) I setup a box over at a friends house for the same purpose is been crankin along for well over 3 years now with no problems.
Ive never had a computer infected by any of the latest viruses, theyve all been shot down at the firewall, and ive tought everyone in my family to never even look at messages with attachments as email was never ment to handle attachments any damn way and still shoudlnt. but thats an entirely different rant.
Id highly recomend FreeBSD for this job. IIRC the *BSDs are supposed to be the most secure out-of-box operating systems.
Perhaps a link for post 2 would have been sufficient?
-------------------- You cannot legislate the poor into prosperity by legislating the wealthy out of prosperity. What one person receives without working for another person must work for without receiving. The government cannot give to anybody anything that the government does not first take from somebody else. When half of the people get the idea that they do not have to work because the other half is going to take care of them and when the other half gets the idea that it does no good to work because somebody else is going to get what they work for that my dear friend is the beginning of the end of any nation. You cannot multiply wealth by dividing it. ~ Adrian Rogers
Thanks for the help. Sounds like I could do it without shitting it up too much.
-------------------- at this point i think we can be relatively certain seperation exists as a fallacy of finite perception, and the only barrier to infinite creativity is a preimposed notion of certainty and artificial conditioning. nothing is without origin
having info in more then one place never hurt anyone... at least its something relevant and provides info rather then something assinine like having a couple dozen blank lines with an attempt to fool someone by trailing the message down to a section that must be scrolled down to get the rest of of or two .sig images.
Its not as hard as it seems, I can get a firewall setup and running in about 45 minutes, including installing the OS, but not including the kernel comile time, its not my fault it takes so long for the kernel to compile now is it? (with compile on a amd k6-2 500 with 128mb ram is ~30 minutes extra)
Install Slackware (yawp its free, or linux distro of choice) and setup Iptables w/ some IDS (intrusion detection system) such as Portsentry...
Remember to strip down the distro and only install modules, etc., needed for firewall or routing. (unless you going to actually use the box for something besides routing/firewall)
Get a good book (think Box Toxen: Real World Linux Security) or look up online how to set firewall rulesets for iptables if you dont wan't to use an IDS. Also, look up rulesets for Masquerading (if you want to share Internet with people on your LAN).
Wanna be lazy? You can buy Norton Firewall or some other winblows software to monitor and route traffic, might be easier. Just google it my friend.
Always remember to RTFM... :-D
All done...
Dont' know if that helped much but just watned to give you an overview. Use the power of the search engines to delve into it more.
Have fun!
-------------------- -------------------------------------------------------------------------------- You laugh at me because I'm different. I laugh at you because you're all the same. --------------------------------------------------------------------------------
You cannot start new topics / You cannot reply to topics HTML is disabled / BBCode is enabled
Moderator: Enlil, Alan Rockefeller 2,229 topic views. 0 members, 0 guests and 1 web crawlers are browsing this forum.
[ Show Images Only | Sort by Score | Print Topic ]