Re: [Fed-Talk] Firewall
Re: [Fed-Talk] Firewall
- Subject: Re: [Fed-Talk] Firewall
- From: Michael <email@hidden>
- Date: Thu, 10 Apr 2008 09:58:36 -0400
On Apr 10, 2008, at 12:31 AM, Boyd Fletcher wrote:
On 4/8/08 5:17 PM, "Boyd Fletcher" <email@hidden> wrote:
On 4/8/08 9:59 AM, "Michael" <email@hidden> wrote:
If you liked the GUI Firewall in OS X 10.3 and 10.4 then you didn't
understand how big the holes in it were. To deal with those holes
you
either did by hand which you can still do in 10.5 or you used a
third-
party GUI program to configure ipfw, i.e. Brickhouse. There is no
reason those programs shouldn't still work.
I understand them quite well. We use a considerable number of "non-
native"
mac apps (i.e. unix apps) and being able to explicitly set ports and
protocols is much better. the 10.5 doesn't work with "non-native"
apps.
There are two points with explicitly setting ports and protocols with
10.3. and 10.4 firewall.
Opening incoming ports and protocols via the GUI was all very nice.
You open an incoming port and protocol and it applies to all
applications on your computer. Under OS 10.5 you should be able to
instead set a specific application to be permitted to listen on
whatever ports it opens. Perhaps you have specific bugs with the new
firewall regarding unix servers you're running under OS X, I don't
have a good test for that (sshd comes with OS X so that does not meet
the requirement of a non-native app and I locked my configuration down
to tight anyway).
Your statement says that you are running a considerable number of unix
servers because the 10.5 firewall only blocks servers and not
applications that wish to talk to servers on other machines. File a
specific bug report with Apple regarding specific unix applications
that don't work with 10.5's firewall unless you turn it off, seems
obvious you shouldn't tell the world the names of those apps and what
ports they listen on, perhaps you can give Apple an example case that
you may not be running.
2) What I'm referring to is all the ports and protocols that the GUI
in 10.3 and 10.4 left open by default. What's the point of a firewall
with so many ways to get around it.
Your original point was that "Apple chose to degrade the firewall
capability in leopard from the much better one in Tiger."
My point is that the one in Tiger was only better for someone running
unix servers and who didn't care that the firewall didn't really do
much to protect them.
my point is that you should not have to install a 3rd party app to
configure
the firewall. apple should provide a suitable GUI that let's you do
it.
My point is that you had to install a 3rd party app to configure the
Firewall under 10.3 and 10.4 unless you were happy with the limited
number of ports and protocols it blocked and that the 10.5 Application-
based firewall is likely more secure.
in the current approach I have to write a bunch of ipfw rules by
hand and I
really have better things to be doing than writing firewall
policies for my
boxes.
If you weren't writing firewall rules by hand under 10.3 and 10.4 then
you had a very limited firewall.
Flaws in 10.4 standard firewall:
<http://prefetch.net/blog/index.php/2006/08/13/locking-down-the-os-x-firewall/
>
"all UDP datagrams with source port 67 or 5353 are allowed in (this
allows you to talk to ntpd and cups, which have a rocky security
history)."
"the default configuration blocks ICMP type code 8 (ICMP echo
requests), but allows all other ICMP traffic in."
"bonjour and the service locator to pollute your network with the
version of OS X you are running, and the hardware architecture you are
running on (this is a shell coders dream!)"
-----
The standard 10.4.11 firewall rules, blocking all udp traffic and
enabled stealth mode.
02000 allow ip from any to any via lo*
02010 deny ip from 127.0.0.0/8 to any in
02020 deny ip from any to 127.0.0.0/8 in
02030 deny ip from 224.0.0.0/3 to any in
02040 deny tcp from any to 224.0.0.0/3 in
02050 allow tcp from any to any out
-- any application can talk out using virtually any TCP source port
(user level apps are restricted by the OS from port 0-1024 I believe)
02060 allow tcp from any to any established
02065 allow tcp from any to any frag
-- any computer on the network can connect to any TCP port on your
computer by setting either the established and fragmented flags.
Great for scanning OS X computers and more. I found my home OS X
machine being obviously scanned by this method.
12190 deny log tcp from any to any
20000 deny log icmp from any to me in icmptypes 8
As the guy said, only one type of icmp traffic is blocked.
20310 allow udp from any to any dst-port 53 in
why? udp port 53 should only be open for incoming if you are running a
DNS server. Something with Bonjour? but it permits all computers on
the Internet access to your machine.
20320 allow udp from any to any dst-port 68 in
udp port 68 should only be open for incoming if you are running a
Bootp server.
20321 allow udp from any 67 to me in
20322 allow udp from any 5353 to me in
Like the guy said - any udp port on your machine is accessible if the
attacking computer sets the source port to 67 or 5353.
20340 allow udp from any to any dst-port 137 in
Listening for NETBIOS which even WinXP's firewall blocks
20350 allow udp from any to any dst-port 427 in
All machines get to query your machine for services?
20360 allow udp from any to any dst-port 631 in
Print sharing port open even if you are not print sharing
20370 allow udp from any to any dst-port 5353 in
mDNS ports open even if you don't need or want Bonjour access to and
from your computer
30510 allow udp from me to any out keep-state
-- any application can talk out on UDP.
30520 allow udp from any to any in frag
-- connect to any UDP port on your machine by setting the fragmented
flag.
35000 deny log udp from any to any in
65535 allow ip from any to any
all 254 remaining protocols are permitted in, one assumes none of
those present a risk, but any application on your machine can listen
for those protocols and a couple of those might even pass though
routers.
Michael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden