Small networks on OpenBSD
Original: Jacek Artymiak
Translation: Useless
This translated document is an isfocus.net production. The Copyrights of the Original Articles Belong to Jacek Artymiak.
Like other things in the world, good security construction needs a lot of money. The truth is actually very simple, because now there is no so many technically superb security experts to take care of our unbearable network. An unfortunate result caused by the shortage of talents is a high unbearable expert commission. This issue gives some small networks to a group of network administrators who don't have much experience. These administrators may not know how to design, configure and monitor hosts in the network, so that these defective hosts are always those on the network. Try to find internal information, free storage space or threat to the invasive person used for DDOS.
Fortunately, there are many good hackers on the Internet to make a lot of excellent security products for network management. This article is an overview of how to use a separate private network / DMZ design and run a small network, which will allow administrators to provide some services to the external network while enabling their users. The implementation and management of this design is quite easy, even if beginners can be easily mastered, and it can also serve as a fundamental security configuration for the security company. I. Design section
Our goal is to achieve maximum protection against external attacks. At the same time, we don't want to spend a lot of money, so that the software we use can only be limited to software or free software that open source code. This is not as bad as it sounds, because most of the free operating systems have almost all have a network security software that meets a small business standard. At the same time, many free security solutions can be found in some commercial products.
In order to make things more simple, we first assume that the network we will build has only one connection to the Internet, and it only has more than ten internal users. Of course, you can always make it smaller or bigger according to your own wishes. This is only to add faster hardware, planning networks into many smaller networks to eliminate bottlenecks, and even add more external connections.
The easiest design is too much to use the firewall to protect the internal private network to build and maintain this network. If there is any external connection, this network is called a non-military zone (DMZ), we need Build it with some external open services while simultaneously using the same firewall to protect the separated network. These services can be DNS, WWW, Mail, FTP, or NEWS, but you completely free to limit or add any other services. DMZ can include a host or many hosts that do you want this network to be complex.
All data streams in our network will be inspected and filtered by firewalls, and these three network interfaces are required on several respective hosts:
· Interface A connect firewall to the Internet. The IP address of the interface will be allocated by ISP (X.x.x.x will be used herein).
· Interface B connect firewall to internal private networks. The IP address of this interface in this article will be 192.168.1.1.
· Interface C connects the firewall to the DMZ network. The IP address of this interface in this article will be 192.168.2.1.
The probably contour of our network is displayed in Figure 1:
Figure 1. The outline map of the network described herein. The firewall will use the following rules to control the data stream:
1. All packets from internal dedicated networks to all legal addresses can have no restrictions through the firewall. (If necessary, this rule can do a bigger limit)
2. All packets sent from the Internet to a private network should be filtered, and only those requested packages that originally sent from the internal private network should be allowed to enter the dedicated network. 3. All packets sent from the Internet to the DMZ should be filtered, only gives the packets that are sent to our services to the Internet can pass the firewall. In addition, a valid response package initially requested from the DMZ is also allowed to enter DMZ. (If necessary, this rule can do a bigger limit)
4. Effective response package for request packets initially sent from internal dedicated networks to DMZ should allow access to private networks.
5. All packets sent from DMZ to the Internet (this does not include) on the DMZ, should pass through the firewall without any restrictions. (If necessary, this rule can do a bigger limit)
6. All other data streams should be discarded.
In addition to the above-mentioned packet filtering rules, we need a way to let our services run on the host in the DMZ. We can run these services on the host of the firewall, but there will be a lot of troubles if we do it, the more services we loaded on the firewall, the firewall will become more weak. We will flow through the relocation data to DMZ so that we actually move the potential attack target from the firewall to DMZ. In this case, if an attacker attacks our network, they are attacking the host in DMZ, and they want to attack the entire internal network, but also invade the firewall and the remaining network, which will slow intruder speed, thus The entire network is safer. (The host responsible to redirect packets is sometimes referred to as port forwarding).
Because the general small network usually only has a separate IP address allocated by their ISP, the firewall also needs to run some "camouflage" software, which makes all data flows from the internal network and DMZ as if it is from one host Like it. This is another security means that makes our network more difficult to break, because the IP address of the machine behind the firewall will never be displayed to the outside.
You can filter packets, redirect data to other addresses and free firewall products that implement IP address camouflage have IPFilter, IPFW, Ipchains, and iptables. The front two packages are used for BSD families, and then two are widely used in the Linux operating system.
II. Select hardware and software
I have selected the firewall software used in this article is the Daren Reed IPFilter running on OpenBSD 2.8, IPFilter has NetBSD, Solaris, Sunos, BSD / OS, IRIX, HP-UX, and QNX versions. If you are using other firewall software, you have to remember to translate the firewall rules we have to say to the rules of the firewall you use. (General design principles will be the same in any case.) I chose IPFilter mainly four reasons. First, I know it very well. Second, it is tested repeatedly by 10 million programmers. Third, it is the default firewall for OpenBSD. Fourth, I like it simple syntax. IPFilter is equivalent to an easy operation, which can organize the requested packages sent by the internal users and their reply packages, and let them pass the firewall without the need to write some complex firewall rules. It has a simple packet redirection and address camouflage module, IPNAT.
As for hardware, the machine running IPFilter firewall software can be any operating system that supports OpenBSD or other IPFilter support version, such as NetBSD, as long as it provides at least three network interfaces (a connection Internet, a connection internal private network and another connection DMZ). My choice is an ordinary low-end Pentium processor computer, equipped with a serial port and a expansion slot that is idle on three motherboards. However, it can be just an alpha, sun, vax or host that meets the needs of our above. However, the hard disk of the host where the firewall is located at least 540MB. You can use IDE instead of SCSI, as long as the disk system does not install too much, as long as the host has a memory of 24MB. Another important part is a network interface card. Connect the internal network and DMZ to the interface card used on the firewall, I recommend a 10 / 100MB / One-second network card and RJ-45 slot for twisted pairs, these things are still new or Second-hand goods are very cheap. Other necessary connection devices include twisted pairs and 10/100 mB / s HUB with 10Base-T slots. (If the entire DMZ is on a machine, you can purchase two HUBs, one for internal private networks and the other for cross twisted pair.)
I recommend that you don't use a coaxial 10Base2 cable, and use twisted pair (and network card with RJ-45 slot), because the twisted pair device is more reliable, although they need a HUB to work . (On the common axis, an error will cause all the computers to connect to a cable that cannot access the network, and if an error occurs on the twisted pair, only one machine will be disconnected, other machines You can access the network normally).
It is also important to note that before you buy second-hand hardware in eBay or local old computer sales store, I suggest that you first go to the OpenBSD website and the software deputy installation instructions to find the hardware of the hardware you want to buy. In support hardware tables in OpenBSD. This step will save you a lot of trouble.
You have to go to the hardware of your hardware to find your hardware driver. Some hardware cannot be driven by its manufacturers, but can drive the driver of the chip used in this hardware.
The last important thing is the rescue dish of the DOS or Windows 95/98. Because I am not too clear, Microsoft is thinking about using the DOS or Windows boot disk, so I suggest you look for a legitimate DOS or MS Windows CD to the most ready, or go directly to buy an IBM DOS, it is best to download Freedos, a free DOS clone version. One, you have a DOS disk, create a boot disk, remove the programs inside, and put the required driver.
(Please note that you don't need DOS or Windows to install OpenBSD, this situation I said is that Windows is already the operating system in your computer.)
III. Installation
The installation process of OpenBSD is quite simple, you can find a detailed installation instructions in Part 4 of OpenBSD FAQ. In this way, I will not explain the settings, but I will mainly explain some questions that will make the first time the user who uses OpenBSD is confused:
SWAP minimum space (Minimum Amount of Swap Space): It is enough to use probably you RAM memory. If you are uncertain, you can use the split size list listed in the OpenBSD FAQ.
Large Disk Support: When the hard disk is unable to start, even if the system is installed is completely smooth, you also need to use a hard disk or computer manufacturer to make the hard disk changeable. Sometimes, especially when there is a very old BIOS, your system may not recognize the size of the hard disk. This problem should not affect the installation of OpenBSD, but after the installation is over, you must go to your computer or hard drive's website to download drivers or configuration programs to make the system work. If you have any questions, read the installation document, there are very detailed pounds to record some different ways to solve the problem of big hard disks. Network Interface Address: When the OpenBSD installer asks you about the network interface address, it is asking which interface you want to configure. Because we can configure it later, it is not very important to choose which one is. The only place to be the main place is that if you want to configure the interface to the Internet, you have to use your ISP to assign your IP address, and you should use an address to the network after the firewall, right The host connected to the Internet uses a reserved address. For example, if we use 192.168.1.x, then the interface to the firewall to the rest of the network should be set to 192.168.1.1, and set the interface connecting the firewall to DMZ to 192.168.2.1 (192.168.2.x is Other networks). You can't configure connections to the serial port because it requires another software (PPPD). However, we can complete this step again.
IRQ conflict (IRQ Conflicts): In order to avoid IRQ conflicts, we need to remove all unwanted hardware. The first one should be a sound card because there is no such thing on a computer used as a firewall. TV / broadcast, scanner controller, and other similar excess cards should also be removed. If your computer is already pre-installed, you only need a network card and SCSI control card. Of course, you need to leave a graphics card because we still have to look at the display during the installation process.
When you encounter a network card problem associated with IRQ, it is generally caused by two reasons. One is because the network card is used with other devices, because the conflict causes the system to detect the device. Alternatively, the NIC cannot be configured during the installation. If you have these questions, there is often a lack of connection to other computers (when testing private networks or DMZ using the ping command, the packet is 100% lost), "Device Timeout" information, or the system will crash during startup, etc. phenomenon. These issues can be solved simply with the appropriate network card formulation and user kernel configuration programs.
When this error occurs, start from the DOS or Windows boot disk, run the network card configuration program, turn off the automatic configuration, set the network media type to 10BASE-T, and select IRQ from the available interrupt list. Repeat this process in your system, exit the configuration program, restart to OpenBSD.
If your computer still has the same problem after passing through the above configuration, you will need to configure your kernel through UKC. You can enter the UKC console by two ways: When you start, enter boot -c in time when you see the boot> prompt, or enter the config -e / bsd as root. When you see the UKC> prompt, you can search for your device, add new devices, disable or start a device, and find the IRQ conflict between these devices. If you find the IRQ you selected for the NIC has been occupied by another device, you may need to disable that device, which is if it is not a system necessary. For example, I always disable the mouse on the firewall machine, because I will not use X Windows on that machine, so the mouse is completely unnecessary. Similarly, all audio devices should also be disabled because they have no effect on the firewall. When you find an available configuration, write it down and use config -e / bsd (using root identity) to build and save a new core to replace the default kernel (the backup of a default kernel is a good idea) . You can find some additional information in config manual (Man Config will become your good partner). IRQ related issues on the SCSI controller can also be solved with similar methods. For more information on UKC, please read the fourth quarter of OpenBSD F.a.q. The list of devices supported by OpenBSD can be found at http://www.openbsd.org/i386.html. In order to test if the NIC is working, you can connect the firewall to the private network and DMZ, and use the ping command to test any of these networks with any of these networks. If there is a long period of delay or 100% loss of packet, there is still a problem with the system.
Network Media Select Problem: These problems can generally be solved by two ways: configuring the card with the appropriate formulation program, or set the media selection option in the "host name .xxx" file (these files generally in / etc directory) solve. You can use ifconfig -a to check which interfaces in your system, this command displays a list of interface devices. You can then read some appropriate man-pages (for example, for the Ne card, reading man ne) and find out which option is responsible for media selection. If you can't identify network devices from the name, please read the Ethernet Adapters Section on the OpenBSD website. When you find the interface you want to configure, look for the "/ etc / hostname" file (for example: device NE1 /etc/hostname.ne1), if necessary, you can edit it. You may need to create this file, but every Ethernet interface should have such a file. (More information, you can read Hostname.if's manual).
When the installation ends and normally does not have any errors, the installed network card is properly identified, then you can start editing the following files (you must log in as root to edit the following files):
· / Etc / hostname. Device name - these files store some basic information that needs to be used to configure the network card. Every NIC should have such a file. You can learn more information in Section 5 of OpenBSD F.a.q and Man Hostname.IF. For example, a NE1 (NE1000 / NE2000 compatible) device that connects the firewall to the internal private network should be this:
· / Etc / hosts - This file is a hostname database prepared for the firewall, which contains all the firewall "knowledge" IP addresses or host name list, which should contain host names known in the internal private network and in DMZ and The list of addresses (a host may be in many networks, and have different hostnames and addresses), in our example, this list should contain 192.168.1.1 (internal private network) and 192.168.2.1 (dmz): 127.0.0.1 Localhost
192.168.1.1 FIREATER.FOO.com Fireater
192.168.2.1 fireball.bar.com Fireball
The firewall interface listed in / etc / hosts should be with the / etc / hostname. The IP address listed in the device name is the same. If the firewall is connected to the Internet via an Ethernet, the / etc / host should have another line to indicate the host name and IP address allocated by ISP. Remember to change foo.com and bar.com in these networks into actual domain names. These don't necessarily have to be registered domain names. I use two different domain names for internal private networks and DMZ because it helps me distinguish between two different networks, but you can of course only use one domain name (or you can use more than two domain names, completely by you).
· /Etc/resolv.conf - This configuration file should include the following lines:
Search foo.com
Nameserver 192.168.1.2
Lookup file bind
Search bar.com
Nameserver 192.168.2.2
Lookup file bind
Notice that I assume that domain name foo.com and Bar.com's Nameservers listened to 192.168.1.2 and 192.168.2.1, but your constructs may be very different, it should be changed according to your requirements.
· /Etc/rc.conf - The following options should be activated in the primary system profile:
ipfilter = yes ipnat = yes
After you have finished all these modifications, use the SYNC to restart the system; restart and check if those network interfaces are running correctly (send requests for internal private networks or DMZ using ping, if the report does not have any packet loss, it means normal). Remember If you connect the firewall to the network interface of the internal network plug in a serial interface, you need to configure the PPPD daemon (read Man PPP). The device name used in such an interface is TUN0. (You don't need to create a /etc/hostname.tun0 file for it).
Remember that you must configure other hosts on private networks and DMZ in a way to allow firewalls and other methods of smooth communication between internal dedicated networks, DMZ, and Internet. To do this, you should configure the TCP / IP protocol on each host on the internal private network, so that they use 192.168.1.1 to do their gateways, and give each machine an IP address in the same address space ( 192.168.1.2, 192.168.1.3, 192.168.1.4, and so on. Similarly, the machine in DMZ should be configured to use 192.168.2.1 as their gateway and give each machine a IP address from 192.168.2-192.168.254. In addition, each machine should be named a unique host name.
Once these work is completed, you should run an internal DNS server in a private network so that internal communication changes easier. All DNS configuration files should be listed on the private network and in the DMZ host. For security reasons, the machine in DMZ will not be able to access data in a private network (they completely disable any packets to private networks), but private networks need to access DMZ rights because users need simple upgrade on the WWW server Document, reading, and sending mail to other hosts on the Internet and using other services on DMZ. Iv. Configuring a firewall
Once you have set your OpenBSD system and network, you will need to configure the firewall. The firewall rules I have shown are very restrictive. Many administrators may not agree to this setting, but I would rather relax from the simplicity of starting, strengthening restrictions, and later relaxing these rules.
IPFilter can be divided into two modules: Network Address Translator, referred to as NAT, and Packet Filter. The first is for camouflage (hidden internal IP addresses behind a single external IP address) and the packets between the host and ports. The package filter will check if the packet modified by the NAT can allow the network after the firewall. You can find a detailed explanation about IPFilter design and grammar rules on the Daren Reed IPFilter website. MAN IPF and Man IPNAT provide more additional information.
Because NAT contacts the data packet, we will configure it first. Network address conversion and data package redirection rules are stored in the /etc/ipnet.rules file. Use the text editor to open this file and enter the following rules:
# private Internal Network Nat rulesmap tun0 192.168.1.0/24 -> xxxx / 32 Portmap TCP / UDP 10000: 20000map tun0 192.168.1.0/24 -> xxxx / 32 # dmz nat rulesmap tun0 192.168.2.0/24 -> xxxx / 32 Portmap TCP / UDP 20001: 30000Map Tun0 192.168.2.0/24 -> xxxx / 32
These rules tell the NAT engine to map all connections on ports 10000-20000, from internal dedicated networks to address "x.x.x.x". And map all connections on ports 20001-30000, from DMZ to address "x.x.x.x". "X.x.x.x" should be replaced with the actual IP address assigned to your ISP. Tun0 is the name of the Internet interface device. If the external interface does not use the serial port, replace TUN0 to the network device name you use.
We can now connect internal private networks and DMZ to the Internet, but external hosts are still unable to access services in DMZ. We need to do a redirection, the following is a simple redirect rule:
the private internal netrdr ne1 xxxx / 32 port> 192.168.2.254 port 8080 udp # redirect HTTP requests from 80 - # redirect HTTP requests from foreign hostsrdr tun0 xxxx / 32 port 80 -> 192.168.2.254 port 8080 tcprdr tun0 xxxx / 32 port 80 -> 192.168.2.254 port 8080 tcprdr ne1 xxxx / 32 port 80 -> 192.168.2.254 port 8080 udp # redirect HTTP requests from the DMZrdr ne2 xxxx / 32 port 80 -> 192.168.2.254 port 8080 tcprdr ne2 xxxx / 32 port 80 - > 192.168.2.254 Port 8080 UDP, "XXXX" is an IP address that connects the firewall to the external interface of the Internet. 192.168.2.254 is an IP address of the HTTP server in DMZ. For security reasons, the server listens for a request on a non-privacy port 8080. Note that this must have a rule to redirect the data package on each interface to the 80-80 number of "X.x.x", otherwise some packets will not be able to reach the correct destination.
Redirect other services, you can copy the rules of HTTP and change the port number. For example, redirect mail, add the following rules to the /etc/ipnat.rules file:
# Redirect SMTP requests from foreign hostsrdr tun0 xxxx / 32 port 25 -> 192.168.2.253 port 25 tcprdr tun0 xxxx / 32 port 25 -> 192.168.2.253 port 25 udp # redirect SMTP requests from the private internal netrdr ne1 xxxx / 32 port 25 -> 192.168.2.253 port 25 tcprdr ne1 xxxx / 32 port 25 -> 192.168.2.253 port 25 udp # redirect SMTP requests from the DMZrdr ne2 xxxx / 32 port 25 -> 192.168.2.253 port 25 tcprdr ne2 xxxx / 32 port 25 - > 192.168.2.253 Port 25 UDP
Note that I use different IP addresses, this address is the machine I run the SMTP daemon. Of course, if all your services are running on the same host, this address does not need to be changed.
Once we set all the NAT rules, we can continue to add the bag filter rules. These are stored in the /etc/ipf.rules file. Use the text editor to open it and add the following two lines to the most:
Pass Out Quick On Lo0 All
Pass in Quick On LO0 All
LO0 is a looping interface, we don't need to move it, because the blocking packets here will waste a lot of processor cycles. Keyword Quick indicates that the firewall stops processing other rules immediately after packet matching this rule. This reduces a large number of processor cycles and simplifies the writing of rules. There is nothing to add here, so we will continue to TUN0 interface rules, we need to block all the output data to the illegal address (some intruders like to use this type of rebound control method, we certainly don't want to help them): Block Out Quick on Tun0 from any to 192.168.0.0/16
Block Out Quick on Tun0 from any to 172.16.0.0/12
Block Out Quick on Tun0 from any to 127.0.0.0.0/8
Block Out Quick on Tun0 from any to 10.0.0.0.0/8
Block Out Quick On Tun0 from any to 0.0.0.0/8
Block Out Quick on Tun0 from any to 169.254.0.0/16
Block Out Quick on Tun0 from any to 192.2.2.0/24
Block Out Quick on Tun0 from any to 204.152.64.0/23
Block Out Quick on Tun0 from any to 224.0.0.0.0/3
After blocking the dangerous packets from propagating into the Internet, we need to add some rules that flow out of the legal data. The following three rules will allow all data issued from the legitimate address on the internal private network to the Internet:
pass out quick on tun0 proto tcp from 192.168.1.0/24 to any keep statepass out quick on tun0 proto udp from 192.168.1.0/24 to any keep statepass out quick on tun0 proto icmp from 192.168.1.0/24 to any keep state
Keyword Keep State tells IPFilter to "Remember" connection status, so that those hosts that send back to create connections can pass through the firewall. Keyword Proto defines a particular rule that will use the protocol.
We also hope that all data sent from the DMZ legal address can be sent smoothly on the Internet. All we need to do is just the rules of the internal private network, and replace the network address. (With 192.168.2.0/24, 192.168.1.0/24 - / 24 is Netmask):
pass out quick on tun0 proto tcp from 192.168.2.0/24 to any keep statepass out quick on tun0 proto udp from 192.168.2.0/24 to any keep statepass out quick on tun0 proto icmp from 192.168.2.0/24 to any keep state
All other tried to arrive at the Internet through TUN0 should be intercepted because of the security reasons.
Block Out Quick on Tun0 All
We now have a set of defined which packets can leave our network and try to connect to the rules of other hosts on the Internet. Take it down, we will add the rules that use to block unpopular packets to send to our network.
As just now, we need to throw out all the packets from the illegal address, because they are always sent by those who have a unhappy picture. This can be implemented by the following rules:
Block in quick on tun0 from 192.168.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.lock
Block in quick on tun0 from 10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8?
Block in Quick on Tun0 from 127.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8?
Block in Quick on Tun0 from 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0/8 to any
Block in quick on tun0 from 169.254.0.0.0/16 to any
Block in quick on tun0 from 192.0.2.0/24 to any
Block in quick on tun0 from 204.152.64.0/23 to any
block in quick on from 224.0.0.0/3 to tun0 any
Block in log quick on tun0 from x.x.x.x / 32 to any
Block in log quick on tun0 from any to x.x.x.0 / 32
Block in log quick on tun0 from any to x.x.x.255 / 32
Keyword log tells ipfilter to record all packets that meet a rule.
When all illegal packets are discarded, we can check if there are packets that go to the public port. If there is, I can make them pass. The following rules check the data packets of the port 80, which is a general HTTP port.
Pass in quick on tun0 proto tcp / udp from any to x.x.x.x / 32 port = 80 Keep StatePass in Quick On Tun0 Proto TCP / UDP from any to 192.168.2.254/32 port = 8080 Keep State
Note that the address / port used in the IPF.Rules file must comply with the address / port used in IPnat.Rules. The following rules allow all data packets of all SMTP servers in DMZ:
Pass in quick on tun0 proto tcp / udp from any to x.x.x.x / 32 port = 25 Keep StatePass in Quick ON TUN0 Proto TCP / UDP from any to 192.168.2.253/32 port = 25 Keep State
All other packets sent from the Internet to an external interface will be discarded.
Block in Quick on Tun0 All
Our external interface is basically protected, and we can now focus on the internal private network and DMZ interface. Suppose internal dedicated networks are connected to interface NE1, we can write down these blocks to block all the rules that attempt to reach the internal private network:
Block Out Quick on Ne1 All ALL
This rule cuts the right to access the internal private network DNS, which is the name server mentioned earlier in the /etc/resolv.conf file. We can activate the access to the name server:
Pass out ran 192.168.1.1 to 192.168.1.2/32 port = 53 Keep StatePass Out Quick on Ne1 Proto UDP from 192.168.1.1 to 192.168.1.2/32 port = 53 Keep State
Or better, use an external name server to replace the internal name server. In this way, / etc / resolv.conf will be like this ("y.y.y" and "z.z" is the address of the external name server, it should be your ISP assignment to you): Lookup file bind
Nameserver y.y.y.y
Nameserver Z.z.z.z
What is worth remember is that the "OUT" rule defines the packet away from the firewall and enter the filter policy of other networks (here is an internal private network), the "In" rule defines the filtering policy that is sent from the outside to the firewall. These often cause some problems to beginners.
Define which packets from internal private networks can enter the firewall rule is very similar to TUN0's "in" rules, although not the same:
Block in Quick On Ne1 from 172.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.o quick on ne1 from 169.254.0.0/16 to anyblock in quick on ne1 from 192.0.2.0/24 to anyblock in quick on ne1 from 204.152.64.0/23 to anyblock in quick on ne1 from 224.0.0.0/3 to anyblock in log quick On ne1 from xxxx / 32 to anyblock in log quick on ne1 from any to xxx0 / 32block in log quick on ne1 from any to xxx255 / 32pass in Quick on Ne1 Proto Tcp from 192.168.1.0/24 to any Keep StatePass in Quick On Ne1 Proto Udp from 192.168.1.0/24 to any Keep StatePass in Quick on Ne1 Proto Icmp from 192.168.1.0/24 to any Keep StateBlock in Quick On NE1 ALL
Different from other internal dedicated networks, a part of DMZ is open. Since this, we will need to let some packages enter before we lose all the packets that try to enter its packets. The first set of rules will enable all packets from the internal private network to enter without constraints:
pass out quick on ne2 proto tcp from 192.168.1.0/24 to 192.168.2.0/24 keep statepass out quick on ne2 proto udp from 192.168.1.0/24 to 192.168.2.0/24 keep statepass out quick on ne2 proto icmp from 192.168. 1.0 / 24 to 192.168.2.0/24 Keep State
Down, we will block all the packets that send the unlaveiled address:
Block Out Quick On Ne2 from any to 192.168.0.0/16
Block Out Quick on Ne2 from any to 172.16.0.0.0/12
Block Out Quick On Ne2 from any to 127.0.0.0/8
Block Out Quick On Ne2 from any to 10.0.0.0.0.0.0.0.0 from any to 0.0.0.0/8
Block Out Quick On Ne2 from any to 169.254.0.0/16
Block Out Quick On Ne2 from any to 192.0.2.0/24
Block Out Quick on Ne2 from any to 204.152.64.0/23
Block Out Quick On Ne2 from any to 224.0.0.0.0/3
Finally, we will let the data packets sent from the outside to the public address:
pass out quick on ne2 proto tcp from any to 192.168.2.254/32 port = 8080 keep statepass out quick on ne2 proto udp from any to 192.168.2.254/32 port = 8080 keep statepass out quick on ne2 proto tcp from any to 192.168. 2.253 / 32 Port = 25 Keep StatePass Out Quick on Ne2 Proto Udp from any to 192.168.2.253/32 port = 25 Keep State
Other packets will be intercepted for security reasons:
Block Out Quick On Ne2 All
For packets sent from DMZ to the Internet, we will let all packets sent from the legal address pass:
Block in Quick on Ne2 from 172.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 from 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2 from 0.0.0.0.0.0 to anyblock in quick on ne2 from 169.254.0.0/16 to anyblock in quick on ne2 from 192.0.2.0/24 to anyblock in quick on ne2 from 204.152.64.0/23 to anyblock in quick on ne2 from 224.0.0.0/3 to anyblock in log quick ON ne2 from xxxx / 32 to anyblock in log quick on ne2 from any to xxx0 / 32block in log quick on ne2 from any to xxx255 / 32pass in quick on ne2 proto TCP 192.168.2.0/24 to any Keep StatePass in Quick ON ne2 proto udp from 192.168.2.0/24 to any keypass in quick on ne2 proto icmp from 192.168.2.0/24 to any key keep stateblock in quick on ne2 all
These now some rules are very restrictive, but it is also safe. You can use the following command to close them:
IPF -A-FA -F /ETC/IPF.Rules -E
IPNAT-FC -F /ETC/ipnat.rules
Our network will have certain immunity to external attacks, but there are also some inconvenience:
We can't use Traceroute - Solution is to relax our rules. Read the IPFilter How-To file to get more tips on relaxing rules. It will be a very good configuration of the firewall. · Pings and connection attempts from outside to our network will report 100% packet loss - this will be a problem. When you want to monitor the firewall by sending Pings from the outside, you can watch whether the machine is running. You can use the connection of the public port instead.
When you want to open some additional services to external users, remember to add an appropriate entry in the /etc/ipnat.rules and /etc/ipf.rules files.
V. Conclusion
Open your service is made by you. The UTTP server is run in DMZ. Another popular choice is an Email server and a DNS server for providing virtual domain services.
There are many available options in the market, but I suggest you use your best, or if you don't know how to manage software's special part, my suggestion begins with simple things. For example, if you don't know how to configure and manage DNS, you can use the / etc / hosts file until you understand more about DNS. If you need to use DNS to implement a virtual domain service, use an external DNS server. You can rent a DNS server at a low price of 5 moon, or you can ask if your ISP can set up your domain name on their name servers.
If you want to run a mail service, consider Postfix, a free mail software that can be used to replace Sendmail, which is very easy to configure and manage, and has been more secure than Sendmail.
As for the HTTP server software, if you have never used the web server, consider using THTTPD instead of APACH. Thttpd is relatively small, and it is easier to configure and manage, and you can also teach you some good management habits. If you want to run the public name server, try DJBDNs. Learn different configuration features in the software you want to use, and learn how to use Chroot to run them, which can greatly increase the security of the system.
Finally, learn from network security, firewall, TCP / IP management as much as possible. The design I mentioned in the article allows security and inconvenience to balance the security and inconvenience, but you can't use it without any trouble, and it is not the safest design. This only seems to start: you should improve it to adapt to your own requirements. Read all available How-TOS and Guide. When you have questions, ask some old and more experienced administrators and learn from them.
