PFFW is expected to be used on production systems. Make sure the SHA checksum is correct: aaa5c3bd8f3cdcba17ffeebcb4b0bbb System, network, and service configuration can be achieved on the web interface. Pf rules are maintained using PFRE. Information on hosts, interfaces, pf rules, states, and queues are provided in a tabular form. System, pf, and network can be monitored via graphs.
|Published (Last):||5 July 2006|
|PDF File Size:||9.62 Mb|
|ePub File Size:||10.88 Mb|
|Price:||Free* [*Free Regsitration Required]|
The problem with NATting is its syntax changed recently. The syntax above is for OpenBSD 4. But for testing, the live one would fail to transfer. I defaulted the firewall to block in from Internet, pass everything else. Now look at the part labelled "block the obviously bogus". The first of those lines is used only in simulation testing, to prevent someone from setting up a route from What could possibly go wrong?
Look at the last three lines of the "obviously bogus" section. The first of those three block rules prevents anything from the Internet trying to access your private networks. For the same reason, the second of those lines must be commented out. Any packet on the Internet purporting itself to be from a private address is no good.
But of course in simulation mode everything coming in is from your LAN and must be commented out. Same with the third of those three lines. And like the other two, it must be commented out for simulation test mode. The pf. But before doing any live testing, you need to do simulation testing, and to do that you need to make some changes to several of these files. Read on Do Simulation Mode Testing Simulation Mode Simulation mode is as safe as the existing firewall, which of course we all hope is safe indeed.
In this example, this NIC would now be addressed at You can do this just by moving the comment character the hash from the test line to the live line. Change the hostname. Once again, just move the comment symbol. In pf. In the section blocking obviously bogus Internet packets, uncomment the first rule -- the one preventing reaching in to This is to compensate for the three you commented out.
At the bottom, uncomment the pass command for port Reboot the BSD machine. If the pfctl command produces errors, it means that pf. This is why the 2 level testing is so important. Now that you have the BSD box configured for simulation testing, perform your simulation tests. The ping should go through your Internet facing NIC, which in this case is attached physically and by IP address subnet to your existing network. If all the preceding are correct, check your pf.
From a box on your current LAN, ping www. Once you can ping www. If the numeric ping fails, make sure you made all the changes to pf. Troubleshoot as necessary. From the BSD box, ping www. It should ping normally. It should pull up Troubleshooters. Com in the Lynx text browser. You can move around the web page with the arrow keys. To quit Lynx, press q twice. Remembering the DHCP provided address of the Internet facing NIC, which you got from the ifconfig command, from a Linux machine on the existing LAN, ssh into the BSD machine username root, and be sure to use your root password for the BSD box not your personal account password and not your password on other machines.
Verify you can ssh into the BSD machine. If not make sure you uncommented the two port 22 pass rule in pf. Remembering the DHCP provided address of the Internet facing NIC, which you got from the ifconfig command, from a Linux machine on your current LAN, run the following penetration tests, as root, against your new firewall: nmap -sT -p It took 20 minutes on my computer.
The -sT command should show port 22 ssh to be open. Now comment out the port 22 pass pf. You should now note that you cannot ssh in, and the penetration tests will not find port 22 open. In this example the test box got an address of On the test box, ping the IP address you earlier wrote down for www. Re-confirm that you can still ping www. On the test box, once you can ping www. Many times that fixes this problem. In this example it would be But this time, when asked for the username, put your username on the test machine.
Same with the password. Someone could be eavesdropping on you right now man-in-the-middle attack! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is b:bcbe:de. Please contact your system administrator. Host key verification failed. If it occurs only once, delete that record dd in Vim. If it occurs more than once, investigate.
Save the file and exit the editor Now when you try the ssh command it should work. If not, troubleshoot. Now put the file back the way it was. Delete the line you just put on the bottom of pf. If you were to do that before reworking all files to get back into live mode, a script kiddie might come in and own you. Wiring it in early can allow a badguy to come in and own your computer! Before you do anything else, you first have to reset everything back to its original "live" settings.
You can do this just by moving the comment character the hash from the live line to the test line. In the section blocking obviously bogus Internet packets, comment out the first rule -- the one preventing reaching in to This is no longer necessary because the rule barring reaching in for a private address does this and more.
At the bottom, comment the pass command for port Now rewire everything: Shut down and power down your existing firewall. When the existing firewall is powered down, power down your cable modem. Unplug your existing firewall from both the cable modem and the existing LAN. Move it out of the way. Power up the cable modem. Wait at least a minute for its boot to complete.
Log in as root. If not, make sure you completely changed back all the files to LIVE mode. Be sure your dhclient. Try downing and upping the firewall and modem again to see if that makes a difference.
Com, which you found and wrote down earlier in this document. This proves you can get out on port It should fail because you have no pass command for port Do not try penetration tests from the outside unless you get permission -- conducting such penetration tests from the Internet are very likely a serious breach of terms of service.
Power up the test machine. Log into the test machine as root, and perform an ifconfig command. If not, on the test machine, bring the network down and up again and see if that helps. If not, try rebooting the test machine. On the test machine, ping the IP address for www. It should ping. On the test machine, ping www. Troubleshoot accordingly. It should come up, thereby proving your ability to go out port
Build a simple router/firewall