Comodo blocking port forwarding

Comodo blocking port forwarding

am 01.04.2008 01:28:11 von fred fleagle

Comodo blocks port forwarding from router, programs can't receive
incoming connections.
Can someone suggest a way to allow port forwarding?

Thanks from
fred fleagle



--
Posted via a free Usenet account from http://www.teranews.com

Re: Comodo blocking port forwarding

am 01.04.2008 06:37:16 von Volker Birk

fred fleagle wrote:
> Comodo blocks port forwarding from router, programs can't receive
> incoming connections.
> Can someone suggest a way to allow port forwarding?

Yes. Drop Comodo.

Yours,
VB.
--
The file name of an indirect node file is the string "iNode" immediately
followed by the link reference converted to decimal text, with no leading
zeroes. For example, an indirect node file with link reference 123 would
have the name "iNode123". - HFS Plus Volume Format, MacOS X

Re: Comodo blocking port forwarding

am 01.04.2008 22:14:15 von MR. Arnold

"fred fleagle" wrote in message
news:47f15c4c$0$30486$88260bb3@free.teranews.com...
> Comodo blocks port forwarding from router, programs can't receive
> incoming connections.
> Can someone suggest a way to allow port forwarding?
>

You go to the personal packet filter/personal firewall and you open the same
ports on it as you did on the router.

Re: Comodo blocking port forwarding

am 05.04.2008 09:50:54 von Hans-Peter Sauer

Dne Tue, 01 Apr 2008 01:28:11 +0200 fred fleagle napsal/-a:

> Comodo blocks port forwarding from router, programs can't receive
> incoming connections.
> Can someone suggest a way to allow port forwarding?
>

I have no problems with forwarded ports with Comodo.

Especially at firewalls, all FW is as good as its configuration.
Well, it can be worse, but never better.

check proper forwarding at router, and incoming connections
in comodo in both Application and Network monitor.

Remember if there is not allowed incoming traffic in network layer,
it does not matter what is allowed at application layer.

First step in blaming is always my own hands,
blaming product is next step.

Re: Comodo blocking port forwarding

am 05.04.2008 10:34:35 von Sebastian Gottschalk

Poutnik wrote:


> I have no problems with forwarded ports with Comodo.
>
> Especially at firewalls, all FW is as good as its configuration.
> Well, it can be worse, but never better.


And Comodo is worse, since it doesn't even allow proper configuration even
in the most simple scenarios.

> Remember if there is not allowed incoming traffic in network layer,
> it does not matter what is allowed at application layer.


There is no matter to the latter anyway.


> First step in blaming is always my own hands,
> blaming product is next step.

Unless you know what you're doing.

Re: Comodo blocking port forwarding

am 05.04.2008 13:25:29 von Hans-Peter Sauer

In article <65ort2F2h69r5U1@mid.dfncis.de>, seppi@seppig.de says...

>
> And Comodo is worse, since it doesn't even allow proper configuration even
> in the most simple scenarios.

As I have said, it is on your hands.

My comodo works fine even at complex scenarios.
But it can be out of your knowledge scope.

Re: Comodo blocking port forwarding

am 05.04.2008 15:04:35 von MR. Arnold

"Poutnik" wrote in message
news:MPG.22618018491b0ac989680@127.0.0.1...
> In article <65ort2F2h69r5U1@mid.dfncis.de>, seppi@seppig.de says...
>
>>
>> And Comodo is worse, since it doesn't even allow proper configuration
>> even
>> in the most simple scenarios.
>
> As I have said, it is on your hands.
>
> My comodo works fine even at complex scenarios.
> But it can be out of your knowledge scope.

Your first mistake is that some 3rd party personal firewall you're even
calling a FW. It's not a FW at best it's a machine level packet filter and
some won't even call it that.

A FW separates two networks. A FW sits at the junction point between two
networks. A FW protects from the network it's protecting from usually the
Internet, and it protects the network it's protecting the LAN. A FW must
have two network interfaces or in the case of a FW running on a secured
gateway computer, the computer must have two NIC(s). One network interface
must face the WAN/Internet, and the other one must face the LAN.

Because of the FW ability to segment networks, it reduces the risk of damage
spreading from one network to another network, like a firewall or firedoor.

Re: Comodo blocking port forwarding

am 05.04.2008 15:27:53 von Sebastian Gottschalk

Poutnik wrote:

> In article <65ort2F2h69r5U1@mid.dfncis.de>, seppi@seppig.de says...
>
>> And Comodo is worse, since it doesn't even allow proper configuration even
>> in the most simple scenarios.
>
> As I have said, it is on your hands.


No, it isn't, since the software puts the limit. It's only in my hand to
choose are not so insanely limited alternative host-based packet filter.

> My comodo works fine even at complex scenarios.

> But it can be out of your knowledge scope.


This is a very simple ruleset that is part of essentially every sane
configuration:

check-state
allow tcp from me to any out setup keep-state
allow tcp from any to any established keep-state
allow tcp from any to any frag keep-state
deny tcp from any to me 1-1023 in setup
skip tcp from any to me in setup keep-state

Any stricter is horribly broken, any laxer is insecure. Yet it's impossible
to implement in Comodo.

Re: Comodo blocking port forwarding

am 05.04.2008 15:32:20 von Sebastian Gottschalk

Mr. Arnold wrote:


> Your first mistake is that some 3rd party personal firewall you're even
> calling a FW. It's not a FW at best it's a machine level packet filter and
> some won't even call it that.


The latter would be idiots, since it is one, albeit a lousy one.

> A FW separates two networks. A FW sits at the junction point between two
> networks. A FW protects from the network it's protecting from usually the
> Internet, and it protects the network it's protecting the LAN. A FW must
> have two network interfaces or in the case of a FW running on a secured
> gateway computer, the computer must have two NIC(s). One network interface
> must face the WAN/Internet, and the other one must face the LAN.


And the inability of Comodo to implement a routing firewall, which is the
minimal strictly isolating firewall concept in scenarios where bridging
firewalls are not applicable, is what makes it not a firewall.

But: he hasn't claimed it to be a firewall. He only wrote that a firewall is
only as good as its ruleset, and the same obviously also applies to pure
host-based packet filters.

Re: Comodo blocking port forwarding

am 05.04.2008 17:51:50 von MR. Arnold

"Sebastian G." wrote in message
news:65pdbbF2h314vU2@mid.dfncis.de...
> Mr. Arnold wrote:
>
>
>> Your first mistake is that some 3rd party personal firewall you're even
>> calling a FW. It's not a FW at best it's a machine level packet filter
>> and some won't even call it that.
>
>
> The latter would be idiots, since it is one, albeit a lousy one.

What they call it is crap, but that was not the exact word.

Re: Comodo blocking port forwarding

am 06.04.2008 21:41:35 von Hans-Peter Sauer

I do not need to learn what the hardware FWs are
and how they are supposed to work.

According to the fact
Comodo is personal software firewall,
I stayed at this topic.

We can debate, if Pers SW FWs are proper term, but it is commonly used.
And modern PSW are much more then plain packet filters.
PF have no more chance against sofisticated malware.

SW FW can be more easily compromized,
but on the other hand, the have more chances
to detect application hijacking
and suspicious interprocess comunication.

This field is closed to distant HW firewalls.

HW and SW FWs have little different goals, purpose and usage.
There is no use for their users fight each other.
They have common enemy.

be toughtIn article ,
"Mr. Arnold" says...
>
> "Poutnik" wrote in message
> news:MPG.22618018491b0ac989680@127.0.0.1...
> > In article <65ort2F2h69r5U1@mid.dfncis.de>, seppi@seppig.de says...
> >
> >>
> >> And Comodo is worse, since it doesn't even allow proper configuration
> >> even
> >> in the most simple scenarios.
> >
> > As I have said, it is on your hands.
> >
> > My comodo works fine even at complex scenarios.
> > But it can be out of your knowledge scope.
>
> Your first mistake is that some 3rd party personal firewall you're even
> calling a FW. It's not a FW at best it's a machine level packet filter and
> some won't even call it that.
>
> A FW separates two networks. A FW sits at the junction point between two
> networks. A FW protects from the network it's protecting from usually the
> Internet, and it protects the network it's protecting the LAN. A FW must
> have two network interfaces or in the case of a FW running on a secured
> gateway computer, the computer must have two NIC(s). One network interface
> must face the WAN/Internet, and the other one must face the LAN.
>
> Because of the FW ability to segment networks, it reduces the risk of damage
> spreading from one network to another network, like a firewall or firedoor.
>
>

Re: Comodo blocking port forwarding

am 06.04.2008 22:39:35 von MR. Arnold

"Poutnik" wrote in message
news:MPG.226345c240bfac71989682@127.0.0.1...
>I do not need to learn what the hardware FWs are
> and how they are supposed to work.

It's not about a hardware FW. It's about FW(s) period. There are software
FW(s) that run on a secured gateway computer that controls traffic between
two networks, the WAN and LAN interface two NIC(s) on the computer are
being used with one NIC facing the WAN and one NIC facing the LAN.

You do know what a gateway computer is a about that's running a FW? You do
know what a network interface card is (a NIC)?

Whether it be a hardware FW solution or a software FW solution, the FW
solution must have at least two interfaces. One interface *must* face the
WAN/Internet and one interface must face the LAN.

>
> According to the fact
> Comodo is personal software firewall,
> I stayed at this topic.

Comodo is not a FW. It's a machine level packet filter that protects at the
machine level. It protects the services running on the computer at the
machine level. It does not separate two networks, like a FW does.

>
> We can debate, if Pers SW FWs are proper term, but it is commonly used.
> And modern PSW are much more then plain packet filters.
> PF have no more chance against sofisticated malware.

Yeah, they got a lot of snake-oil in them trying to protect you from you
that it cannot do.

>
> SW FW can be more easily compromized,
> but on the other hand, the have more chances
> to detect application hijacking
> and suspicious interprocess comunication.

That's not a FW functionality. That's snake-oil in a personal so called FW
or personal packet filter trying to protect you from you, that it cannot do.
However, if the O/S on a gateway computer is stripped of all software and
services that could lead to a compromise of the gateway computer, it's just
as secure as a hardware solution.

That's not the case with a PFW/packet filter solution having a secured O/S
platform to run on, so it's more easily attacked, along with the O/S being
attacked.

>
> This field is closed to distant HW firewalls.
>
> HW and SW FWs have little different goals, purpose and usage.

Hardware firewalls and network software firewalls, with a software solution
running on a secured host gateway computer, not a PFW, have the same goals,
that is to segment networks, they sit at the junction point between two
networks and act as a firewall or a firedoor to limit the possible spread of
damage between one network to another network, using two network interfaces.

> There is no use for their users fight each other.
> They have common enemy.
>
You should learn what FW(s) are about and some 3rd party personal solution
called a FW is not a FW. It's a packet filter protecting at the machine
level, at best.

You should learn what FW(s) are about hardware and software FW(s). A
personal FW in not a FW solution.

Viacomsoft has a software FW solution that uses two NIC(s) and runs on a
secured Windows Server O/S. There are others too besides Viacomsoft. Some
snake-oil trash like Commando and others are nowhere in the ballpark.

http://www.vicomsoft.com/knowledge/reference/firewalls1.html
http://www.more.net/technical/netserv/tcpip/firewalls/

Re: Comodo blocking port forwarding

am 07.04.2008 22:54:51 von Hans-Peter Sauer

Hehe, I know what SW and HW firewall is, in pure IT terminology.

For simplicity I called both HW FWs, as having dedicated device for
their functionality, in opposite to so called PFWs.

I know what the gateway computer is about,
so do I know about all OSI or TCP/IP layers it works with.
So Do I know NICs, obviously.

Surpricingly, firewalls have nothing to do with NICs. They were here
before computers have come. FWs safely separate 2 independent spaces
for fire not easily gets from one to the other. What is the "space" and
what is the "fire" can have high level of abstraction.

Computers with NICs, separating networks are just one particular
application of this idea.
Dividing spaces inside and outside of computers is other application.

But I agree with you, just for pure terminology reasons,
it is unlucky call both of them firewalls.
Neither do I like calling tea something not originated
from Camelia sinensis.
>
> Comodo is not a FW. It's a machine level packet filter that protects at the
> machine level. It protects the services running on the computer at the
> machine level. It does not separate two networks, like a FW does.

"PFW" were packet filters lets say 6-7 years before. Now these would be
horrible inefficient in protection. BTW some simple pure HW firewalls
are not any better than these packet filters...

> Yeah, they got a lot of snake-oil in them trying to protect you from you
> that it cannot do.

Well, I can get through big corporate firewalls of our big IT company
whatever I want. I would not be able to do it, if my workstation there
would have modern PFW properly configured not to allow me it.
>
> >
> > SW FW can be more easily compromized,
> > but on the other hand, the have more chances
> > to detect application hijacking
> > and suspicious interprocess comunication.
>
> That's not a FW functionality. That's snake-oil in a personal so called FW
> or personal packet filter trying to protect you from you, that it cannot do.

It depends on what you mean by separating network.
If this is not FW functionality, than they will be obsolete soon.

There is no need to compromise or even attack FW ( where HW/SW ones are
strong ), if you can persuade him.
These days is so easy to bypass strong inbound protection of HW
firewalls by other ways, relaying on weak human factor.
And than, so easy to persuade firewalls that outbound traffic should be
allowed.

> However, if the O/S on a gateway computer is stripped of all software and
> services that could lead to a compromise of the gateway computer, it's just
> as secure as a hardware solution.

No point to disagree here.

Re: Comodo blocking port forwarding

am 07.04.2008 23:42:07 von Sebastian Gottschalk

Poutnik wrote:


> "PFW" were packet filters lets say 6-7 years before. Now these would be
> horrible inefficient in protection.


Correction: They are pretty inefficient in protection, and have always been.
They can't even get the simple packet filtering stuff right, much less any
of their additional horribly stupid attempts.

> Well, I can get through big corporate firewalls of our big IT company
> whatever I want. I would not be able to do it, if my workstation there
> would have modern PFW properly configured not to allow me it.


If a host is vulnerable without a firewall, then it also is with one.
Firewalls are only a redundant layer (aka defense-in-depth) to guard against
configuration errors and to efficiently filter out junk traffic (instead of
stressing the host with doing so).

Re: Comodo blocking port forwarding

am 08.04.2008 00:50:56 von MR. Arnold

"Poutnik" wrote in message
news:MPG.2264a87969f1b81e989683@127.0.0.1...
>
> Hehe, I know what SW and HW firewall is, in pure IT terminology.
>
> For simplicity I called both HW FWs, as having dedicated device for
> their functionality, in opposite to so called PFWs.
>
> I know what the gateway computer is about,
> so do I know about all OSI or TCP/IP layers it works with.
> So Do I know NICs, obviously.
>
> Surpricingly, firewalls have nothing to do with NICs. They were here
> before computers have come. FWs safely separate 2 independent spaces
> for fire not easily gets from one to the other. What is the "space" and
> what is the "fire" can have high level of abstraction.

What? The traffic travels from the WAN to the LAN. That is traffic that's
let through the firewall, the trusted and untrusted zone. Whether it be two
NICS doing a (WAN/LAN) or the WAN/LAN on a FW appliance, traffic is
controlled between the interfaces, inbound and outbound, the trusted and
untrusted zones with a FW solution.
>
> Computers with NICs, separating networks are just one particular
> application of this idea.
> Dividing spaces inside and outside of computers is other application.
>
> But I agree with you, just for pure terminology reasons,
> it is unlucky call both of them firewalls.
> Neither do I like calling tea something not originated
> from Camelia sinensis.
>>
>> Comodo is not a FW. It's a machine level packet filter that protects at
>> the
>> machine level. It protects the services running on the computer at the
>> machine level. It does not separate two networks, like a FW does.
>
> "PFW" were packet filters lets say 6-7 years before. Now these would be
> horrible inefficient in protection. BTW some simple pure HW firewalls
> are not any better than these packet filters...
>
That's a NAT router for home usage. That's not a FW appliance.

>> Yeah, they got a lot of snake-oil in them trying to protect you from you
>> that it cannot do.
>
> Well, I can get through big corporate firewalls of our big IT company
> whatever I want. I would not be able to do it, if my workstation there
> would have modern PFW properly configured not to allow me it.

Look man, I was contacting my ISP's NNTP server on TCP 119 and POP3 TCP
110/SMTP on TCP 587 from my laptop at a client's site. First they told me
they didn't want me to do it, and then when I continued, they stopped the
connections via the company's network FW. So, please don't tell me that they
cannot stop you if they choose to do so. Whatever you're doing, they don't
view it as a threat that needs to be stopped. They stopped me last Friday by
setting FW rules.

So, are you going to sit there and tell me you have some kind of slick
little program that hidding your activities, and that the FW admin can't see
what you're doing?

>>
>> >
>> > SW FW can be more easily compromized,
>> > but on the other hand, the have more chances
>> > to detect application hijacking
>> > and suspicious interprocess comunication.
>>
>> That's not a FW functionality. That's snake-oil in a personal so called
>> FW
>> or personal packet filter trying to protect you from you, that it cannot
>> do.
>
> It depends on what you mean by separating network.
> If this is not FW functionality, than they will be obsolete soon.

It never was a FW functionality. It's a snake-oil personal FW solution.

>
> There is no need to compromise or even attack FW ( where HW/SW ones are
> strong ), if you can persuade him.

We are talking about something like Commando that runs with the O/S. The O/S
can be fooled and so can the snake-oil PFW solution if malware can get there
and can be executed. It can punceh right through it.


> These days is so easy to bypass strong inbound protection of HW
> firewalls by other ways, relaying on weak human factor.
> And than, so easy to persuade firewalls that outbound traffic should be
> allowed.

So, what happens at the boot and login process when malware can beat the
PFW, run and communicate, before the PFW can run to protect the
connection? The O/S is not waiting for the PFW before the connection is make
available? The 3rd patry PFW is not an intergrated solution.


>
>> However, if the O/S on a gateway computer is stripped of all software and
>> services that could lead to a compromise of the gateway computer, it's
>> just
>> as secure as a hardware solution.
>
> No point to disagree here.

Re: Comodo blocking port forwarding

am 08.04.2008 01:13:24 von Sebastian Gottschalk

Mr. Arnold wrote:


> Look man, I was contacting my ISP's NNTP server on TCP 119 and POP3 TCP
> 110/SMTP on TCP 587


587 is typically SUBMISSION (which is essentially SMTP but with a bit
relaxed semantics to allow more stringent spam filtering).

> So, are you going to sit there and tell me you have some kind of slick
> little program that hidding your activities, and that the FW admin can't see
> what you're doing?


Not that I'd support using such tools for circumventing a company's network
policy (which exists for a good reason), but yes, such tools exists. In
fact, one can even create cryptographically secure hidden channels, that is
if you had any method differing them from legitimate traffic (yes, even
adaptive active attacks) you would also be able to break some protocols
which are considered cryptographically strong.

Re: Comodo blocking port forwarding

am 08.04.2008 01:21:52 von MR. Arnold

"Sebastian G." wrote in message
news:65vo4tF2hi7p2U1@mid.dfncis.de...
> Mr. Arnold wrote:
>
>
>> Look man, I was contacting my ISP's NNTP server on TCP 119 and POP3 TCP
>> 110/SMTP on TCP 587
>
>
> 587 is typically SUBMISSION (which is essentially SMTP but with a bit
> relaxed semantics to allow more stringent spam filtering).

That's what the ISP told me why they were using 587. I still get a lot of
spam, but that's to be expected by Earthlink. The only reason I use
Earthlink is becuase I can use a BB or dial-up connection.
>
>> So, are you going to sit there and tell me you have some kind of slick
>> little program that hidding your activities, and that the FW admin can't
>> see what you're doing?
>
>
> Not that I'd support using such tools for circumventing a company's
> network policy (which exists for a good reason), but yes, such tools
> exists. In fact, one can even create cryptographically secure hidden
> channels, that is if you had any method differing them from legitimate
> traffic (yes, even adaptive active attacks) you would also be able to
> break some protocols which are considered cryptographically strong.

I know about the tools. But I doubt that the person I am talking to knows
this and again maybe he does. And if he is doing it, then he his not getting
paid to to that.

Re: Comodo blocking port forwarding

am 08.04.2008 02:26:34 von Sebastian Gottschalk

Mr. Arnold wrote:


>>> Look man, I was contacting my ISP's NNTP server on TCP 119 and POP3 TCP
>>> 110/SMTP on TCP 587
>>
>> 587 is typically SUBMISSION (which is essentially SMTP but with a bit
>> relaxed semantics to allow more stringent spam filtering).
>
> That's what the ISP told me why they were using 587.


I rather guess they run SMTP on port 25 as well, but offer SUBMISSION as a
good alternative for the more competent users - after all, it allows you to
generally block outgoing traffic with destination port 25, which immediately
kills off almost any thread of your machine sending out spam when getting
compromised.

> I know about the tools. But I doubt that the person I am talking to knows
> this and again maybe he does.


But Google knows them. And he certainly knowns Google.

Re: Comodo blocking port forwarding

am 08.04.2008 20:40:23 von Hans-Peter Sauer

In article , Mon, 7
Apr 2008 18:50:56 -0400 says...

> What? The traffic travels from the WAN to the LAN. That is traffic that's
> let through the firewall, the trusted and untrusted zone. Whether it be two
> NICS doing a (WAN/LAN) or the WAN/LAN on a FW appliance, traffic is
> controlled between the interfaces, inbound and outbound, the trusted and
> untrusted zones with a FW solution.

Why is so hard to understand I do know all that stuff ? BTW you forgot
to mention DMZ. Just pointing you not to be so much IT focused as being
a human being. I am expecting some abstraction ability at you :-)

> Look man, I was contacting my ISP's NNTP server on TCP 119 and POP3 TCP
> .......
> setting FW rules.

I was not saying anywere they cannot stop my activity.
What I was trying to say it is easy to hide unwanted activity within
legitimate one.


> It never was a FW functionality. It's a snake-oil personal FW solution.

A Snake is your favorite animal, I see :-)

> > There is no need to compromise or even attack FW ( where HW/SW ones are
> > strong ), if you can persuade him.
>
> We are talking about something like Commando that runs with the O/S. The O/S
> can be fooled and so can the snake-oil PFW solution if malware can get there
> and can be executed. It can punceh right through it.

You have twice mentioned Commando - I do not know such PFW.
Every software can be fooled, even such running on FWs,
no matter if in DRAM or NOR Flash.
BTW tests shows malware have hard time to get through PFWs.
And there is very huge difference between packet filter,
as you said PFW are at the best, and today PFWs.
>
> So, what happens at the boot and login process when malware can beat the
> PFW, run and communicate, before the PFW can run to protect the
> connection? The O/S is not waiting for the PFW before the connection is make
> available? The 3rd patry PFW is not an intergrated solution.

Well, You made me little dissappointed at this moment.
I have thought you have better idea about how they work.
Their low level drivers are blocking all connection activity
until PFW application is running.

You may know Perfectdisk as one of leading defragmenting programs,
able to perform "offline" defrag of all system files.
Well It has hard time today, not able to do it.
Latest PFW denies exclusive access for it.

Re: Comodo blocking port forwarding

am 08.04.2008 22:18:16 von Sebastian Gottschalk

Poutnik wrote:


> Every software can be fooled, even such running on FWs,
> no matter if in DRAM or NOR Flash.


Yes, that's the opinion of obviously clueless people. Say I setup a packet
filter to drop every packets, how exactly would you try to circumvent this?
Heck, there's even a special patch for the Linux kernel that ensures that no
packets can be sent whatsoever.

As for a more practical example: I setup a packet filter to only allow HTTP
on port 80 via a proxy, and the proxy does both DNS forwarding and HTTP
proxying. In both application protocols I set up a whitelist of allowed
domains - now how exactly would you circumvent it?

> BTW tests shows malware have hard time to get through PFWs.


Serious tests show how blatantly wrong these tests are.

> And there is very huge difference between packet filter,
> as you said PFW are at the best, and today PFWs.


And that's the problem. Not just that they shouldn't be any more, they
didn't ever manage to even get the packet filtering stuff done right.

> Their low level drivers are blocking all connection activity
> until PFW application is running.


And what happens before the driver is loaded?

> You may know Perfectdisk as one of leading defragmenting programs,
> able to perform "offline" defrag of all system files.
> Well It has hard time today, not able to do it.
> Latest PFW denies exclusive access for it.


If this is really the case, then these PFWs are obviously horribly broken.

Re: Comodo blocking port forwarding

am 09.04.2008 00:59:58 von Hans-Peter Sauer

In article <66228hF2ij117U1@mid.dfncis.de>, Tue, 08 Apr 2008 22:18:16
+0200 Sebastian G. says...
> Poutnik wrote:
>

> Yes, that's the opinion of obviously clueless people. Say I setup a packet
> filter to drop every packets, how exactly would you try to circumvent this?

Easily.
Such settings will be soon replaced by something useful.
Similarly it can be said PC switched off is 100% secure.
But such one is useless one.
>
> As for a more practical example: I setup a packet filter to only allow HTTP
> on port 80 via a proxy, and the proxy does both DNS forwarding and HTTP
> proxying. In both application protocols I set up a whitelist of allowed
> domains - now how exactly would you circumvent it?

easily, by human press to cancel such limited funtionality.

There will be always forced trade off between functionality
and security. Any system is as strong as people let him to be,
not as it could be. This trade off will be always
a weakness by principle, not less serious than
principial ability of PFW to be compromised.
>
> > BTW tests shows malware have hard time to get through PFWs.
> Serious tests show how blatantly wrong these tests are.

Not proved. Well, most you say about PFW, can be easily applied
to AV solutions. Would you persuade people not to use AV ?
The fact there is no 100% secure sw solution of any kind
( and I have never claimed the opposite )
does not mean we should not use it.
Would you not trying to cure a disease, just because there is
no garance of success ?

> > Their low level drivers are blocking all connection activity
> > until PFW application is running.
>
> And what happens before the driver is loaded?

Then there are suspicious data transactions
between other already booted devices
within so called secured LAN HW FWs do not care after.
Who would care about FW in age of notebooks,
palms, IR, wifi, bluetooth and all related stuff ? :-D

I think this discussion probably leads to nowhere.
But I take it like an income, not lost.
Glad to share opinions with all of you.
Thanks for cooperation.

Re: Comodo blocking port forwarding

am 09.04.2008 02:24:44 von MR. Arnold

"Poutnik" wrote in message
news:MPG.2265da79aa488fa3989684@127.0.0.1...
> In article , Mon, 7
> Apr 2008 18:50:56 -0400 says...
>
>> What? The traffic travels from the WAN to the LAN. That is traffic that's
>> let through the firewall, the trusted and untrusted zone. Whether it be
>> two
>> NICS doing a (WAN/LAN) or the WAN/LAN on a FW appliance, traffic is
>> controlled between the interfaces, inbound and outbound, the trusted and
>> untrusted zones with a FW solution.
>
> Why is so hard to understand I do know all that stuff ? BTW you forgot
> to mention DMZ. Just pointing you not to be so much IT focused as being
> a human being. I am expecting some abstraction ability at you :-)

We are not talking about the DMZ, and besides, no PFW has one, and it is not
a FW, period. That's what we are talking about. The junk being called a FW,
when it's not that.

>
>> Look man, I was contacting my ISP's NNTP server on TCP 119 and POP3 TCP
>> .......
>> setting FW rules.
>
> I was not saying anywere they cannot stop my activity.
> What I was trying to say it is easy to hide unwanted activity within
> legitimate one.
>
>
>> It never was a FW functionality. It's a snake-oil personal FW solution.
>
> A Snake is your favorite animal, I see :-)

When did oil become an animal? I'll put it to you another way. You have
been took. You have been bamboozled into thinking that something like
Commando is a FW solution.


>> > There is no need to compromise or even attack FW ( where HW/SW ones are
>> > strong ), if you can persuade him.
>>
>> We are talking about something like Commando that runs with the O/S. The
>> O/S
>> can be fooled and so can the snake-oil PFW solution if malware can get
>> there
>> and can be executed. It can punceh right through it.
>
> You have twice mentioned Commando - I do not know such PFW.
> Every software can be fooled, even such running on FWs,
> no matter if in DRAM or NOR Flash.

One can call it Commando, Comodo or Commode it doesn't make any difference
to me about a PFW solution. They are all junk. You see any of that trash
running on the Linux platform?


> BTW tests shows malware have hard time to get through PFWs.
> And there is very huge difference between packet filter,
> as you said PFW are at the best, and today PFWs.

No, they don't, when the user is running with admin rights and the malware
is running under those rights, which they can and do manipulate the FW rules
or some of that, toilet bowl, application control junk in them, punch right
through it. And beside, there is the fallible human being factor too. It's
not that hard to circumvent them.

>>
>> So, what happens at the boot and login process when malware can beat the
>> PFW, run and communicate, before the PFW can run to protect the
>> connection? The O/S is not waiting for the PFW before the connection is
>> make
>> available? The 3rd patry PFW is not an intergrated solution.
>
> Well, You made me little dissappointed at this moment.
> I have thought you have better idea about how they work.
> Their low level drivers are blocking all connection activity
> until PFW application is running.

Thst's BS, because I have tested the 3rd party PFW(s) for this, and they
CANNOT get to the connection first, because they are not an integrated part
of the Windows O/S platform. No Windows NT service is dependent upon or is
made to wait on the PFW service, none of them. If the PFW service is not up
and running, then how is it stopping anything that's gotten to the
connection first? It can't do it. The ones that can do it are the Windows XP
and the Vista FW(s), that's is, they get to the connection first and protect
the network connection, before anything else can use the connection.

You can put it to the test. You install Gator on that machine, and you set
all the rules you want to stop Gator form connecting outbound to one of its
many sites with your PFW solution, and you see if that PFW you hold in such
high regards can stop Gator at boot and logon. You can use Active Ports or
Currpotrs, and the best you might see is the connections being closed after
Gator has done its thing.

>
> You may know Perfectdisk as one of leading defragmenting programs,
> able to perform "offline" defrag of all system files.
> Well It has hard time today, not able to do it.
> Latest PFW denies exclusive access for it.

It's doing everything that it's not suppose to be doing. It's doing
everything but acting like a packet filter stopping unsolicited inbound
traffic from reaching the computer. It's a jack of all trades master of none
trying to protect *you* from *you*. If I don't want something to
communicate, then I stop with the O/S, or better yet, I don't install the
software at all.

Re: Comodo blocking port forwarding

am 09.04.2008 13:53:08 von Sebastian Gottschalk

Poutnik wrote:


>> As for a more practical example: I setup a packet filter to only allow HTTP
>> on port 80 via a proxy, and the proxy does both DNS forwarding and HTTP
>> proxying. In both application protocols I set up a whitelist of allowed
>> domains - now how exactly would you circumvent it?
>
> easily, by human press to cancel such limited funtionality.


Obviously you've never been working as an admin in a company. Indeed, there
is some press at the beginning, until they learn how to sit down and shut
up. After all, you're supposed to work, and thus only get access to the
resources you need for getting the work done.

> This trade off will be always

> a weakness by principle, not less serious than
> principial ability of PFW to be compromised.


Well, I'd say the latter is always more serious, especially since it's
typically an implementation problem.

>>> BTW tests shows malware have hard time to get through PFWs.
>> Serious tests show how blatantly wrong these tests are.
>
> Not proved. Well, most you say about PFW, can be easily applied
> to AV solutions. Would you persuade people not to use AV ?


Persuade? The default hypothesis is that you don't use something until you
actually need it. A virus scanner can be a useful intrusion detection
system, and a god junk filter, but anything bezong is quite furtile.

That is, if they really decide to use a virus scanner, I'd persuade them to
not rely on it as a security measure, since (sadly) most of them do. Which
also typically means that it's of no value to them any more, and thus they
should simply stop using it at all.

> The fact there is no 100% secure sw solution of any kind
> ( and I have never claimed the opposite )
> does not mean we should not use it.


Wrong direction. By principle, any additional software increases the
system's complexity and therefore reduces its security. Unless this can be
justified by the additional protection introduced, it's absolutely wrong to
use it. And for PFWs this case always holds.

> Would you not trying to cure a disease, just because there is
> no garance of success ?


And now a wrong analogy between the analogue and the digital world (hint:
the latter has an enumerable possibility space, and doesn't know the
equivalence of "just use more force"), as well as a wrong analogy between
biological diseases and computer security problems (hint: biological bodies
are open systems, by design).

>>> Their low level drivers are blocking all connection activity
>>> until PFW application is running.
>> And what happens before the driver is loaded?
>
> Then there are suspicious data transactions
> between other already booted devices
> within so called secured LAN HW FWs do not care after.
> Who would care about FW in age of notebooks,
> palms, IR, wifi, bluetooth and all related stuff ? :-D


You shouldn't post while being drunk or stoned. This absolutely doesn't make
any sense.