How to block this....
Hi guys...
Everyday I always get this in my log. The iptables seems to work fine but how do I get rid of this? Code:
[root@eapi log]# grep eth0 messages Thanks in advance. |
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.
|
Quote:
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).
You get this everyday? Do you host a server on this machine? |
Quote:
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. |
Quote:
Code:
Jul 24 05:23:13 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.24 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=782 PROTO=UDP SPT=10991 DPT=33438 LEN=12 |
Throw their address in your /etc/hosts.deny file and forget about it. Unless you need them for something.
|
Quote:
|
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. Thanks guys. |
Hmmm...its a coincidence that this is a part of DNS poisoning? Come to think of it. It started 2 weeks thats just about the same day within 07/10/08.
Excerpt from https://rhn.redhat.com/errata/RHSA-2008-0533.html 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) Is it? |
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. |
Hi..Mr C.
Because I tried the test...and sad to say... Code:
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 |
You've shown you have the DNS vulnerability, but haven't demonstrated a connection between the two.
Regardless, get the DNS problem fixed. |
Quote:
How do I know (or trace) if the IP is hostile or not? Example below... Code:
Jul 28 09:26:04 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=49464 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=46334 DF PROTO=TCP INCOMPLETE [8 bytes] ] |
You're like the young lad on his first fishing trip, always yanking at the reel. :-)
Blocking ICMP type 3 codes 0-3, 9-13 is bad. ICMP messages are required for proper network functionality. Inexperienced firewallers block all of ICMP and then are troubled when their networks are slow, have bizarre timeouts, delays, or dropped connections. Spend some time learning about how TCP/IP network works if you are interested in this stuff. Go look-up ICMP and the different types and codes. Believe me, when the hostile guy wants your system, you'll never know it hit you. |
Quote:
|
All times are GMT -5. The time now is 12:10 AM. |