I noticed this in the firewall log. It seems that each time a host contacts MW for new work, MW scans a random port on the host that made the contact. I assumed at first that the IP making the scans (128.213.28.20)
was likely being spoofed, but upon comparing the firewall log with the BOINC log, the timestamps are an exact match between MW contact and port scans. Here's a couple examples, first excerpts from the BOINC log followed by a summary from the firewall log showing time, IP, and port on which access was attempted:

----------------------------------------------------------------
Tue 05 May 2009 02:07:26 AM CDT|Milkyway@home|Sending scheduler request: To fetch work. Requesting 27619 seconds of work, reporting 0 completed tasks
Tue 05 May 2009 02:07:31 AM CDT|Milkyway@home|Scheduler request completed: got 0 new tasks

FW> 2009-05-05 02:07:27 128.213.28.20 50995
-------------------------------------------------------------------
Tue 05 May 2009 05:04:27 AM CDT|Milkyway@home|Sending scheduler request: To fetch work. Requesting 39356 seconds of work, reporting 0 completed tasks
Tue 05 May 2009 05:04:32 AM CDT|Milkyway@home|Scheduler request completed: got 0 new tasks
Tue 05 May 2009 05:04:32 AM CDT|Milkyway@home|Message from server: No work available

FW> 2009-05-05 05:04:28 128.213.28.20 39277
---------------------------------------------------------------------
Tue 05 May 2009 05:07:05 AM CDT|Milkyway@home|Sending scheduler request: To fetch work. Requesting 39440 seconds of work, reporting 0 completed tasks
Tue 05 May 2009 05:07:10 AM CDT|Milkyway@home|Scheduler request completed: got 0 new tasks
Tue 05 May 2009 05:07:10 AM CDT|Milkyway@home|Message from server: No work available

FW> 2009-05-05 05:07:06 128.213.28.20 59316
-----------------------------------------------------------------------
Tue 05 May 2009 07:53:07 AM CDT|Milkyway@home|Sending scheduler request: To fetch work. Requesting 50017 seconds of work, reporting 0 completed tasks
Tue 05 May 2009 07:53:12 AM CDT|Milkyway@home|Scheduler request completed: got 0 new tasks
Tue 05 May 2009 07:53:12 AM CDT|Milkyway@home|Message from server: No work available

FW> 2009-05-05 07:53:09 128.213.28.20 58451
-------------------------------------------------------------------------
Tue 05 May 2009 08:14:31 AM CDT|Milkyway@home|Sending scheduler request: To fetch work. Requesting 50804 seconds of work, reporting 0 completed tasks
Tue 05 May 2009 08:14:36 AM CDT|Milkyway@home|Scheduler request completed: got 0 new tasks
Tue 05 May 2009 08:14:36 AM CDT|Milkyway@home|Message from server: No work available

FW> 2009-05-05 08:14:32 128.213.28.20 33898
-------------------------------------------------------------------------

Wazzup wid dat?

Hmmm...

First a question, is that the log from a gateway appliance, or a 'local' to the host FW?

I scanned my gateway firewall logs for the IP you gave, and it didn't show up as dropped for any reason.

Alinator

Hmmm...
First a question, is that the log from a gateway appliance, or a 'local' to the host FW?

It's a gateway firewall. 18 machines behind it. Also, the scan is always just a single port. And, since the first of May, no port has been scanned more than once. There have been 128 hits since 01 May, each on a unique port.

OK....

Well, that's kind of strange then. ;-)

I'll keep closer eye on what's going on at my gateways to see if it shows up here.

I suppose if you have a suspicious mind (which I do), you can infer some ugly implications from that! :-D

<edit> I guess I'll have to set Kiwi up again, just to make sure I'm not missing anything.

Alinator

Here's the running tally since 01 May... The firewall logs get archived monthly and I'm too lazy so far to pull up last month's to see what the situation was like. :) I got the zoo crew here checking the perimeter for any trojan road apples. <snicker>

[edit]
I forgot that I get mailed a copy of the "Firewall Hall of Shame" summary each month.
Looks like the same was happening last month too.....

414 hits from 128.213.28.20
[/edit]

    TIMESTAMP               IP_IN      TCP_PORT
2009-05-07 13:16:33	128.213.28.20	42947
2009-05-07 13:20:27	128.213.28.20	42950
2009-05-07 11:00:18	128.213.28.20	46013
2009-05-07 09:33:38	128.213.28.20	55048
2009-05-07 09:02:02	128.213.28.20	53847
2009-05-07 09:28:27	128.213.28.20	55047
2009-05-07 07:53:04	128.213.28.20	57984
2009-05-07 07:56:19	128.213.28.20	57985
2009-05-07 04:23:11	128.213.28.20	47427
2009-05-07 04:25:16	128.213.28.20	47428
2009-05-07 04:16:38	128.213.28.20	44285
2009-05-07 02:47:18	128.213.28.20	42891
2009-05-07 00:36:05	128.213.28.20	50618
2009-05-07 00:28:31	128.213.28.20	51335
2009-05-07 00:20:23	128.213.28.20	34811
2009-05-06 23:30:22	128.213.28.20	42362
2009-05-06 23:13:10	128.213.28.20	60517
2009-05-06 23:06:50	128.213.28.20	43642
2009-05-06 21:23:29	128.213.28.20	51962
2009-05-06 21:16:39	128.213.28.20	40121
2009-05-06 16:14:04	128.213.28.20	57173
2009-05-06 16:09:00	128.213.28.20	57153
2009-05-06 16:04:19	128.213.28.20	53599
2009-05-06 15:58:23	128.213.28.20	58133
2009-05-06 14:09:05	128.213.28.20	50910
2009-05-06 13:56:35	128.213.28.20	51302
2009-05-06 13:47:55	128.213.28.20	50694
2009-05-06 11:00:19	128.213.28.20	40712
2009-05-06 11:07:34	128.213.28.20	49591
2009-05-06 06:53:06	128.213.28.20	53105
2009-05-06 06:59:13	128.213.28.20	47451
2009-05-06 04:36:34	128.213.28.20	47270
2009-05-06 04:25:12	128.213.28.20	35228
2009-05-06 04:23:29	128.213.28.20	35227
2009-05-06 01:06:36	128.213.28.20	37769
2009-05-06 00:53:33	128.213.28.20	53532
2009-05-06 00:57:16	128.213.28.20	53533
2009-05-06 01:03:53	128.213.28.20	37767
2009-05-06 00:46:42	128.213.28.20	36305
2009-05-06 00:45:21	128.213.28.20	46779
2009-05-05 21:34:24	128.213.28.20	33252
2009-05-05 21:17:51	128.213.28.20	45012
2009-05-05 21:25:09	128.213.28.20	40417
2009-05-05 21:15:19	128.213.28.20	54597
2009-05-05 18:11:20	128.213.28.20	40741
2009-05-05 18:08:55	128.213.28.20	40738
2009-05-05 18:01:39	128.213.28.20	33665
2009-05-05 18:02:55	128.213.28.20	33666
2009-05-05 14:54:35	128.213.28.20	35088
2009-05-05 14:47:45	128.213.28.20	37789
2009-05-05 11:28:59	128.213.28.20	35757
2009-05-05 11:24:48	128.213.28.20	58556
2009-05-05 11:18:21	128.213.28.20	36170
2009-05-05 08:14:32	128.213.28.20	33898
2009-05-05 07:53:09	128.213.28.20	58451
2009-05-05 07:45:19	128.213.28.20	38536
2009-05-05 05:30:18	128.213.28.20	48256
2009-05-05 05:04:28	128.213.28.20	39277
2009-05-05 05:07:06	128.213.28.20	59316
2009-05-05 02:07:27	128.213.28.20	50995
2009-05-04 23:10:41	128.213.28.20	48887
2009-05-04 23:02:53	128.213.28.20	34514
2009-05-04 22:42:38	128.213.28.20	57419
2009-05-04 22:31:49	128.213.28.20	35095
2009-05-04 22:38:44	128.213.28.20	57418
2009-05-04 20:55:52	128.213.28.20	56476
2009-05-04 20:47:14	128.213.28.20	57743
2009-05-04 20:49:32	128.213.28.20	57760
2009-05-04 18:55:21	128.213.28.20	53198
2009-05-04 18:53:12	128.213.28.20	53197
2009-05-04 18:45:22	128.213.28.20	50050
2009-05-04 18:46:42	128.213.28.20	59807
2009-05-04 15:33:55	128.213.28.20	32845
2009-05-04 15:27:08	128.213.28.20	40991
2009-05-04 15:23:59	128.213.28.20	40990
2009-05-04 15:17:43	128.213.28.20	52002
2009-05-04 15:13:49	128.213.28.20	52001
2009-05-04 15:07:14	128.213.28.20	39641
2009-05-04 15:02:05	128.213.28.20	33142
2009-05-04 15:00:47	128.213.28.20	33031
2009-05-04 14:54:28	128.213.28.20	53441
2009-05-04 11:17:58	128.213.28.20	51531
2009-05-04 11:09:31	128.213.28.20	49696
2009-05-04 09:42:47	128.213.28.20	50091
2009-05-04 09:33:30	128.213.28.20	59817
2009-05-04 04:17:02	128.213.28.20	48604
2009-05-04 04:10:17	128.213.28.20	57967
2009-05-04 03:42:31	128.213.28.20	39651
2009-05-04 01:28:19	128.213.28.20	43873
2009-05-04 01:21:58	128.213.28.20	49678
2009-05-04 01:15:19	128.213.28.20	43166
2009-05-04 01:18:52	128.213.28.20	49647
2009-05-04 01:09:31	128.213.28.20	56579
2009-05-04 01:09:41	128.213.28.20	56612
2009-05-04 01:01:47	128.213.28.20	34171
2009-05-01 18:49:17	128.213.28.20	35501
2009-05-01 18:47:16	128.213.28.20	53665
2009-05-01 18:45:16	128.213.28.20	53650
2009-05-01 17:41:39	128.213.28.20	44086
2009-05-01 17:39:44	128.213.28.20	44085
2009-05-01 17:37:16	128.213.28.20	44492
2009-05-01 17:31:40	128.213.28.20	42405
2009-05-01 17:30:20	128.213.28.20	42388
2009-05-01 15:23:25	128.213.28.20	60610
2009-05-01 15:34:12	128.213.28.20	50125
2009-05-01 15:16:38	128.213.28.20	44647
2009-05-01 15:15:22	128.213.28.20	59257
2009-05-01 12:52:34	128.213.28.20	36530
2009-05-01 12:02:54	128.213.28.20	56444
2009-05-01 12:01:02	128.213.28.20	56437
2009-05-01 11:56:48	128.213.28.20	53330
2009-05-01 11:51:06	128.213.28.20	58121
2009-05-01 11:49:46	128.213.28.20	35310
2009-05-01 10:46:53	128.213.28.20	39249
2009-05-01 10:44:07	128.213.28.20	39248
2009-05-01 07:00:20	128.213.28.20	57194
2009-05-01 05:43:11	128.213.28.20	34248
2009-05-01 05:41:49	128.213.28.20	47163
2009-05-01 05:35:38	128.213.28.20	42246
2009-05-01 02:40:26	128.213.28.20	57191
2009-05-01 02:35:18	128.213.28.20	57190
2009-05-01 02:28:07	128.213.28.20	54960
2009-05-01 02:21:17	128.213.28.20	49076
2009-05-01 01:08:37	128.213.28.20	35306
2009-05-01 01:01:43	128.213.28.20	37602
2009-05-01 01:00:23	128.213.28.20	37596

Do you have both Milkyway@home and Milkyway@Home_for_GPU activated
and is it any change if you disable one of them?

Do you have both Milkyway@home and Milkyway@Home_for_GPU activated
and is it any change if you disable one of them?

No GPU involved at all (as my impressive RAC may indicate). :)

I may be showing my ignorance here, but other than settings to "Suspend GPU work while computer is in use? in Computing Preferences, I see no other settings relating to GPU.

Hmmm...

I think what he was asking is if you have a host attached to the GPU project. They both go through the same IP from the way it looks.

However, that doesn't explain why GPU would be sending unsolicited packets to any host (or anyone for that matter).

In addition, why would a contact session to CPU trigger an unsolicited packet from GPU?

Curious stuff! ;-)

Alinator

Hmmm...

I think what he was asking is if you have a host attached to the GPU project. They both go through the same IP from the way it looks.

Ah.. then no, only attached to the plain old 'creamy chocolate coating and oh-so-chewy caramel center" MilkyWay Project. Heck, I'm so low-tech I can't even spell GPU.

LOL...

The hosts I have attached via this account don't have GPU's, they have graphics de-accelerators, and Completely Paralyzed Units. :-D

Alinator

I guess one other point of interest here is that the handful of other projects I'm attached to do not seem to "hit me back" when I contact them. Of course right now I have the lion's share of resources going to MW, so it's getting the most 'call outs' from me. My magic screen of the 'Firewall Hall of Shame" only shows the 10 most active IP's that have come snooping about. I'll have to figure out the IPs of the other projects I'm attached to and and walk though the log to see if they might be in there, but to a lesser extent. But until recently, someone would have to charge pretty hard to beat out the Chinese and Russian sites as the top snoopers. MW seems to be in the lead by a nose at this point.

Well, one thing I have seen from time to time is duplicate packets getting dropped from a project. SAH during their 'meltdown and recovery periods' is an example.

I suppose that could be what you are seeing, but the part I don't like about that is I figure I should have some instances of them too. Like most folks here right now, my hosts spend a fair amount of time finding out Mother Hubbard's cupboard is bare.

Alinator

I suppose that could be what you are seeing, but the part I don't like about that is I figure I should have some instances of them too. Like most folks here right now, my hosts spend a fair amount of time finding out Mother Hubbard's cupboard is bare.

The thing that's sort of curdling my chowder is the fact that of the (now) 131 hits, each one has been to a unique port, no duplicates. Seems almost like there some intelligence behind it.

Well, now up to 137 hits, with 137 unique TCP ports scanned (all above 32000) and all still directly correlating to BOINC requests to MW.

Whether by design or not, MilkyWay@Home seems to be port scanning me.

Do a packet grab and see what it's asking for?

-jim

Do a packet grab and see what it's asking for?

-jim

Good thought, Jim. But I may have discovered the cause without having to unleash the wireshark. . It appears that the mystery packets are coming in "new not syn", which is said most likely to be caused by a broken TCP implementation. They are all part of the exchange with the server but for some reason come in with no sync bit. I doesn't seem to cause any stutters in the overall transaction, I can upload, report, and if there's work available, download it. I read a couple articles that claimed that MS IIS strayed from accepted TCP protocols and use the 'new not' syn' scenario as some sort of speed up mechanism for it's servers. Or, I suppose it could be a buglet in BOINC too. A packet with the new and not the syn bit set really shouldn't exist in this plane of the universe, so we have a firewall rule to deep-six and log any that happened along. I don't know that the logging of them is all that important in a non-debugging environment, so I think my fix for now will simply be to turn off logging for packets of that nature. Still odd though that I've never seen it happen with other projects. Anyways, I *think* this solves the mystery.

Hmmmm...

The only part I don't like about that is AFAIK, the spurious 'New not Syn' packets during connection negotiation comes from certain implementations of IIS and IE. Therefore, why should MW exhibit this phenomena, since unless they ported BOINC to IIS it should be running on a *nix.

However, there are other uses for 'New not Syn'. A more likely one is that RPI has redundant firewalling and what you are seeing is 'backscatter leakage' from misconfiguration or malfunction.

This might also explain why I'm not seeing it. I'm assuming you're observing this at BlueNorthern, and thus you have a less filtered 'pipe' than I do on my residential RR account. IOWs, they are heading my way too, but RR drops them before they can get here.

Of course, it doesn't take much imagination to see they can also be used as a method to scan network/firewall configurations and look for possible attack vectors.

So as always, if you're not expecting packets, and you don't know why they're there in the first place, it's best to poof them first and ask questions later. ;-)

Alinator

Here's something else that makes you go hmmmm. Having more curiosity than good sense, I untarred all the firewall logs since the first of May and searched though them. (mmmmm! good reading!) Amongst all those many lines of dropped packets I found three other IP's that have had 'new not syn' packets turned away at the front door. And guess what? Two of them are Seti's (128.32.18.150 & 128.32.18.189)
The other (195.184.98.178) is some FreeBSD group. Now I haven't crunched for Seti for quite a while, but still frequent the message boards and exchange the occasional PM over there. Out of 3962 packets, comprised of 317 unique IP's, that were filtered so far this month , the addresses above and MW are the only ones that have had 'new not syn' packets. I've tweaked my firewall now to log the 'new not syn' stuff, but not to include it in the "MAYDAY! MAYDAY! INTRUDER ALERT!" stats. That way I can keep an eye on them but not have them clog up the daily views of things. But now it's Friday evening, the Cubs are on, as is my low alcohol light. So I officially make this a "tomorrow problem". :)

It appears that the mystery packets are coming in "new not syn", which is said most likely to be caused by a broken TCP implementation. They are all part of the exchange with the server but for some reason come in with no sync bit. I doesn't seem to cause any stutters in the overall transaction, I can upload, report, and if there's work available, download it. I read a couple articles that claimed that MS IIS strayed from accepted TCP protocols and use the 'new not' syn' scenario as some sort of speed up mechanism for it's servers.

FWIW, Milkyway is running Apache. Yay. :)

But now it's Friday evening, the Cubs are on, as is my low alcohol light. So I officially make this a "tomorrow problem". :)

Hmm. Not a baseball fan, but a refreshing beverage sounds like a fine idea.

-jim

At the risk of digging up a long-gone thread, I thought I'd post what I've discovered over the last weeks.
The 'new not syn' packets seem to be a bug/feature/problem in BOINC. All I have to do is allow work for any given project, or for that matter, just visit the message boards for a given site, and the flakey packets come rolling in. After cleaning out all the 'new not syn' entries from the database after my last post, there are a bunch back in there only from BOINC related sites, including the the boinc/dev forums. (U of Cal). So, I guess what I'm saying is, there is no evil activity related to this project. It's just a Boinc-ism that hopefully someday will get fixed. Carry on.