info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mac OS X 10.8.2's firewall not enabled by default?
332 views
Skip to first unread message
Ant
Sep 22, 2012, 6:57:57 PM9/22/12
to
Hello.
Is it me or is Mountain Lion's firewall not enabled by default? I didn't
check in the preinstalled 10.7.x before I upgraded to it. I find that
weird and puzzled why Apple did that if that was by design.
Thank you in advance. :)
--
"What do ants and bees use for cattle?" --Tom
/\___/\ Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site)
/ /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net
| |o o| |
\ _ / If crediting, then use Ant nickname and AQFL URL/link.
( ) If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.
Is it me or is Mountain Lion's firewall not enabled by default? I didn't
check in the preinstalled 10.7.x before I upgraded to it. I find that
weird and puzzled why Apple did that if that was by design.
Thank you in advance. :)
--
"What do ants and bees use for cattle?" --Tom
/\___/\ Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site)
/ /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net
| |o o| |
\ _ / If crediting, then use Ant nickname and AQFL URL/link.
( ) If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.
Bob Harris
Sep 22, 2012, 7:48:04 PM9/22/12
to
In article <krOdndiGo_nr38PN...@earthlink.com>,
firewall by default.
But then again, by default Mac OS X does not enable ANY ports, so
there is nothing for the firewall to protect.
Keep in mind that the Firewall focuses on incoming connections,
and if there are not open ports, there is nothing to protect.
If you start enabling System Preferences -> Sharing services, then
you will be opening ports. If you are concerned about those
services being a risk, then enable your Firewall.
Be aware that sometimes the Firewall interferes with stuff you
expect to work. So if some of your network stuff is giving you
problems, try disabling your Firewall as an experiment, and if
things get better start looking at the Firewall setup to see if
there something you need to change.
Ant <a...@zimage.comANT> wrote:
> Hello.
>
> Is it me or is Mountain Lion's firewall not enabled by default? I didn't
> check in the preinstalled 10.7.x before I upgraded to it. I find that
> weird and puzzled why Apple did that if that was by design.
>
> Thank you in advance. :)
To the best of my knowledge no version of Mac OS X has enabled the
> Hello.
>
> Is it me or is Mountain Lion's firewall not enabled by default? I didn't
> check in the preinstalled 10.7.x before I upgraded to it. I find that
> weird and puzzled why Apple did that if that was by design.
>
> Thank you in advance. :)
firewall by default.
But then again, by default Mac OS X does not enable ANY ports, so
there is nothing for the firewall to protect.
Keep in mind that the Firewall focuses on incoming connections,
and if there are not open ports, there is nothing to protect.
If you start enabling System Preferences -> Sharing services, then
you will be opening ports. If you are concerned about those
services being a risk, then enable your Firewall.
Be aware that sometimes the Firewall interferes with stuff you
expect to work. So if some of your network stuff is giving you
problems, try disabling your Firewall as an experiment, and if
things get better start looking at the Firewall setup to see if
there something you need to change.
Ant
Sep 22, 2012, 8:03:50 PM9/22/12
to
On 9/22/2012 4:48 PM PT, Bob Harris typed:
> To the best of my knowledge no version of Mac OS X has enabled the
> firewall by default.
>
> But then again, by default Mac OS X does not enable ANY ports, so
> there is nothing for the firewall to protect.
>
> Keep in mind that the Firewall focuses on incoming connections,
> and if there are not open ports, there is nothing to protect.
>
> If you start enabling System Preferences -> Sharing services, then
> you will be opening ports. If you are concerned about those
> services being a risk, then enable your Firewall.
>
> Be aware that sometimes the Firewall interferes with stuff you
> expect to work. So if some of your network stuff is giving you
> problems, try disabling your Firewall as an experiment, and if
> things get better start looking at the Firewall setup to see if
> there something you need to change.
Thanks. I thought older versions did like in 10.5.x. :)
--
"... Ooh, we haven't done that in a long time. I love picnics. I'll
bring my ant jar." --The Berenstain Bears (unknown episode)
> To the best of my knowledge no version of Mac OS X has enabled the
> firewall by default.
>
> But then again, by default Mac OS X does not enable ANY ports, so
> there is nothing for the firewall to protect.
>
> Keep in mind that the Firewall focuses on incoming connections,
> and if there are not open ports, there is nothing to protect.
>
> If you start enabling System Preferences -> Sharing services, then
> you will be opening ports. If you are concerned about those
> services being a risk, then enable your Firewall.
>
> Be aware that sometimes the Firewall interferes with stuff you
> expect to work. So if some of your network stuff is giving you
> problems, try disabling your Firewall as an experiment, and if
> things get better start looking at the Firewall setup to see if
> there something you need to change.
--
"... Ooh, we haven't done that in a long time. I love picnics. I'll
bring my ant jar." --The Berenstain Bears (unknown episode)
Gerry
Sep 22, 2012, 8:53:10 PM9/22/12
to
> Hello.
>
> Is it me or is Mountain Lion's firewall not enabled by default? I didn't
> check in the preinstalled 10.7.x before I upgraded to it. I find that
> weird and puzzled why Apple did that if that was by design.
>
> Thank you in advance. :)
I upgraded from Lion to Mountain Lion and my Firewall is turned on, so
>
> Is it me or is Mountain Lion's firewall not enabled by default? I didn't
> check in the preinstalled 10.7.x before I upgraded to it. I find that
> weird and puzzled why Apple did that if that was by design.
>
> Thank you in advance. :)
the upgrade didn't change anything it only retained the same settings
that I had under Lion.
Alan Browne
Sep 22, 2012, 9:08:22 PM9/22/12
to
On 2012.09.22 18:57 , Ant wrote:
> Hello.
>
> Is it me or is Mountain Lion's firewall not enabled by default? I didn't
> check in the preinstalled 10.7.x before I upgraded to it. I find that
> weird and puzzled why Apple did that if that was by design.
If you're behind a router with a firewall activated I'd leave the Mac
> Hello.
>
> Is it me or is Mountain Lion's firewall not enabled by default? I didn't
> check in the preinstalled 10.7.x before I upgraded to it. I find that
> weird and puzzled why Apple did that if that was by design.
firewall off unless there are specific "trust" issues within that LAN's
user population. Some services (file sharing, printer sharing, screen
sharing) become flaky when the firewall is on.
Don't use "WiFi Protected Setup" - disable it at the WiFi.
If it's a portable, then don't forget to enable the firewall before
connecting to hotel/airport/café WiFi's ...
--
"There were, unfortunately, no great principles on which parties
were divided – politics became a mere struggle for office."
-Sir John A. Macdonald
Ant
Sep 22, 2012, 11:00:49 PM9/22/12
to
On 9/22/2012 6:08 PM PT, Alan Browne typed:
> If you're behind a router with a firewall activated I'd leave the Mac
> firewall off unless there are specific "trust" issues within that LAN's
> user population. Some services (file sharing, printer sharing, screen
> sharing) become flaky when the firewall is on.
>
> Don't use "WiFi Protected Setup" - disable it at the WiFi.
>
> If it's a portable, then don't forget to enable the firewall before
> connecting to hotel/airport/café WiFi's ...
Yes, this MBP will be used for travelling on various WAPs. I am
surprised Apple doesn't enable it for security.
--
"Did the ant fall off the toilet seat because she was pissed off?" --unknown
> If you're behind a router with a firewall activated I'd leave the Mac
> firewall off unless there are specific "trust" issues within that LAN's
> user population. Some services (file sharing, printer sharing, screen
> sharing) become flaky when the firewall is on.
>
> Don't use "WiFi Protected Setup" - disable it at the WiFi.
>
> If it's a portable, then don't forget to enable the firewall before
> connecting to hotel/airport/café WiFi's ...
surprised Apple doesn't enable it for security.
--
"Did the ant fall off the toilet seat because she was pissed off?" --unknown
Message has been deleted
Bob Harris
Sep 23, 2012, 7:54:49 PM9/23/12
to
In article <3-CdnVKBjaX85sPN...@earthlink.com>,
is nothing to protect out of the box.
The Firewall does not protect out-going traffic, only unsolicited
connections, and if there is nothing to connect to, then there is
nothing to protect.
In addition, the current Mac OS X network services you can enable,
do not have known security issues.
Ant <a...@zimage.comANT> wrote:
> On 9/22/2012 6:08 PM PT, Alan Browne typed:
>
> > If you're behind a router with a firewall activated I'd leave the Mac
> > firewall off unless there are specific "trust" issues within that LAN's
> > user population. Some services (file sharing, printer sharing, screen
> > sharing) become flaky when the firewall is on.
> >
> > Don't use "WiFi Protected Setup" - disable it at the WiFi.
> >
> > If it's a portable, then don't forget to enable the firewall before
> > connecting to hotel/airport/café WiFi's ...
>
> Yes, this MBP will be used for travelling on various WAPs. I am
> surprised Apple doesn't enable it for security.
again, Apple does not ship Mac OS X with ANY ports open, so there
> On 9/22/2012 6:08 PM PT, Alan Browne typed:
>
> > If you're behind a router with a firewall activated I'd leave the Mac
> > firewall off unless there are specific "trust" issues within that LAN's
> > user population. Some services (file sharing, printer sharing, screen
> > sharing) become flaky when the firewall is on.
> >
> > Don't use "WiFi Protected Setup" - disable it at the WiFi.
> >
> > If it's a portable, then don't forget to enable the firewall before
> > connecting to hotel/airport/café WiFi's ...
>
> Yes, this MBP will be used for travelling on various WAPs. I am
> surprised Apple doesn't enable it for security.
is nothing to protect out of the box.
The Firewall does not protect out-going traffic, only unsolicited
connections, and if there is nothing to connect to, then there is
nothing to protect.
In addition, the current Mac OS X network services you can enable,
do not have known security issues.
Wes Groleau
Sep 23, 2012, 8:59:19 PM9/23/12
to
On 09-23-2012 19:54, Bob Harris wrote:
> again, Apple does not ship Mac OS X with ANY ports open, so there
> is nothing to protect out of the box.
Bonjour must be open, no?
> again, Apple does not ship Mac OS X with ANY ports open, so there
> is nothing to protect out of the box.
--
Wes Groleau
“Two things are infinite, the universe and human stupidity.
But I'm not so sure about the universe.”
— Albert Einstein
Message has been deleted
Message has been deleted
Wes Groleau
Sep 24, 2012, 8:30:55 PM9/24/12
to
On 09-24-2012 05:50, Lewis wrote:
> In message <k3ob98$sdc$1...@dont-email.me>
Recent events make it doubtful anyone knows what I am thinking.
In this thread, "open ports" has been used to mean two things:
- allowed incoming connections
- listening to a particular report.
For bonjour to work, it has to be listening on that port, and the
devices to be discovered must be able to connect through that port.
> In message <k3ob98$sdc$1...@dont-email.me>
> Wes Groleau <Grolea...@FreeShell.org> wrote:
>> On 09-23-2012 19:54, Bob Harris wrote:
>>> again, Apple does not ship Mac OS X with ANY ports open, so there
>>> is nothing to protect out of the box.
>
>> Bonjour must be open, no?
>
> Not in the way you are thinking, no.
>> On 09-23-2012 19:54, Bob Harris wrote:
>>> again, Apple does not ship Mac OS X with ANY ports open, so there
>>> is nothing to protect out of the box.
>
>> Bonjour must be open, no?
>
Recent events make it doubtful anyone knows what I am thinking.
In this thread, "open ports" has been used to mean two things:
- allowed incoming connections
- listening to a particular report.
For bonjour to work, it has to be listening on that port, and the
devices to be discovered must be able to connect through that port.
Message has been deleted
Wes Groleau
Sep 25, 2012, 9:13:11 PM9/25/12
to
On 09-25-2012 20:10, Lewis wrote:
> When people talk about 'open ports' they generally mean TCP ports, not
> UDP ports, because in order to establish a connection, you need TCP (UDP
> is connectionless, unordered, and ACKless).
When I talk about open ports, I mean open ports.
Did anyone mention connection before this post?
No one said "Mac has never has any open ports except ..."
http://www.youtube.com/watch?v=ExWfh6sGyso
--
Wes Groleau
Is it an on-line compliment to call someone a Net Wit ?
> When people talk about 'open ports' they generally mean TCP ports, not
> UDP ports, because in order to establish a connection, you need TCP (UDP
> is connectionless, unordered, and ACKless).
When I talk about open ports, I mean open ports.
Did anyone mention connection before this post?
No one said "Mac has never has any open ports except ..."
http://www.youtube.com/watch?v=ExWfh6sGyso
--
Wes Groleau
Is it an on-line compliment to call someone a Net Wit ?
Wes Groleau
Sep 25, 2012, 9:14:57 PM9/25/12
to
On 09-25-2012 21:13, Wes Groleau wrote:
> http://www.youtube.com/watch?v=ExWfh6sGyso
Let's repeal Godwin's Law and replace it with
"When someone posts a Monty Python video, the thread is over." :-)
> http://www.youtube.com/watch?v=ExWfh6sGyso
Let's repeal Godwin's Law and replace it with
"When someone posts a Monty Python video, the thread is over." :-)
Message has been deleted
Richard Kettlewell
Sep 26, 2012, 9:34:13 AM9/26/12
to
Lewis <g.k...@gmail.com.dontsendmecopies> writes:
> misunderstand what is going on, that is up to you. At this point it
> seems like you are chosing willful ignorance, so I'm done trying to
> explain it to you.
I'm not sure what you think the relevant distinction is. It's true that
there are API- and wire-level differences in detail between
connectionful and connectionless transport protocols but if you're
trying to control whether and how an external actor can communicate with
an application process, they're not very relevant.
>> Did anyone mention connection before this post?
>
> If you are talking about a firewall to protect your computer you are
> protecting it from *connections*.
That's not true at all. An attack may use either a connectionful or a
connectionless protocol.
--
http://www.greenend.org.uk/rjk/
> Wes Groleau <Grolea...@FreeShell.org> wrote:
>> On 09-25-2012 20:10, Lewis wrote:
>>> When people talk about 'open ports' they generally mean TCP ports,
>>> not UDP ports, because in order to establish a connection, you need
>>> TCP (UDP is connectionless, unordered, and ACKless).
>>
>> When I talk about open ports, I mean open ports.
>
> UDP ports are not 'open' in the way that TCP ports are. If you want to
>> On 09-25-2012 20:10, Lewis wrote:
>>> When people talk about 'open ports' they generally mean TCP ports,
>>> not UDP ports, because in order to establish a connection, you need
>>> TCP (UDP is connectionless, unordered, and ACKless).
>>
>> When I talk about open ports, I mean open ports.
>
> misunderstand what is going on, that is up to you. At this point it
> seems like you are chosing willful ignorance, so I'm done trying to
> explain it to you.
I'm not sure what you think the relevant distinction is. It's true that
there are API- and wire-level differences in detail between
connectionful and connectionless transport protocols but if you're
trying to control whether and how an external actor can communicate with
an application process, they're not very relevant.
>> Did anyone mention connection before this post?
>
> protecting it from *connections*.
That's not true at all. An attack may use either a connectionful or a
connectionless protocol.
--
http://www.greenend.org.uk/rjk/
David Empson
Sep 26, 2012, 8:46:40 PM9/26/12
to
includes these two:
[begin quote]
BIND
Available for: OS X Lion v10.7 to v10.7.4,
OS X Lion Server v10.7 to v10.7.4
Impact: A remote attacker may be able to cause a denial of service
in systems configured to run BIND as a DNS nameserver
Description: A reachable assertion issue existed in the handling of
DNS records. This issue was addressed by updating to BIND 9.7.6-P1.
This issue does not affect OS X Mountain Lion systems.
CVE-ID
CVE-2011-4313
BIND
Available for: OS X Lion v10.7 to v10.7.4,
OS X Lion Server v10.7 to v10.7.4,
OS X Mountain Lion v10.8 and v10.8.1
Impact: A remote attacker may be able to cause a denial of service,
data corruption, or obtain sensitive information from process memory
in systems configured to run BIND as a DNS nameserver
Description: A memory management issue existed in the handling of
DNS records. This issue was addressed by updating to BIND 9.7.6-P1 on
OS X Lion systems, and BIND 9.8.3-P1 on OS X Mountain Lion systems.
CVE-ID
CVE-2012-1667
[end quote]
If you had your computer set up to act as a DNS server, it was
vulnerable to these issues. The packet which could have potentially
triggered them would have come in via a connectionless protocol (UDP),
using port 53, so if your firewall was only blocking incoming TCP
connections, it would not help.
Of course, having a firewall block all access to the DNS server you are
running would defeat the purpose of running the server in the first
place, but a selective firewall which reduced the potential sources of
DNS packets would have reduced the risk of striking this issue.
There could easily be other issues with UDP-based conectionless
protocols, such as Bonour (multicast DNS), but I didn't spot any Apple
has fixed in the last couple of years (since I started getting Apple's
security notifications via e-mail).
--
David Empson
dem...@actrix.gen.nz
Message has been deleted
Wes Groleau
Sep 27, 2012, 12:02:18 AM9/27/12
to
On 09-26-2012 21:22, Lewis wrote:
> Bind uses a TCP port AND it's privileged (port 53). Section 4.2 of RFC1035
>
> The Internet supports name server access using TCP [RFC-793] on server
> port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
> port 53 (decimal).
>
> And a firewall wouldn't help you at all. If you were running a DNS
> server, ou would necessarily have port 53 open. Not only that, but BIND
> is disabled by default and is rather difficult to enable (at least in
> terms of the normal user) without using OS X Server.
I don't know whether it's difficult in 10.8 but it wasn't difficult in
10.3. (to enable it, that is. Took me an hour to get my definition
files correct.
>> Of course, having a firewall block all access to the DNS server you are
>> running would defeat the purpose of running the server in the first
>> place,
>
> You would have punched port 53 TCP/UDP open, so a firewall would have
> done exactly nothing.
> firewall works. Either it blocks a port, or it doesn't; it doesn't block
> a port depending on where the request comes from.
Again, I don't know about 10.8 but in 10.5 and earlier, I used ipfw
which most certainly (like most firewalls) allows blocking based on
port, IP, protocol, direction, interface, etc.And in fact, it DID block
according to "where the request comes from"--it allowed everything to or
from other hosts within my LAN, blocked ALL from non-LAN IPs (except
connections established from inside), and blocked most _to_ non-LAN IPs.
If 10.8 doesn't allow ipfw or ipfilters or some other _real_ firewall,
then Apple gets one more demerit in my book.
--
Wes Groleau
There are more Baroque musicians than any other kind.
>
> The Internet supports name server access using TCP [RFC-793] on server
> port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
> port 53 (decimal).
>
> And a firewall wouldn't help you at all. If you were running a DNS
> server, ou would necessarily have port 53 open. Not only that, but BIND
> is disabled by default and is rather difficult to enable (at least in
> terms of the normal user) without using OS X Server.
I don't know whether it's difficult in 10.8 but it wasn't difficult in
10.3. (to enable it, that is. Took me an hour to get my definition
files correct.
>> Of course, having a firewall block all access to the DNS server you are
>> running would defeat the purpose of running the server in the first
>> place,
>
> done exactly nothing.
>
> but a selective firewall which reduced the potential sources of
>> DNS packets would have reduced the risk of striking this issue.
>
> That's not how firewalls generally work, and is not at all how OS X's
> but a selective firewall which reduced the potential sources of
>> DNS packets would have reduced the risk of striking this issue.
>
> firewall works. Either it blocks a port, or it doesn't; it doesn't block
> a port depending on where the request comes from.
Again, I don't know about 10.8 but in 10.5 and earlier, I used ipfw
which most certainly (like most firewalls) allows blocking based on
port, IP, protocol, direction, interface, etc.And in fact, it DID block
according to "where the request comes from"--it allowed everything to or
from other hosts within my LAN, blocked ALL from non-LAN IPs (except
connections established from inside), and blocked most _to_ non-LAN IPs.
If 10.8 doesn't allow ipfw or ipfilters or some other _real_ firewall,
then Apple gets one more demerit in my book.
--
Wes Groleau
There are more Baroque musicians than any other kind.
Paul Sture
Sep 27, 2012, 8:24:40 AM9/27/12
to
In article <k40j4d$7e1$1...@dont-email.me>,
my VMS system so it wasn't hard at all. I did have the DNS & BIND
O'Reilly book to help me. There was at the time an OS X app available
to configure those files for you, but it was something like 30 bucks.
> >> Of course, having a firewall block all access to the DNS server you are
> >> running would defeat the purpose of running the server in the first
> >> place,
> >
> > You would have punched port 53 TCP/UDP open, so a firewall would have
> > done exactly nothing.
> >
> > but a selective firewall which reduced the potential sources of
> >> DNS packets would have reduced the risk of striking this issue.
> >
> > That's not how firewalls generally work, and is not at all how OS X's
> > firewall works. Either it blocks a port, or it doesn't; it doesn't block
> > a port depending on where the request comes from.
>
> Again, I don't know about 10.8 but in 10.5 and earlier, I used ipfw
> which most certainly (like most firewalls) allows blocking based on
> port, IP, protocol, direction, interface, etc.And in fact, it DID block
> according to "where the request comes from"--it allowed everything to or
> from other hosts within my LAN, blocked ALL from non-LAN IPs (except
> connections established from inside), and blocked most _to_ non-LAN IPs.
>
> If 10.8 doesn't allow ipfw or ipfilters or some other _real_ firewall,
> then Apple gets one more demerit in my book.
ipfw is certainly there on 10.8 Server, and looking at its date it
appears to have arrived on my system with the client version of 10.8.
On the Server side of things, there's something called 30-ipfwmigrator
down in the bowels of Server.App.
--
Paul Sture
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 09-26-2012 21:22, Lewis wrote:
> > And a firewall wouldn't help you at all. If you were running a DNS
> > server, ou would necessarily have port 53 open. Not only that, but BIND
> > is disabled by default and is rather difficult to enable (at least in
> > terms of the normal user) without using OS X Server.
>
> I don't know whether it's difficult in 10.8 but it wasn't difficult in
> 10.3. (to enable it, that is. Took me an hour to get my definition
> files correct.
I did it on 10.4. I had already got some working definition files for
> On 09-26-2012 21:22, Lewis wrote:
> > And a firewall wouldn't help you at all. If you were running a DNS
> > server, ou would necessarily have port 53 open. Not only that, but BIND
> > is disabled by default and is rather difficult to enable (at least in
> > terms of the normal user) without using OS X Server.
>
> I don't know whether it's difficult in 10.8 but it wasn't difficult in
> 10.3. (to enable it, that is. Took me an hour to get my definition
> files correct.
my VMS system so it wasn't hard at all. I did have the DNS & BIND
O'Reilly book to help me. There was at the time an OS X app available
to configure those files for you, but it was something like 30 bucks.
> >> Of course, having a firewall block all access to the DNS server you are
> >> running would defeat the purpose of running the server in the first
> >> place,
> >
> > You would have punched port 53 TCP/UDP open, so a firewall would have
> > done exactly nothing.
> >
> > but a selective firewall which reduced the potential sources of
> >> DNS packets would have reduced the risk of striking this issue.
> >
> > That's not how firewalls generally work, and is not at all how OS X's
> > firewall works. Either it blocks a port, or it doesn't; it doesn't block
> > a port depending on where the request comes from.
>
> Again, I don't know about 10.8 but in 10.5 and earlier, I used ipfw
> which most certainly (like most firewalls) allows blocking based on
> port, IP, protocol, direction, interface, etc.And in fact, it DID block
> according to "where the request comes from"--it allowed everything to or
> from other hosts within my LAN, blocked ALL from non-LAN IPs (except
> connections established from inside), and blocked most _to_ non-LAN IPs.
>
> If 10.8 doesn't allow ipfw or ipfilters or some other _real_ firewall,
> then Apple gets one more demerit in my book.
appears to have arrived on my system with the client version of 10.8.
On the Server side of things, there's something called 30-ipfwmigrator
down in the bowels of Server.App.
--
Paul Sture
Message has been deleted
Wes Groleau
Sep 28, 2012, 12:48:52 AM9/28/12
to
>>> >>That's not how firewalls generally work, and is not at all how OS X's
>>> >>firewall works. Either it blocks a port, or it doesn't; it doesn't block
>>> >>a port depending on where the request comes from.
>> >Again, I don't know about 10.8 but in 10.5 and earlier, I used ipfw
> "OS X's firewall" which would be understood to be the GUI switch in
> system preferences.
So because OS X has a dumbed down imitation of a firewall in addition to
a _real_ firewall, you generalize the inadequacies of the GUI version to
"how firewalls generally work"
--
Wes Groleau
“A man with an experience is never
at the mercy of a man with an argument.”
— Ron Allen
Fred Moore
Sep 28, 2012, 11:17:17 AM9/28/12
to
In article <slrnk690er....@mbp55.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> Did it involve using the Terminal? Then it is out of the comfort zone
> for the vast majority of Mac users.
WaterRoof is supposed to be a good GUI for ipfw and the price is right.
<http://www.macupdate.com/app/mac/23317/waterroof>
--
And It's Just That Easy
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> Did it involve using the Terminal? Then it is out of the comfort zone
> for the vast majority of Mac users.
WaterRoof is supposed to be a good GUI for ipfw and the price is right.
<http://www.macupdate.com/app/mac/23317/waterroof>
--
And It's Just That Easy
Message has been deleted
Wes Groleau
Sep 28, 2012, 11:10:23 PM9/28/12
to
On 09-28-2012 21:49, Lewis wrote:
> Most firewalls block incoming connections based on ports, not on where
> the connection is coming from. And this is a *Mac* group, talking abut
> *Mac* software. If you want to talk about ipfw, you need to specify that
> up front.
ipfw is Mac software, and it does what any decent firewall does.
NO firewall is worth anything if it can't tell the difference between
inside and outside. That's the very minimum and that is based on
destination and/or source.
The first commercial firewall "monitored the protocol, source and
destination addresses and ports" according to "A History and Survey of
Network Firewalls" (Inham & Forrest, 2002), later republished in a book:
<books.google.com/books?id=9qdytv-eKyQC&pg=PA9>
Port, protocol, source, destination, and a lot of other things are
equally easy to read in the packet headers. And most firewalls have
done so from the first.
--
Wes Groleau
Words of the Wild Wes
http://Ideas.Lang-Learn.us/WWW
> Most firewalls block incoming connections based on ports, not on where
> the connection is coming from. And this is a *Mac* group, talking abut
> *Mac* software. If you want to talk about ipfw, you need to specify that
> up front.
ipfw is Mac software, and it does what any decent firewall does.
NO firewall is worth anything if it can't tell the difference between
inside and outside. That's the very minimum and that is based on
destination and/or source.
The first commercial firewall "monitored the protocol, source and
destination addresses and ports" according to "A History and Survey of
Network Firewalls" (Inham & Forrest, 2002), later republished in a book:
<books.google.com/books?id=9qdytv-eKyQC&pg=PA9>
Port, protocol, source, destination, and a lot of other things are
equally easy to read in the packet headers. And most firewalls have
done so from the first.
--
Wes Groleau
Words of the Wild Wes
http://Ideas.Lang-Learn.us/WWW
Wes Groleau
Sep 28, 2012, 11:15:52 PM9/28/12
to
--
Wes Groleau
He that complies against his will is of the same opinion still.
— Samuel Butler, 1612-1680
Message has been deleted
Wes Groleau
Sep 29, 2012, 7:32:21 PM9/29/12
to
On 09-29-2012 10:56, Lewis wrote:
> In message <k45or2$so7$1...@dont-email.me>
> from IP addresses in the range 2.0.0.0-17.255.255.255, but otherwise
> leave it open." While possible, this is not normal.
You know exactly what I meant, and that's why you chose to snip to
pretend I meant something else.
It is normal and has been since before the first commercial firewall a
couple of decades ago.
It's one thing to be misinformed.
Being dishonest is something else.
Good-bye.
> In message <k45or2$so7$1...@dont-email.me>
> Wes Groleau <Grolea...@FreeShell.org> wrote:
>> On 09-28-2012 21:49, Lewis wrote:
>>> Most firewalls block incoming connections based on ports, not on where
>>> the connection is coming from. And this is a *Mac* group, talking abut
>>> *Mac* software. If you want to talk about ipfw, you need to specify that
>>> up front.
>
>> ipfw is Mac software, and it does what any decent firewall does.
>
>> NO firewall is worth anything if it can't tell the difference between
>> inside and outside. That's the very minimum and that is based on
>> destination and/or source.
>
> You meant internal and external? I thought you meant "Block port 1234
>> On 09-28-2012 21:49, Lewis wrote:
>>> Most firewalls block incoming connections based on ports, not on where
>>> the connection is coming from. And this is a *Mac* group, talking abut
>>> *Mac* software. If you want to talk about ipfw, you need to specify that
>>> up front.
>
>> ipfw is Mac software, and it does what any decent firewall does.
>
>> NO firewall is worth anything if it can't tell the difference between
>> inside and outside. That's the very minimum and that is based on
>> destination and/or source.
>
> from IP addresses in the range 2.0.0.0-17.255.255.255, but otherwise
> leave it open." While possible, this is not normal.
You know exactly what I meant, and that's why you chose to snip to
pretend I meant something else.
It is normal and has been since before the first commercial firewall a
couple of decades ago.
It's one thing to be misinformed.
Being dishonest is something else.
Good-bye.
Message has been deleted
Paul Sture
Nov 4, 2012, 2:51:12 PM11/4/12
to
In article <k45p5c$tvo$1...@dont-email.me>,
<http://www.hanynet.com/waterroof/>
The GUI comes up, but it's going to take some time to explore its
features.
--
Paul Sture
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 09-28-2012 11:17, Fred Moore wrote:
> > In article <slrnk690er....@mbp55.local>,
> > Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> >
> >> Did it involve using the Terminal? Then it is out of the comfort zone
> >> for the vast majority of Mac users.
> >
> > WaterRoof is supposed to be a good GUI for ipfw and the price is right.
> >
> > <http://www.macupdate.com/app/mac/23317/waterroof>
>
> At the moment, it is unavailable. Developer's website is down.
This is up and I managed a download:
> On 09-28-2012 11:17, Fred Moore wrote:
> > In article <slrnk690er....@mbp55.local>,
> > Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> >
> >> Did it involve using the Terminal? Then it is out of the comfort zone
> >> for the vast majority of Mac users.
> >
> > WaterRoof is supposed to be a good GUI for ipfw and the price is right.
> >
> > <http://www.macupdate.com/app/mac/23317/waterroof>
>
> At the moment, it is unavailable. Developer's website is down.
<http://www.hanynet.com/waterroof/>
The GUI comes up, but it's going to take some time to explore its
features.
--
Paul Sture
Wes Groleau
Nov 4, 2012, 9:29:01 PM11/4/12
to
On 11-04-2012 14:51, Paul Sture wrote:
> This is up and I managed a download:
>
> <http://www.hanynet.com/waterroof/>
>
> The GUI comes up, but it's going to take some time to explore its
> features.
The page seems to agree with Apple's claim that PF is better than ipfw.
> This is up and I managed a download:
>
> <http://www.hanynet.com/waterroof/>
>
> The GUI comes up, but it's going to take some time to explore its
> features.
So I downloaded the icefloor app instead
--
Wes Groleau
It seems a pity that psychology should have
destroyed all our knowledge of human nature.
— G. K. Chesterton
han...@gmail.com
Dec 17, 2012, 6:35:56 PM12/17/12
to non...@your.biz
Hello, I'm the developer of WaterRoof and IceFloor.
Yes, pf on OS X 10.8 is much better than ipfw, no doubts.
pf, like ipfw, is used to filter (and optionally log) both inbound and outbound connections; those connections are managed independently.
Network firewalls are not used to open ports. Ports are open when a server needs it. Network firewalls are used to close or filter ports.
Mac OS X System Preferences (from version 10.5) allows the configuration of ALF, which is an "application firewall", not a "network firewall".
Mac OS X 10.7 and OS X 10.8 features 3 firewalls: ipfw, pf, alf.
ipfw is deprecated but fully functional with one exception being OS X 10.8 with Server.app installed. In this case sysctl net.inet.ip.fw.enable must be manually set to 1 in order for ipfw to work.
Just to be clear.
Yes, pf on OS X 10.8 is much better than ipfw, no doubts.
pf, like ipfw, is used to filter (and optionally log) both inbound and outbound connections; those connections are managed independently.
Network firewalls are not used to open ports. Ports are open when a server needs it. Network firewalls are used to close or filter ports.
Mac OS X System Preferences (from version 10.5) allows the configuration of ALF, which is an "application firewall", not a "network firewall".
Mac OS X 10.7 and OS X 10.8 features 3 firewalls: ipfw, pf, alf.
ipfw is deprecated but fully functional with one exception being OS X 10.8 with Server.app installed. In this case sysctl net.inet.ip.fw.enable must be manually set to 1 in order for ipfw to work.
Just to be clear.
0 new messages