Re: PF Logging FAQ clarification
67 is indeed the port number. What does your rule that logs this traffic look like? Does the rule refer to an internal or external network card? Daniel Original message from Jim Mays at 30-12-2003 5:18 Wow, that's what I'm afraid of. The log files are filled with rejects from 10.180.160.1.67. Is 67 the port number? Why am I getting hammered from a non-routable address?
FW: pf rules advice
I'm seting up a OpenBSD 3.4 machine to replace an older OpenBSD machine as my firewall for the home LAN. I'm conected via a cablemodem which seesm to be quite a hostile environment these days. So I'd like some advice on my pf ruleset. Here is what I have on the old machine: ipf.rules # Accept anything on the loopback interface pass in on lo0 pass out on lo0 # # Block any inherently bad packets coming in from the outside world. # These include ICMP redirect packets, IP fragments so short the # filtering rules won't be able to examine the whole UDP/TCP header, # and anything with IP options. # block in quick on ep1 proto igmp from any to any block in log quick on ep1 proto icmp from any to any icmp-type redir block in log quick on ep1 proto tcp/udp all with short block in log quick on ep1 from any to any with ipopts # # Block any IP spoofing atempts. (Packets "from" our network # shouldn't be coming in from outside). # block in log quick on ep1 from 192.168.4.0/24 to any block in log quick on ep1 from localhost to any block in log quick on ep1 from 0.0.0.0/32 to any block in log quick on ep1 from 255.255.255.255/32 to any # # Block all incoming UDP traffic except talk and DNS traffic. NFS # and portmap are special-cased and logged. # block in log on ep1 proto udp from any to any block in log on ep1 proto udp from any to any port = sunrpc block in log on ep1 proto udp from any to any port = 2049 pass in on ep1 proto udp from any to any port = domain # For dcc client pass in on ep1 proto udp from any to any port = 6277 pass in on ep1 proto udp from any to any port = talk pass in on ep1 proto udp from any to any port = ntalk pass in on ep1 proto udp from 192.5.41.41 to any port = ntp pass in on ep1 proto udp from 192.5.41.40 to any port = ntp pass in on ep1 proto udp from 128.115.14.97 to any port = ntp # # Block all incoming TCP traffic connections to known services, # returning a connection reset so things like ident don't take # forever timing out. Don't log ident (auth port) as it's so common. # block return-rst in log on ep1 proto tcp from any to any flags S/SA block return-rst in on ep1 proto tcp from any to any port = auth flags S/SA # # Allow incoming TCP connections to ports between 1024 and 5000, as # these don't have daemons listening but are used by outgoing # services like ftp and talk. For slightly more obscurity (though # not much more security), the second commented out rule can chosen # instead. # pass in on ep1 proto tcp from any to any port 1024 >< 5000 #pass in on ep1 proto tcp from any port = ftp-data to any port 1024 >< 5000 # # Now allow various incoming TCP connections to particular hosts, TCP # to the main nameserver so secondaries can do zone transfers, SMTP # to the mail host, www to the web server (which really should be # outside the firewall if you care about security), and ssh to a # hypothetical machine caled 'gatekeeper' that can be used to gain # access to the protected network from the outside world. # pass in on ep1 proto tcp from any to 68.58.176.69 port = www pass in on ep1 proto tcp from any to 205.159.77.224 port = www pass in on ep1 proto tcp from any to 68.58.176.69 port = sftp pass in on ep1 proto tcp from any to 205.159.77.224 port = sftp pass in on ep1 proto tcp from any to 68.58.176.69 port = ssh pass in on ep1 proto tcp from any to 205.159.77.224 port = ssh pass in on ep1 proto tcp from any to 68.58.176.69 port = 8022 # pass in on ep1 proto tcp from 166.84.0.227 to 205.159.77.240 port = 6000 # pass in on ep1 proto tcp from 166.84.0.228 to 205.159.77.240 port = 6000 # pass in on ep1 proto tcp from 166.84.0.231 to 205.159.77.240 port = 6000 and the nat config file # $OpenBSD: ipnat.rules,v 1.2 1999/05/08 16:33:10 jason Exp $ # # See /usr/share/ipf/nat.1 for examples. # edit the ipnat= line in /etc/rc.conf to enable Network Address Translation #map ppp0 10.0.0.0/8 -> ppp0/32 portmap tcp/udp 1:2 rdr ep1 68.58.176.69/32 port http -> 205.159.77.224 port http rdr ep1 68.58.176.69/32 port 8022 -> 205.159.77.224 port 22 rdr ep1 68.58.176.69/32 port sftp -> 205.159.77.224 port sftp rdr ep1 68.58.176.69/32 port 6000 -> 205.159.77.240 port 6000 map ep1 205.159.77.0/24 -> ep1/32 proxy port ftp ftp/tcp map ep1 205.159.77.0/24 -> ep1/32 portmap tcp/udp 1:2 map ep1 205.159.77.0/24 -> ep1/32 # map ep1 192.168.1.0/24 -> ep1/32 proxy port ftp ftp/tcp # map ep1 192.168.1.0/24 -> ep1/32 portmap tcp/udp 1:2 # map ep1 192.168.1.0/24 -> ep1/32 Now, I have a pf.conf that moslty works. The one issue I am aware of on it, is that it seems to prevent the new machien from ftp'ing to any machine on the local network. # $OpenBSD: pf.conf,v 1.21 2003/09/02 20:38:44 david Exp $ # # See pf.conf(5) and /usr/share/pf for syntax and examples. # Required order: options, normalization, queueing, translation, filtering. # Macros and tables may be defined and used anywhere. # Note that translation rules are first match while filter rule
Re: PF Logging FAQ clarification
Wow, that's what I'm afraid of. The log files are filled with rejects from 10.180.160.1.67. Is 67 the port number? Why am I getting hammered from a non-routable address? Jim - Original Message - From: "Daniel Polak" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 29, 2003 9:45 PM Subject: Re: PF Logging FAQ clarification > Jim, > > I wrote that particular part of the PF FAQ and you are right that the > instruction to "touch /var/log/pflog.txt" is missing. Sorry about that. > > If I remember correctly syslog will just not log to a file that does not > already exist which is why you need a special touch :-) > > Enter the following to see what the number for each rule is: > pfctl -v -v -s rules | grep @ | more > > Daniel > Original message from Jim Mays at 30-12-2003 3:06 > > > In the /var/log directory I entered "touch pflog.txt" and now it works fine. > > I can't believe this it won't create the file if it isn't already there. I > > have run both the scripts by hand that are listed in the FAQ and they both > > run fine. I looked through the new ascii log files and I have one more > > question. What constitutes a rule? If something matches rule 4, does that > > include a "scrub" line and a "nat" line? Or is it only lines that start > > with "pass" or "block"? > > > > Thanks > > Jim > > > > > > > > - Original Message - > > From: "Jim Mays" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, December 29, 2003 7:09 PM > > Subject: PF Logging FAQ clarification > > > > > > > >>I am trying to get PF to log in ASCII format so I followed the FAQ page on > >>PF Logging to the letter. When it gets to the line that says > >># kill -HUP $(cat /var/run/syslog.pid) > >> > >>I get an error that says: > >>/var/log/pflog.txt: No such file or directory > >> > >>I also get this error when I reboot the system. Why am I getting this > >>error? Shouldn't it just create the file? The man page doesn't say > >>anything about the file having to exist already. > >> > >>Jim > >> > >> > >> > > > > > > > >
Re: PF Logging FAQ clarification
Jim, I wrote that particular part of the PF FAQ and you are right that the instruction to "touch /var/log/pflog.txt" is missing. Sorry about that. If I remember correctly syslog will just not log to a file that does not already exist which is why you need a special touch :-) Enter the following to see what the number for each rule is: pfctl -v -v -s rules | grep @ | more Daniel Original message from Jim Mays at 30-12-2003 3:06 In the /var/log directory I entered "touch pflog.txt" and now it works fine. I can't believe this it won't create the file if it isn't already there. I have run both the scripts by hand that are listed in the FAQ and they both run fine. I looked through the new ascii log files and I have one more question. What constitutes a rule? If something matches rule 4, does that include a "scrub" line and a "nat" line? Or is it only lines that start with "pass" or "block"? Thanks Jim - Original Message - From: "Jim Mays" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 29, 2003 7:09 PM Subject: PF Logging FAQ clarification I am trying to get PF to log in ASCII format so I followed the FAQ page on PF Logging to the letter. When it gets to the line that says # kill -HUP $(cat /var/run/syslog.pid) I get an error that says: /var/log/pflog.txt: No such file or directory I also get this error when I reboot the system. Why am I getting this error? Shouldn't it just create the file? The man page doesn't say anything about the file having to exist already. Jim
Re: pf and smtp
Jay Moore ([EMAIL PROTECTED]) wrote:
> On Mon, Dec 29, 2003 at 03:06:23PM -0700, the entity calling itself Edward A.
> Gardner stated:
> > I don't really understand so-called dynamic DNS, other that what seems self
> > evident from the name. But wouldn't that provide a way to get around such
> > blocking and send mail from dynamic addresses?
>
> I don't understand the term either.
Dynamic DNS service is a one-way (domain name -> IP address) service
to help people with dynamic IP addresses run services. It uses a
third party DNS server with a very short Time To Live.
Example: Alice wants to run a low-volume web site on her cable modem
which uses DHCP to get a dynamic address. She signs up with an
imaginary dynamic DNS service called dyno-dns.com (which may or may
not charge her a fee). She chooses the hostname "alicesrestaurant".
Now, she "owns" the FQDN "alicesrestaurant.dyno-dns.com". It's an A
record in a DNS zone controlled by the registrant of dyno-dns.com, with
a very short TTL (usually on the order of 60 seconds). When she brings
up her Internet connection (typically at boot time), she gets her
dynamic IP address from her ISP. Then she runs some program on her
local computer (a perl script, etc.) which transmits her hostname
("alicesrestaurant"), her current IP address, and her authentication
credentials to dyno-dns.com. dyno-dns.com updates their DNS zone file,
and then voila! Her friends can now reach her web site on her dynamic
IP address just by going to http://alicesrestaurant.dyno-dns.com/.
This is a one-way service, because typically she will have no control over
the PTR record for her address (the IP -> name translation). So, looking
up alicesrestaurant.dyno-dns.com will reveal an IP address, but looking
up that same IP address will give unpredictable results (either no PTR
record at all, or something like "host-1-2-3-4.la.ca.big-cable-isp.com").
This really has nothing to do with spam, AFAIK.
--
Greg Wooledge | "Truth belongs to everybody."
[EMAIL PROTECTED] |- The Red Hot Chili Peppers
http://wooledge.org/~greg/ |
signature.asc
Description: Digital signature
Re: PF Logging FAQ clarification
In the /var/log directory I entered "touch pflog.txt" and now it works fine. I can't believe this it won't create the file if it isn't already there. I have run both the scripts by hand that are listed in the FAQ and they both run fine. I looked through the new ascii log files and I have one more question. What constitutes a rule? If something matches rule 4, does that include a "scrub" line and a "nat" line? Or is it only lines that start with "pass" or "block"? Thanks Jim - Original Message - From: "Jim Mays" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 29, 2003 7:09 PM Subject: PF Logging FAQ clarification > I am trying to get PF to log in ASCII format so I followed the FAQ page on > PF Logging to the letter. When it gets to the line that says > # kill -HUP $(cat /var/run/syslog.pid) > > I get an error that says: > /var/log/pflog.txt: No such file or directory > > I also get this error when I reboot the system. Why am I getting this > error? Shouldn't it just create the file? The man page doesn't say > anything about the file having to exist already. > > Jim > > >
PF Logging FAQ clarification
I am trying to get PF to log in ASCII format so I followed the FAQ page on PF Logging to the letter. When it gets to the line that says # kill -HUP $(cat /var/run/syslog.pid) I get an error that says: /var/log/pflog.txt: No such file or directory I also get this error when I reboot the system. Why am I getting this error? Shouldn't it just create the file? The man page doesn't say anything about the file having to exist already. Jim
Re: pf and smtp
On Mon, Dec 29, 2003 at 03:06:23PM -0700, the entity calling itself Edward A. Gardner stated: > I think I understand dynamic vs. static IP addresses, and I understand why > some people feel compelled to filter on them, and why others consider that > an ill-conceived idea. But how is the filtering actually performed? Before you can filter dynamic ip addresses, you must have an idea of which addresses are dynamically assigned by an ISP. Here's a FAQ on how one dnsbl provider comes up with a list of dynamic ip addresses: http://www.dnsbl.au.sorbs.net/DUL-FAQ.html Identifying dynamic ip addresses is not straightforward unless the ISP cooperates and lists them. Before they shut down their service, easynet.nl had (IMHO) the most complete list of dynamic ip's; they also had a FAQ that explained in better detail how they developed their list. Unforutnately their FAQ also appears to be gone, but as I recall they used some heuristics to help them identify dynamic ip addresses. For example, consider the following host names: h24-67-5-214.ed.shawcable.net iam.spamsender.com You can get a pretty good clue that the first of these hostnames might be associated with a dynamic ip address; you get a little stronger clue when you actually do a lookup on this hostname and get: 24.67.5.214 Once you have the list, it works like all the other dnsbl's: you do a reverse DNS to the dnsbl server, and look at the return value. For example, using the dnsbl server 'dnsbl.sorbs.net': # nslookup 214.5.67.24.dnsbl.sorbs.net Server: Address:#53 Non-authoritative answer: Name: 214.5.67.24.dnsbl.sorbs.net Address: 127.0.0.10 The return is '127.0.0.10'. In the case of the sorbs dnsbl, that means that this address is in their "Dial-Up List", aka dynamic ip address list. This is explained further: http://www.dnsbl.us.sorbs.net/using.html > Is this simply recognizing the well-known non-routable IP addresses (10..., > 192.168.., etc.) in the source address of an incoming connection to port > 25? I don't see how that could ever happen. You're correct - it doesn't > Is it scanning email headers > for those addresses? I don't see that this would filter much of > anything. One of the "ideological battle" messages blamed some part of > this on NAT; I don't see where NAT has anything to do with this, as NAT is > not the only source of dynamic addresses. Obfuscation of technical facts is one of the problems with ideological battles :) > I'm sending this email via a dial-up PPP connection. My ISP has assigned > me IP address 209.248.81.177, derived from where I landed in the modem > pool. If I disconnect and dial-in again I will likely get a different IP > address. 209.248.81.177 is what I think is meant by "dynamic address" in > this discussion. Bingo! > When I send email, it goes from my PC to a server at my ISP. The mail > server has the static IP address 209.248.82.245. It is registered under > the DNS name mail.ophidian.com. > > The above two IP addresses appear as the first "Received:" headers in email > that I send. Right again - reading your headers from top to bottom will give the reverse order of the relays through which your message flowed to reach its final destination. However, only the ip address of the last relay (at the top of your header) can be counted on to be correct because the others are easily forged. And, FWIW, you can see who's blacklisting your & your ISP's addresses: http://www.dnsstuff.com/tools/ip4r.ch?ip=209.248.81.177 > From just the IP addresses themselves, I don't see any way to distinguish > the one address as dynamic and the other as static. One could perform a > reverse DNS lookup, which should succeed on the static address and fail on > the dynamic. It won't necessarily fail on the dynamic address; hopefully the example above showed how this works. > Is this what it means to "block mail from dynamic addresses"? To block > incoming connections to port 25 unless a reverse DNS lookup succeeds? Is > any other checking done with the results of the lookup? Typically, if a dnsbl server returns an address of the form '127.0.0.X' this means the ip address you've queried is "listed", and the connection is blocked by the receiving mail server. If nothing is returned, the address isn't listed and (may be) accepted. > I don't really understand so-called dynamic DNS, other that what seems self > evident from the name. But wouldn't that provide a way to get around such > blocking and send mail from dynamic addresses? I don't understand the term either. > A more succinct way of asking the above might be to ask how one would write > a pf filter (or an email filter) to recognize and block email from dynamic > addresses. That's a very good question (I think so since I asked more or less the same question some time ago :) I thought it would be possible to do a pf redirect based on the result of a reverse dns lookup. I posted the
Re: pf and smtp
(Somewhat pf relevant...) --As off Monday, December 29, 2003 3:06 PM -0700, Edward A. Gardner is alleged to have said: Is this simply recognizing the well-known non-routable IP addresses (10..., 192.168.., etc.) in the source address of an incoming connection to port 25? I don't see how that could ever happen. Is it scanning email headers for those addresses? I don't see that this would filter much of anything. One of the "ideological battle" messages blamed some part of this on NAT; I don't see where NAT has anything to do with this, as NAT is not the only source of dynamic addresses. --As for the rest, it is mine. My experience is that it is done by knowing which addresses are dynamic: Many ISP's directly list which IP addresses they assign dynamically, and for those that don't a watch of their customers will quickly tell you. People then block directly on those addresses: if a SMTP connection comes in from one it is dropped/blocked/slowed (depending on the Sysadmin's taste). Basically, the sysadmin considers the known dynamically assigned IP addresses a form of extended non-routable IP addresses. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: pf and smtp
Why do you feel that way? Are you aware that the spam problem has forced many to block _all_ mail coming from dynamic IP addresses - regardless of Trying to avoid the pitched ideological battle and get back to a technical discussion. I think I understand dynamic vs. static IP addresses, and I understand why some people feel compelled to filter on them, and why others consider that an ill-conceived idea. But how is the filtering actually performed? Is this simply recognizing the well-known non-routable IP addresses (10..., 192.168.., etc.) in the source address of an incoming connection to port 25? I don't see how that could ever happen. Is it scanning email headers for those addresses? I don't see that this would filter much of anything. One of the "ideological battle" messages blamed some part of this on NAT; I don't see where NAT has anything to do with this, as NAT is not the only source of dynamic addresses. I'm sending this email via a dial-up PPP connection. My ISP has assigned me IP address 209.248.81.177, derived from where I landed in the modem pool. If I disconnect and dial-in again I will likely get a different IP address. 209.248.81.177 is what I think is meant by "dynamic address" in this discussion. When I send email, it goes from my PC to a server at my ISP. The mail server has the static IP address 209.248.82.245. It is registered under the DNS name mail.ophidian.com. The above two IP addresses appear as the first "Received:" headers in email that I send. From just the IP addresses themselves, I don't see any way to distinguish the one address as dynamic and the other as static. One could perform a reverse DNS lookup, which should succeed on the static address and fail on the dynamic. Is this what it means to "block mail from dynamic addresses"? To block incoming connections to port 25 unless a reverse DNS lookup succeeds? Is any other checking done with the results of the lookup? I don't really understand so-called dynamic DNS, other that what seems self evident from the name. But wouldn't that provide a way to get around such blocking and send mail from dynamic addresses? A more succinct way of asking the above might be to ask how one would write a pf filter (or an email filter) to recognize and block email from dynamic addresses. Edward A. Gardner eag at ophidian dot com Ophidian Designs719 593-8866 voice 1262 Hofstead Terrace 719 210-7200 cell Colorado Springs, CO 80907
Re: pf rules advice
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
do you really want to try to rdr when you have real IP# listed?
rather :
black_allowed_ports = "{22,25,80}"
pass in quick proto tcp on $ext_if from any to $black ports
$black_allowed_ports keep state
or even add some flags to that, use the synproxy, etc
Read through the pf faq pages online, there is a lot more to pf that
you have even looked at if you are concerned about it...
CH
On 29-Dec-03, at 9:34 AM, Michael Clark wrote:
Stan this is more for the PF list so I am redirecting it.
-Original Message-
From: stan [mailto:[EMAIL PROTECTED]
Sent: Monday, December 29, 2003 10:16 AM
To: OpenBSD general usage list
Subject: pf rules advice
I'm seting up a 3.4 machine to replace an older OpenBSD machine as my
firewall for the home LAN. I'm conected via a cablemodem which seesm
to be
quite a hostile environment these days. So I'd like some advice on my
pf
ruleset.
Here is what I have on the old machine:
ipf.rules
# Accept anything on the loopback interface
pass in on lo0
pass out on lo0
#
# Block any inherently bad packets coming in from the outside world.
# These include ICMP redirect packets, IP fragments so short the
# filtering rules won't be able to examine the whole UDP/TCP header,
# and anything with IP options.
#
block in quick on ep1 proto igmp from any to any
block in log quick on ep1 proto icmp from any to any icmp-type redir
block in log quick on ep1 proto tcp/udp all with short
block in log quick on ep1 from any to any with ipopts
#
# Block any IP spoofing atempts. (Packets "from" our network
# shouldn't be coming in from outside).
#
block in log quick on ep1 from 192.168.4.0/24 to any
block in log quick on ep1 from localhost to any
block in log quick on ep1 from 0.0.0.0/32 to any
block in log quick on ep1 from 255.255.255.255/32 to any
#
# Block all incoming UDP traffic except talk and DNS traffic. NFS
# and portmap are special-cased and logged.
#
block in log on ep1 proto udp from any to any
block in log on ep1 proto udp from any to any port = sunrpc
block in log on ep1 proto udp from any to any port = 2049
pass in on ep1 proto udp from any to any port = domain
# For dcc client
pass in on ep1 proto udp from any to any port = 6277
pass in on ep1 proto udp from any to any port = talk
pass in on ep1 proto udp from any to any port = ntalk
pass in on ep1 proto udp from 192.5.41.41 to any port = ntp
pass in on ep1 proto udp from 192.5.41.40 to any port = ntp
pass in on ep1 proto udp from 128.115.14.97 to any port = ntp
#
# Block all incoming TCP traffic connections to known services,
# returning a connection reset so things like ident don't take
# forever timing out. Don't log ident (auth port) as it's so common.
#
block return-rst in log on ep1 proto tcp from any to any flags S/SA
block return-rst in on ep1 proto tcp from any to any port = auth flags
S/SA
#
# Allow incoming TCP connections to ports between 1024 and 5000, as
# these don't have daemons listening but are used by outgoing
# services like ftp and talk. For slightly more obscurity (though
# not much more security), the second commented out rule can chosen
# instead.
#
pass in on ep1 proto tcp from any to any port 1024 >< 5000
#pass in on ep1 proto tcp from any port = ftp-data to any port 1024 ><
5000
#
# Now allow various incoming TCP connections to particular hosts, TCP
# to the main nameserver so secondaries can do zone transfers, SMTP
# to the mail host, www to the web server (which really should be
# outside the firewall if you care about security), and ssh to a
# hypothetical machine caled 'gatekeeper' that can be used to gain
# access to the protected network from the outside world.
#
pass in on ep1 proto tcp from any to 68.58.176.69 port = www
pass in on ep1 proto tcp from any to 205.159.77.224 port = www
pass in on ep1 proto tcp from any to 68.58.176.69 port = sftp
pass in on ep1 proto tcp from any to 205.159.77.224 port = sftp
pass in on ep1 proto tcp from any to 68.58.176.69 port = ssh
pass in on ep1 proto tcp from any to 205.159.77.224 port = ssh
pass in on ep1 proto tcp from any to 68.58.176.69 port = 8022
# pass in on ep1 proto tcp from 166.84.0.227 to 205.159.77.240 port =
6000
# pass in on ep1 proto tcp from 166.84.0.228 to 205.159.77.240 port =
6000
# pass in on ep1 proto tcp from 166.84.0.231 to 205.159.77.240 port =
6000
and the nat config file
# $OpenBSD: ipnat.rules,v 1.2 1999/05/08 16:33:10 jason Exp $
#
# See /usr/share/ipf/nat.1 for examples.
# edit the ipnat= line in /etc/rc.conf to enable Network Address
Translation
#map ppp0 10.0.0.0/8 -> ppp0/32 portmap tcp/udp 1:2
rdr ep1 68.58.176.69/32 port http -> 205.159.77.224 port http
rdr ep1 68.58.176.69/32 port 8022 -> 205.159.77.224 port 22
rdr ep1 68.58.176.69/32 port sftp -> 205.159.77.224 port sftp
rdr ep1 68.58.176.69/32 port 6000 -> 205.159.77.240 port 6000
map ep1 205.159.77.0/24 -> ep1/32 proxy port ftp ftp/tcp
map ep1 205.159.77.0/24 -> ep1/32 portmap t
RE: pf rules advice
Stan this is more for the PF list so I am redirecting it. -Original Message- From: stan [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 10:16 AM To: OpenBSD general usage list Subject: pf rules advice I'm seting up a 3.4 machine to replace an older OpenBSD machine as my firewall for the home LAN. I'm conected via a cablemodem which seesm to be quite a hostile environment these days. So I'd like some advice on my pf ruleset. Here is what I have on the old machine: ipf.rules # Accept anything on the loopback interface pass in on lo0 pass out on lo0 # # Block any inherently bad packets coming in from the outside world. # These include ICMP redirect packets, IP fragments so short the # filtering rules won't be able to examine the whole UDP/TCP header, # and anything with IP options. # block in quick on ep1 proto igmp from any to any block in log quick on ep1 proto icmp from any to any icmp-type redir block in log quick on ep1 proto tcp/udp all with short block in log quick on ep1 from any to any with ipopts # # Block any IP spoofing atempts. (Packets "from" our network # shouldn't be coming in from outside). # block in log quick on ep1 from 192.168.4.0/24 to any block in log quick on ep1 from localhost to any block in log quick on ep1 from 0.0.0.0/32 to any block in log quick on ep1 from 255.255.255.255/32 to any # # Block all incoming UDP traffic except talk and DNS traffic. NFS # and portmap are special-cased and logged. # block in log on ep1 proto udp from any to any block in log on ep1 proto udp from any to any port = sunrpc block in log on ep1 proto udp from any to any port = 2049 pass in on ep1 proto udp from any to any port = domain # For dcc client pass in on ep1 proto udp from any to any port = 6277 pass in on ep1 proto udp from any to any port = talk pass in on ep1 proto udp from any to any port = ntalk pass in on ep1 proto udp from 192.5.41.41 to any port = ntp pass in on ep1 proto udp from 192.5.41.40 to any port = ntp pass in on ep1 proto udp from 128.115.14.97 to any port = ntp # # Block all incoming TCP traffic connections to known services, # returning a connection reset so things like ident don't take # forever timing out. Don't log ident (auth port) as it's so common. # block return-rst in log on ep1 proto tcp from any to any flags S/SA block return-rst in on ep1 proto tcp from any to any port = auth flags S/SA # # Allow incoming TCP connections to ports between 1024 and 5000, as # these don't have daemons listening but are used by outgoing # services like ftp and talk. For slightly more obscurity (though # not much more security), the second commented out rule can chosen # instead. # pass in on ep1 proto tcp from any to any port 1024 >< 5000 #pass in on ep1 proto tcp from any port = ftp-data to any port 1024 >< 5000 # # Now allow various incoming TCP connections to particular hosts, TCP # to the main nameserver so secondaries can do zone transfers, SMTP # to the mail host, www to the web server (which really should be # outside the firewall if you care about security), and ssh to a # hypothetical machine caled 'gatekeeper' that can be used to gain # access to the protected network from the outside world. # pass in on ep1 proto tcp from any to 68.58.176.69 port = www pass in on ep1 proto tcp from any to 205.159.77.224 port = www pass in on ep1 proto tcp from any to 68.58.176.69 port = sftp pass in on ep1 proto tcp from any to 205.159.77.224 port = sftp pass in on ep1 proto tcp from any to 68.58.176.69 port = ssh pass in on ep1 proto tcp from any to 205.159.77.224 port = ssh pass in on ep1 proto tcp from any to 68.58.176.69 port = 8022 # pass in on ep1 proto tcp from 166.84.0.227 to 205.159.77.240 port = 6000 # pass in on ep1 proto tcp from 166.84.0.228 to 205.159.77.240 port = 6000 # pass in on ep1 proto tcp from 166.84.0.231 to 205.159.77.240 port = 6000 and the nat config file # $OpenBSD: ipnat.rules,v 1.2 1999/05/08 16:33:10 jason Exp $ # # See /usr/share/ipf/nat.1 for examples. # edit the ipnat= line in /etc/rc.conf to enable Network Address Translation #map ppp0 10.0.0.0/8 -> ppp0/32 portmap tcp/udp 1:2 rdr ep1 68.58.176.69/32 port http -> 205.159.77.224 port http rdr ep1 68.58.176.69/32 port 8022 -> 205.159.77.224 port 22 rdr ep1 68.58.176.69/32 port sftp -> 205.159.77.224 port sftp rdr ep1 68.58.176.69/32 port 6000 -> 205.159.77.240 port 6000 map ep1 205.159.77.0/24 -> ep1/32 proxy port ftp ftp/tcp map ep1 205.159.77.0/24 -> ep1/32 portmap tcp/udp 1:2 map ep1 205.159.77.0/24 -> ep1/32 # map ep1 192.168.1.0/24 -> ep1/32 proxy port ftp ftp/tcp # map ep1 192.168.1.0/24 -> ep1/32 portmap tcp/udp 1:2 # map ep1 192.168.1.0/24 -> ep1/32 Now, I have a pf.conf that moslty works. The one issue I am aware of on it, is that it seems to prevent the new machien from ftp'ing to any machine on the local network. # $OpenBSD: pf.conf,v 1.21 2003/09/02 20:38:44 david Exp $ # # See pf.conf(5) and /usr/share/pf for s
Re: ALTQ & filter rules
On Mon, Dec 29, 2003 at 05:44:33PM +0700, Ilya A. Kovalenko wrote: > Why queueing filters & packet filters cannot > be configured separatelly ? because that is our design.
Re: ALTQ & filter rules
AES>> 3.4's (and above) "tagging" is your friend :) AES>> if you need skeleton ruleset, this one... > > [skipped] > > hmm ... thanks for method (shaping on lo0, tagging), 'll see > how it works. But the question was "shaping on lo0" is NOT the method :) it is just example to you, ready to pfctl -nf. you need to replace lo0 with interface name where you actually need to shape. but "tagging" is the real and powerful method. > Why queueing filters & packet filters cannot > be configured separatelly ? please, do not waking up Henning :) this question is previuosly answered. see my post "ALTQ: before and after merge" in archives. you just have not catched the main pf+altq idea yet. like i have not previuosly :)
Re: ALTQ & filter rules
Good time of day,
AES> 3.4's (and above) "tagging" is your friend :)
AES> if you need skeleton ruleset, this one...
[skipped]
hmm ... thanks for method (shaping on lo0, tagging), 'll see
how it works. But the question was
Why queueing filters & packet filters cannot
be configured separatelly ?
Shaping & filtering, theoretically, can have completely
different policy.
I.e. not "pass-n-shape" as on your ruleset, but "pass" &
"shape" in different rules/rulesets.
It is development question.
Before 3.3 ALTQ ruleset was completely separated, but inflexible. On
3.3+ ALTQ was merged into PF and pf.conf it become more more flexible
(BIG thanks to developers), but queue filters become hard-linked to
packet filter ruleset.
I think, there is a reasons to let queueing filters to can be
independed from packet filter rules, if need.
Maybe, it means hard work for developers, maybe it is inpossible
at all ('cause, for example, hard deep-low-level dependings), I don't,
really, know. It's just an opinion and feeling, that separated options
must to can be configured separatelly.
Regards,
Ilya A. Kovalenko(mailto:[EMAIL PROTECTED])
S.A.
JSC Oganer-Service
Special Equipment Software section
