ปรับให้ anti-brute force attacks ทำงานร่วมกับ CloudFlare

เวลาเอา web ไปไว้หลัง CloudFlare ปัญหานึงคือ IP ของ client จะส่งเข้ามายังเครื่อง server เป็น IP ของ CloudFlare ทำให้เราตรวจสอบลำบากว่าใครเข้ามา (รวมไปถึงการเก็บ access log เพื่อทำตาม พรบ คอมพิวเตอร์)

ปัญหาต่อมาคือเวลาเรา implement ตัวป้องกัน brute force attacks เรามักจะทำได้ยาก

วิธีหนึ่งที่ทำกันคือ ย้ายการเก็บข้อมูลของ IP มาดูที่ HTTP header ชื่อ X-Forwarded-For และ CF-Connecting-IP แทน ซึ่งก็โอเคดี แต่ก็ไม่ได้สะดวกมากเท่าแบบเดิมๆ คือเรียกจาก REMOTE_ADDR ตรงๆ เพราะพวก brute force attacks จะไปโฟกัสที่ header REMOTE_ADDR เป็นหลัก

วิธีการแก้ไขคือ ติดตั้ง mod_cloudflare สำหรับ Apache หรือ ngx_http_realip_module ใน nginx เป็นต้น แล้วตั้งค่าตาม link นี้ Restoring original visitor IPs: Logging visitor IP addresses

เสร็จแล้วติดตั้ง anti-brute force attacks อย่าง mod_evasive บน Apache หรือ ngx_http_limit_req_module บน nginx ก็จะช่วยป้องกัน brute force attacks ได้ในระดับหนึ่ง

ปล. เหตุผลที่ต้องทำเพิ่มเติมจาก CloudFlare แม้ระบบ CloudFlare จะช่วยป้องกันได้ในระดับนึงก็คือ บางครั้งโดนยิงจนดับไปแล้ว CloudFlare มันเพิ่งมาช่วย ก็เลยเป็นที่มาของการป้องกันตัวเองในเบื้องต้นด้วย

เรื่องเล่า myujikkii.com และ music48voter.com ฉบับปี 2020

สำหรับเว็บ music48voter.com ตัวเว็บใช้บริการ DigitalOcean ด้วยเหตุผลการเข้าถึงได้ดีจากนอกประเทศ ราคาไม่แพง รวมทั้ง 6 อย่างที่เห็น จ่ายเดือนละ 30USD โดยให้ B/W ค่อนข้างเยอะ สเปคก็ค่อนข้างดี เร็วใช้ได้ (ปีก่อนมีปัญหา ตปท เข้าได้ยาก เพราะระบบอยู่ในไทย)

ใช้ VM จำนวน 4 ตัว เป็น LBx1 (HAProxy), Webx2 (docker-compose),DBx1 (MariaDB+Redis) ส่วนไฟล์สลิปไปฝากที่บริการ Spaces คล้ายๆ S3 ของ AWS เก็บแยกไปต่างหาก

เว็บพัฒนาบน .NET Core 3.1 (C#) ต่อยอดจากปีก่อน (ปีที่แล้ว .NET Core 2.0) docker image build บน Docker Hub
เหตุผลที่มี Webx2 เพราะกลัว deploy แก้ไขจะได้ไม่ล่มแบบปีก่อน ทำ auto deploy ร่วมด้วย (ปีก่อนแก้หรือ deploy แล้วเว็บจะ down แป็บนึง เพราะ start/stop Kestrel manual) และเหตุผลที่ไม่ใช้ K8s เพราะเครื่องมันจะเยอะขึ้นอีกตัว บวกกับขี้เกียจ (จบ ?)

myujikkii.com อันนี้อีกทีมนึงทำ ซึ่งด้านการ sync ยอด progress ดึงจาก music48voter อีกที (cache 5 นาที) ทีม myujikkii ก็จะได้ไม่ปวดหัวกับระบบหลังบ้าน เลยรวมที่เดียว และ myujikkii เอา cloudflare ทำ proxy cache ด้วยเพื่อให้โหลดเร็วขึ้นประหยัด B/W

ระบบหลังบ้านในการตรวจสลิป มีทีมตรวจแล้วแจ้งสถานะ approve/reject แล้วส่งอีเมลแจ้งสมาชิกในเว็บ (ปีก่อนไม่มีอีเมลแจ้ง) ถือว่าโอเค เพราะทีมหลังบ้านไม่ต้องคอยแจ้งหรือลุ้นว่าเค้าจะกลับมาแก้ไขไหม และทำให้ทีมงานเช็คยอดง่ายขึ้น (ตัวอีเมลใช้บริการ mailgun ส่งอีเมลฟรี 5,000 ฉบับ)

ส่วนฝั่งโค้ดโหวตก็เหมือนปีก่อน และสุดท้าย last word ตอนแรกจะใช้ Google Form แต่คิดว่าลำบากตรงเอาข้อความมาแปะ และตรวจยอด เลยเขียนเพิ่มให้ทีมงานบริการจัดการได้จากจุดเดียว โดยข้อมูลโดเนทและข้อความก็อยู่ฐานข้อมูลเดียวกันทั้งหมด เอาเวลาไปโฟกัสเรื่องยอดกับบิ้วโหวตดีกว่า

สุดท้าย ปีนี้เราพยายามให้แฟนคลับ ไม่ว่าจะเป็นสมาชิกที่โหวตเอง โดเนทกับกิจกรรม หรือรู้สึกยุ่งยากแต่อยากโดเนทแบบไม่ระบุตัวตน ก็ทำได้หมด เราพยายามให้ทุกคนมีส่วนรวมกับกิจกรรมให้เยอะที่สุด

หวังว่าจะสนุกกับกิจกรรมของทีมงานที่ทำกันทุกคน ^^

DNS Propagation Check

เจอปัญหาว่าตอนเช็ค domain ที่ดูแล ว่าตอน client ไป resolve กับ DNS resolver เจ้าต่าง ๆ ได้ผลตอบกลับออกมาเป็น IP อะไรบ้าง เพื่อตรวจสอบว่าแต่ละ DNS resolver เข้าที่ CDN/Server ชุดไหน (ถ้ามีหลายเครื่อง) หรือตรวจสอบว่าเป็นข้อมูลล่าสุดแล้วหรือยัง

หากตรวจสอบแค่ 1-2 ISP หรือ Public DNS หลัก ๆ ก็ไม่ยาก แต่ถ้าเยอะ ๆ สัก 4-5 ตัวขึ้นไป ก็จะลำบากแล้ว ต้องมานั่ง dig ทีละ Nameserver ก็ยุ่งยากเสียเวลา หรือใช้ whatsmydns.net ก็มีไม่ครบสำหรับ ISP ในไทย

ก็เลยเขียน console app ง่าย ๆ เร็ว ๆ ไว้ใช้เอง (เขียนแบบลวกมาก แบบให้มันใช้ได้ก่อน)

แต่ก็เจอปัญหาอยู่บ้างว่ามี DNS resolver พวก ISP หลายที่เค้าไม่เปิด public ให้คนนอก ISP ใช้ ก็ลำบากนิดหน่อยแต่รวม ๆ ก็ทุ่นเวลาไปได้พอสมควรถ้าตรวจสอบกับ DNS resolver หลัก ๆ ได้ (ISP บางเจ้าข้อมูลอาจจะไม่อัพเดท เดี่ยวค่อยปรับรายการอีกที)

โปรแกรมชุดนี้พัฒนาด้วย C# บน .NET Core 3.1 ทำงานได้ทั้งบน Windows และ Linux ซึ่งตอนนี้บน GitHub ได้ build รองรับทั้ง 2 platform

สำหรับ binary ที่ได้จาก build ทดสอบบน Windows 10 (1909) และ Ubuntu 18.04 ซึ่งทำงานได้ตามวัตถุประสงค์

ตัว source code เปิด source อยู่ที่ GitHub นี้ DNS Propagation Check และ binary โหลดได้จากในส่วน Release ของ GitHub

ตรวจสอบการส่งข้อมูลของแอปที่เราใช้ ว่า Facebook ได้รับข้อมูลหรือไม่ ผ่าน Off-Facebook Activity

วันนี้ เฟซบุ๊กเปิดให้ดูข้อมูลที่ได้จากนอกเฟซบุ๊ก หรือเรียกว่า Your off-Facebook activity ใครหาเมนูไม่เจอ สามารถเข้าผ่าน URL ด้านล่างได้

https://www.facebook.com/off_facebook_activity/

ในนั้นจะมีรายการแอปที่นำส่งข้อมูลแชร์กับ Facebook มากมาย โดยเราสามารถยกเลิก หรือ block การส่งข้อมูลเข้า Facebook ได้ผ่าน Turn off future activity ได้จากหน้านี้

หากเราอยากตรวจสอบ Your off-Facebook activity แบบรายละเอียดว่า แต่ละแอปที่เราใช้ส่งข้อมูลอะไรกับ Facebook บ้าง สามารถทำได้ผ่านเมนู Download your information เราจะได้ข้อมูลทั้งหมดที่เราให้กับ Facebook เป็นไฟล์ zip

เราก็เปิด zip ไฟล์ แล้วไปที่ ads_and_business แล้วโยนไฟล์ทั้ง folder ออกมา

รายการไฟล์ทั้ง 4 แบบจะมีความหมายคือ

  • your_off-facebook_activity.html
    Your off-Facebook activity – กิจกรรมที่ถูกจัดเก็บมาจากภายนอก Facebook
  • advertisers_you’ve_interacted_with.html
    Advertisers that you’ve interacted with – โฆษณาที่คุณคลิกบน Facebook
  • advertisers_who_uploaded_a_contact_list_with_your_information.html
    Advertisers who’ve uploaded a contact list with your information – ผู้ลงโฆษณาที่ใช้ข้อมูลติดต่อด้วยการอัพโหลดข้อมูลเข้ามา
  • ads_interests.html
    Ads interests – คีย์เวิร์ดต่าง ๆ ที่ระบบคาดว่าคุณจะสนใจโฆษณา

ไฟล์ที่เราสนใจคือ your_off-facebook_activity.html เป็นหลัก (ส่วนไฟล์อีก 3 ไฟล์ จะลองดูเล่นๆ ก็ได้ แต่ไม่อธิบายในบทความนี้)

เราสามารถเช็คได้จากรายการนี้อีกรอบจากในแต่ละชื่อแอป ซึ่งจะมี link เข้าไปดูข้อมูลอย่างละเอียดอีกครั้ง

การตรวจสอบข้อมูลก็จะประมาณนี้สำหรับการดูว่ามีแอปอะไรบ้างที่ส่งข้อมูลให้ Facebook และเราจะปิดการส่งข้อมูลของแอปต่างๆ ให้ Facebook ได้อย่างไร

เปรียบทียบ Microsoft Pro IntelliMouse และ Microsoft Classic IntelliMouse

ในไทยมี Microsoft Classic IntelliMouse ขายอยู่มาปีกว่า ๆ แล้ว แต่ Microsoft Pro IntelliMouse นั้นยังไม่ได้เอามาขายสักที ส่วนตัวผมสั่ง ตัว Pro IntelliMouse มาใช้งานตั้งแต่เดือนสิงหาคมปีที่แล้ว จนถึงวันนี้ (วันที่ลง blog) ทาง Microsoft ก็ยังไม่เอามาขายสักที จนราคาที่ญี่ปุ่นมันลงมาจนทำราคาได้ดีขึ้นมาก (ถูกลงมากว่า 1,000 บาท รวมค่าส่งและภาษี) ก็เลยเอาข้อมูลมาลงอีกรอบใน blog เปรียบเทียบทั้งสองตัว

  1. ตัว Sensor
    Pro เป็น PixArt PAW 3389PRO-MS รองรับ DPI 16,000 (200-16,000), polling rate 1,000Hz และ refresh rate 12,000 FPS
    การปรับเปลี่ยน DPI ทำผ่านปุ่มด้านซ้ายที่เป็น shortcut key ผ่าน software driver เช่นกัน
    Classic เป็น PixArt PAW 3808EK BlueTrack รองรับ DPI 3,200 (400-3,200) และ polling rate 1,000Hz
  2. ตัว Switch
    Pro ใช้ Omron D2FC-F-7N (การันตี 20 ล้านคลิ๊ก)
    Classic ใช้ Omron 70g (การันตี 10 ล้านคลิ๊ก)
  3. ยางที่ใช้ใช้ทำกริป Pro ใช้ของคุณภาพดีกว่า Classic
  4. ตัวไฟ LED ท้าย mouse ของ Pro เป็น RGB ปรับเปลี่ยนสีได้ผ่าน software driver
  5. สายของ Pro เป็นสายผ้าแบบถัก ส่วนของ Classic เป็นยาง
  6. งานสี งานออกแบบ และงานประกอบ Pro ดีกว่า Classic

ว่ากันง่ายๆ ด้วย sensor และการเลือกใช้ switch ก็พอสรุปได้ว่า “Pro คือ Gaming mouse ส่วน Classic คือ Office mouse”

จากการใช้งานมา 4-5 เดือน Pro IntelliMouse สามารถใช้แทน Gaming mouse ในระดับราคาใกล้ๆ กันได้ดี แน่นอนว่าตัวปุ่ม และลูกเล่นอาจจะเทียบกับกลุ่มที่ทำออกมาเฉพาะได้ยากหน่อย แต่ถ้าคุณชอบแนวการออกแบบของ Pro IntelliMouse ดั่งเดิม ที่มาพร้อมกับ sensor ที่แม่นยำและปุ่มที่ทนทาน เป็นตัวเลือกที่ดีตัวหนึ่ง

สำหรับราคา

  • Microsoft Classic IntelliMouse ราคาขาย $39.99 ราคาในไทยประมาณ 1,390 บาท
  • Microsoft Pro IntelliMouse ราคาขาย $59.99 ยังไม่มีจำหน่ายในไทย ส่วนตัวสั่งผ่าน Amazon JP ซึ่งรวมค่าส่งและภาษีแล้วจะอยู่ที่ประมาณ 2,3xx บาท ราคาเดือน 8 ปี 2019 (ข้อมูล ณ วันที่ 28/1/2020 ลงมาอยู่ไม่เกิน 1,500 บาทแล้ว โดยรวมค่าส่งและภาษีแล้ว)