It was a pretty good list and when I traced some of the IP's, they'd all been acquired thru one of two services (one in Australia and one in Holland). I don't actually think they are malevolent, but let's entertain the idea that they might be and that these people are just port scanning at random as much as possible looking for different opportunities (such as a lucky ssh hit).
Now, one of the big goals of such a person would be a successful DoS attack, which can be done with SYN flooding. Another big goal would be to not get caught. So (here's where you can reach for the salt, because it's all just conjecture) if I had a small zombie net or whatever and was trying to test it out, I might just go around somewhat randomly looking to see if my SYN requests on port 80 weren't receiving ACKs or any kind of response at all -- this might indicate the server has successfully been overwhelmed.
And if you set up a non-http server on port 80, that's what it might appear to be from that perspective (a stressed out server that DoS's easily). So if this just started happening, maybe your IP is now on someone's "experiment here" list.
Kind of far fetched. Some missing links in it. Anyway, get on the mailing list for the firewall and ask about your problem. You should NOT be just ignoring that.
Pretty much what MK said; but if you are providing a non-HTTP service on a standard HTTP port you are *asking* for problems that you could easily side-step by moving it to another, non-standard port. I am not saying this is the cause of your current problems, just that it will likely to cause you problems down the road. Standards are standards for a reason. It would be like providing a non-email service on your SMTP port; you can do it but you will get Sam and Joe Spammer slamming your server trying to find a way to make it a relay (spoofing)...
Making the symptom go away is not the same thing as diagnosing the problem. You could move to a different port, but how do you know some fault is not still lurking? I think you should try to figure out what's happening -- using the sysrq control key combo to figure out where in the kernel the thing is hanging seems like an obvious first step.