PDA

View Full Version : Avira's firewall



gufus
12-31-69, 07:00 PM
Hi Grant,

Sunday April 11 2010, Grant Taylor writes to All:

> I'm not so much filtering the same thing that the edge
> firewall is filtering. Rather, I'm filtering other things
> that other servers behind the edge firewall could attack.

With only /basic/ networking experience, I can't /see/ anything wrong with
this theory, It can only increase security, what if a employee infects via a
CD.
....
IMHO (In my humble opinion)
AKA: gufus

--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... Get off my back, I can't swim either!

gufus
12-31-69, 07:00 PM
Hi Ansgar,

12 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:

> From: usenet-2010@planetcobalt.net

> Wrong. Running an additional firewall means running
> additional code that can contain additional exploitable

No comment (for now)

> misconfiguration, which in turn may inadvertently
> open attack vectors.

Brief your employees.

> What if? That employee's computer still needs to be able to
> access the server, meaning the server's ports still need to
> be open, meaning that the personal firewall won't help
> anything at all.

Agreed.. anti-viral /should/ be install on the network, obviously stopping this
first.


--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... Can I blame my spelling on line noise?

gufus
12-31-69, 07:00 PM
Hi Ansgar,

12 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:

> make a mistake or overlook something. You could brief them
> all day long and still not prevent this from happening.

Tell me about it... good-bad employees. :(

--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... Evangelists do more than lay people.

gufus
12-31-69, 07:00 PM
Hi Ansgar,

12 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:

> You missed the point again. Even the best employees are

I beg to differ. Sir.

Employees /need/ to understand the system, especially when I have MS-DOS
workstation(s), try getting MS-DOS talking to a Win NT server. <grin>

>> -+- SoupGate-Win32 v1.05
>> + Origin: Calgary Organization CDN Fidonet-Internet Gateway
>> (1:342/77.10)

--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... Nothing is ever a complete failure; it can always serve as a bad example.

gufus
12-31-69, 07:00 PM
Hi Ansgar,

13 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:

> From: usenet-2010@planetcobalt.net
>> Employees /need/ to understand the system,

> True, but besides the point. Repeating myself: even the best
> employees are still human and *will* make mistakes here and

Agreed... and you don't have to repeat your self, there will always be human
error in life. Thats life.

gufus
--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... Dr. Scott!" " Janet!" " Brad!" "Rocky!" "Uhhh!

gufus
12-31-69, 07:00 PM
Hi Grant,

12 Apr 10, Grant Taylor writes to All:

> Conversely if the web servers were running a software based
> firewall, they could easily filter SNMP and / or RPC traffic
> so that only the management station(s) could access them.
> There by protecting them from the program running locally on
> the compromised server.

> These types of side attacks (if you will) are what I'm
> saying that a software based firewall will help prevent.

I still think your way is more secure. IMHO.

gufus
--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... Up your accumulator.

gufus
12-31-69, 07:00 PM
Hi Ansgar,

13 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:

>> I still think your way is more secure. IMHO.

> That's simply because you entirely failed to understand the
> implications.

Have fun hashing it out with Grant. :)

--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... Take the bull by the hand and avoid mixed metaphors.

gufus
12-31-69, 07:00 PM
Hi Grant,

13 Apr 10, Grant Taylor writes to All:

>> True, but besides the point. Repeating myself: even the
>> best employees are still human and *will* make mistakes

> I agree. The human element of a network is (at times) one
> of it's weakest links.

Hmmmm... sounds like an echo here. <grin>

With only basic networking skills, I'm taking notes on you discussion with
Ansgar, interesting to-say-the least.

gufus

--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... A man without a religion is like a fish without a bicycle.

gufus
12-31-69, 07:00 PM
Hi Grant,

Wednesday April 14 2010, Grant Taylor writes to Gypsy BBS:


> Ansgar seems to have a very strong opinion on what we are
> discussing. Further, Ansgar is presenting logical points to
> support his / her opinion. With no insults going back and

Nice... yes no insults, I guess with myself he/her didn't like what my opinion
was about this thread, which started about a server having a firewall, but
with that, I do understand, /first/ firewall the network boundary, then if
wanted/needed firewall everything behind it.


> That being said, Ansgar has presented a couple of compelling
> points:
> 1) The code of the firewall its self could be a
> weakness.
> 2) There is little point in protecting one server from
> another when both can be attacked the same way that
> successfully exploited the first.

Good points! Agreed!

Kind Regards.
--
K Klement

Enhance your marketing at http://www.gypsy-designs.com
mailto:info@gypsy-designs.com
Gypsy Designs Fax: (403) 242-3221

.... It is annoying to be honest to no purpose.

gufus
04-07-10, 05:19 PM
Hello, All!

Is any one here using Avira's firewall? it's is included with Avira's
Security Suite. I want to upgrade my servers firewall.
If not... any suggestions for a good firewall would be great.
--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

Jimmy Jiiimz
04-07-10, 11:31 PM
"gufus" <stop.nospam.gbbsg@shaw.ca> wrote:
> Hello, All!
>
> Is any one here using Avira's firewall? it's is included with Avira's
> Security Suite. I want to upgrade my servers firewall.
> If not... any suggestions for a good firewall would be great.

I wouldn't recommend a software based firewall on a server! Go out and
buy a hardware device like from WatchGuard, Fortinet, Juniper etc...

--
Jimmy

Benji Z-Man
04-08-10, 12:01 AM
On 08/04/10 14:31, Jimmy Jiiimz wrote:
> "gufus"<stop.nospam.gbbsg@shaw.ca> wrote:
>> Hello, All!
>>
>> Is any one here using Avira's firewall? it's is included with Avira's
>> Security Suite. I want to upgrade my servers firewall.
>> If not... any suggestions for a good firewall would be great.
>
> I wouldn't recommend a software based firewall on a server! Go out and
> buy a hardware device like from WatchGuard, Fortinet, Juniper etc...
>

^ This.

On a personal computer, however, Avira is... alright. Just be prepared
for some issues if you have programs that you'd like to give routine
permissions to, or opening ports.

I'd personally recommend Sygate except that they got absorbed into the
Symantec oozeball.

schtebo
04-08-10, 06:50 AM
On Apr 8, 12:19*am, "gufus" <stop.nospam.gb...@shaw.ca> wrote:
> Hello, All!
>
> Is any one here using Avira's firewall? it's is included with Avira's
> Security Suite. I want to upgrade my servers firewall.
> If not... any suggestions for a good firewall would be great.
> --
> With best regards, gufus. *E-mail: stop.nospam.gb...@shaw.ca

Hi Gufus,

as far as i know Avira Premium Security Suite ist not for Servers.
If you try to install you should be notified that Microsoft Server ist
not supported.
I think default Firewall from Microsoft should do it for us all.

Benji Z-Man
04-08-10, 08:05 AM
On 08/04/10 21:50, schtebo wrote:
[ Snip ]
> I think default Firewall from Microsoft should do it for us all.

Ktchk- are you insane?

Jon Solberg
04-08-10, 08:16 AM
On 2010-04-08, Benji Z-Man <khormin@bigpond.com> wrote:
> On 08/04/10 21:50, schtebo wrote:
> [ Snip ]
>> I think default Firewall from Microsoft should do it for us all.
>
> Ktchk- are you insane?

No, just Microsoftcentric. A common disease these days.

--
Jon Solberg (remove "nospam." from email address)

Ansgar -59cobalt- Wiechers
04-08-10, 08:27 AM
Benji Z-Man <khormin@bigpond.com> wrote:
> On 08/04/10 21:50, schtebo wrote:
> [ Snip ]
>> I think default Firewall from Microsoft should do it for us all.
>
> Ktchk- are you insane?

This coming from someone who recommended Sygate, of all things. A
firewall with well-known critical design flaws, like running an
interactive service with SYSTEM privileges.

The Windows Firewall is perfectly fine for blocking inbound connections.
Outbound connections can't be controlled reliably anyway, not to mention
that once they happen, the system already has been compromised.

cu
59cobalt
--
"Personal Firewalls are crap. Throw away any personal firewall. Personal
Firewalls are bad[tm]."
--Malte von dem Hagen on security-basics

Benji Z-Man
04-08-10, 11:23 AM
On 08/04/10 23:27, Ansgar -59cobalt- Wiechers wrote:
> Benji Z-Man<khormin@bigpond.com> wrote:
>> On 08/04/10 21:50, schtebo wrote:
>> [ Snip ]
>>> I think default Firewall from Microsoft should do it for us all.
>>
>> Ktchk- are you insane?
>
> This coming from someone who recommended Sygate, of all things. A
> firewall with well-known critical design flaws, like running an
> interactive service with SYSTEM privileges.

Honestly did not know that. Anything else you can point out about it,
then? And where I can verify that?

Rick
04-08-10, 01:07 PM
Jimmy Jiiimz wrote:
> "gufus"<stop.nospam.gbbsg@shaw.ca> wrote:
>> Hello, All!
>>
>> Is any one here using Avira's firewall? it's is included with Avira's
>> Security Suite. I want to upgrade my servers firewall.
>> If not... any suggestions for a good firewall would be great.
>
> I wouldn't recommend a software based firewall on a server! Go out and
> buy a hardware device like from WatchGuard, Fortinet, Juniper etc...
>

i have heard that recommendation many times and do not dispute it, but
assuming that the s/w firewall comes up first during boot up, WHY would
you insist on not having a s/w firewall on a server?

gufus
04-08-10, 02:48 PM
Hello, Jon!

You wrote on Thu, 8 Apr 2010 13:16:07 +0000 (UTC):

>>> I think default Firewall from Microsoft should do it for us all.
>>
>> Ktchk- are you insane?
|
| No, just Microsoftcentric. A common disease these days.

Unworthily... I guess. :-)

--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

gufus
04-08-10, 02:56 PM
Hello, Benji!

You wrote on Thu, 08 Apr 2010 05:01:44 GMT:

| for some issues if you have programs that you'd like to give routine
| permissions to, or opening ports.

I do.

| I'd personally recommend Sygate except that they got absorbed into the
| Symantec oozeball.

I /don't/ do Symantec. <grin>

--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

gufus
04-08-10, 02:58 PM
Hello, Jimmy!

You wrote on Thu, 08 Apr 2010 04:31:14 GMT:

| I wouldn't recommend a software based firewall on a server! Go out and
| buy a hardware device like from WatchGuard, Fortinet, Juniper etc...
|

'k
--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

gufus
04-08-10, 03:07 PM
Hello, Rick!

You wrote on Thu, 08 Apr 2010 14:07:41 -0400:


>> I wouldn't recommend a software based firewall on a server! Go out and
>> buy a hardware device like from WatchGuard, Fortinet, Juniper etc...
>>
|
| i have heard that recommendation many times and do not dispute it, but
| assuming that the s/w firewall comes up first during boot up, WHY would
| you insist on not having a s/w firewall on a server?
|
Good question.
--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

gufus
04-09-10, 07:27 PM
Hello, Ansgar!

You wrote on 8 Apr 2010 13:27:41 GMT:

|
| The Windows Firewall is perfectly fine for blocking inbound connections.
| Outbound connections can't be controlled reliably anyway, not to mention
| that once they happen, the system already has been compromised.
|
Duly noted.

--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

Ansgar -59cobalt- Wiechers
04-11-10, 07:41 AM
Benji Z-Man <khormin@bigpond.com> wrote:
> On 08/04/10 23:27, Ansgar -59cobalt- Wiechers wrote:
>> Benji Z-Man<khormin@bigpond.com> wrote:
>>> On 08/04/10 21:50, schtebo wrote:
>>>> I think default Firewall from Microsoft should do it for us all.
>>>
>>> Ktchk- are you insane?
>>
>> This coming from someone who recommended Sygate, of all things. A
>> firewall with well-known critical design flaws, like running an
>> interactive service with SYSTEM privileges.
>
> Honestly did not know that. Anything else you can point out about it,
> then? And where I can verify that?

Get some window of the software in question (configuration, notifi-
cation, whatever). Use a tool like Spy++ to identify the process that
window belongs to. Check the process list to find the process and its
owner (the account it's been started under). This should never be SYSTEM
(or any other privileged account).

For a better understanding of the underlying problem check these links:

http://en.wikipedia.org/wiki/Shatter_attack
http://support.microsoft.com/kb/327618
http://msdn.microsoft.com/en-us/library/ms683502.aspx

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Ansgar -59cobalt- Wiechers
04-11-10, 07:46 AM
gufus <stop.nospam.gbbsg@shaw.ca> wrote:
> You wrote on Thu, 08 Apr 2010 14:07:41 -0400:
>>> I wouldn't recommend a software based firewall on a server! Go out and
>>> buy a hardware device like from WatchGuard, Fortinet, Juniper etc...
>
> | i have heard that recommendation many times and do not dispute it, but
> | assuming that the s/w firewall comes up first during boot up, WHY would
> | you insist on not having a s/w firewall on a server?
>
> Good question.

Actually, no. It's a rather stupid question. A good question would be:
why would anyone in his right mind insist on HAVING a sofware firewall
on a server?

Open ports on a server need to be open, because otherwise the server
would be unable to provide its services (which would render it rather
futile). You cannot block access to ports that need to be accessible.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Grant Taylor
04-11-10, 12:51 PM
Ansgar -59cobalt- Wiechers wrote:
> Actually, no. It's a rather stupid question. A good question would
> be: why would anyone in his right mind insist on HAVING a sofware
> firewall on a server?

I would say that part of the problem is the "insistence" of having (or
not) a software firewall, with no possibility of the other.

I will argue that a software firewall is just another form of security.
(I'm not going to debate how good of a form of security it may or may
not be.) Like most good over all security systems, security is provided
in layers of multiple smaller forms of security. With this in mind, the
software firewall on a server (or any thing for that matter) is another
layer of security. Thus if the server has the resources to run the
software firewall and it is not a detriment to the function of the
system, then it's probably ok to have it there. If the server does not
have the resources to run the software firewall or if it is a detriment
to the function of the system, then don't run the firewall unless you
really need to. In short, it is situational dependent.

> Open ports on a server need to be open, because otherwise the server
> would be unable to provide its services (which would render it rather
> futile). You cannot block access to ports that need to be accessible.

There are some advantages to running a firewall even on ports that you
need to have open. Some services don't have any ability to filter what
IP addresses are allowed to talk to them. Or there are some cases where
it is appropriate to centrally manage a firewall across multiple systems
rather than having to manage each service on every system.

I think it really comes down to where does a software firewall fall in
your over all security scheme. If you feel your organization can
benefit from it, then use one. If you feel a software firewall is not
appropriate for your organization, then don't use one.

I personally view software firewalls as an additional line of defense to
protect against outbreaks behind the edge hardware firewalls.



Grant. . . .

gufus
04-11-10, 02:34 PM
Hello, Grant!

You wrote on Sun, 11 Apr 2010 12:51:03 -0500:

| I think it really comes down to where does a software firewall fall in
| your over all security scheme. If you feel your organization can
| benefit from it, then use one. If you feel a software firewall is not
| appropriate for your organization, then don't use one.
|
| I personally view software firewalls as an additional line of defense to
| protect against outbreaks behind the edge hardware firewalls.
|
Excellent policy IMHO
|

--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

gufus
04-11-10, 02:58 PM
Hello, Ansgar!

You wrote on 11 Apr 2010 12:46:15 GMT:

FL> >> i have heard that recommendation many times and do not dispute it,
FL> >> but assuming that the s/w firewall comes up first during boot up,
FL> >> WHY would you insist on not having a s/w firewall on a server?
FL>>
FL>> Good question.
|
| Actually, no. It's a rather stupid question.

Hu.. :(

--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

gufus
04-11-10, 03:18 PM
Hello, schtebo!

You wrote on Thu, 8 Apr 2010 04:50:02 -0700 (PDT):

| I think default Firewall from Microsoft should do it for us all.

Taking notes... <grin>
--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

Ansgar -59cobalt- Wiechers
04-11-10, 03:52 PM
Grant Taylor <gtaylor@riverviewtech.net> wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> Actually, no. It's a rather stupid question. A good question would
>> be: why would anyone in his right mind insist on HAVING a sofware
>> firewall on a server?
>
> I would say that part of the problem is the "insistence" of having (or
> not) a software firewall, with no possibility of the other.
>
> I will argue that a software firewall is just another form of
> security. (I'm not going to debate how good of a form of security it
> may or may not be.) Like most good over all security systems,
> security is provided in layers of multiple smaller forms of security.
> With this in mind, the software firewall on a server (or any thing for
> that matter) is another layer of security.

Oh *please*, spare me that "layers" ********.

Personal firewalls do not increase the security of a server. They
increase the attack surface (larger codebase, thus most likely more
vulnerabilities) and the overall complexity of the system, and thus
actually *lower* your security.

[...]
>> Open ports on a server need to be open, because otherwise the server
>> would be unable to provide its services (which would render it rather
>> futile). You cannot block access to ports that need to be accessible.
>
> There are some advantages to running a firewall even on ports that you
> need to have open. Some services don't have any ability to filter
> what IP addresses are allowed to talk to them.

That's what you already filter at the network boundary. No need to
filter yet again on the server.

> Or there are some cases where it is appropriate to centrally manage a
> firewall across multiple systems rather than having to manage each
> service on every system.

And managing firewalls centrally instead of managing services centrally
is more appropriate, how?

> I think it really comes down to where does a software firewall fall in
> your over all security scheme.

They don't. Period.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

gufus
04-11-10, 07:02 PM
Hello, Ansgar!

You wrote on 11 Apr 2010 20:52:39 GMT:

| Personal firewalls do not increase the security of a server. They
| increase the attack surface (larger codebase, thus most likely more

So.. a firewall belongs in between what you protect, and what you
protect it from.


--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

Grant Taylor
04-11-10, 08:37 PM
Ansgar -59cobalt- Wiechers wrote:
> Oh *please*, spare me that "layers" ********.

*chuckle*

I want my opinion to stand, so I have to allow yours to stand. Even if
I disagree with it. Thus, we will agree to disagree. Does that work
for you?

> Personal firewalls do not increase the security of a server. They
> increase the attack surface (larger codebase, thus most likely more
> vulnerabilities) and the overall complexity of the system, and thus
> actually *lower* your security.

That is a different point. One that no one has brought up before. Do
you have any examples to show?

> That's what you already filter at the network boundary. No need to
> filter yet again on the server.

I'm not so much filtering the same thing that the edge firewall is
filtering. Rather, I'm filtering other things that other servers behind
the edge firewall could attack.

I'm sure that the edge firewall is filtering NetBIOS ports, but what
happens if another system in the network gets infected with something /
web site gets breached and starts attacking your other servers? This is
the type of thing that I think the host based firewall is meant for.

> And managing firewalls centrally instead of managing services centrally
> is more appropriate, how?

I'm not saying that centrally managing services is not appropriate. I
know of multiple smaller shops that can't afford centrally managed
services, yet they are running a network based AV scanner with firewall
that they can centrally mange. Thus, they can centrally manage the
firewall but not the services.

> They don't. Period.

That's your opinion.



Grant. . . .

Ansgar -59cobalt- Wiechers
04-12-10, 05:32 AM
Grant Taylor <gtaylor@riverviewtech.net> wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> Oh *please*, spare me that "layers" ********.
>
> *chuckle*
>
> I want my opinion to stand, so I have to allow yours to stand. Even
> if I disagree with it. Thus, we will agree to disagree. Does that
> work for you?

I guess it'll have to.

>> Personal firewalls do not increase the security of a server. They
>> increase the attack surface (larger codebase, thus most likely more
>> vulnerabilities) and the overall complexity of the system, and thus
>> actually *lower* your security.
>
> That is a different point. One that no one has brought up before. Do
> you have any examples to show?

http://en.wikipedia.org/wiki/Witty_(computer_worm)

>> That's what you already filter at the network boundary. No need to
>> filter yet again on the server.
>
> I'm not so much filtering the same thing that the edge firewall is
> filtering. Rather, I'm filtering other things that other servers
> behind the edge firewall could attack.

If you have to do that, you have a server placement issue. Boxes that
shouldn't be able to access what the server is providing, should not be
located in the same network segment.

> I'm sure that the edge firewall is filtering NetBIOS ports, but what
> happens if another system in the network gets infected with something
> / web site gets breached and starts attacking your other servers? This
> is the type of thing that I think the host based firewall is meant
> for.

This is the exact type of thing, that firewall can't protect you from
(unless you're using a sanitizing reverse proxy or something).

Again: any service that should be accessible, cannot be protected by a
packet filter. Any service that shouldn't be accessible, should not be
running (or at least not be listening on the external interface) in the
first place. It really is as simple as that.

>> And managing firewalls centrally instead of managing services centrally
>> is more appropriate, how?
>
> I'm not saying that centrally managing services is not appropriate. I
> know of multiple smaller shops that can't afford centrally managed
> services, yet they are running a network based AV scanner with firewall
> that they can centrally mange.

They can't afford using the tools that come with the operating system,
but can afford to buy a centrally manageable host-based firewall
solution? You have to be kidding me.

> Thus, they can centrally manage the firewall but not the services.

"sc /?" tells you why you're wrong.

>> They don't. Period.
>
> That's your opinion.

A quite substantiated opinion, no less.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Ansgar -59cobalt- Wiechers
04-12-10, 03:01 PM
gufus <stop.nospam.gbbsg@shaw.ca> wrote:
> Sunday April 11 2010, Grant Taylor writes to All:
>> I'm not so much filtering the same thing that the edge firewall is
>> filtering. Rather, I'm filtering other things that other servers
>> behind the edge firewall could attack.
>
> With only /basic/ networking experience, I can't /see/ anything wrong
> with this theory, It can only increase security,

Wrong. Running an additional firewall means running additional code that
can contain additional exploitable vulnerabilities. This already has
happened ITW. Additional software also means additional complexity, that
may lead to misconfiguration, which in turn may inadvertently open
attack vectors.

> what if a employee infects via a CD.

What if? That employee's computer still needs to be able to access the
server, meaning the server's ports still need to be open, meaning that
the personal firewall won't help anything at all.

Besides, how is the employee's box going to get infected in the first
place? Disabling autoplay is one of the most basic countermeasures
available in the toolbox. Not granting your employees administrative
privileges is another one.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Ansgar -59cobalt- Wiechers
04-12-10, 04:01 PM
gufus <stop.nospam.gbbsg@shaw.ca> wrote:
> 12 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:
>> misconfiguration, which in turn may inadvertently open attack
>> vectors.
>
> Brief your employees.

You failed to understand the issue. The more complex your systems
become, the more likely it's for your employees to make a mistake or
overlook something. You could brief them all day long and still not
prevent this from happening.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Ansgar -59cobalt- Wiechers
04-12-10, 04:09 PM
gufus <stop.nospam.gbbsg@shaw.ca> wrote:
> 12 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:
>> make a mistake or overlook something. You could brief them
>> all day long and still not prevent this from happening.
>
> Tell me about it... good-bad employees. :(

You missed the point again. Even the best employees are still human and
*will* make mistakes here and there. Unnecessarily increasing system
complexity will raise the chances of this happening.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

gufus
04-12-10, 07:17 PM
Hello, schtebo!

You wrote on Thu, 8 Apr 2010 04:50:02 -0700 (PDT):


s> I think default Firewall from Microsoft should do it for us all.

After setting up a few off-the-shelf firewalls, and getting frustrated with
everything, I'm back to using Win NT stock firewall, everything is back
working again.

Good advice. :)


--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

Grant Taylor
04-12-10, 07:33 PM
Ansgar -59cobalt- Wiechers wrote:
> I guess it'll have to.

Fair enough. ;-)

> http://en.wikipedia.org/wiki/Witty_(computer_worm)

Interesting. I will have to do some follow up reading on that.

> If you have to do that, you have a server placement issue. Boxes that
> shouldn't be able to access what the server is providing, should not
> be located in the same network segment.

I think we mis-understand each other. Let me give an example.

Suppose that a hosting company has multiple IIS web servers behind an
edge ingress filtering firewall that only allows traffic to TCP ports 80
and 443 through. With in the network the servers also allow SNMP and /
or RPC for remote computer management.

What prevents a web site on one of these hosts from becoming compromised
and running a local program that starts attacking the other systems in
the local subnet. This local program would have unfettered access to
SNMP and / or RPC to the other servers that are behind the edge ingress
filtering firewall.

Conversely if the web servers were running a software based firewall,
they could easily filter SNMP and / or RPC traffic so that only the
management station(s) could access them. There by protecting them from
the program running locally on the compromised server.

These types of side attacks (if you will) are what I'm saying that a
software based firewall will help prevent.

> This is the exact type of thing, that firewall can't protect you from
> (unless you're using a sanitizing reverse proxy or something).

I'm not sure that I understand what you are trying to say.

The closest that I can come up with is that the edge firewall is doing
egress filtering.

> Again: any service that should be accessible, cannot be protected by
> a packet filter. Any service that shouldn't be accessible, should not
> be running (or at least not be listening on the external interface)
> in the first place. It really is as simple as that.

What if you modify my above example of the server farm where one
interface is public and another interface is private (think DMZ /
management network) and the local program starts attacking the internal
network. Again, I believe that the software based firewall would help
protect other servers from the attack.

A perfect example of a service would be to not run SSH on the external
interface, yet run it on the internal interface for remote management.

> They can't afford using the tools that come with the operating
> system, but can afford to buy a centrally manageable host-based
> firewall solution? You have to be kidding me.

I believe you mis-understand what I'm getting at.

I'm not aware of any utility included in either 2k3 or 2k8 that allows
changes to multiple IIS web servers at one time. I.e. do not process
requests from the w.x.y/24 network.

> "sc /?" tells you why you're wrong.

You are correct that there are ways to administer the operational state
of a service in such as is it started / stopped / etc. That does little
to prevent a service from talking to a given subnet.

> A quite substantiated opinion, no less.

I'm sure it is. ;-)



Grant. . . .

Ansgar -59cobalt- Wiechers
04-13-10, 01:49 AM
gufus <stop.nospam.gbbsg@shaw.ca> wrote:
> 12 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:
>> You missed the point again. Even the best employees are
>
> I beg to differ. Sir.
>
> Employees /need/ to understand the system,

True, but besides the point. Repeating myself: even the best employees
are still human and *will* make mistakes here and there. Unnecessarily
raising the complexity of a system will only increase the chances of
this happening.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Ansgar -59cobalt- Wiechers
04-13-10, 03:56 PM
Grant Taylor <gtaylor@riverviewtech.net> wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> If you have to do that, you have a server placement issue. Boxes that
>> shouldn't be able to access what the server is providing, should not
>> be located in the same network segment.
>
> I think we mis-understand each other. Let me give an example.
>
> Suppose that a hosting company has multiple IIS web servers behind an
> edge ingress filtering firewall that only allows traffic to TCP ports
> 80 and 443 through. With in the network the servers also allow SNMP
> and / or RPC for remote computer management.
>
> What prevents a web site on one of these hosts from becoming
> compromised and running a local program that starts attacking the
> other systems in the local subnet. This local program would have
> unfettered access to SNMP and / or RPC to the other servers that are
> behind the edge ingress filtering firewall.

Sorry, but that's just ridiculous. If you're that concerned about
security, you don't allow SNMP or RPC in the first place. Period. Rather
than running additional code on the servers, you'd lock them down tight,
update them frequently, and monitor them closely.

> Conversely if the web servers were running a software based firewall,
> they could easily filter SNMP and / or RPC traffic so that only the
> management station(s) could access them. There by protecting them
> from the program running locally on the compromised server.

You don't seem understand how SNMP works. What exactly prevents
compromised server A from spoofing the source address of the SNMP
packets it sends to victim server B on the same network segment? The
protocol is UDP-based after all.

>> This is the exact type of thing, that firewall can't protect you from
>> (unless you're using a sanitizing reverse proxy or something).
>
> I'm not sure that I understand what you are trying to say.
>
> The closest that I can come up with is that the edge firewall is doing
> egress filtering.

You mean the "sanitizing reverse proxy" thingie? Those are not about
egress filtering, but ingress filtering. They sanitize (i.e. rewrite/
canonicalize) the input data stream going from a client to a server, and
thus protect a server from malicious user-supplied data. mod_security
for Apache is an example of this kind of software.

>> Again: any service that should be accessible, cannot be protected by
>> a packet filter. Any service that shouldn't be accessible, should not
>> be running (or at least not be listening on the external interface)
>> in the first place. It really is as simple as that.
>
> What if you modify my above example of the server farm where one
> interface is public and another interface is private (think DMZ /
> management network) and the local program starts attacking the
> internal network. Again, I believe that the software based firewall
> would help protect other servers from the attack.

As explained above, this won't necessarily work as you expect.

> A perfect example of a service would be to not run SSH on the external
> interface, yet run it on the internal interface for remote management.

SSH is a perfect example of a service that does not need to be
"protected" with a local firewall at all. You disallow password
authentication and restrict which user can login from where.

If you're referring to exploitable vulnerabilities: trying to "protect"
SSH with some kind of personal firewall would just move the problem from
sshd to the personal firewall instead of solving it, and I clearly trust
SSH more than any personal firewall. IPv6, anyone?

>> They can't afford using the tools that come with the operating
>> system, but can afford to buy a centrally manageable host-based
>> firewall solution? You have to be kidding me.
>
> I believe you mis-understand what I'm getting at.
>
> I'm not aware of any utility included in either 2k3 or 2k8 that allows
> changes to multiple IIS web servers at one time. I.e. do not process
> requests from the w.x.y/24 network.

I don't consider the potential gain in security (which may be a lot less
than you expect, as explained above) worth the additional complexity and
effort in keeping another piece of software up-to-date.

>> "sc /?" tells you why you're wrong.
>
> You are correct that there are ways to administer the operational
> state of a service in such as is it started / stopped / etc. That
> does little to prevent a service from talking to a given subnet.

Of course not, because that's not what management of services is about.
I believe I already said that if you want that level of isolation,
you're far better off putting the servers in separate DMZs.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Ansgar -59cobalt- Wiechers
04-13-10, 03:58 PM
gufus <stop.nospam.gbbsg@shaw.ca> wrote:
> 13 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS:
>> From: usenet-2010@planetcobalt.net
>>> Employees /need/ to understand the system,
>>
>> True, but besides the point. Repeating myself: even the best
>> employees are still human and *will* make mistakes here and
>
> Agreed... and you don't have to repeat your self, there will always be
> human error in life. Thats life.

*sigh*

I give up. Apparently I'm unable to explain matters in a way you'd
understand.

Please do yourself and the world a favor and don't ever touch anything
security-related.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Ansgar -59cobalt- Wiechers
04-13-10, 04:00 PM
gufus <stop.nospam.gbbsg@shaw.ca> wrote:
> 12 Apr 10, Grant Taylor writes to All:
>> Conversely if the web servers were running a software based firewall,
>> they could easily filter SNMP and / or RPC traffic so that only the
>> management station(s) could access them. There by protecting them
>> from the program running locally on the compromised server.
>>
>> These types of side attacks (if you will) are what I'm saying that a
>> software based firewall will help prevent.
>
> I still think your way is more secure. IMHO.

That's simply because you entirely failed to understand the
implications.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

gufus
04-13-10, 04:43 PM
Hello, Ansgar!

You wrote on 13 Apr 2010 20:58:45 GMT:

AcW>
AcW> Please do yourself and the world a favor and don't ever touch anything
AcW> security-related.
AcW>

:-)


--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

Grant Taylor
04-13-10, 10:01 PM
Ansgar -59cobalt- Wiechers wrote:
> Sorry, but that's just ridiculous. If you're that concerned about
> security, you don't allow SNMP or RPC in the first place. Period.
> Rather than running additional code on the servers, you'd lock them
> down tight, update them frequently, and monitor them closely.

I was just using SNMP / RPC as an example.

For the sake of discussion, please provide a service that would be
needed internally to support line-of-business applications (even in a
DMZ) that would not be allowed externally.

> You don't seem understand how SNMP works. What exactly prevents
> compromised server A from spoofing the source address of the SNMP
> packets it sends to victim server B on the same network segment? The
> protocol is UDP-based after all.

I do understand SNMP well enough for this discussion. There is nothing
that prevents the compromised server from spoofing any thing.

However, I think we can agree on the fact that there is an order of
magnitude difference in complexity in mal-ware that is capable of
spoofing IP and possibly MAC addresses verses not doing so and relying
on the OS IP stack. Likewise, I believe there is quite a bit of
difference in the number of each.

You can't protect against everything. There is a point of diminishing
return with more security.

> You mean the "sanitizing reverse proxy" thingie? Those are not about
> egress filtering, but ingress filtering. They sanitize (i.e. rewrite/
> canonicalize) the input data stream going from a client to a server,
> and thus protect a server from malicious user-supplied data.
> mod_security for Apache is an example of this kind of software.

No. I mean an edge firewall that is (hopefully) only allowing replies
from TCP ports 80 and 443 (and possibly some ICMP) as well as only
allowing the internal subnet as a source IP range.

I am perfectly aware of what a reverse (or forward) proxy is for and can
do. I was not bringing them in to this discussion.

> As explained above, this won't necessarily work as you expect.

Aside from IP spoofing and your opinion that the firewalls present a
bigger target, I fail to see how this will not work or at least help
prevent (read: slow down / limit attack) internally initiated attacks.

> SSH is a perfect example of a service that does not need to be
> "protected" with a local firewall at all. You disallow password
> authentication and restrict which user can login from where.

Other than the fact that SSH is a little more intelligent about the
application layer, I believe it too is equally susceptible to the IP
spoofing that you were referring to above. (Granted, once successfully
spoofed, there is a greater hurtle to overcome at the application layer
with encryption RSA keys and the likes.)

> If you're referring to exploitable vulnerabilities: trying to
> "protect" SSH with some kind of personal firewall would just move the
> problem from sshd to the personal firewall instead of solving it, and
> I clearly trust SSH more than any personal firewall. IPv6, anyone?

I will agree that SSH is quite a bit more hardened than most public
services, and can probably withstand quite an onslaught.

For the sake of discussion, suppose that the server farm that we are
talking about is for multiple MS-SQL servers that have to allow inbound
connections, at least from the systems behind the edge firewall.

> I don't consider the potential gain in security (which may be a lot
> less than you expect, as explained above) worth the additional
> complexity and effort in keeping another piece of software
> up-to-date.

That is a valid opinion that I can't argue with. Nor can I say that
it's logically wrong. The only thing that I can say is that mine
differs from yours.

> Of course not, because that's not what management of services is
> about. I believe I already said that if you want that level of
> isolation, you're far better off putting the servers in separate
> DMZs.

I was referring to something specifically meant to remotely manage the
configuration of aspects of services in such as you can control what IPs
that SSH (or what ever) will talk to.

I am referring to a server farm / DMZ of servers for a given task, off
by them selves. I.e. a subnet dedicated to web servers or email servers
or db servers or ...

Or do I mis-understand you in such as you are stating to put each
individual server in it's own DMZ away from other servers?



Grant. . . .

Grant Taylor
04-13-10, 10:02 PM
Ansgar -59cobalt- Wiechers wrote:
> True, but besides the point. Repeating myself: even the best employees
> are still human and *will* make mistakes here and there. Unnecessarily
> raising the complexity of a system will only increase the chances of
> this happening.

I agree. The human element of a network is (at times) one of it's
weakest links.



Grant. . . .

Ansgar -59cobalt- Wiechers
04-14-10, 04:54 PM
Grant Taylor <gtaylor@riverviewtech.net> wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> Sorry, but that's just ridiculous. If you're that concerned about
>> security, you don't allow SNMP or RPC in the first place. Period.
>> Rather than running additional code on the servers, you'd lock them
>> down tight, update them frequently, and monitor them closely.
>
> I was just using SNMP / RPC as an example.
>
> For the sake of discussion, please provide a service that would be
> needed internally to support line-of-business applications (even in a
> DMZ) that would not be allowed externally.

The only services that come to mind are Remote Desktop and SSH.

>> You don't seem understand how SNMP works. What exactly prevents
>> compromised server A from spoofing the source address of the SNMP
>> packets it sends to victim server B on the same network segment? The
>> protocol is UDP-based after all.
>
> I do understand SNMP well enough for this discussion. There is
> nothing that prevents the compromised server from spoofing any thing.
>
> However, I think we can agree on the fact that there is an order of
> magnitude difference in complexity in mal-ware that is capable of
> spoofing IP and possibly MAC addresses verses not doing so and relying
> on the OS IP stack.

No, actually we can't agree on that, as it's just plain wrong. Unless
you are talking about script-kiddy level, spoofing of addresses (either
IP or MAC) is the most basic of the basics. And in case of UDP sending
the packet with a fake sender address is all there is to it. It's
neither difficult nor complex at all.

[...]
>> As explained above, this won't necessarily work as you expect.
>
> Aside from IP spoofing and your opinion that the firewalls present a
> bigger target, I fail to see how this will not work or at least help
> prevent (read: slow down / limit attack) internally initiated attacks.

Because with UDP you don't need to establish a connection. You write the
spoofed sender address to the packet, fire and forget.

>> SSH is a perfect example of a service that does not need to be
>> "protected" with a local firewall at all. You disallow password
>> authentication and restrict which user can login from where.
>
> Other than the fact that SSH is a little more intelligent about the
> application layer, I believe it too is equally susceptible to the IP
> spoofing that you were referring to above.

On top of being a lot more intelligent at the application layer, SSH
(unlike SNMP) is also TCP-based. How do you think the compromised host
is going to receive TCP response packets when they're not going back to
the attacker's IP address? Unlike UDP, TCP is not stateless.

> (Granted, once successfully spoofed, there is a greater hurtle to
> overcome at the application layer with encryption RSA keys and the
> likes.)

That (and the user/source restrictions) come on top of the problem of
intercepting/spoofing a TCP connection.

>> If you're referring to exploitable vulnerabilities: trying to
>> "protect" SSH with some kind of personal firewall would just move the
>> problem from sshd to the personal firewall instead of solving it, and
>> I clearly trust SSH more than any personal firewall. IPv6, anyone?
>
> I will agree that SSH is quite a bit more hardened than most public
> services, and can probably withstand quite an onslaught.
>
> For the sake of discussion, suppose that the server farm that we are
> talking about is for multiple MS-SQL servers that have to allow inbound
> connections, at least from the systems behind the edge firewall.

Please be more specific about the scenario. By "from the systems behind
the edge firewall" you mean connections from within some LAN (management
or whatever) to the servers in the DMZ? What kind of connection? Why
wouldn't RDP suffice? Why can't the connection be tunneled (e.g. with
stunnel) in case RDP does not suffice?

>> Of course not, because that's not what management of services is
>> about. I believe I already said that if you want that level of
>> isolation, you're far better off putting the servers in separate
>> DMZs.
>
> I was referring to something specifically meant to remotely manage the
> configuration of aspects of services in such as you can control what
> IPs that SSH (or what ever) will talk to.
>
> I am referring to a server farm / DMZ of servers for a given task, off
> by them selves. I.e. a subnet dedicated to web servers or email
> servers or db servers or ...

In a scenario like that: if an attacker can exploit one server, he can
exploit the other (similar) servers just the same. No need at all to
take a different route for compromizing them.

> Or do I mis-understand you in such as you are stating to put each
> individual server in it's own DMZ away from other servers?

For a server farm as you described above: no. But as explained above,
there's no need to further isolate them anyway. For servers carrying out
different tasks it might be an option.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Grant Taylor
04-14-10, 06:38 PM
Ansgar -59cobalt- Wiechers wrote:
> The only services that come to mind are Remote Desktop and SSH.

RDP.

> No, actually we can't agree on that, as it's just plain wrong. Unless
> you are talking about script-kiddy level, spoofing of addresses
> (either IP or MAC) is the most basic of the basics. And in case of
> UDP sending the packet with a fake sender address is all there is to
> it. It's neither difficult nor complex at all.

I was referring to script-kiddy.

I'm of the opinion that little will stop a properly motivated skilled
attacker.

The rest of the chaff is what I'm thinking about protecting against.

> On top of being a lot more intelligent at the application layer, SSH
> (unlike SNMP) is also TCP-based. How do you think the compromised
> host is going to receive TCP response packets when they're not going
> back to the attacker's IP address? Unlike UDP, TCP is not stateless.

The compromised host would need to be in the return path or local LAN of
the spoofed host.

> That (and the user/source restrictions) come on top of the problem of
> intercepting/spoofing a TCP connection.

Agreed.

> Please be more specific about the scenario. By "from the systems
> behind the edge firewall" you mean connections from within some LAN
> (management or whatever) to the servers in the DMZ? What kind of
> connection? Why wouldn't RDP suffice? Why can't the connection be
> tunneled (e.g. with stunnel) in case RDP does not suffice?

Let's say that it's a routed VLAN that is firewalled and using globally
routable IPs for the servers in said VLAN. (Said another way, the same
broadcast domain.)

RDP or SSH should suffice for management. But what about some other
service that is used by the server. - I've never messed with it, what
ports need to be open for MS Cluster Server to communicate with each other?

> In a scenario like that: if an attacker can exploit one server, he
> can exploit the other (similar) servers just the same. No need at all
> to take a different route for compromizing them.

As long as the edge firewall will allow access to the other servers (not
doing some sort of load balancing based on source IP that would ensure
that one IP would talk to one server) sure.

That is also assuming that all the servers are serving the same content.
That assumption might not be the case for a web farm that assigns a
(vulnerable) web site to some but not all servers.



Grant. . . .

Grant Taylor
04-14-10, 06:43 PM
gufus wrote:
> Hi Grant,

Hi gufus,

> Hmmmm... sounds like an echo here. <grin>

;-)

> With only basic networking skills, I'm taking notes on you discussion
> with Ansgar, interesting to-say-the least.

Ansgar seems to have a very strong opinion on what we are discussing.
Further, Ansgar is presenting logical points to support his / her
opinion. With no insults going back and forth, I see no reason why it
can't be a productive discussion, even if we ultimately decide to agree
to disagree.

That being said, Ansgar has presented a couple of compelling points:

1) The code of the firewall its self could be a weakness.
2) There is little point in protecting one server from another when
both can be attacked the same way that successfully exploited the first.



Grant. . . .

Grant Taylor
04-14-10, 09:23 PM
gufus wrote:
> Hi Grant,

*wave*

> Nice... yes no insults, I guess with myself he/her didn't like what
> my opinion was about this thread, which started about a server having
> a firewall, but with that, I do understand, /first/ firewall the
> network boundary, then if wanted/needed firewall everything behind
> it.

A friend and colleague of mine used an analogy to describe the edge
firewall (with lack of internal firewall / layers) that I chuckled at.
I figured that others were over worked like my self and could use a
chuckle, so here it is.

"crunchy shell / soft-gooey center"



> Good points! Agreed!

:)

> Kind Regards.

Likewise.



Grant. . . .

gufus
04-15-10, 05:23 PM
Hello, Grant!

You wrote on Wed, 14 Apr 2010 21:23:59 -0500:

| chuckle, so here it is.
|
| "crunchy shell / soft-gooey center"
|
:-)

Good one!

--
With best regards, gufus. E-mail: stop.nospam.gbbsg@shaw.ca

Grant Taylor
04-15-10, 07:43 PM
gufus wrote:
> Hello, Grant!

*wave*

> Good one!

I thought so. That's why I shared it.

Here's my colleagues full comment (with permission):

"""Yes, host-based firewalls are necessary to keep the "crunchy
shell/soft-gooey center" phenomenon from happening in a network. It is
about layers. If an attacker gets beyond a border firewall and there is
nothing keeping them from accessing every machine, the network owner
will wish host-based firewalls would have been in place."""

Again, I think this is more talking about end user workstations than
servers. But I still think it's a good point.



Grant. . . .

Ansgar -59cobalt- Wiechers
04-25-10, 03:38 PM
Sorry about the late response. I had a busy week.

Grant Taylor <gtaylor@riverviewtech.net> wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> The only services that come to mind are Remote Desktop and SSH.
>
> RDP.

That's the protocol Remote Desktop uses. So, what about it?

>> No, actually we can't agree on that, as it's just plain wrong. Unless
>> you are talking about script-kiddy level, spoofing of addresses
>> (either IP or MAC) is the most basic of the basics. And in case of
>> UDP sending the packet with a fake sender address is all there is to
>> it. It's neither difficult nor complex at all.
>
> I was referring to script-kiddy.
>
> I'm of the opinion that little will stop a properly motivated skilled
> attacker.

Script-kiddies are no serious threat to properly maintained systems.
It's the determined attackers that you need to defend agains. They are
the guys that will cost your business real money.

[...]
>> On top of being a lot more intelligent at the application layer, SSH
>> (unlike SNMP) is also TCP-based. How do you think the compromised
>> host is going to receive TCP response packets when they're not going
>> back to the attacker's IP address? Unlike UDP, TCP is not stateless.
>
> The compromised host would need to be in the return path or local LAN
> of the spoofed host.

TCP is not SMTP. If the compromised host spoofs the source address, the
response packets will not go back to the compromised host (unless the
attacker gets the switch into hub-mode, which your monitoring should
notice).

>> Please be more specific about the scenario. By "from the systems
>> behind the edge firewall" you mean connections from within some LAN
>> (management or whatever) to the servers in the DMZ? What kind of
>> connection? Why wouldn't RDP suffice? Why can't the connection be
>> tunneled (e.g. with stunnel) in case RDP does not suffice?
>
> Let's say that it's a routed VLAN that is firewalled and using
> globally routable IPs for the servers in said VLAN. (Said another
> way, the same broadcast domain.)
>
> RDP or SSH should suffice for management. But what about some other
> service that is used by the server. - I've never messed with it, what
> ports need to be open for MS Cluster Server to communicate with each
> other?

I didn't have to deal with it either, but the fine documentation [1]
mentions these:

Cluster Services 3343/udp
RPC 135/tcp
Cluster Administrator 137/udp
Randomly allocated ports 1024/udp - 65535/udp
49152/udp - 65535/udp (Server 2008)

However, since the cluster nodes need to be able to talk to each other,
there's nothing a personal firewall can do about protecting these.

>> In a scenario like that: if an attacker can exploit one server, he
>> can exploit the other (similar) servers just the same. No need at all
>> to take a different route for compromizing them.
>
> As long as the edge firewall will allow access to the other servers
> (not doing some sort of load balancing based on source IP that would
> ensure that one IP would talk to one server) sure.
>
> That is also assuming that all the servers are serving the same
> content. That assumption might not be the case for a web farm that
> assigns a (vulnerable) web site to some but not all servers.

A vulnerable web-site is not the same as a vulnerable service. And
although the vulnerability may be exploited to compromise another
service or even the system (through SQL injection for instance), this
kind of attack can be done from the outside as well.

[1] http://support.microsoft.com/kb/832017

Regards
Ansgar Wiechers
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Ansgar -59cobalt- Wiechers
04-25-10, 03:42 PM
Grant Taylor <gtaylor@riverviewtech.net> wrote:
> Here's my colleagues full comment (with permission):
>
> """Yes, host-based firewalls are necessary to keep the "crunchy
> shell/soft-gooey center" phenomenon from happening in a network. It is
> about layers. If an attacker gets beyond a border firewall and there
> is nothing keeping them from accessing every machine, the network
> owner will wish host-based firewalls would have been in place."""
>
> Again, I think this is more talking about end user workstations than
> servers. But I still think it's a good point.

Catchy. However, despite all the catchiness your colleague is still
wrong. Sorry to burst your bubble.

A locked-down system is far from being "gooey on the inside". And I
already outlined a couple reasons why your host-based firewall may not
make your system as "crunchy" as you think it does.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

kalvin
05-26-10, 02:10 AM
We provide you with the most popular and most stylish, Patek 1579 .
Welcome new and old customers to buy the corresponding product on this
site, so stay tuned!
Product is a credit guarantee, you can buy at ease, shasha will
provide you all, welcome service.
For more information, please visit our web site : http://www.ghdtradezone.com

We will take the first answer for you.
The company features:
1) All shoes are high-quality first-class products and the lowest
prices: first-class quality and best price.
2) Quick shipment: ship the goods within 24 hours after we received
your payment.
3) Quick delivery: 5 - 7 days, door to door service
4) the mode of transport: EMS EMS, TNT, DHL company, UPS, Federal
Express
5) Normal Packing: original box, tags, labels
Welcome your presence! !