FromTheRafters wrote:
"John Doe" wrote in message
...
"FromTheRafters" wrote:

"Richard Mueller [MVP]" wrote
"FromTheRafters" wrote
"I.C. Greenfields" wrote
Some of us want to choose what "gets out" and what
doesn't.
And this info doesn't work since there is nowhere to
make such
a change in the Windows Firewall window that comes up.
Configure it - HOW? Can someone explain how it's
configured to
actually work without being a programmer writing
strange
unknown confusing rules for everything that wants to
connect to
the net? If not, can someone recommend a good free
easy to
use two-way FireWall like ZoneAlarm that's compatible
with
Vista? Thanks.


http://www.vistastic.com/2007/03/09/...und-filtering/
I bet you didn't know that Microsoft Windows Vista
includes a
two-way firewall.
Windows Firewall with Advanced Security includes an API
that
allows services, applications, and installers to write
their own
ticket through the firewall. In other words, they can
add
themselves to the exclusions list.

http://msdn.microsoft.com/en-us/libr...53(VS.85).aspx
Thanks for the information.

So, it doesn't really do what most people think it
does.

The key to not having programs make outbound
connections, or
opening up ports for receiving unsolicited inbound
traffic, is
to not run those programs on
the machine.

Third party firewalls don't make it *that* easy - but
they don't
make it much
harder either. They provide the illusion that they can
stop
outbound traffic.
Apparently the makers of ZoneAlarm fixed such a problem by
preventing ZoneAlarm from being shut down. After that , I
have never
heard an authoritative claim that an application snuck
through
ZoneAlarm.

Which is why I never use the Windows firewall. Every app
thinks
they are special and should be able to contact big
brother with
news about me and retrieve info on things they feel I
need. Some
companies are especially bad. I know because I don't use
Windows
firewall so I see the requests and deny them. Over the
years it
seems to have gotten much worse.
I think it comes down to trust. If you don't trust a
program -
don't execute it. If you *do* trust it, let it do
whatever it is
programmed to do.
Sounds like a symptom of the ones and zeros disease.

When there is no "grey area" ones and zeroes describe things
accurately.


http://www.securityfocus.com/infocus/1839/1

"Jack the Ripper" wrote in message
...
FromTheRafters wrote:
"John Doe" wrote in message
...
"FromTheRafters" wrote:

"Richard Mueller [MVP]" wrote
"FromTheRafters" wrote
"I.C. Greenfields" wrote
Some of us want to choose what "gets out" and what
doesn't.
And this info doesn't work since there is nowhere to
make such
a change in the Windows Firewall window that comes
up.
Configure it - HOW? Can someone explain how it's
configured to
actually work without being a programmer writing
strange
unknown confusing rules for everything that wants to
connect to
the net? If not, can someone recommend a good free
easy to
use two-way FireWall like ZoneAlarm that's
compatible with
Vista? Thanks.


http://www.vistastic.com/2007/03/09/...und-filtering/
I bet you didn't know that Microsoft Windows Vista
includes a
two-way firewall.
Windows Firewall with Advanced Security includes an
API that
allows services, applications, and installers to
write their own
ticket through the firewall. In other words, they can
add
themselves to the exclusions list.

http://msdn.microsoft.com/en-us/libr...53(VS.85).aspx
Thanks for the information.

So, it doesn't really do what most people think it
does.

The key to not having programs make outbound
connections, or
opening up ports for receiving unsolicited inbound
traffic, is
to not run those programs on
the machine.

Third party firewalls don't make it *that* easy - but
they don't
make it much
harder either. They provide the illusion that they
can stop
outbound traffic.
Apparently the makers of ZoneAlarm fixed such a problem
by
preventing ZoneAlarm from being shut down. After that ,
I have never
heard an authoritative claim that an application snuck
through
ZoneAlarm.

Which is why I never use the Windows firewall. Every
app thinks
they are special and should be able to contact big
brother with
news about me and retrieve info on things they feel I
need. Some
companies are especially bad. I know because I don't
use Windows
firewall so I see the requests and deny them. Over the
years it
seems to have gotten much worse.
I think it comes down to trust. If you don't trust a
program -
don't execute it. If you *do* trust it, let it do
whatever it is
programmed to do.
Sounds like a symptom of the ones and zeros disease.

When there is no "grey area" ones and zeroes describe
things accurately.
http://www.securityfocus.com/infocus/1839/1

Thanks for the link, although I'm not sure why you posted it
here. This poster seemed to imply that there is middle
ground to cover for programs that you trust to play your
video files, yet don't trust to access the internet for
instance. My point is that there is no middle ground - if
you don't trust it to access the internet, don't have it on
your system (who knows what other horrible things it could
be doing that you aren't aware of). There is no problem
having an API that allows a program you have given
permission to execute the ability to configure your
firewall. You indicated your trust when you installed or
executed the program.

In the case of foistware/malware, there is no reason to
assume outbound filtering would catch it in egression.
Houdini demonstrated that a safe isn't designed to keep a
person locked *in*. When he repeatedly managed to escape
from them, it didn't cause the manufacturers to redesign
their safes to be escape proof. You just have to work within
the safe's specifications.

+Bob+ wrote:
On Wed, 18 Feb 2009 13:49:42 -0500, Jack the Ripper
wrote:

Is this suppose to be some kind of a joke here, because you seem serious?

You sure post under a lot of different names. Is that a joke?

You didn't answer the question. Therefore, I know that you don't know
what you are talking about.

+Bob+ wrote:
On Wed, 18 Feb 2009 19:59:31 -0500, "FromTheRafters"
wrote:

Thanks for the link, although I'm not sure why you posted it
here. This poster seemed to imply that there is middle
ground to cover for programs that you trust to play your
video files, yet don't trust to access the internet for
instance. My point is that there is no middle ground - if
you don't trust it to access the internet, don't have it on
your system (who knows what other horrible things it could
be doing that you aren't aware of).

Nonsense. I run programs that have no need to access the Internet - at
least not unless I want them too. They aren't intrinsically evil
programs, but they also don't need to do internet access unless there
is a specific need for it.

Nonesense, you either know what is running on the computer or you don't.
If you trust the program, then you should have no problems in allowing
that program to access the Internet. If you don't trust the program,
then you shouldn't have the program on the computer period.

It's as simple as that, and it doesn't take a rocket scientist to figure
it out.


In the case of foistware/malware, there is no reason to
assume outbound filtering would catch it in egression.

Some is very sharp (in an evil sense) and no doubt will sneak through.
THen again, some isn't and will be easily trapped. This is like having
a dead bolt on your front door - some thieves are sharp enough to pick
such a lock and will get in. Most will not and move on to easier prey.


No, some are sharp in a technical sense, and the developer of the
exploit knew where the holes are at, while some are still learning and
have to practice on someone before moving to bigger game.

"mayayana" wrote in message
...

Complicating matters, Microsoft shrouds a number of
services in the svchost.exe process, which can run in
multiple instances. So if you allow svchost through the
firewall it's not so easy to know exactly what you're
allowing. And ZA can't differentiate between the actual
processes running under the svchost "hat".

Actually it is possible to determine what each instance of svchost is doing.
WMI can show what is executed by each instance and you can use the Task
Manager interactively to determine that information (you probably need to
modify the view to show the columns). The sysinternals site in Microsoft has
a process monitor that can show the information.

The ZoneAlarm people are technical enough that they could hook each instance
of svchost if necessary.

"FromTheRafters" wrote in message
...

My point is that there is no middle ground - if you don't trust it to
access the internet, don't have it on your system (who knows what other
horrible things it could be doing that you aren't aware of).

Using that logic, most users of SQL Server should not use it. SQL Server can
communicate over a network, including the network, but Microsoft recommends
not allowing SQL Server to access the internet unless there is a need for
it. I think the MBSA suggests closing the SQL Server ports if they are open.

MySQL is worse, unless they fixed it in the past few years. It does, or at
least did, require access to the internet in order to communicate among
processes in a single system. I think it used localhost and therefore
perhaps it is possible to configure firewalls to only allow localhost but
that is still more than what you are suggesting to allow, correct?

FromTheRafters wrote:
"Jack the Ripper" wrote in message
...
FromTheRafters wrote:
"John Doe" wrote in message
...
"FromTheRafters" wrote:

"Richard Mueller [MVP]" wrote
"FromTheRafters" wrote
"I.C. Greenfields" wrote
Some of us want to choose what "gets out" and what
doesn't.
And this info doesn't work since there is nowhere to
make such
a change in the Windows Firewall window that comes
up.
Configure it - HOW? Can someone explain how it's
configured to
actually work without being a programmer writing
strange
unknown confusing rules for everything that wants to
connect to
the net? If not, can someone recommend a good free
easy to
use two-way FireWall like ZoneAlarm that's
compatible with
Vista? Thanks.


http://www.vistastic.com/2007/03/09/...und-filtering/
I bet you didn't know that Microsoft Windows Vista
includes a
two-way firewall.
Windows Firewall with Advanced Security includes an
API that
allows services, applications, and installers to
write their own
ticket through the firewall. In other words, they can
add
themselves to the exclusions list.

http://msdn.microsoft.com/en-us/libr...53(VS.85).aspx
Thanks for the information.

So, it doesn't really do what most people think it
does.

The key to not having programs make outbound
connections, or
opening up ports for receiving unsolicited inbound
traffic, is
to not run those programs on
the machine.

Third party firewalls don't make it *that* easy - but
they don't
make it much
harder either. They provide the illusion that they
can stop
outbound traffic.
Apparently the makers of ZoneAlarm fixed such a problem
by
preventing ZoneAlarm from being shut down. After that ,
I have never
heard an authoritative claim that an application snuck
through
ZoneAlarm.

Which is why I never use the Windows firewall. Every
app thinks
they are special and should be able to contact big
brother with
news about me and retrieve info on things they feel I
need. Some
companies are especially bad. I know because I don't
use Windows
firewall so I see the requests and deny them. Over the
years it
seems to have gotten much worse.
I think it comes down to trust. If you don't trust a
program -
don't execute it. If you *do* trust it, let it do
whatever it is
programmed to do.
Sounds like a symptom of the ones and zeros disease.
When there is no "grey area" ones and zeroes describe
things accurately.
http://www.securityfocus.com/infocus/1839/1

Thanks for the link, although I'm not sure why you posted it
here. This poster seemed to imply that there is middle
ground to cover for programs that you trust to play your
video files, yet don't trust to access the internet for
instance. My point is that there is no middle ground - if
you don't trust it to access the internet, don't have it on
your system (who knows what other horrible things it could
be doing that you aren't aware of). There is no problem
having an API that allows a program you have given
permission to execute the ability to configure your
firewall. You indicated your trust when you installed or
executed the program.

If one doesn't trust the program in this case, then one shouldn't have
it on the machine. Who has time to be playing Russian roulette, because
that's what is happening when one starts playing that game?

Those programs are smart enough to find
other ways of punching out by piggy-backing off of other legit processes
running on the machine.


In the case of foistware/malware, there is no reason to
assume outbound filtering would catch it in egression.
Houdini demonstrated that a safe isn't designed to keep a
person locked *in*. When he repeatedly managed to escape
from them, it didn't cause the manufacturers to redesign
their safes to be escape proof. You just have to work within
the safe's specifications.


Malware can have several back doors and other means to punch its way
out, undetected.

You know, a malware maker can set-up a honey-pot situation sort of
speaking, where as, they expose the exploit and let it be seen so that
it can be caught, giving someone a false sense of accomplishment that
they caught it.

In the meantime, they are being back-doored somewhere else, undetected.

Sam Hobbs wrote:
"mayayana" wrote in message
...

Complicating matters, Microsoft shrouds a number of
services in the svchost.exe process, which can run in
multiple instances. So if you allow svchost through the
firewall it's not so easy to know exactly what you're
allowing. And ZA can't differentiate between the actual
processes running under the svchost "hat".

Actually it is possible to determine what each instance of svchost is
doing. WMI can show what is executed by each instance and you can use
the Task Manager interactively to determine that information (you
probably need to modify the view to show the columns). The sysinternals
site in Microsoft has a process monitor that can show the information.

The ZoneAlarm people are technical enough that they could hook each
instance of svchost if necessary.


Look man, those users using ZA (home users most likely) or any other
personal FW solutions are not savvy enough to find a hidden process,
because I have talked with them in other NG(s) including ZA users about
using PE, how to use it and they couldn't find a thing, probably looking
right at it in their face.

Sam Hobbs wrote:
"FromTheRafters" wrote in message
...

My point is that there is no middle ground - if you don't trust it to
access the internet, don't have it on your system (who knows what
other horrible things it could be doing that you aren't aware of).

Using that logic, most users of SQL Server should not use it. SQL Server
can communicate over a network, including the network, but Microsoft
recommends not allowing SQL Server to access the internet unless there
is a need for it. I think the MBSA suggests closing the SQL Server ports
if they are open.


If someone is in communications with SQL server from a SQL Server
management standpoint remotely, then they are behind a network FW doing
it in a LAN situation or a VPN solution it's over the Internet.

With SQL server 2005 and now 2008 using CLR for even the express
editions let alone the server editions of SQL Server, SQL server can be
in communications with another SQL Server as a client over the
Internet, which has nothing to do with TCP port 1434 I think it is, by
means of queue processing.

http://www.eggheadcafe.com/articles/20040703.asp

So ports are open on SQL server and a FW, if a remote Internet client
solution calls for it and one knows how to protect SQL server.

On Wed, 18 Feb 2009 20:52:49 -0800, "Sam Hobbs"
wrote:

"FromTheRafters" wrote in message
...

My point is that there is no middle ground - if you don't trust it to
access the internet, don't have it on your system (who knows what other
horrible things it could be doing that you aren't aware of).

Using that logic, most users of SQL Server should not use it. SQL Server can
communicate over a network, including the network, but Microsoft recommends
not allowing SQL Server to access the internet unless there is a need for
it. I think the MBSA suggests closing the SQL Server ports if they are open.

I'm convinced that's configurable and therefore doesn't need a PFW to
"control" it.

MySQL is worse, unless they fixed it in the past few years. It does, or at
least did, require access to the internet in order to communicate among
processes in a single system. I think it used localhost and therefore
perhaps it is possible to configure firewalls to only allow localhost but
that is still more than what you are suggesting to allow, correct?

Since when did localhost reside on the Internet?