On Saturday 09 December 2006 04:43, David B. wrote:
> I've looked an man pf, and it's way too confusing; I'm using smoothwall as
> a standalone firewall, and it pretty much works the way I want it to;
> however, I've found a reason to block a an IP range, particularly
> 216.87.0.0/17; is there an equivalent to an iptables command I can use to
> simply
> drop all traffic coming from that range?
>
> like go into a file, and have a command in the form of: 'drop all from
> 216.87.0.0/17'?
>
> oh, and does anyone have any comments on Labrea? as a honeypot? it looks
> pretty good, and it comes for openbsd, or is openbsd simply best left
> alone?
OBSD is for anyone who wants to use it. However, making changes to a computer
which is connected directly to the Internet can be a liability as you may
open yourself up to being hacked.
Having enough experience to at least be able to follow the instructions on how
to set up a firewall is so basic that without it you are "a sitting duck".
This is of course applicable to any O/S.
A good OBSD book to read is Absolute Openbsd by Lucas, No Starch Press.
BSD's begs to be worked on and used. Getting an understanding of pf is really
not that hard as things go. Following the steps in:
http://openbsd.org/faq/faq6.html
are really very simple.
OBSD is different than Linux. It's similar but different. All unix based O/S
have a certain number of things in common. But each have their own direction
and specific ways. Reading a book like the above is a good start for those
new to it and will get you the conceptual understanding needed.
A line in pf.conf along this line may stop traffic from an IP. I say may
because again not knowing what you are doing you can undo it elsewhere.
block in quick on $ext_if from 216.87.0.0/17 to any
Pf.conf is really very very flexible and able to handle any situation. But
again, you must have a clue of what you are doing. The best rule is probably
to know that when looking at a firewall, realize it does not know which side
is on the inside or outside. It simply looks at packets either coming into or
exiting.
You normally only filter on one interface, the external one.
Best practice is usually to start by blocking everything, and then opening
ports/addresses as needed. On that interface you can not only block all
inbound, but also all outbound. This will give you control on what your
computer and or network can do.
The above FAQ example uses a block all inbound and allow all outbound policy,
if I recall correctly. This is a good start. But sometimes it might be needed
to also control which external services can be accessed, at least by port.
(Since there are many workarounds by using commonly used ports like www, port
80.)
One of the really nice things about pf is that you can use variables. So you
can say friends="{ ip ip ip ip ip }" and then later say:
allow in on $ext_if from $friends to any
Or, if you have a LAN and want to let friends reach a computer (192.168.0.10
on a specific number of ports like 2000,2002,2012):
my_comp="192.168.0.10"
my_ports="{ 2000 2002 2012 }"
allow in on $ext_if from $friends to $my_comp port $my_ports
The variable names are of course whatever you choose them to be. Descriptive
names are usually best.
OpenBSD have pretty decent documentation. Just remember not to go past words
or definitions you don't understand. When an unknown term is used chase it
down on google, for example, before going on. Make sure it makes sense before
going on. This is key in learning anything. Otherwise you'll get stuck.
I had a friend that used to program in assembler (machine code) and just enter
the hex values into the computer. He could never really debug what he wrote,
but he could write a new program just like that. He said the key was that he
had complete understanding of all the commands and the environment. There
were nothing misunderstood.
--
Steve Szmidt
"To enjoy the right of political self-government, men must be
capable of personal self-government - the virtue of self-control.
A people without decency cannot be secure in its liberty.
From the Declaration Principles
