LinuxQuestions.org - How to block this....

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - How to block this.... (https://www.linuxquestions.org/questions/linux-security-4/how-to-block-this-657601/)

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

Jul 22 14:59:53 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=271 PROTO=UDP SPT=10106 DPT=33436 LEN=12

Jul 22 14:59:57 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=271 PROTO=UDP SPT=10106 DPT=33436 LEN=12

Jul 22 15:00:02 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=272 PROTO=UDP SPT=10106 DPT=33436 LEN=12

Jul 22 15:00:07 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=786 PROTO=UDP SPT=10106 DPT=33438 LEN=12

Jul 22 15:00:11 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=786 PROTO=UDP SPT=10106 DPT=33438 LEN=12

Jul 22 15:00:16 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=787 PROTO=UDP SPT=10106 DPT=33438 LEN=12

Jul 22 15:00:21 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=787 PROTO=UDP SPT=10106 DPT=33438 LEN=12

Jul 22 15:00:26 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=3 ID=788 PROTO=UDP SPT=10106 DPT=33438 LEN=12

Jul 22 15:00:31 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=3 ID=788 PROTO=UDP SPT=10106 DPT=33438 LEN=12

Jul 22 06:19:30 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.152 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=782 PROTO=UDP SPT=11467 DPT=33438 LEN=12 

Jul 22 06:19:35 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.152 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=782 PROTO=UDP SPT=11467 DPT=33438 LEN=12

Jul 23 06:19:41 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.152 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=783 PROTO=UDP SPT=11467 DPT=33438 LEN=12

Jul 23 06:19:47 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.152 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=783 PROTO=UDP SPT=11467 DPT=33438 LEN=12

Jul 23 06:19:53 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.144 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=1043 PROTO=UDP SPT=11467 DPT=33439 LEN=12

Jul 23 06:19:59 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.144 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=1043 PROTO=UDP SPT=11467 DPT=33439 LEN=12

Jul 23 06:20:05 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.144 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=1044 PROTO=UDP SPT=11467 DPT=33439 LEN=12

Jul 23 06:20:11 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.144 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=1044 PROTO=UDP SPT=11467 DPT=33439 LEN=12

Or just ignore this?

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:

Originally Posted by Mr. C. (Post 3223400)

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).
You get this everyday? Do you host a server on this machine?

Quote:

Originally Posted by nx5000 (Post 3223966)

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.

Quote:

Originally Posted by nx5000 (Post 3223966)

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?

Yes this is a webserver. And yes I get this everyday and below is for today July 24.

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

Jul 24 05:23:18 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

Jul 24 05:23:24 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=2 ID=783 PROTO=UDP SPT=10991 DPT=33438 LEN=12

Jul 24 05:23:30 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=2 ID=783 PROTO=UDP SPT=10991 DPT=33438 LEN=12

Jul 24 05:23:36 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.16 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=1298 PROTO=UDP SPT=10991 DPT=33440 LEN=12

Jul 24 05:23:41 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.16 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=1298 PROTO=UDP SPT=10991 DPT=33440 LEN=12

Jul 24 05:23:47 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.16 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=1299 PROTO=UDP SPT=10991 DPT=33440 LEN=12

Jul 24 05:23:53 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.16 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=1299 PROTO=UDP SPT=10991 DPT=33440 LEN=12

Thanks.

Throw their address in your /etc/hosts.deny file and forget about it. Unless you need them for something.

Quote:

Originally Posted by Hendronicus (Post 3224479)

Throw their address in your /etc/hosts.deny file and forget about it. Unless you need them for something.

That doesn't make sense; iptables gets the packet and logs the event before tcpwrappers ever sees it. It is too late for tcpwrappers.

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 



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.

snip..:(

You've shown you have the DNS vulnerability, but haven't demonstrated a connection between the two.

Regardless, get the DNS problem fixed.

Quote:

Originally Posted by Mr. C. (Post 3225691)

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...

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] ]

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=49466 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=46336 DF PROTO=TCP INCOMPLETE [8 bytes] ]

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=49468 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=46338 DF PROTO=TCP INCOMPLETE [8 bytes] ]

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=49470 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=46340 DF PROTO=TCP INCOMPLETE [8 bytes] ]

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=49472 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=46342 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Jul 28 09:36:49 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=52676 DF 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=13147 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Jul 28 09:36:49 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=52678 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=13149 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Jul 28 09:36:49 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=52680 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=13151 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Jul 28 09:36:49 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=52682 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=13153 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Jul 28 09:36:49 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=52684 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=13155 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Thanks in advance.