|
| |||||
| Home | Reviews | Tools | Forums | FAQs | Find Service | ISP News | Maps | About |
how-to block ads |
3.0 Results
Normally, a closed UDP port responds to an incoming packet by returning an "ICMP unreachable" message. Many port scanners depend on this message to list the port as "closed". Some firewall programs "absorb" the UPD packet before it ever reaches the UPD port and an "ICMP unreachable" message is not sent. In a case like this the scanner is fooled and thinks the port is "open", when it actually may be closed. One way to tell if your firewall is exhibiting this behavior is to scan a large number of your UDP ports. Since it's impossible for your system to have several thousand ports open at once, if a UDP scan tells you they are, chances are it's your firewall doing its job.
by Mack Bolan • If a UDP port is probed and a PORT UNREACHABLE packet comes back, the port is marked as closed. • If a UDP port is probed and nothing comes back, it is marked as open. If you block only certain UDP ports, then strangely, you appear to have those ports open to a scanner. It is better to simply block response from ANY and ALL UDP ports. That way, you are not giving away any information at all. by KeysCapt by KeysCapt by KeysCapt IDENT is used when you connect to mail servers, or to IRC servers, to find out "who" is using the service. With IDENT filtered, your ISP mail server (unlikely) or IRC server (likely) may refuse your request or take a long time to respond as it waits for a closed/open response. It is possible to remove IDENTD as showing up as a port by reconfiguring your firewall to over-ride the default rules. As above, if IDENTD is filtered in this way, IRC and mail servers may not work properly. You can also decide that IDENTD is safe, since just having it visible does not mean there is anything that can be exploited on your side, and live with the less than "perfect" results.
| ||||||||
| Tuesday, 21-May 20:36:01 | Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo over 13.5 years online © 1999-2013 dslreports.com. |