Can avast firewall block a specific port?

An online test shows me three issues.
ICMP Ping
Telnet (port 23)
HTTP (Hypertext Transfer Protocol) (port 80)

Even setting ICMP ping to block, the test return it as a threat.
The other two, well, how to close that ports? Should they?

Oh, the test is from Symantec: http://security.symantec.com/sscv6/home.asp

do you have a router with firewall in ?
is it on ?

Usual question; do you have a router or other interface box with the internet? When telnet and http show up it is usually because they are the way you access router configuration from outside via logon and password. There is nothing within your computer typically that listens, so at most you should see “closed”. Ping listens, but your block should work unless there is a router involved. You can run something like currports and see if anything is listening for telnet and http.

when i do these test like “shields up” i get full stealth on all ports exept Telnet (port 23), even if i turn off or uninstall the firewall…
This bc it is the first firewall that is tested, and my ISP have supplied me with a interface box (have integrated IP phone etc ) that i must use or i have no internet, this also have a firewall that is turned on and my ISP use Telnet (port 23) to comunicate/controll the interface box

so whatever i do with the firewall in my computer i always get the same result when i run these firewall tests

https://www.grc.com/x/ne.dll?rh1dkyd2

Detecting Ports Blocked by Your ISP

Internet service providers often block specific traffic entering their network before it reaches their customers, or after leaving their customers before it exits their network. This is sometimes done to block the exploitation of common security vulnerabilities, and sometimes to prevent their customers from offering proscribed Internet services.

As a customer, it can be useful and interesting to know which service ports, if any, an ISP has chosen to preemptively block in order to restrict their customers’ global Internet traffic.

ISP port blocking can be easily tested, often quite rapidly, by arranging to allow the ShieldsUP! probe to have access to an unprotected computer. Since all non-stealth machines will respond to every open request — either affirmatively or negatively — ports appearing as STEALTH will be those blocked by your ISP, corporate firewall, or other external agency.

 	If your system is unprotected, without any personal firewall or NAT router, any ports showing as stealth  are being blocked somewhere between your computer and the public Internet. This is probably being done by your ISP. Internet traffic directed to your computer at the stealth ports will be dropped before reaching your machine.


 	If your system has a personal firewall that can be instructed to "trust" a specific remote IP, you can temporarily instruct it to trust the ShieldsUP! probe IP of [4.79.142.206]. If, after doing so, most of the service ports change to either open  or closed , you have succeeded and any which remain stealth are being blocked by your ISP.


 	If your system is operating behind a residential "NAT" router, the router will be acting as a natural and excellent hardware firewall. But that's not what you want for the moment. You can temporarily remove your NAT router and connect an unprotected computer directly to your cable modem or DSL line. Or, if you are comfortable reconfiguring your NAT router, you may be able to point the router's "DMZ" at one of your computers which has been instructed to "trust" our probe IP of [4.79.142.206]. If, after doing so, most of the service ports change to either open  or closed , you have succeeded and any remaining stealth are being blocked by your ISP.


 	Finally, if your Internet security system, NAT router, personal firewall, or whatever, can produce detailed logs of incoming Internet packets, you could leave your existing security in place, clear your log, run the service ports scan, then carefully inspect your log for any consistently missing port probes. We send out four sets of probing packets because individual packets are sometimes dropped along the way. Therefore, it won't be unusual to see occasional missing packets from your logs. What you're looking for is a complete lack of packets bound for a specific port. A careful and detailed examination of your log will reveal any missing ports which are being blocked before they reach your logging tool. (Note that this technique is not quite as foolproof as the other approaches since ISPs could be blocking outbound packets from their customers, which the other approaches would detect but log-watching would not.)

After completing the experiments above, remember to return your system to its previous tight security and verify that everything is safe again by re-running any of our tests.

Well… I’m behind the router of my business network… I mean, I’m in the office.
I really don’t know what kind of architecture the IT guys have there… but for sure there are servers and so on :slight_smile:

About Currports, how do I hell find anything related to telnet among the tons of listed processes there? ???

You can start simplifying currports output by going to “options” and selecting tcp connection/listening to cut down the traffic. In a test like this, “open” specifically means there is a process listening on the port that may be able to respond to a tcp in connection request. “closed” means the port exists, but the os is telling you there is nothing listening. “stealth” is an artificial term that says your firewall has turned off the required response to the probe, which also tells the prober there is someone there at the IP or they would get a “destination unreachable” response. “stealth” hopes the prober is preoccupied because of the delay and doesn’t notice. :slight_smile: In your case you are almost certainly seeing your corporate firewall in action.

Thanks sded. I’m really stupid regarding to firewalls… I never learned enough.
I’ve promised myself when avast released a firewall… But I was not able to.
I’ve tried to change the options… Even so, I couldn’t…

Currports is a little difficult to configure. You can only check/uncheck one entry at a time, and to display the listening ports you also need to check “Display items without remote address”. But it can be done; see attachments. :slight_smile:

Set exactly the same configuration.
Skype is listening the 80.
Nothing at 23.

How should I setup AIS firewall?

Looks like you are in pretty good shape. You already have the Skype ports allowed, since that is generally part of the setup. Only issue at work would be if they blocked some ports in that you needed, and since you can see port 80 in, looks like they haven’t. Does Skype work? If not, don’t know how to convince the IT staff to allow other open ports for you. :wink: Is there a problem, or are you just seeing the Norton report of open ports? Usually the AIS popups ask you to allow the minimum to let the current activity proceed, and if that is not enough you will see another popup later asking for more privileges. Very nice firewall to work with because of that. I block the netbios ports because I am either standalone, or on a public network, but in the corporate environment there is no reason to do that. Even in the real world I am probably overly cautious, but things work fine with the extra blocks so I leave them in even at home.

Sure. Worked yesterday… I did not test today.

I’m just seeing the Norton report. Should I ignore it?

Thanks. I use the notebook both at home and at the office.

How to accomplish that? I mean, with the netbios ports…

Thanks for the help. I know nothing about it ;D

I would just ignore the Norton report in terms of your work network. Probably worth a try running it at home, though. As far as the Netbios ports, you need them if you have a LAN at home or share things there. You can control a lot of this just by indicating that your network is private, work, or public in Windows or in AIS. Unless you have some special issues, that is the easiest route if you have AIS. Let Avast! take care of you. A lot of this stuff can be controlled manually, but unfortunately you then need to deal with “the law of unintended consequences”. :wink: .

Thanks, I will :slight_smile: