how-to block ads
|
| | | | FAQ Revisions | Editors: Wildcatboy  , gwion , keith2468 , amysheehan , CalamityJane
Last modified on 2009-08-11 17:26:23
| |
|
|
2. Personal Firewalls (general)·Why is my ISP's nameserver scanning/attacking me?
·Why is my computer trying to contact crl.verisign.net?
·Why am I being pinged, probed or attacked on this port?
| | | It's not! This is common behavior of personal firewalls (of most vendors) when handling traffic from a very slow or otherwise misconfigured domain name server. These "attacks" are always inbound UDP request from port 53 on the ISP's machine to increasing ports on your machine. This is legitimate traffic that is being mischaracterized by your firewall as an "attack."
Here's what's happening:
When your computer sends out a domain name request to your ISP's DNS server (say, to look up the IP address for "www.dslreports.com"), your firewall makes note of this request so when the response arrives, it's able to recognize it as being associated with the original request and permits it to return. You couldn't surf the web (or do much of anything else on the Internet) without these DNS queries and responses.
Not all DNS requests actually get responses. Sometimes the request gets lost on the way out, sometimes the server fails to respond for whatever reason and sometimes the response itself is lost. If the firewall decided to wait forever for all responses, it would find that its table of pending requests would grow every time one got lost.
To prevent this, an internal (and invisible to you) table attaches a "timeout" to each waiting connection, and if so much time elapses without a response, the firewall simply discards the information. For responses that were truly lost, this is exactly the right thing to do.
But once in a while a DNS server is misconfigured or horridly busy and sends back responses after the firewall has discarded its memory of the request. This UDP datagram is otherwise well formed -- it answers the question you asked -- but since the firewall isn't expecting it any longer, it reports an "attack."
We could hardly be more clear: you are not in any conceivable way being "attacked." At most, you should ignore these reports, and many advise adding your ISP's nameserver to your trusted zone. By relying on these servers to translate names to IP addresses, you are already granting enormous trust to these machines, so adding a bit more trust to silence your firewall seems like a minor concession.
In theory, there may be some way to adjust the timeouts used by the firewall, but we don't know how in any particular case.
Ignore these reports.
 feedback form
 feedback form
by Steve edited by JMGullett
last modified: 2007-06-11 16:39:58 | | | "CRL" is a "Certificate Revocation List," and it's a list of SSL web security certificates that should no longer be trusted. These could have expired, been stolen or otherwise removed from service, and it's part of a security infrastructure supported by Verisign. Your system is merely trying to get the latest list of revoked certificates so it won't accept them as "valid" any longer. The activity is innocuous and won't hurt anything. You trust Verisign for a lot more than this every day.
It is dumb, however, that visiting crl.verisign.net brings up a list of files whose purpose is not obvious; it raises many more questions than it answers. Many of us believe they ought to put up an "index.html" page that describes why the server is there.
feedback form
feedback form
by Steve edited by JMGullett
last modified: 2007-05-31 16:11:25 | | | Your firewall is recording "events," not "probes." Events can really only be called probes after an investigation shows an intent to enter computers without proper authorization.
1. Provided the destination ports the events are occurring on are closed or stealthed, nobody is getting into your computer.
Repeated activity from a source IP address on closed or stealthed ports usually indicates a worm or virus or a script kiddie using a simple trojan kit.
Beware of attackers who try dozens of ports looking for an open port with an unpatched vulnerability.
2. Determine how long you have had your IP address. You can do this by examining your firewall log for the destination address of inbound events.
Most surges in events are caused by inheriting an IP address that was formerly used by a busy server. In this case, the events commonly taper off over a period of 1 to 72 hours.
These are not probes; these are legitimate attempts to contact the server that formerly held that IP address.
3. Gather information on the ports concerned and their common uses here:
http://isc.incidents.org/
Enter a port number in the "Port Look" box on the left, and click the "details" button.
Using ports 6667 and 6668 as examples you get:
isc.incidents.org/port_details.html?port=6667
isc.incidents.org/port_details.html?port=6668
Scroll down to read the well-known uses and vulnerabilities of the port.
Using ports 6667 and 6668 as examples:
- 6667 is used by a variety of trojans, and
- 6668 is used by IRC and IRCU.
Keep in mind that many software packages can be configured to use different ports than the standard. Port usage lists do not include ports used by uncommon software and malware. Neophasis and other port usage lists merely suggest the common software and malware that use a port.
If your software isn't using the ports described, and you don't have a trojan using the port described, or if the events are blocked by a firewall, you have no immediate concern.
4. You can use the Security Scan in the Tools section of BBR, "Shields Up" at grc.com or the port scan at »security.symantec.com to see what ports are open on your computer.
5. If you are concerned about events occurring on ports on your system, you can use the free services of myNetWatchman and DShield. Both of these organizations collect, anonymize and analyze firewall logs.
http://www.mynetwatchman.com
MNW focuses on filtering out false alarms and reporting infected machines and hacking attempts to the ISP responsible for the IP address they originate from.
http://www.dshield.org
DShield focuses on gathering statistics on abnormal Internet activity. DShield feeds the Internet Storm Center.
6. If you are still concerned about what is going on, feel free to post a question in a new topic in the BBR Security Forum.
Please include these details in your post:
a) Have you had your current IP address for less than 72 hours (3 days)? If less, roughly how long?
b) What are the first two parts of your IP address? (e.g. 123.123.xxx.xxx)
c) What source and destination ports (number and TCP/UDP) are involved?
d) Do the events occur in clusters or one at a time? Roughly how many do you get in an hour (a few, dozens, hundreds)?
e) Is it just one source IP address or many? List some of the source IPs (they aren't secret).
f) An extract of your firewall logs would be very useful. (It is okay to obscure the last 2 parts of your IP address, but do not obscure anything else.)
7. If you are a business, organization or professional that depends on the security of your computer system, we strongly urge you to consider using the services of an IT security professional to review the security of your system.
Additional Information:
Additional places to look up ports:
»www.neohapsis.com/neolabs/neo-ports/
»lists.gpick.com/pages/Port_Lists.htm
/ports
Third Party Firewall Log Collection and Analysis Tools (these work with NAT routers):
www.WallWatcher.com
www.LinkLogger.com
www.kiwisyslog.com
Other useful links:
/faq/9444
/faq/9445
/faq/9763
/faq/3497
/faq/2467
/faq/5503
The advice given here is general in nature and not adequate for high-value or highly attractive targets.
Recent changes:
2005-05-14
Added section for "Third Party Firewall Log Collection and Analysis Tools." IM keith2468 with suggestions of other safe and inexpensive tools.
2005-01-15
Inserted item 6, suggestions on what to include in a forum post if still concerned.
feedback form
feedback form
by keith2468 edited by JMGullett
last modified: 2007-06-11 16:54:01 |
|
