how-to block ads
|
| | | | FAQ Revisions | Editors: yock  , No_Strings , Zuhaib , adsldude , FastEddie
Last modified on 2008-01-24 14:55:55
| |
|
|
3 BSD·What is BSD?
·What are the different types of BSD?
·What are the differences between the different BSDs?
·Where can I download BSD?
·How do I set up my FreeBSD box to act as router without using a second NIC?
·How do I set up firewalling using FreeBSD?
·How do I configure a packet filter using ipf?
·How do I setup OpenBSD as a cable NAT system?
| | | BSD (originally: Berkeley Software Distribution) refers to the particular version of the UNIX operating system that was developed at and distributed from the University of California at Berkeley. "BSD" is customarily preceded by a number indicating the particular distribution level of the BSD system (for example, "4.3 BSD"). BSD UNIX has been popular and many commercial implementations of UNIX systems are based on or include some BSD code.
 show feedback form
 close
by howe81 | | | There are four different types of BSD UNIX that comes in mind. These are:
show feedback form
close
by howe81
last modified: 2004-02-14 20:39:15 | | | To help you answer this question, there's a link to The BSD Family Tree thanks to meowbot.
show feedback form
close
by howe81 | | | FreeBSD, NetBSD and OpenBSD could be downloaded from their respective sites.
FreeBSD and NetBSD could also be found at Linuxiso.org.
show feedback form
close
by howe81 | | | If you don't want to purchase a second NIC, you'll have to bind two IP addresses to the same interface.
Suppose you have a single IP from your ISP. Let's say it's 192.168.1.1. Suppose your internal network uses the IP range 10.1.1.0 - 10.1.1.255 exclusive. The single NIC in your system is device "ep0".
In your /etc/rc.conf you would have:ifconfig_ep0="inet 192.168.1.1 netmask 255.255.255.0"
ifconfig_ep0_alias0="inet 10.1.1.1 netmask 255.255.255.0"
gateway_enable="YES"
router_enable="YES" You would then plug everything, your DSL router/bridge, all your internal network, and the FreeBSD box into the same hub. Set up your internal network (10.1.1.x) to use 10.1.1.1 as their default gateway.
This setup is not secure if you don't set up ipfw or similar. After you have filtering configured and enabled, you should be secure if you have a routed connection to the Internet. You could theoretically have trouble if your connection is bridged, or if you have a cable modem. It really depends on the characteristics of your internal network. You'll probably need NAT as well.
Note: I tested this on FreeBSD 3.4. The 4.x series should be the same, but your mileage may vary.
show feedback form
close
by Eatmeingreek edited by howe81 | | | A very useful site on how to configure a firewall in FreeBSD can be found here. Another useful link can be found at O'Reilly's Network.
show feedback form
close
by howe81 | | | OpenBSD has an excellent section in its FAQ on pf (OpenBSD uses pf now - it's similar to ipf.) The pf FAQ section can be found here:
»www.openbsd.org/faq/pf/index.html
show feedback form
close
by Eatmeingreek edited by howe81
last modified: 2003-12-17 03:57:39 | | | The following information was found from BSD Today to help users using OpenBSD on setting up an NAT system.
By Vlad Sedach
The first thing I did upon getting cable modem access in my apartment was to get an old Pentium 133 computer, put in two NICs, and fire up the OpenBSD 2.7 boot floppy. I did this for several reasons: first, because I heard that OpenBSD runs as a fast network node even with old hardware; and second, because I knew that it was probably the most secure operating system I can get in that price range. While some people may view OpenBSD security as overkill for a simple home cable modem setup, upon closer examination I found that OpenBSD's secure upon install feature did save my butt more than once; right now, the logfiles show that (literally) not an hour goes by without my system being scanned by someone on the internet.
I had a previous experience with installing OpenBSD a while back (release 2.4 I think), and although it had gone successfully, I did not use it for anything and must have promptly deleted it not too long afterwards. I went over to OpenBSD's site, downloaded the floppy image, put it on a floppy, and booted. The kernel saw both my network cards (a 3c509 for the cable modem and an Intel Etherexpress Pro for the network), and detected my ide drives without problem. I choose the install option, and managed to get through partitioning my harddrive into one big chunk without a problem. Next onto the network configuration. OpenBSD was able to fetch DHCP information from my cable modem hooked up to the 3c509 flawlessly, and I quickly configured the Intel interface card with the static address of my private network.
I choose ftp install (ahh, finally the joys of cable :)) and picked out the server offered closest to me from the list of mirrors. As this box would run headless, I choose the minimal install configuration (required files and development tools to build packages, no X here!), and proceeded to download them. The downloading went by quickly, and being outside the US, I then chose to install the international version of the SSL package. I then finished off the install with some quick configuration options, and rebooted.
To my amazement, the system booted fine, and gave me the login prompt. I logged in as root, and the system gave me a nasty message not to log in as root but to use su instead. That was the first thing I went about doing; after adding a regular user account and noticing that in fact it did not let me su, I reconfigured the account (through vipw, editing the password file directly will not produce any results), but still had no luck. A quick trip to the OpenBSD FAQ revealed that I also had to add this user to the list in /etc/group. Having that done, I then proceeded to check that both network interfaces were running fine (they were), and set up SSH for remote logins. I went to /etc and looked around for ssh config files -- /etc/sshd_config is the file where the ssh's server configuration is stored. I set the ListenAddress option to the IP address of the interface that would be serving my internal network (remember, we don't want anyone having any type of access to this box), and then disallowed remote root logins. I ran to my other workstation and tried to get in -- bingo, it worked! Form this point on, I would do everything on the box remotely.
The first thing I did after that point was to try to set up Network Address translation for the rest of my lan. Being familiar with doing that on a Linux box with a dial-up link, I looked for familiar tools. ipchains wasn't there, and neither were the slackware config files. Once again I hit the OpenBSD FAQ. Upon reading it, I changed my /etc/rc.local file to start up the NAT and IP Filtering services on bootup (change the ipfilter= and ipnat= lines to YES). Because I used the GENERIC kernel that came with the installation, I also had to enable ip forwarding in the /etc/sysctl.conf file (change the net.inet.ip.forwarding= from a 0 to a 1). I then edited the /etc/ipf.rules file to pass in packets from both sides to see how it would work. My /etc/ipf.rules looked like the following:
pass in from any to any
pass out from any to any
Next, I had to edit the /etc/ipnat.rules file to set up the NAT rules (a simple syntax is map [outside interface] [internal network/netmask (in CIDR format - 255.255.255.0 corresponds to a 24)] -> [name of outside interface OR ip of outside interface/netmask] ). My /etc/ipnat.rules looks like the following:
map ep0 172.16.10.0/24 -> ep0/32 portmap tcp/udp 10000:20000
map ep0 172.16.10.0/24 -> ep0/32
For some reason, the two of those lines are necessary to get things working.
After that, I rebooted the machine, changed the settings on my client (specifically, you have to put the IP of you OpenBSD NAT box as the default gateway in the TCP/IP properties of the network nodes), and (to my surprise) was surfing from my network. Upon testing out the network services, I discovered that I could not download anything from ftp sites from my client machines, while I could fine from my OpenBSD box. The problem was that the NAT box does its address translation by taking packets from the network from a specific IP address and passing them through an available port on the outgoing interface (the range of those usable ports is specified in the first line of the above example), and then passing the returning information back to that IP address. However, ftp data is downloaded at a random port chosen by the server, and as the NAT box has no knowledge that the incoming traffic is destined for a particular host on the network, it does not forward it to those hosts. A solution was once again offered in the FAQ in the form of an extra parameter in the /etc/ipnat.rules file:
ap dc0 192.168.1.0/24 -> 24.5.0.5/32 proxy port ftp ftp/tcp
The above code was supposed to trigger a built-in ftp proxy that would remedy this situation, but alas, for some reason it did nothing to help in my case. The only solution I had left was to configure all my ftp clients to use passive mode, which used a predetermined port for sending data to the client. While not user friendly (and I found that not all clients supported this), this solution worked.
Next came the job of making the box as secure as possible. The first thing I did was to disable the loading of the inetd daemon in the /etc/rc.conf file (change the line inetd=YES to a NO). Since I would be sending mail from my clients using my ISP's mail server, I also disabled sendmail. Next, I set up a better IP Filtering scheme; while allowing all packets to pass out (as I had before), I looked at the OpenBSD FAQ and in the /usr/share/ipf directory which contained several sample files for the IPFilter and IPNAT. I came up with the following basic ruleset:
#This is to stop ip spoofing ( packets coming in from the internet
should not have my network's ip address in them)
block in log on ep0 from 172.16.10.0/24 to any
block in log on ep0 from localhost to any
block in log on ep0 from 255.255.255.255/32 to any
block in log on ep0 from 0.0.0.0/32 to any
#the following rules are to stop icmp packets from reaching the
#OpenBSD box
block in on ep0 proto icmp from any to any icmp-type redir
block in on ep0 proto icmp from any to any
block in on ep0 proto icmp from any to any icmp-type echo
#the following rule is to still allow icmp replies through to the
#internal network
pass in log quick on ep0 proto icmp from any to 172.16.10.0/24 icmp-type echorep
#the following is to drop short packets
block in quick proto tcp all with short
#drop source routed packets
block in quick on ep0 all with opt lsrr
block in quick on ep0 all with opt ssrr
#block in connections to local services
block return-rst in log quick on ep0 proto tcp from any to any flags S/SA
Notice that this ruleset is focused on denying specific instances rather than denying everything and then allowing the necessary stuff in. I did this because I wanted an extra degree of flexibility with my setup, as I would also run an ftp and a www server from behind the NAT box (see the OpenBSD FAQ for info on how to do that). A much better general rule that would suit most users would be:
block in on ep0 from any to any
Now that IP Filtering is set up, you're pretty much set. However, the truly paranoid (and those with a bad IP Filtering policy like mine :)) will want to set up a good network logging facility. I went to freshmeat.net and found iplog. The app seemed to fit my needs, and I downloaded and compiled it without a problem. I set up a configuration file where I would log ICMP and UDP traffic to a separate logfile. After letting it run for a couple of hours, the results were surprising (especially when I turned off the ICMP blocking rules in my /etc/ipf.rules file). I was getting scanned periodically, at least every hour, from hosts from every variety of ISPs (today, I even found a .mil domain in the logfile!). For any one out there that is wondering, my cable provider is @Home.
While iplog suited my needs, there are plenty of other logging utilities out there. Some users might be interested in looking at PortSentry (port scan detection tool) and Logcheck (logfile auditing software) from Psionic Software (www.psionic.com -- the tools are free and come with source code). Portsentry was featured in this BSD Today article: »www.bsdtoday.com/2000/July/Features233.html.
Although it may seem to complicated or powerful as a simple NAT gateway for a home cable installation, OpenBSD makes a really ideal platform for such a task, not only because of its flawless performance and solid security, but also (as the author learned) relatively painless setup and good documentation.
Comments should be made here.
show feedback form
close
by howe81 |
|
