Bot-ek zure zerbitzariaren baliabideak xahutzea maite dute: hona hemen nola borrokatu

Ikuspegi publikoko web zerbitzari bat kudeatzen baduzu, ohartuko zara bot-ek zortea probatzen dutela existitzen ez diren hainbat orrialdetan. Erabili HAProxy atean gelditzeko.

Zure erregistroak /.DS_Store , /backup.sql , /.vscode/sftp.json eta beste URL ugarirekin 404 aipamenez beteta daude. Eskaera hauek gehienetan kaltegarriak ez diren arren, noski, zure zerbitzariak leku horietan zerbait eskaintzeko ez badu behintzat, bot-ak plazaratu beharko dituzu.

Zergatik?

Zerbitzari bat sakatzea baliabide intentsiboa da eta, bot horiek URL ezberdinen zerrenda zabala dutela kontuan hartuta, ez dago lagun zaitzakeen cachean gordetzeko mekanismorik. Gainera, bot-ak geldiaraztea beti da segurtasun neurri bat.

Aurretik HAProxy erabili dugu Wordpress-en saio-hasiera orrialdeko erasoak arintzeko , ideia planteamendu hori zabaltzea da 404 akatsak ere estaltzeko.

Bot-ek ahal duten guztia egingo dute zure zerbitzarian hondamena sortzen

Sasa Tekovic-en inspirazioa hartu dut, hau da, benetako bilatzaileen arakatzaileak ez blokeatzea eta baliabide estatikoei 404 baimentzea benetako falta diren baliabideak (zure aldetik errore bat) erabiltzaile legitimoak ez blokeatzea saihesteko.

Inplementatu aurretik, beti da ona proba-ingurune lokal bat sortzea. Has gaitezen HAProxy eta Apache Docker erabiliz. Benetako backend zerbitzari bat behar dugu 404 horiek emateko.

 version : '3' services: haproxy: image: haproxy:3.1.3-alpine ports: - "8100:80" volumes: - "./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg" networks: - webnet apache: image: httpd:latest container_name: apache1 ports: - "8080:80" volumes: - ./html:/usr/local/apache2/htdocs/ networks: - webnet networks: webnet:

Ondoren, exekutatu docker-compose up , eta localhost:8100 atzi dezakezu zure arakatzailean.

haproxy.cfg fitxategia nahiko argia da:

 global log stdout format raw daemon debug defaults log global mode http frontend main bind *:80 acl static_file path_end .css .js .jpg .jpeg .gif .ico .png .bmp .webp .csv .ttf .woff .svg .svgz acl excluded_user_agent hdr_reg(user-agent) -i (yahoo|yandex|kagi|(google|bing)bot) # tracks IPs but exclude hits on static files and search engine crawlers http-request track-sc0 src table mock_404_tracking if !static_file !excluded_user_agent # increment gpc0 if response code was 404 http-response sc-inc-gpc0(0) if { status 404 } # checks if the 404 error rate limit was exceeded http-request deny deny_status 403 content-type text/html lf-string "404 abuse" if { sc0_gpc0_rate(mock_404_tracking) ge 5 } # whatever backend you're using use_backend apache_servers backend apache_servers server apache1 apache1:80 maxconn 32 # mock backend to hold a stick table backend mock_404_tracking stick-table type ip size 100k expire 10m store gpc0,gpc0_rate(1m)

Minutu bakarrean 404 eskaeratan 5 hit baino gehiago lortzen badituzu, bot-a 10 minutuz debekatuko da.

Honen arabera, konfigurazio honek 404 gehiegi sortzen dituzten bot-ak eraginkortasunez mugatzen ditu. Hala ere, gure aurreko adibidearekin ere integratu nahi dugu, non HAProxy erabili genuen WordPress en erasoak blokeatzeko.

 global log stdout format raw daemon debug defaults log global mode http frontend main bind *:80 # We may, or may not, be running this with Cloudflare acting as a CDN. # If Cloudflare is in front of our servers, user/bot IP will be in # 'CF-Connecting-IP', otherwise user IP with be in 'src'. So we make # sure to set a variable 'txn.actual_ip' that has the IP, no matter what http-request set-var(txn.actual_ip) hdr_ip(CF-Connecting-IP) if { hdr(CF-Connecting-IP) -m found } http-request set-var(txn.actual_ip) src if !{ hdr(CF-Connecting-IP) -m found } # gets the actual IP on logs log-format "%ci\ %hr\ %ft\ %b/%s\ %Tw/%Tc/%Tt\ %B\ %ts\ %r\ %ST\ %Tr IP:%{+Q}[var(txn.actual_ip)]" # common static files where we may get 404 errors and also common search engine # crawlers that we don't want blocked acl static_file path_end .css .js .jpg .jpeg .gif .ico .png .bmp .webp .csv .ttf .woff .svg .svgz acl excluded_user_agent hdr_reg(user-agent) -i (yahoo|yandex|kagi|google|bing) # paths where we will rate limit users to prevent Wordpress abuse acl is_wp_login path_end -i /wp-login.php /xmlrpc.php /xmrlpc.php acl is_post method POST # 404 abuse blocker # track IPs but exclude hits on static files and search engine crawlers # increment gpc0 counter if response status was 404 and deny if rate exceeded http-request track-sc0 var(txn.actual_ip) table mock_404_track if !static_file !excluded_user_agent http-response sc-inc-gpc0(0) if { status 404 } http-request deny deny_status 403 content-type text/html lf-string "404 abuse" if { sc0_gpc0_rate(mock_404_track) ge 5 } # wordpress abuse blocker # track IPs if the request hits one of the monitored paths with a POST request # increment gpc1 counter if path was hit and deny if rate exceeded http-request track-sc1 var(txn.actual_ip) table mock_wplogin_track if is_wp_login is_post http-request sc-inc-gpc1(1) if is_wp_login is_post http-request deny deny_status 403 content-type text/html lf-string "login abuse" if { sc1_gpc1_rate(mock_wplogin_track) ge 5 } # your backend, here using apache for demonstration purposes use_backend apache_servers backend apache_servers server apache1 apache1:80 maxconn 32 # mock backends for storing sticky tables backend mock_404_track stick-table type ip size 100k expire 10m store gpc0,gpc0_rate(1m) backend mock_wplogin_track stick-table type ip size 100k expire 10m store gpc1,gpc1_rate(1m)

Bi stick tables korrika egitea eta bi mehatxuak geldituz.

Eta hor daukazue. HAProxy berriro ere alderantzizko proxy soil gisa baino askoz gehiagorako erabiltzen da. Suitzako aizto txiki bat da!

Farol honek joko-aldaketa izan du konponketetan lanean.

Bat neukan, baina apurtu zenean, ordezkatzeko zalantzarik izan nuen, telefonoaren linternara joz. Eta ziur, funtzionatzen du, baina bi eskuak berriro libre edukitzeko erosotasuna sentitzen duzunean , ez dago atzera bueltarik. Esku libreko argiztapen fidagarria behar baduzu, hau ezinbestekoa da!