Comodo blocking port forwarding

Yes. Drop Comodo.

Yours, VB.

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

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

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.

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

There is no matter to the latter anyway.

Unless you know what you're doing.

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.

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.

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.

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

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.

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

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

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.

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.

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

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.

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.

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.

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.

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

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.

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.

No point to disagree here.

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.

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

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.

That's a NAT router for home usage. That's not a FW appliance.

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?

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

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.

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.

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

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.

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.

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.

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.

But Google knows them. And he certainly knowns Google.

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 :-)

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.

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

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.

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.

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?

Serious tests show how blatantly wrong these tests are.

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.

And what happens before the driver is loaded?

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