{"id":1818,"date":"2024-05-16T02:08:59","date_gmt":"2024-05-16T06:08:59","guid":{"rendered":"https:\/\/www.rfdm.com\/blog\/?p=1818"},"modified":"2024-05-16T04:22:35","modified_gmt":"2024-05-16T08:22:35","slug":"unacknowledged-syns-by-as-autonomous-system-may-15-2024","status":"publish","type":"post","link":"https:\/\/www.rfdm.com\/blog\/?p=1818","title":{"rendered":"Unacknowledged SYNs by AS (autonomous system) May 15, 2024"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">I still have two \/24 Google networks blocked by automation: 66.249.66.0\/24 and 66.249.72.0\/24.  These are used by Googlebot crawlers.  I don&#8217;t intend to leave them blocked indefinitely.  But with just these two \/24 networks, Google sits at the top of the list of TCP SYN senders I don&#8217;t acknowledge.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I don&#8217;t log User-agent on my web server, nor use it to make any decisions.  Some would argue that I could use it to differentiate Google Gemini \/ Vertex AI scraping versus other Google bots.  However, User-agent isn&#8217;t reliable.  I&#8217;ve seen rogue crawlers with User-agent set to Googlebot or some other bot they want to impersonate for some reason.  My favorite values are the ones with typos. \ud83d\ude42  In the age of LLM training, the longstanding handshake agreement is breaking down.  For the same reason, I don&#8217;t use robots.txt to try to prevent crawlers from crawling particular content.   I can&#8217;t trust a web client to abide a handshake agreement that&#8217;s trivially betrayed and unenforceable.  I don&#8217;t expect Google to violate the handshake agreement.  But if I want to block or not block Google bots, I&#8217;m going to do it via more reliable means than User-agent.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For this reason, I wish Google would explicitly use different address space for different bots.  It would make blocking or shaping traffic to\/from their bots easier and more reliable.<\/p>\n\n\n\n<canvas id=\"synChart20240516\" style=\"height:600px;width:100%;display:flex;flex-flow:column;\"><\/canvas>\n<script src=\"https:\/\/cdn.jsdelivr.net\/npm\/chart.js\"><\/script>\n<script>\nnew Chart(document.getElementById('synChart20240516'),\n{type:'bar',data:{labels: ['15169 Google (US)','16509 Amazon (US)','8075 Microsoft (US)','13335 Cloudflare (US)','21859 Zenlayer (US)','396982 Google Cloud (US)','39798 MivoCloud (MD)','32934 Facebook (US)','132203 Tencent (CN)','57523 Chang Way (HK)','14061 DigitalOcean (US)','136907 Huawei cloud (HK)','4134 China Telecom (CN)','14618 Amazon (US)','36183 Akamai (US)','4837 China Unicom (CN)','398324 Censys, Inc. (US)','210743 Babbar SAS (FR)','209366 SEMrush CY LTD (CY)','54113 FASTLY (US)','208312 Red Byte LLC (RU)','202425 IP Volume inc (SC)','22616 Zscaler, Inc. (US)','209 CenturyLink (US)','199524 G-Core Labs S.A. (LU)'],datasets:[{label:'Unacknowledged SYNs by AS',data:[7707,5089,3732,1371,1284,1113,672,647,603,598,568,549,497,457,423,397,379,378,377,354,328,309,297,288,260],borderWidth:1,backgroundColor:\"rgba(255,160,0,0.7)\"}]},options:{plugins:{legend:{labels:{color:\"white\"}},title:{color:'white',display:true,font:{size:14},text:'May 15, 2024 00:00 - May 16, 2024 00:00'}},scales:{x:{ticks:{autoSkip:false,color:'white'},title:{text:'autonomous system',color:'white',display:true}},y:{ticks:{color:'white'},title:{text:'Unacknowledged SYNs',color:'white',display:true}}},y:{beginAtZero:true}}});\n<\/script>\n","protected":false},"excerpt":{"rendered":"<p>I still have two \/24 Google networks blocked by automation: 66.249.66.0\/24 and 66.249.72.0\/24. These are used by Googlebot crawlers. I don&#8217;t intend to leave them blocked indefinitely. But with just these two \/24 networks, Google sits at the top of the list of TCP SYN senders I don&#8217;t acknowledge. I don&#8217;t log User-agent on my &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/www.rfdm.com\/blog\/?p=1818\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Unacknowledged SYNs by AS (autonomous system) May 15, 2024&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[93,85,86,12],"tags":[],"class_list":["post-1818","post","type-post","status-publish","format-standard","hentry","category-cloud","category-network-security","category-networks","category-software-development"],"_links":{"self":[{"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1818","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1818"}],"version-history":[{"count":7,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1818\/revisions"}],"predecessor-version":[{"id":1826,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1818\/revisions\/1826"}],"wp:attachment":[{"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1818"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1818"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rfdm.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1818"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}