< It's effectively impossible to blind spoof TCP, so since you're completing the TCP session you can be assured the traffic is really coming from where it claims to be. < < Is it a high rate from a smallish number of IPs, or a low rate from a large number? What specifically do the HTTP requests look like? < Getting full packet captures and examining the REFERER and other parts of the HTTP request may at least lead you to an explanation of why it's happening and a better understanding of what's happening, at which point you can implement mitigation if necessary or < feasible. < This doesn't sound like a deliberate attack, rather that someone did something to whatever you're hosting to cause this to happen, which is where the REFERER may lead you directly to the answer. < _______________________________________________
Thanks Chris... I am watching this happening still and we are still slack jawed on a resolution... The referrer when we capture it from the browser user agent via webserver log is blank... this is what we expect usually since the URL is in a print a publication encoded in a QR Code... What happens is that someone scans the QR Code, hits the page (updating the stats) and then is redirected to the final content elsewhere on another website. I am unable to see any referrer in wireshark packets on that web server, but I am by no means an expert using wireshark, it is possible I'm missing them. If correct, this implies that someone is either going straight to the URL manually (typing it in) or is scanning it in. I agree with you that it seems like it is something that is not deliberate because the IP's are mostly all local, the browser agent is all iPhone with varying OS versions and Webkit versions... (HTTP_USER_AGENT:Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_2 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Mobile/10B146) (I have lots more info if needed, just can't post public), so either it is phone specific OR the browser agents are forged... But as you said, impossible(?) to fake the IP address, so unsure why they would bother faking agents of the same general type (other than making it harder to block, but that was the purpose they should have mixed it up considerably with Android, etc...) An example is that a "user" scans 13 unique codes within a matter of a couple of minutes (which is pretty aggressive... time between scans is below 40 seconds). They seem to switch up the sessionID every ~8 attempts... I should also point out that these are valid requests (they are not random generated URLs or guessing)... they are valid codes. So they are either really scanning paper OR they have a valid list of URLs they hit. My feeling is that it's something wrong with handling the redirects in QR Code Scanning process which is somehow locking onto the URLs and hitting them over and over again... specifically on iPhone... I have installed a handful of scanners but am getting expected results... the developer disagrees that it is not deliberate... He feels it is a deliberate attack since it started several hours after the last website update (which was minor I am told), it is hitting valid codes only (with the exception of a deleted code that was used for testing only)... he implies that this deleted code would have NEVER been seen by the public or appear in print. He feels that the code was likely displayed on an administrator's page while creating the QR Codes (displaying a list of all encoded URLs) on a compromised machine... the machine then to captured these URLs from local cache and passed those codes to a central server and it instructed bots to start hitting them with traffic... Any further ideas? I don't mind paying someone to help debug the situation, but I think the pfSense commercial support is limited to the firewall specifically, not the traffic that passes through it (I assume it would be a combo of pfSense captures and IIS Log Analysis). Chuck _______________________________________________ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
