constant probes on port 25975

Does this abuse thing actually work? I have a lot of probes inbound on udp ports 1026 and 1027 from some IP(s) out of Asia over the last few days. They are hammering on the ports so much that I have taken notice of it.

I wonder if there is some kind of list of IP(s) for Asia that I can get and set rules to eliminate that whole area, even though the WG is blocking them .

Duane :)

BitTorrent? Some other P2P application? I know that BitTornado, a client that I use, will randomly pick any port from 10000 to 60000 with UPnP enabled to control ports on the router. Many users of P2P clients set them to use high ports to avoid their ISPs blocking on the default client ports.

Sometimes. Odds of success is down in the 0.1 percent or less, but that _is_ "sometimes".

GENERALLY, 1026/1027 UDP is messenger spam. Unless you can have your upstream block it, there's really not a whole lot you can do. UDP is connectionless, meaning that everything can be in one packet, and no ACK or RESET, or anything else is going to have any effect. The spam was delivered, possibly from a faked source address, and that's that. We've gone to the point where we port-shift any _outbound_ UDP (which for us is almost always DNS queries) out of the 1025-1075 OR SO range to higher port numbers, and have our upstream block ALL inbound traffic in that range. As we don't send out stuff sourced from ports

1025-1075, there should be no valid UDP coming back, and any that _appears_ to be doing so is bogus, and is silently dropped.

Well, yes but... If you google for this, you'll find that the subject comes up constantly. You could start by blocking "/8s' assigned to APNIC - there are only 16.

this doesn't cover everything, AND it may cover to much. Do you have friends/business in .au or .nz? Don't forget that that part of the world is the turf of APNIC (Afghanistan east to Pitcairn Island, excluding the former Soviet Union). See below.

People are usually bitching about Korea as a source. Let's look at that using data derived from the RIR zone files:

[compton ~]$ grep -c KR IP.ADDR/stats/[ALR]* | column IP.ADDR/stats/AFRINIC:0 IP.ADDR/stats/LACNIC:0 IP.ADDR/stats/APNIC:349 IP.ADDR/stats/RIPE:0 IP.ADDR/stats/ARIN:1 [compton ~]$ grep KR IP.ADDR/stats/ARIN KR 206.219.0.0 255.255.192.0 assigned [compton ~]$

First problem. Korea (and a number of other countries) gets IP space assigned from RIRs other than APNIC. In this case, it's only a single /18, but that's just this particular case.

[compton ~]$ grep KR IP.ADDR/stats/[ALR]* | cut -d' ' -f2 | cut -d'.' -f1 | sort | uniq -c | sort -n +1 | column 11 58 1 141 1 157 1 169 2 219 3 59 1 143 1 158 24 192 10 220 1 60 4 147 1 161 19 202 7 221 13 61 2 150 3 163 35 203 6 222 1 128 2 152 2 164 1 206 1 129 1 154 10 165 75 210 1 134 1 155 4 166 85 211 1 137 1 156 8 168 10 218 [compton ~]$

That may be a bit hard to decipher, but this lists the number of network blocks assigned/allocated to Korea, sorted by the first octet of the IP address. Thus, you are taking about a lot of rules that you may need for your firewall, and this is only ONE country. You _could_ put in a rule for each block, but your poor little firewall is going to wind up spending more CPU cycles consulting the block list than actually passing (or dropping or rejecting) packets. Now, how about the rest of APNIC?

[compton ~]$ cut -d' ' -f1 < IP.ADDR/stats/APNIC | sort | uniq -c | sort +1 | column 3 AF 1 GB 30 LK 1 NR 1 TO 90 AP 9 GU 2 MM 1 NU 1 TV 1 AS 529 HK 9 MN 1126 NZ 321 TW 4738 AU 224 ID 15 MO 4 PF 6 US 52 BD 352 IN 2 MP 9 PG 38 VN 11 BN 1 IO 1 MU 187 PH 1 VU 1 BT 1489 JP 4 MV 77 PK 2 WS 1 CH 8 KH 191 MY 1 PW 1 CK 1 KI 6 NC 2 SB 868 CN 349 KR 2 NF 302 SG 10 FJ 6 LA 13 NP 295 TH [compton ~]$

Again, that is _just_ APNIC. BTW, hope you know your country codes. Did you notice that there are six blocks assigned to .us in that list? How about the one to .ch and one to .gb?

Old guy

Yea, it could be, but it's been at least a week of it doing this and we don't have anyone in the network at this time (on our end)....

I understand the UDP is a broadcast protocol and just comes down the pipe for anything that is listening.

Thanks for the other info. I guess I'll just let the FW block it on its own.

I do have another question about my ISP's DNS servers sending unsolicited inbound on UDP port 53 to the external IP at the same high port number

35469, which the FW is blocking this traffic. Do you know what that is about? I don't think I have noticed this traffic until I started using static IP(s) on one of my machines recently.

Duane :)

0768 User Datagram Protocol. J. Postel. Aug-28-1980. (Format: TXT=5896 bytes) (Also STD0006) (Status: STANDARD)

No, it's a point to point protocol, the main difference from TCP is that there is a minimum of built in support. The entire UDP header is only

8 bytes (16 bit source and destination port, 16 bit length of packet (less the IP header), and an optional 16 bit checksum. The TCP header is a minimum of 20 bytes (plus any options), and includes such things as 32 bit SYN and ACK numbers used to keep track of larger transmission sizes. 0793 Transmission Control Protocol. J. Postel. Sep-01-1981. (Format: TXT=172710 bytes) (Updated by RFC3168) (Also STD0007) (Status: STANDARD)

Even the size of the applicable RFCs show UDP to be simple, and TCP to have a lot of extra "stuff". The 16 bit UDP length (65k, which would be fragmented at the IP level) limits the size of the data. One common use (other than DNS) is UNIX file sharing - where the data is passed around in chunks of 1024 to 8192 bytes in the various default settings. The file sharing program keeps track of what's going on, rather than using TCP and sequence numbers. This gives speed over the wire, at the cost of extra CPU cycles.

The allocation of IP addresses wasn't done with this concept in mind. Some people complain about Latin/South America the same way, and advocated blocking 200.0.0.0/7 to "eliminate" the packets from there. That is no more successful than trying to block Asia (or Europe, or Africa, or California, or...). If your firewall is blocking - don't worry about it. If your systems are configured such that there is no demon/service listening on port $FOO, then any connection attempt will fail, which is also a "don't worry about it" situation.

Your posting address says InsightBB, and while I have "issues" with them, I highly doubt that their name servers would be sending unsolicited from their 53/udp to your >1025/udp. Without seeing a dump of the traffic, it's hard to say what the exact cause is, but I'd give odds that it's something on your end that initiates the traffic, and you are seeing the attempted replies to those requests.

None the less, 35469 is a "user-land" port, meaning some application on your end initiated the connection. There is no "well-known" service, nor is the port registered for anything. You are posting with OE, which says windoze - do you have sharing enabled within your LAN? Windoze boxes are notorious for badgering name servers, trying to find new hosts to drop their pants in front of. You might want to run a packet sniffer such as Ethereal on a host behind your firewall, and look at the traffic there. The normal solution I recommend is to run your own caching name server, that is authoritative for your LAN and the local 'in-addr.arpa' zone, and forwarding other requests to the ISP. If you then point your windoze boxes at that host as the name server, it will resolve all local requests without bothering the ISP. There may also be a configuration somewhere that tells applications to stop this noise, but I can't help with that, as I stopped using windoze in 1992. Perhaps Leythos, or one of the others knows how.

Old guy