Unsolicited udp & tcp packets aimed at port 42508

Hello,

I was wondering if anyone else has seen the type of traffic I will describe herein.

Packets are both udp and tcp with the vast majority being udp. The dst port is always 42508(candp). The src port varies.

The traffic comes from many different addresses from around the globe.

The udp hex dump always contains IP@.SCPA.

Here is a captured packet:
No. Time Source Destination Protocol Info
8 369.488553 200.42.87.243 24.243.46.239 UDP Sourceport:30407 Destination port: candp

Frame 8 (77 bytes on wire, 77 bytes captured)
Arrival Time: Jan 7, 2009 12:15:10.655051000
[Time delta from previous captured frame: 5.057417000 seconds]
[Time delta from previous displayed frame: 5.057417000 seconds]
[Time since reference or first frame: 369.488553000 seconds]
Frame Number: 8
Frame Length: 77 bytes
Capture Length: 77 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:data]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Cisco_29:df:05 (00:15:f9:29:df:05), Dst: 3com_ce:ee:01 (my mac)
Destination: 3com_ce:ee:01 (my mac)
Address: 3com_ce:ee:01 (my mac)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Cisco_29:df:05 (00:15:f9:29:df:05)
Address: Cisco_29:df:05 (00:15:f9:29:df:05)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 200.42.87.243 (200.42.87.243), Dst: 24.243.46.239 (24.243.46.239)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 63
Identification: 0x9b2c (39724)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 113
Protocol: UDP (0x11)
Header checksum: 0x4682 [correct]
[Good: True]
[Bad : False]
Source: 200.42.87.243 (200.42.87.243)
Destination: 24.243.46.239 (24.243.46.239) User Datagram Protocol, Src Port: 30407 (30407), Dst Port: candp (4250
Source port: 30407 (30407)
Destination port: candp (4250
Length: 43
Checksum: 0x44a1 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Data (35 bytes)

0000 47 e2 0f 52 e9 99 0d 55 7e a5 14 67 0a f3 ef 00 G..R...U~..g....
0010 00 01 00 0c 00 00 00 c3 02 49 50 40 83 53 43 50 .........IP@.SCP
0020 41 02 00 A..
Data: 47E20F52E9990D557EA514670AF3EF000001000C000000C3...

Any ideas?

 

I was just curious if anyone that read this was looking for and open port 42508 today. From 15:05 GMT to 15:22 GMT with some intermittent packets after ending at 18:48, I received unsolicited packets directed at the port. The traffic was different that what I normally see in that there were almost the same amount of tcp packets as the udp. The period of elapsed time between the packets was also different.

If someone was trying to help, thanks.

Again, any ideas as to what this traffic might be?

 

Hello,

Thanks. However, I already knew all of that. I submit daily logs to dshield and have for years. I know what they say about it.

No, I do not use CA software, I never have; unless Astaro is using it for one of the two gateway AVs. However, I do not think that is the case. I believe they use Clam AV and Authentium Scanner.

https://www.wilderssecurity.com/showthread.php?t=180126

I am not aware of a default port of 42508 for Authentium, and since I have captured hours of packets during these events, I can be relatively sure when I say; I do not see any solicitation of the traffic. Unless there is a protocol that wireshark/ethereal does not recognize that could prompt a machine (and its owner) to seek a connection on port 42508.

My IP being cloned might facilitate this traffic since the internet routers would not know the difference; but what would be the point of that, other than to irritate me. I am sure that my ISP would catch that?

Thanks for your help. If you think of anything else please let me know.

 

I thought of it and then dismissed it. I have worked hard to clean up this IP. If I get a new one then I may be getting traffic from who knows what. Kazaa, limewire, trojans, worms, bots/zombies, and the like from the previous IP holder.

I am reading an article about the Cisco CMTS. If it is configured correctly, cloning should be very difficult. However, that would not stop someone from spoofing my IP address outside of the 10 net. I think the internet routers would still send me some of the traffic.

I looked at the tcp traffic again from the last event captured, and the syn flag is set every time. If it were reset then it could be a DDOS spoofing my IP. I have seen that before. I am not sure yet what the syn flag could indicate. If it is an attempt at a syn flood attack then the person lacks the understanding on how it works.

I wonder if it could be filesharing software or someone looking for bittorrent/filesharing type traffic. Tcp syn flags and all the udp traffic.

Alas, I wish I could smack the person in the back of the head. Waza madda wit ya?

Still thinking...

 

I may know how this traffic originates.

SYN: The TCP SYN flag indicates a request to establish a connection.

Now, months ago I realized that my wireless connection had been cracked (even with WPAAES and a 63 character ascii key) I think the person had time to install all sorts of stuff I found 3 of my servers needed cleaning.

Unfortunately, I am am ignorant about computer forensics. I am learning about forensics. I still have one box that I upgraded/replaced ready to examine once I learn enough.

I wonder if the syn flags and the udp traffic is an indicator of someone trying to reconnect to one of the once hijacked servers? Hum... Maybe they just continue to send the packets thinking that my pc might be turned off, and when I turn it on, they can reconnect? Or maybe my IP is still in one of their address lists so when they reconnect it begins to try and reconnect with something that no longer exists.

Speculatin'...

 

I think that I would like to send "synack" packets back at the IP during this event, but only synack. I think that may hang up his or her pc.

Am I right?

What software could I open quickly and accomplish this end. I would have to be able to pick the synack to send and input the IP address of the person. It would have to be configurable so I could time my synack with his or her syn.

Is this possible?

 

Ok, then let me explain a syn flood and ddos attack.

If I were to conduct such an action I would be sending the syn packets to a port or ports. Lets use port 42508 for example. when the victim's machine, in accordance with a proper three way handshack, sends the synack, I would withhold my ack hence causing the other machine to wait for the ack. I would do this to every open port over and over effectively leaving no ports for actual traffic. All ports would be in a half-open state.

I did not indicate that I would do that at all. Since the unsolicited syn packets are directed at MY network, I could be described as the victim of an attempted syn flood. Though as I said in a previous post, not a very well crafted one.

A ddos basically uses up all of the victims bandwidth. It would take more that a couple of PC to accomplish this. That is why ddos attacks usually come from large bot nets. That were not roasted. Yes, I did say that I have received the reset traffic from a ddos attack on someone elses server a few years back. The host nulled all of the server's ports but one. I received the reset traffic from that port since my IP address was being spoofed for about 27 hours. About 300-600 packets a second for 27 hours. That was an annoyance. I spoke to the owner of the server. He was willing to give me the data logged from the successful ddos attack on his server, but the hosting entity was not so helpful. So I could not track what machines were actually compromised (probably bots/zombies). I doubt the hosting entity did anything to help anyone but themselves.

With syn flood and ddos explained, I hope you can now rest easy again, as I am not the bad guy. Though in today's world knowing the difference is clouded. Germany and the UK being prime examples. They (the good guys) break into homes and plant keyloggers and spyware. That sounds criminal to me, but they are the good guys, right?

What I wanted to do was send the synack only (completely controlled) and ignore the ack. Since I did not originate the attack I am not the badguy. It is like someone knocking at your door and you say hello come on in, but never allow the guy to open the door. If he or she is a persistent criminal they will knock again, but I won't open the door after I say come on in. Hopefully they will get disinterested and go away.

If the address is spoofed then the real address with see synack packets and if they use stateful (not ip chains) the packets will be dropped since they did not originate from that machine. No biggy. It would look like background radiation if I may quote someone else. If they notice at all. I would probably not have to send very many packets.

Back to the question that brought my integrity and honor into question, what I asked was, if I send the synack(s) only, would the perpetrators machine get hung up trying to send and ack. My hope would be that they give up or that the traffic would stop. Since I do not know very much about this sort of thing, and the traffic has become an irritant, I was thinking about turning the irritation back onto him or her. Again, I did not originate the traffic. I an not trying to do anything malicious. Someone else might be though.

Now, is your assumption correct, am I trying to syn flood or ddos someone?

I say no.

...and I doubt anyone else cares enough to respond. So I sincerely thank you for your time and effort.

 

Another...this is the third different IP since I posted. And its still going. abuse_at_verizon_dot_net received an email from me, but I doubt they do anything. I am always a little disappointed with ISP response both here in America and Globally.

2009:01:12-09:54:13 action="drop" srcip="71.177.123.172" dstip="24.243.46.239" proto="06" length="48" tos="0x00" prec="0x00" ttl="116" srcport="4044" dstport="42508" tcpflags="SYN"
2009:01:12-09:54:16 action="drop" srcip="71.177.123.172" dstip="24.243.46.239" proto="06" length="48" tos="0x00" prec="0x00" ttl="116" srcport="4044" dstport="42508" tcpflags="SYN"
2009:01:12-09:54:22 action="drop" srcip="71.177.123.172" dstip="24.243.46.239" proto="06" length="48" tos="0x00" prec="0x00" ttl="116" srcport="4044" dstport="42508" tcpflags="SYN"

Current time 14:51 and still SYNning away...no pun intended.

 

now using 44197 all udp with IP@.SCPA in the data...3 hours now

13:49:23 DROP UDP 99.140.57.96 : 49162 24.243.46.239 : 44197 len=63 ttl=111 tos=0x00
13:51:30 DROP UDP 99.140.57.96 : 49162 24.243.46.239 : 44197 len=63 ttl=111 tos=0x00
13:53:23 DROP UDP 99.140.57.96 : 49162 24.243.46.239 : 44197 len=63 ttl=111 tos=0x00
13:55:28 DROP UDP 99.140.57.96 : 49162 24.243.46.239 : 44197 len=63 ttl=111 tos=0x00
13:57:33 DROP UDP 99.140.57.96 : 49162 24.243.46.239 : 44197 len=63 ttl=111 tos=0x00
13:59:29 DROP UDP 99.140.57.96 : 49162 24.243.46.239 : 44197 len=63 ttl=111 tos=0x00
14:01:24 DROP UDP 99.140.57.96 : 49162 24.243.46.239 : 44197 len=63 ttl=111 tos=0x00

 

Now ICMP flood from 76.220.126.207 over 300 packets so far...

 

Yea I know.

Thanks.

So have you any other ideas to what this traffic might be?