Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What UDP-based application do you have running that are communicating with performance-4.chi.pnap.net.and 72-19-129-117.network.mesanetworks.net.
It started 2 weeks & I didn't change anything for the last 2 months. Nor using any UDP Application. Sorry for the wrong title....its already blocked...I just want to get rid of it. ^_^
Btw...thanks Mr. C for this & the termcap thingy. I still have not done that yet. I temporarily used the VT220.
My guess is that there is a site monitoring your network for reachability.
This occurs when, for exmaple, you are running a P2P app, or other service.
This isn't uncommon, and the connection is blocked anyway.
You could create a specific rule to drop the packet without logging, but this
is what logs are for.
yes it's a traceroute (ttl increase)coming from a linux (using udp).
Good catch.
I did note the non-routable RFC 1918 address, and thought traceroute, but let it drift by.
I'm afraid I was on my way towards sleep when I review the thread.
Well...I will just ignore this for the time being as suggested by Mr. C.. Its just funny that it was started last 2 weeks ago.
Seems it is only a few hits once a day and as long as the box can handle it (running 24/7). Probably a zombie machine tracerouting every domain name from his/her favorite or bookmark.
The DNS protocol protects against spoofing attacks by requiring an attacker to predict both the DNS transaction ID and UDP source port of a request.
In recent years, a number of papers have found problems with DNS implementations which make it easier for an attacker to perform DNS cache-poisoning attacks.
Previous versions of BIND did not use randomized UDP source ports. If an attacker was able to predict the random DNS transaction ID,
this could make DNS cache-poisoning attacks easier. In order to provide more resilience, BIND has been updated to use a range of random UDP source ports.
(CVE-2008-1447)
Why do you this has anything to do with DNS cache poisoning? It appears to be a simple traceroute.
Anyone can start one, and some applications you use can cause other servers to attempt to measure your distance and latency.
I traceroute a number of sites constantly, to maintain a graph of network health.
Look at the source address: 69.25.172.16. That the IP maps to performance-4.phx003.pnap.net makes a pretty strong case there is
nothing malicious here.
If they bother you, create an iptables rule that blocks/drops the packet w/out logging it.
This tool checks for DNS cache poisoning susceptibility, a serious security flaw in DNS recently acknowledged by CERT (US Computer Emergency Readiness Team). US-CERT VU#800113
This DNS server is vulnerable!
The DNS server at IP address XXX.XXX.XXX.XXX is susceptible to a DNS cache poisoning attack. The server is not changing its source port, query id, or both, between queries. This means it is easier than average for an attacker to spoof responses to DNS queries from this server, causing the server to serve a potentially malicious DNS record in response to any query.
Click here for more details on this vulnerability and how to patch it.
If you are not in control of your own DNS server, contact your DNS provider but do not be unduly concerned in the near term. IT administrators have only recently been apprised of this issue, and should have time to safely evaluate and deploy a fix.
DNS Server Address Query source port Query ID
XXX.XXX.XXX.XXX 32768 50674
XXX.XXX.XXX.XXX 32768 8899
How do I read the results table?
Based on the results, a DNS server is vulnerable if:
The IPs AND the Query source ports match or the query IDs match. Matching query source ports or query IDs make it easier to spoof fake results to the DNS server, poisoning its cache.
How can I check for other DNS issues related to my domain or email?
We encourage you to run DNSreport to make sure your DNS is configured properly. This comprehensive health check runs 55 tests against your domain, pinpoints the issue and offers mitigation steps on how to fix it. You can automate this report with DNSalerts - we will monitor your DNS around-the-clock and notify you via email if problems arise.
Look at the source address: 69.25.172.16. That the IP maps to performance-4.phx003.pnap.net makes a pretty strong case there is nothing malicious here.
Hi..Mr. C.
How do I know (or trace) if the IP is hostile or not? Example below...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.