Re: Newbie question.
On Jun 22, 2005, at 11:39 AM, Henning Brauer wrote:
* Kelley Reynolds <[EMAIL PROTECTED]> [2005-06-22 15:24]:
One thing to note on a semi-related topic is that when specifying
subnets in tables, as of 3.7-RELEASE, subnets that weren't /24 (or
probably /16 or /8) didn't work.
I highly doubt that (and it is the first time I hear this)
Here is an excerpt from a message I wrote on June 9
# This contains localnet traffic that does not go out a T (shouldn't
be limited to 1.5 or state tracked)
table persist { x.x.12.0/24 x.x.13.0/24 x.x.14.0/24 x.x.
15.0/24 }
..
On a somewhat related note, the localnet rule applies if I specify
each class C but the rule ceases to match if I use a CIDR x.x.12.0/22.
Now, I understand missing that since it isn't exactly a bug report.
Regardless, unfortunately for me and fortunately for everybody else
it works now, which means I was merely incompetent previously.
Never mind and keep up the good work.
Kelley Reynolds
President
Inside Systems, Inc.
Re: Newbie question.
* Kelley Reynolds <[EMAIL PROTECTED]> [2005-06-22 15:24]: > One thing to note on a semi-related topic is that when specifying > subnets in tables, as of 3.7-RELEASE, subnets that weren't /24 (or > probably /16 or /8) didn't work. I highly doubt that (and it is the first time I hear this)
Re: Newbie question.
Jason Dixon wrote:
> On Jun 21, 2005, at 6:24 PM, Bill Swisher wrote:
>
>> After reading over the pf-faq.pdf file I have, at this time, one
>> question. The home/small office example assumes that the internet
>> lives off of "ep0". In my case this is partially true. What really
>> is there is a router running on the network 192.168.2.* (my internal
>> network is the standard 192.168.1.*) and if I use the command "block
>> drop in quick on $ext if from $priv_nets" and it's corresponding
>> output block I'd pretty much be sitting deaf and mute, as far as the
>> rest of the computing world goes near as I can figure.
>>
>> I like that router! It does the PPoE for me, along with minimal
>> blocking. I don't want to toss it.
>>
>> Anyone have a way around this?
>
> priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
> !192.168.2.0/24 }"
or just drop these lines altogether.
This is much more a "feel good" line than something that adds a serious
measure of security.
There are lots of other addresses that nothing should be coming from.
Stuff will come from them anyway. Trying to itemize them is more
hazzardous than it is worth (they will likely get allocated later), and
even then, there is no reason a spoofed address can't claim to come from
a perfectly valid IP address. Thus, your protection from spoofed
addresses will most likely have to come from other places. These lines
adds little.
Nick.
Re: Newbie question.
One thing to note on a semi-related topic is that when specifying
subnets in tables, as of 3.7-RELEASE, subnets that weren't /24 (or
probably /16 or /8) didn't work. I had a /22 subnet which didn't work
where specifying the 4 class C's using /24 did. I mentioned it before
but it was either trivially fixed or missed somewhere.
Kelley Reynolds
President
Inside Systems, Inc.
On Jun 21, 2005, at 8:23 PM, Jason Dixon wrote:
On Jun 21, 2005, at 6:24 PM, Bill Swisher wrote:
After reading over the pf-faq.pdf file I have, at this time, one
question. The home/small office example assumes that the internet
lives off of "ep0". In my case this is partially true. What
really is there is a router running on the network 192.168.2.* (my
internal network is the standard 192.168.1.*) and if I use the
command "block drop in quick on $ext if from $priv_nets" and it's
corresponding output block I'd pretty much be sitting deaf and
mute, as far as the rest of the computing world goes near as I can
figure.
I like that router! It does the PPoE for me, along with minimal
blocking. I don't want to toss it.
Anyone have a way around this?
priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12,
10.0.0.0/8, !192.168.2.0/24 }"
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net
Re: Newbie question.
On Jun 21, 2005, at 10:00 PM, Jason Opperisano wrote:
priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
!192.168.2.0/24 }"
i'm certainly missing something here, as i am somewhat new-ish to pf
(long time with ipf, though)...
the above macro definition of priv_nets will create the rules:
block drop in quick on ep0 inet from 127.0.0.0/8 to any
block drop in quick on ep0 inet from 192.168.0.0/16 to any
block drop in quick on ep0 inet from 172.16.0.0/12 to any
block drop in quick on ep0 inet from 10.0.0.0/8 to any
block drop in quick on ep0 inet from ! 192.168.2.0/24 to any
where the second rule will drop traffic from 192.168.2.0/24, and the
fifth rule will effectively drop all other traffic.
Duh, thanks for catching that. I shot from the hip while running out
the door for a meeting. :-P
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net
Re: Newbie question.
On Tue, Jun 21, 2005 at 08:23:49PM -0400, Jason Dixon wrote:
> On Jun 21, 2005, at 6:24 PM, Bill Swisher wrote:
>
> >After reading over the pf-faq.pdf file I have, at this time, one
> >question. The home/small office example assumes that the internet
> >lives off of "ep0". In my case this is partially true. What really
> >is there is a router running on the network 192.168.2.* (my internal
> >network is the standard 192.168.1.*) and if I use the command "block
> >drop in quick on $ext if from $priv_nets" and it's corresponding
> >output block I'd pretty much be sitting deaf and mute, as far as the
> >rest of the computing world goes near as I can figure.
> >
> >I like that router! It does the PPoE for me, along with minimal
> >blocking. I don't want to toss it.
> >
> >Anyone have a way around this?
>
> priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
> !192.168.2.0/24 }"
i'm certainly missing something here, as i am somewhat new-ish to pf
(long time with ipf, though)...
the above macro definition of priv_nets will create the rules:
block drop in quick on ep0 inet from 127.0.0.0/8 to any
block drop in quick on ep0 inet from 192.168.0.0/16 to any
block drop in quick on ep0 inet from 172.16.0.0/12 to any
block drop in quick on ep0 inet from 10.0.0.0/8 to any
block drop in quick on ep0 inet from ! 192.168.2.0/24 to any
where the second rule will drop traffic from 192.168.2.0/24, and the
fifth rule will effectively drop all other traffic.
in my experience--lists of networks/IP's that need to be negated always
seem to need to go in a table to work properly. now i never tried this
before, but i just tested it (on 3.7-release), and it appears to work
(tables *really* kick ass):
ext_if = "ep0"
table const \
{ 127/8, 10/8, 172.16/12, 192.168/16, !192.168.2/24 }
block drop in quick on $ext_if from
with that--traffic from the RFC1918 space plus the loopback net (*) gets
dropped, but 192.168.2.0/24 gets to the next rule.
HTH...
-j
(*) i'm pretty sure that the openbsd routing code drops traffic from
127/8 received "on the wire" before pf ever sees it--so the inclusion of
127/8 in the table is not strictly necessary.
--
"Stewie: Damn you, vile woman, you've impeded my work since the day I
escaped your wretched womb."
--Family Guy
Re: Newbie question.
Bill Swisher wrote: After reading over the pf-faq.pdf file I have, at this time, one question. The home/small office example assumes that the internet lives off of "ep0". In my case this is partially true. What really is there is a router running on the network 192.168.2.* (my internal network is the standard 192.168.1.*) and if I use the command "block drop in quick on $ext if from $priv_nets" and it's corresponding output block I'd pretty much be sitting deaf and mute, as far as the rest of the computing world goes near as I can figure. I like that router! It does the PPoE for me, along with minimal PPPoE blocking. I don't want to toss it. Anyone have a way around this? I'm no pf expert but why not just remove the 192.168.2. subnet from $priv_nets? (That's what I did). Regards, -- Gudni Thor Bjorgvinsson <[EMAIL PROTECTED]>
Re: Newbie question.
On Jun 21, 2005, at 6:24 PM, Bill Swisher wrote:
After reading over the pf-faq.pdf file I have, at this time, one
question. The home/small office example assumes that the internet
lives off of "ep0". In my case this is partially true. What really
is there is a router running on the network 192.168.2.* (my internal
network is the standard 192.168.1.*) and if I use the command "block
drop in quick on $ext if from $priv_nets" and it's corresponding
output block I'd pretty much be sitting deaf and mute, as far as the
rest of the computing world goes near as I can figure.
I like that router! It does the PPoE for me, along with minimal
blocking. I don't want to toss it.
Anyone have a way around this?
priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
!192.168.2.0/24 }"
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net
Newbie question.
After reading over the pf-faq.pdf file I have, at this time, one question. The home/small office example assumes that the internet lives off of "ep0". In my case this is partially true. What really is there is a router running on the network 192.168.2.* (my internal network is the standard 192.168.1.*) and if I use the command "block drop in quick on $ext if from $priv_nets" and it's corresponding output block I'd pretty much be sitting deaf and mute, as far as the rest of the computing world goes near as I can figure. I like that router! It does the PPoE for me, along with minimal blocking. I don't want to toss it. Anyone have a way around this? -- While you don't greatly need the outside world, it's still very reassuring to know that it's still there.
Re: newbie question about "user = " feature
No, there was no bug where I suspected one. If rules with 'user = unknown' don't match packets, that means those packets are part of connections that originate from or end on the firewall itself. You mention SSH and NTP traffic. Are you sure you're not ssh'ing from or into the firewall? And sure that it's not the firewall doing NTP queries (or answering NTP queries)? I agree it's annoying that the uid/gid of the packet isn't logged, but the reason is that the lookup isn't cheap, and doing it for all logged packets would make logging a more expensive operation. Can you provide a pflog output line which shows a packet that you expect to be passed by a rule using 'user = unknown'? Daniel
Re: newbie question about "user = " feature
On Tue, Jul 01, 2003 at 09:17:30PM -0400, T. wrote: > And so on, and so forth. Unfortunately, I haven't had consistent success with this > strategy. Specifically, I've run into situations where the SSH or NTP traffic above > is blocked by PF even though it should, theoretically, match the rules I've written. > My pflogd output hasn't really help much because it doesn't show what pf thinks the > user is. However, I think the problem is related to the "user = " logic because, if > I remove the "user = unknown" bits from the rules above, pf permits the traffic. Hmm, I think there is a bug for 'user = unknown', while 'user != unknown' works. I'll have to check more closely. If you only want to pass forwarded connections, you can work around the problem with something like block log quick all user != unknown pass out all keep state pass in proto tcp from foo to bar port = 22 flags S/FSRPAUEW keep state ... The 'quick' option on the block rule will abort ruleset evalution for packets with known user (connections originating from or ending on the firewall), hence you don't need the 'user = unknown' on subsequent rules anymore. Daniel
newbie question about "user = " feature
Greetings, PF experts. I'm new to PF and quite intrigued by the "user = unknown" (or "user = root" or "user = ") capability of PF. I've been doing a bit of testing and was hoping to find a pointer to some documentation that might help me understand my results a bit more clearly. Specifically, I have some rules that look like this: set block-policy drop set optimization aggressive block log all block log all user != unknown pass out all user = unknown keep state [...] pass in proto tcp from foo to bar port = 22 user = unknown flags S/FSRPAUEW keep state pass in proto udp from abc to def pot = 123 user = unknown keep state [...] And so on, and so forth. Unfortunately, I haven't had consistent success with this strategy. Specifically, I've run into situations where the SSH or NTP traffic above is blocked by PF even though it should, theoretically, match the rules I've written. My pflogd output hasn't really help much because it doesn't show what pf thinks the user is. However, I think the problem is related to the "user = " logic because, if I remove the "user = unknown" bits from the rules above, pf permits the traffic. So... can anyone please provide some information on how pf decides who the user is associated with a given packet? The pf.conf man page reads: For forwarded connections, where the firewall is not a connection endpoint, the user and group are unknown. However, this doesn't seem to be the case on at least two of my test systems, which are running OpenBSD 3.3 (GENERIC#37 with some features stripped out, i.e. ipv6) and is blocking routed NTP connections (amongst other things) when "user = unknown" is part of the NTP rule. This also happen for some TCP connections as well, for what it's worth. The worst part is that a third system, running an identical kernel and similar rulesets, is not exhibiting the same behavior for a slightly different connection profile (it's routing primarily a home-grown TCP application). Thanks in advance. T.E. ___ Join Excite! - http://www.excite.com The most personalized portal on the Web!
Re: newbie question
Nathan Fisher <[EMAIL PROTECTED]> wrote : > I'm a newbie myself, isn't it best to lock out all > inbound connections and then open up only the services you want to > provide? Can anyone tell me if this would be an appropriate > configuration for a trusted network w/ a 2 port router? Yes : it's better to use this solution and a 2-port firewall. Block all inbound connections and allow only connections for services with redirection. > # BEGIN /etc/pf.conf > > #- variables - > > ExtIF="dc1" [...] > FlagsOSfinger="flags FUP/FUP" > #- end variables - Maybe, too many macros and the conf becomes more difficult to read : suppress "Flags" and "Tcp" variables if you want. > # immediate block of private IP's > block in log quick on $ExtIF inet from $PrivateIPs to any > block out log quick on $ExtIF inet from any to $PrivateIPs You can replace these rules with 'antispoof' keyword : see pf.conf(5) > #- stateful services - > # Is this section correct? Yes this section is correct : redirection of inbound HTTP and SMTP connections to internal HTTP and SMTP servers. A++ Foxy. -- Laurent Cheylus <[EMAIL PROTECTED]> OpenPGP ID 0x5B766EC2
Re: newbie question
Hello,
I'm a newbie myself, isn't it best to lock out all
inbound connections and then open up only the services you want to
provide? Can anyone tell me if this would be an appropriate
configuration for a trusted network w/ a 2 port router? I placed
questions in the configuration for points of my concern. What
improvements would you suggest to balance between log size and
information effective for auditing? I could only test part of the
configuration, because I have a LinkSYS doing NAT and my machine is
headless in the basement. Needless to say I didn't want to lock myself
out playing with NAT on a private network. Hopefully this doesn't
stretch the bounds of an appropriate question for this mailing list.
Thanks for any help.
Regards,
Nathan
# BEGIN /etc/pf.conf
#- variables -
ExtIF="dc1"
IntraIF="dc0"
IntraNet="192.168.0.0/16"
IPv4="x.x.x.x"
IPv4wMask="x.x.x.x/32"
# all private IP's, network address, broadcast address, loopback, and MS
# autoconfig
PrivateIPs="{ 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16,
172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 }"
# substitute server IP's accordingly
Http="port { http, https }"
Http_IP="192.168.0.4"
Mail="port smtp"
Mail_IP="192.168.0.5"
Tcp="proto tcp"
NonTcp="proto {udp, icmp}"
FlagsSynAwkSeq="flags S/SA"
FlagsOSfinger="flags FUP/FUP"
#- end variables -
# reassemble packets
scrub in all
# IPv4 nat
nat on $ExtIF from $IntraNet to any -> $IPv4
# quick blocks -
# immediate block of private IP's
block in log quick on $ExtIF inet from $PrivateIPs to any
block out log quick on $ExtIF inet from any to $PrivateIPs
# immediate block of IPv6 (I think)
block out log quick on $ExtIF from !$IPv4 to any
# immediate block of nmap style OS finger printing
block in log quick on $ExtIF inet $Tcp from any to any $FlagsOSfinger
# end quick blocks -
# block all inbound connections open up services below
block in on $ExtIF all
#- stateful services -
# Is this section correct?
# http server
rdr in log on $ExtIF inet $Tcp from any to $IPv4wMask $Http ->
$Http_IP $Http $FlagsSynAwkSeq modulate state
# mail server
rdr in log on $ExtIF inet $Tcp from any to $IPv4wMask $Mail ->
$Mail_IP $Mail $FlagsSynAwkSeq modulate state
# end services -
# block all outbound and make stateful connections
block out on $ExtIF inet $Tcp all
# Would logging be appropriate here even with a trusted network?
pass out on $ExtIF inet $Tcp all $FlagsSynAwkSeq modulate state
pass out on $ExtIF inet $NonTcp keep state
# END /etc/pf.conf
Re: newbie question
On Sun, Feb 16, 2003 at 06:18:06PM +0100, Peter Hun?ár wrote: > pass in log all > > So I'm trying to block these ports, but it doesn't work I'm still able > to connect to postgres running on that machine. you're not testing from another machine that is on the same network as dc0 are you? i assume the pflog shows the db traffic matching on "pass in log all" rule? > It's an old machine. Can I use it as a firewall/NAT for approximately > 200 win computers? (campus) People have done more with less :) - jolan
newbie question
Title: newbie question
Hi
I’m currently trying to run an OpenBSD firewall, I’ve read the man pages, but probably I’m doing something wrong…
I’m running OBSD 3.2 stable with NAT (NAT works fine) now I’m playing with pf rules.
e.g.
dc1 – external xxx.xxx.xxx.xxx
dc0 – internal 192.168.1.1
scrub in all
nat on dc1 from 192.168.0.0/16 to any -> xxx.xxx.xxx.xxx
block in log quick on dc1 proto { tcp, udp } from any to xxx.xxx.xxx.xxx \
port { 5432, 5801, 5901, 6001 }
block out log quick on dc1 from ! xxx.xxx.xxx.xxx to any
block in quick on dc1 from any to 255.255.255.255
block in log quick on dc1 from { 10.0.0.0/8, 172.16.0.0/12, \
192.168.0.0/16, 255.255.255.255/32 } to any
pass in log all
pass out all
So I’m trying to block these ports, but it doesn’t work I’m still able to connect to postgres running on that machine…
(I know that I can block it in pg_hba.conf but that’s not the question) Even if I put both pass rules in front of the block rules
as I was advised in [EMAIL PROTECTED] nothing will change.
And the last question:
The machine is Pentium Pro 200 MMX with 64MB SIMM RAM two DEC 21142/3 interfaces and 2.5GB 3600rpm IDE drive
It’s an old machine. Can I use it as a firewall/NAT for approximately 200 win computers? (campus)
Thank you
Hunci
Peter Huncar
SP SCCh FChPT STU
RE: newbie question
Peter, If you want to learn about TCP/IP, especially in regards to UNIX, the best book on the market is: TCP/IP Illustrated, Volume 1 by W. Richard Stevens You might even be able to get it in Slovakian as it is widely translated. This book thoroughly dissects TCP/IP. An excellent general book on Firewalls is: Building Internet Firewalls, 2nd Edition by Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman After you've read this, another good book is: Network Intrusion Detection, 3rd Edition by Stephen Northcutt and Judy Novak This is a good book to learn about security internals as you have to really understand how things work to effectively implement a Network Intrusion Detection system. Of course, if Daniel decides to write a book, I would recommend that... Otherwise, the OpenBSD Networking FAQ is also a good place to look: http://www.openbsd.org/faq/faq6.html <> Jim -Original Message- May I ask you something before I ask you something? If I want to learn more about TCP/IP and that kind of stuff to better understand firewalling, are there any (there are many I know, but that's the problem (: ) 'good' tutorials or FAQs or documentation on 'the net' I should study before I send some questions here? You know what I mean. :) About flags, attacks, sniffers, port scans and so on. I spend 70% of my time allocated to learn more about this only by searching for some good documentation. So would you be please so kind and direct me to some links where I can find 'the knowldege'? :o) Thank you very much. Peter Hunčár ŠCCh FChPT STU
newbie question
Hi! May I ask you something before I ask you something? If I want to learn more about TCP/IP and that kind of stuff to better understand firewalling, are there any (there are many I know, but that's the problem (: ) 'good' tutorials or FAQs or documentation on 'the net' I should study before I send some questions here? You know what I mean. :) About flags, attacks, sniffers, port scans and so on. I spend 70% of my time allocated to learn more about this only by searching for some good documentation. So would you be please so kind and direct me to some links where I can find 'the knowldege'? :o) Thank you very much. Peter Hunčár ŠCCh FChPT STU
Re: Newbie Question (one of many to come)
On Mon, Aug 12, 2002 at 03:27:35PM -0700, Chris Willis wrote: > I did not want to discuss the particular application, as it was developed > by an outside vendor for us to use. It is a confidential app. > > Besides, the application is not of consequence. It matters whether the protocol embeds client IP addresses inside the data stream. There are many such protocols that don't survive NAT at all. If you don't know or can't tell, try the procedure I suggested to find out. > The logistical problems don't seem that big of a deal. If the server > records that 192.168.100.100 sends out tcp 5000 packets to 20.20.20.20, > then it should have no problem knowing that udp 4900-1 should go back to > 192.168.100.100. Heck, it probably isn't even much extra code. In case of instant messaging clients and online games, there will be multiple concurrent connections, and the problem is forwarding the back-channels to the right local client. The firewall gets an incoming UDP packet to port 4900. It checks the state table and sees the following established TCP connections: 192.168.100.100:60001 -> $ext_if:55001 -> 20.20.20.20:5000 192.168.100.101:60001 -> $ext_if:55002 -> 20.20.20.20:5000 192.168.100.200:61234 -> $ext_if:55003 -> 20.20.20.20:5000 Where should the incoming UDP packet be forwarded to? .100, .101 or .200? If you're claiming general usefulness for a broad range of protocols, you have to address this case. Daniel
RE: Newbie Question (one of many to come)
>Well, the admins who would potentially use this proposed feature, yes. >It would not take a lot of effort to trick the firewall into exposing >the ports. People aren't perfectly capable of writing a good ruleset. >This is evident from the amount of traffic on the mailing lists asking >for assistance in creating rudimentary rule sets. I agree, most people seem to require assistance with basic rulesets. However, can someone offer an example of how the proposed feature could be exploited from the outside? Assuming there is no NAT... can't think of anything myself. Cheers, Adrian.
Re: Newbie Question (one of many to come)
On Mon, Aug 12, 2002 at 03:27:35PM -0700, Chris Willis wrote: > I did not want to discuss the particular application, as it was developed > by an outside vendor for us to use. It is a confidential app. It would have be nice if you had mentioned this initially. Perhaps the application itself could be modified. > Besides, the application is not of consequence. Actually it sort of is. Seeing as you're making suggestions to modify the behavior of a low level packet filter in order to ensure that the application performs correctly. > The logistical problems don't seem that big of a deal. If the server > records that 192.168.100.100 sends out tcp 5000 packets to 20.20.20.20, > then it should have no problem knowing that udp 4900-1 should go back to > 192.168.100.100. Heck, it probably isn't even much extra code. You might want to actually look at the code before making such statements. Or perhaps you can do it yourself since it isn't even much extra code. > putting words into my email that I never typed. Actually, the mod that I > proposed would be great with the majority of IM and P2P clients out > there, wouldn't it? No it wouldn't. What are you talking about? > And finally, you say that sysadmins would ruin rulesets? Why are you so > intent on treating people like children? You should operate on the > assumption that people are perfectly capable of writing a good ruleset. > When you operate on the assumption that people are incompetent, you just > come off as very arrogant. I certainly don't enjoy dealing with arrogant > people. Well, the admins who would potentially use this proposed feature, yes. It would not take a lot of effort to trick the firewall into exposing the ports. People aren't perfectly capable of writing a good ruleset. This is evident from the amount of traffic on the mailing lists asking for assistance in creating rudimentary rule sets.
Re: Newbie Question (one of many to come)
I did not want to discuss the particular application, as it was developed by an outside vendor for us to use. It is a confidential app. Besides, the application is not of consequence. The logistical problems don't seem that big of a deal. If the server records that 192.168.100.100 sends out tcp 5000 packets to 20.20.20.20, then it should have no problem knowing that udp 4900-1 should go back to 192.168.100.100. Heck, it probably isn't even much extra code. You can translate all you wish - that is not my fault that you are putting words into my email that I never typed. Actually, the mod that I proposed would be great with the majority of IM and P2P clients out there, wouldn't it? And finally, you say that sysadmins would ruin rulesets? Why are you so intent on treating people like children? You should operate on the assumption that people are perfectly capable of writing a good ruleset. When you operate on the assumption that people are incompetent, you just come off as very arrogant. I certainly don't enjoy dealing with arrogant people. -Original Message- From: Jolan Luff <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Mon, 12 Aug 2002 13:38:17 -0400 Subject: Re: Newbie Question (one of many to come) > On Mon, Aug 12, 2002 at 10:16:34AM -0700, Chris Willis wrote: > > I am puzzled still. No one can explain why it is bloated junk. It > would > > assist people who need to handle complex applications with their > firewall. > > Daniel gave a rather good explanation as to the logistical problems to > implement something such as this. He also pointed out why it is > somewhat pointless. Adding complexities such as this to pf for little > gain means bloat. Think of it as "cost benefit analysis". > > When you say "It would assist people..." I translate that as "me". > When you say "handle complex applications" I translate that as "create > a good method for system administrators to ruin rulesets". > > Of course, if you took the time to reply to Daniel's last e-mail on the > subject and explained in more detail what the particulars of this > application are, maybe people would be more receptive. > > - jolan
Re: Newbie Question (one of many to come)
On Mon, Aug 12, 2002 at 10:16:34AM -0700, Chris Willis wrote: > I am puzzled still. No one can explain why it is bloated junk. It would > assist people who need to handle complex applications with their firewall. Daniel gave a rather good explanation as to the logistical problems to implement something such as this. He also pointed out why it is somewhat pointless. Adding complexities such as this to pf for little gain means bloat. Think of it as "cost benefit analysis". When you say "It would assist people..." I translate that as "me". When you say "handle complex applications" I translate that as "create a good method for system administrators to ruin rulesets". Of course, if you took the time to reply to Daniel's last e-mail on the subject and explained in more detail what the particulars of this application are, maybe people would be more receptive. - jolan
Re: Newbie Question (one of many to come)
I am puzzled still. No one can explain why it is bloated junk. It would assist people who need to handle complex applications with their firewall. Anyways, it isn't a big deal. I understand that netfilter on Linux can perform this functionality. I will simply switch over to a Linux box as my firewall. Thanx everyone! Chris -Original Message- From: Henning Brauer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Mon, 12 Aug 2002 10:25:24 +0200 Subject: Re: Newbie Question (one of many to come) > On Sat, Aug 10, 2002 at 06:21:26PM -0700, Chris Willis wrote: > > enet = ne3 > > inet = xl0 > > X=192.168.100.100 > > If port 5000 from $X to any on $inet then > > pass all in $enet udp 4900-4901 > > rdr udp 4900-4901 to $X > > else block in all in $enet udp 4900-4901 > > > > X should be variable (depending on what machine is trying to do the > > outbound traffic) > > enet is my external network card (attached to a router on the > internet) > > inet is my internal LAN (192.168.100.1) > > > > This would not require any authentication, since my internal > workstation > > is a trusted entity already (its my own computer). > > > > This would be VERY useful functionality to have in pF. > > No. That's bloated junk. >
Re: Newbie Question (one of many to come)
On Sat, Aug 10, 2002 at 06:21:26PM -0700, Chris Willis wrote: > enet = ne3 > inet = xl0 > X=192.168.100.100 > If port 5000 from $X to any on $inet then > pass all in $enet udp 4900-4901 > rdr udp 4900-4901 to $X > else block in all in $enet udp 4900-4901 > > X should be variable (depending on what machine is trying to do the > outbound traffic) > enet is my external network card (attached to a router on the internet) > inet is my internal LAN (192.168.100.1) > > This would not require any authentication, since my internal workstation > is a trusted entity already (its my own computer). > > This would be VERY useful functionality to have in pF. No. That's bloated junk. msg00071/pgp0.pgp Description: PGP signature
RE: Newbie Question (one of many to come)
Why would an attacker fine-tune a firewall? Do you mean that this would be a fine way to fine-tune an attack on a firewall? Sure, I guess it would - all you would have to do is port scan a machine over and over again, until you see those ports open up, then attack the machine thru those ports. But since you can attack thru existing ports anyways (web, ftp, etc..) then who cares if additional ports are open once in a while or not? If the individual admin is OK with the addtional risk, they why would you guys care? -Original Message- From: "Ed White" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Sun, 11 Aug 2002 13:33:58 +0200 Subject: RE: Newbie Question (one of many to come) > > I think it would be an EXCELLENT way for a corporate administrator to > fine-tune their firewall > > to their particular environment. > > I think it would be an EXCELLENT way for an attacker to fine-tune their > firewall to his particular environment. > This is "Security" Through Obscurity. > > Ed >
Re: Newbie Question (one of many to come)
On Sat, Aug 10, 2002 at 06:21:26PM -0700, Chris Willis wrote: > This would be VERY useful functionality to have in pF. By having pF look > for a trigger port (in this case, a connection outbound on tcp/5000) > BEFORE it opens ports for the inbound traffic, you can setup complex > rules that only activate when a certain application is requesting > communications thru the firewall. Ok, I see what you mean. But it's not as simple as you might think, especially when these connections are NATed as well. First question is, what applications/protocols depend on this? I can only think of H.323 (voice over IP) and games. I don't know about the latter much, but the former wouldn't work even with such a 'trigger' setup, because the protocol transfers client IP addresses inside the data portion of packets as well, which would require translation by a proxy. In general, you can try to statically forward the UDP ports to a single local host (and pass them with filter rules) and then try to use the protocol from that local host. If that doesn't work, it's likely because the client embeds its (private) address in the data, and the external server uses it to connect back. We are talking about protocols that were not created with NAT and firewalls in mind, otherwise they'd use the single TCP connection as single channel. I mean, these multiple UDP backchannels are worse than ftp. The second issue occurs when multiple local hosts connect to the same external server with such protocols concurrently. A single redirection for incoming UDP packets would not deal with this sufficiently, you'd want to associate UDP streams with individual TCP connections and forward to the right internal host. This requires that the incoming UDP packets have some criterion (like external source port) that allows such a distinction. I don't think cluttering the packet filter syntax with such monstruous constructs is the way to go. Rather, I could imagine a userland proxy on the firewall that intercepts the outgoing TCP connections and then dynamically adds/removes filter and translation rules for the incoming UDP streams to the local hosts, similar to what authpf does, but without the authentication. If you don't mind the authentication, authpf could already do that. If the protocol transmits client IP addresses as data, the proxy has to understand the data and translate them. That's why a H.323 proxy is a non-trivial project. ftp-proxy does that for ftp, but the ftp protocol is simple, compared to H.323. > I don't think this would be feature bloat - I think it would be an > EXCELLENT way for a corporate administrator to fine-tune their firewall > to their particular environment. It's also a fine way to poke huge holes into the firewall if not used very carefully. And looking at netfilter example rule sets, I see plenty of misuses that allow _external_ hosts to trigger the rule relaxations. Daniel
RE: Newbie Question (one of many to come)
> I think it would be an EXCELLENT way for a corporate administrator to fine-tune their firewall > to their particular environment. I think it would be an EXCELLENT way for an attacker to fine-tune their firewall to his particular environment. This is "Security" Through Obscurity. Ed
Re: Newbie Question (one of many to come)
Sorry if this is too wordy. And let me know if it doesn't make any sense. I think I didn't communicate my thoughts clearly. If my Internal Workstation (192.168.100.100) has a stateful connection to the internet (tcp 5000 to 20.20.20.20) that is already open and in your state table(s), then I want pF to allow UDP ports 4900-4901 back to my internal workstation (192.168.100.100). If my internal workstation doesn't have that tcp 5000 port open to an internet address, then I don't want pF to leave 4900&4901 open. Sort of like this (this isn't proper syntax, just my attempt to show the logic behind what I am asking about): enet = ne3 inet = xl0 X=192.168.100.100 If port 5000 from $X to any on $inet then pass all in $enet udp 4900-4901 rdr udp 4900-4901 to $X else block in all in $enet udp 4900-4901 X should be variable (depending on what machine is trying to do the outbound traffic) enet is my external network card (attached to a router on the internet) inet is my internal LAN (192.168.100.1) This would not require any authentication, since my internal workstation is a trusted entity already (its my own computer). This would be VERY useful functionality to have in pF. By having pF look for a trigger port (in this case, a connection outbound on tcp/5000) BEFORE it opens ports for the inbound traffic, you can setup complex rules that only activate when a certain application is requesting communications thru the firewall. I don't think this would be feature bloat - I think it would be an EXCELLENT way for a corporate administrator to fine-tune their firewall to their particular environment. Chris -Original Message- From: Daniel Hartmeier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Sat, 10 Aug 2002 23:00:14 +0200 Subject: Re: Newbie Question (one of many to come) > On Sat, Aug 10, 2002 at 09:37:15AM -0700, Chris Willis wrote: > > > I would like to create a filter that allows 4900&4901 inbound to the > > machine that already has tcp 5000 open. If tcp 5000 isn't open, then > I > > do not want the UDP ports to be open inbound. > > Short answer: you can't. > > I know this is possible with Linux' netfilter, but I don't think it's a > feature that can be used securely. If you think about it, how does the > existing TCP connection authenticate the peer in any way that makes you > trust him more than the rest of the world? Anyone could establish that > TCP connection first and get access to the other ports. If you're not > allowing the whole world to establish the TCP connection (by blocking > on > peer address), you could use the same restrictions for the other ports. > > Ok, someone spoofing the source address couldn't complete a TCP > handshake, so the established TCP connection excludes that. But a > source > spoofer could just as well pick an address that is likely to have a TCP > connection already established with you and use that to send UDP > packets. > > There is a way to open ports after peers have truely authenticated > themselves: authpf(8). Logging in via ssh might seem overly > complicated, > but what you get in exchange is a real authentication, as compared to > security by obscurity that the 'related' (or whatever it's called in > netfilter) feature offers. > > Daniel
Re: Newbie Question (one of many to come)
On Sat, Aug 10, 2002 at 09:37:15AM -0700, Chris Willis wrote: > I would like to create a filter that allows 4900&4901 inbound to the > machine that already has tcp 5000 open. If tcp 5000 isn't open, then I > do not want the UDP ports to be open inbound. Short answer: you can't. I know this is possible with Linux' netfilter, but I don't think it's a feature that can be used securely. If you think about it, how does the existing TCP connection authenticate the peer in any way that makes you trust him more than the rest of the world? Anyone could establish that TCP connection first and get access to the other ports. If you're not allowing the whole world to establish the TCP connection (by blocking on peer address), you could use the same restrictions for the other ports. Ok, someone spoofing the source address couldn't complete a TCP handshake, so the established TCP connection excludes that. But a source spoofer could just as well pick an address that is likely to have a TCP connection already established with you and use that to send UDP packets. There is a way to open ports after peers have truely authenticated themselves: authpf(8). Logging in via ssh might seem overly complicated, but what you get in exchange is a real authentication, as compared to security by obscurity that the 'related' (or whatever it's called in netfilter) feature offers. Daniel
Newbie Question (one of many to come)
How can I setup a packet filter that works with a trigger? Example: I have an app that uses TCP 5000 for its connection state info, and UDP 4900 & 4901 for the actual work. I would like to create a filter that allows 4900&4901 inbound to the machine that already has tcp 5000 open. If tcp 5000 isn't open, then I do not want the UDP ports to be open inbound. Thanx! Chris
