Comodo blocking port forwarding

Comodo blocking port forwarding

Secure Home | Search | About
 Networking Firewalls    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Comodo blocking port forwarding fred fleagle 03-31-2008
Posted by Sebastian G. on April 9, 2008, 7:53 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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.

Posted by Mr. Arnold on April 8, 2008, 8:24 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

> 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.


Posted by Sebastian G. on April 5, 2008, 9:27 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Poutnik wrote:

>
>> 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.

Similar ThreadsPosted
iptables port forwarding - port is filtered, needs to be open March 11, 2005, 4:15 pm
Why is port forwarding more secure than opening up a port? December 16, 2004, 1:03 pm
port forwarding/ opening port November 2, 2005, 11:03 am
ssh and vnc port forwarding March 11, 2005, 9:11 pm
pix + port forwarding September 26, 2005, 3:34 pm
Port forwarding... December 16, 2007, 3:25 pm
How safe is port forwarding? July 16, 2004, 6:46 pm
Port forwarding on a speedtouch 510? August 6, 2004, 2:30 am
Port Forwarding - The Risks? December 20, 2004, 12:35 am
port forwarding problem March 8, 2005, 2:29 pm

The site map in XML format XML site map

Contact Us | Privacy Policy