Firewall not working properly

Comodo Internet Security - CIS Firewall Help - CIS
1

Many questions, good to have a forum to sort to :a0

I have a problem. I use opera. Opera have an integrated irc client which is not related to world wide web, it is an entirely different service on the internet, it usually use ports between 6667 and above.

I have granted opera a predefined policy called “Web browser” which means it has access to the loopback zone, outgoing http requests, outgoing ftp requests, and dns requests, everything unmatching is blocked.

Why, in the name of mother theresa is opera still allowed to connect to irc, flawlessly. In the open connections there is perfect and smoothly established connections to irc servers on ports like 6667 and so forth. I am able to chat on irc. This should not be possible as I have granted opera only the web browser policy. There is no ports other than web requests, ftp and dns. Everything else is blocked.

Can anyone explain what is happening? :smiley:

2

Here are the rules for opera by the way:

http://i.imgur.com/P871N.png

3

There is outgoing traffic allowed; that is enough for IM programs to be able to talk to people.

Unless you need an open port for unsolicited incoming then you need to adapt the rule you made for Opera.

4

It only allows outgoing http ports, you can not connect to IRC using http ports. Irc ports are usually between 6667 - 7000. My irc connection in opera uses port 6667.

Why does it not block the remaining requests as the firewall rules indicates?

5

Opera is not a stand alone IRC client, it uses a web gateway to route IRC traffic, hence you don’t need to allow the same ports as a native client such as MIRC. However, if you’re going to use things like DCC/fserve, you may need to make adjustments.

6

I don’t know how you come to conclude that, the connection list clearly shows that opera runs a separate thread towards an irc server directly on port 6667.

There can not be a web gateway involved here, the connection is directly against an irc server on port 6667. The connection is established and running smoothly, data keep flowing in like it should (Should not) do. The firewall rules does not allow opera to use such services so I wonder why it passes the firewall rules.

7

You’re quite right, I don’t actually use Opera and I was thinking about one or the ways connectivity works to IRC in another browser. My apologies for the mistake.

It is quite a curious scenario, as the pre-defined web browser rule does indeed prohibit connections on port 6667, yet Opera does connect. Curiously, if one changes the alert level in the firewall to capture port information and instead of using the pre-defined rule, one uses custom rules, requests are made over TCP to port 6667.

Further investigation is warranted.

8

I have the alert setting to ‘very high’ and the ‘firewall security level’ set to custom policy

9

Can you show the Firewall logs of around the time Opera is connecting toIRC?

10

Sorry no logs post on the internet. I suppose you are looking for IRC related stuff, I CAN filter out specific IRC related connections if you like to, but I will not paste entire logs on the internet.

Let me know if you’re interested.

11

I could not find any logs, it is obviously not being logged, so I had to capture the connection list itself. You judge whats happening.

If you lookup the ip addresses you see they are irc servers.

http://i.imgur.com/C9klz.png

12

There’s definitely something strange occurring here.

When the default web browser policy is used, with the addition of the logging to each rule, (image 1) no alerts are given and the only entry logged id for DNS. (image 2) However, when the connection status is viewed in TCPView/Currports, it’s clear that a connection has been made over TCP to port 6667 (image 3)

When placed in custom policy mode with the alert level cranked up, Opera will prompt for connection on 6667. (image 4) it will also request a SSDP connection (image 5) and a rather odd TCP connection (image 6)

I also checked this in Wiresharrk and Opera appears to be making a direct connection to IRC over TCP port 6667, however, I need to take a closer look at the data.

Edit: The SSDP request seems to be related to Opera Unite and the odd TCP request is something called md-cg-http, about which I can find very little.

There’s something very odd going on here, apart from Opera being able to connect on a port for which it has no permission, I’ve found the the only rule in the pre-defined web browser policy that’s triggered, when it makes a connection on port 6667, is the passive-ftp rule, which allows TCP out to everywhere, but only to the privileged port set (ports 0 to1023)

[attachment deleted by admin]

13

I believe there may be a problem with the pre-defined web browser rule. As stated above, if Opera is allocated this pre-defined policy, it is able to connect to IRC and does so via the passive ftp rule. This can be see by selecting that specific rule and selecting to log.

As a test, I gave Opera a custom rule that is equivalent to the passive ftp rule, DNS and a block all unmatching rule, using just these. Opera was blocked from making connections to port 6667.

In another test, I allocated Opera the pre-defined browser rule but removed loopback, http and ftp, leaving only passive ftp, DNS and the block rule. Opera was able to connect to IRC without any additional alerts.

I will run all these tests again as a check but it would be helpful if someone could check these results.

14

Radaghast,

I’m not sure at all, but doesn’t the last paragraph in the link below give some light on the mystery?

If you are unable to unblock the required ports, you can also tell Opera to try using passive DCC. When using passive DCC, the recipient must have the required ports available (the port will be chosen from the recipient's DCC port pool). To tell Opera to use passive DCC when sending files, edit the properties of the chat account you are using, and say that you cannot accept incoming connections; Tools > Mail and chat accounts > Select the account, and click 'Edit' > Outgoing > untick 'Can accept incoming connections'. The recipient will need to ensure that their client is able to accept incoming connections, and that their DCC ports are not blocked by any firewall or router.
15

Thanks for the reply Boris, unfortunately, we’re not even that far into using IRC yet, just merely connecting. I would sincerely hope that DCC and Fserve would generate the required alerts but that test can wait for now.

16

Sorry, I was unclear. I meant that in using passive DCC, Opera Chat seems able to bypass the restrictions made in FW.

17

Thanks for the reply, I did understand your previous comment, however, what we’re talking about here is simply connecting to and IRC server, not hosting Direct Client to Client chats/file transfer, which only takes place after a connection has been established.

There’s something else going on here and it’s not solely related to Opera. It would also appear that I am able to connect to an IRC server using my IRC client (HydraIRC) of choice, using the pre-defined web browser rule. Once again, it appears this rule is allowing connections to be made to a port, which is restricted by the rule.

18

Some further tests:

Switching away from Opera to a dedicated IRC client (HydraIRC) to try to determine the nature of the issue. These tests were performed on a clean installation of Windows 7 Ultimate x86 (not a VM) with a clean installation of CIS. HydraIRC is a portable application so the zip was unpacked to folder on the desktop.

Windows settings:
All defaults apart from the DNS client service, which is disabled.

Settings for CIS:
Firewall enabled in Custom policy Mode and Alert settings on very high.
Ipv6 filtering and create rules for safe applications are unchecked.
Defense+ and AV are not installed and cloud look-ups are disabled, as are automatic updates.
I also deleted the folder containing the TVL.
All other settings are defaults.

In the first test we create a rule for HydraIRC using the pre-defined web browser rule. The rule is edited to enable logging. Once the rule is applied we run HydraIRC and connect to an IRC server. This succeeds and log entries are created for DNS and the connection via TCP to port 6667 (one of the default IRC server ports). A local connection is also made to IDENT over TCP port 113, although this is not logged by CIS, it can be seen via netstat or some other network monitor such a TCPView/Currports. (See images 1 to 5)

In the second test we modify the pre-defined web browser rule by placing a block and log on the entry for passive ftp (Allow Outgoing FTP-PASV Requests), as this is the only rule in the pre-defined set, apart from DNS, that generates a log entry. Now we attempt to connect to an IRC server. This time the connection fails. (see images 6 to 9)

In the final test, we remove the pre-defined web browser rule and create a functionally equivalent analogue. Once done, we attempt to connect to an IRC server. This fails. (see images 10 and 11)

One point of note, when capturing data in the CIS logs, only the first connection to an IRC server will generate an entry, however, subsequent connection’s do succeed.

The question is, why does the pre-defined web browser rule allow these connections when a functionally equivalent rule does not, (which is as it should be)? Moreover, why does this rule allow these connections in the first place. To my mind, this appears to be a security vulnerability in the firewall.

[attachment deleted by admin]

19

At the danger of making a mistake but since FTP was discussed, the following by egemen about FTP in response to a remark by L.A.R. Grizzly:

20

Thanks for the reply Eric. Thing is, this isn’t ftp, it’s IRC and it’s only the pre-defined web browser rule that’s a problem. It just so happens that for what ever reason, an IRC client is able to connect out on TCP port 6667, using the passive ftp rule, and that rule only allow TCP out to ports 0 to 1023.