Skip to main content

What is Firewall Rule (Policy) Review / Firewall Rule Review คืออะไร มาดูกัน

















สามารถอ่าน version ภาษาไทยได้ด้านล่างเช่นเคยครับ

Sometime it's call Firewall Rule Re-validate or Firewall Rule-base review .
Firewall Rule review is part of Firewall audit process. Auditor will review Firewall Rule or ACLs on router that appropriate to network security no need rule will be removed for example

permit ip any any : it's should not be placed in top of each segment of network.

why ! firewall rule review
From my experience, many organization will have firewall admin who is responsible for add, move, delete, modify rules but he never come back to see which rule is expired or no need, which rule can be merge or have to re-arrange sequence to improve performance and mitigate risk from attacker.

what can we do

1. Duplicate object include host, ip, group, service must be removed.
2. Expired rule or no need rule must be removed.
3. Duplicate rule --> remove ^^
4. There is rule that can be merge no bad impact to business --> merge them.
5. Sequencing rule, we can use utilize log or matching count to see which rule is be used frequently --> move them up on the top of each network segment.
6. Unused rule in last 6 months will be sent to requester to get confirmation that he still need to use this rule or not. This process is related with Firewall change request document (should be kept).

Before modify or remove rule as above. If organization which is compiled to ISO27001 or other standard. They have change management process , we need to create change to approver before (should have).

Normally we should do firewall rule review once a year. 


If you have any inquiry or recommend please advise.

Additional from author.

- In some big Japanese company, they no need to review firewall rule because they have strong change management process that requester and related parties must review request document carefully before implement. That make all new rule is not duplicate with the old one.

- Firewall admin should keep all Change request to be reference.

- Naming convention is very important. You should design carefully and make it easy to your job (admin).

- Should implement or turn on monitoring to see rule statistic and use them to improve firewall's performance.


Remark : I write this post from my experience. If you have any suggestion please let me know all time. Thanks.
--------------------------------------------------------------------------------------------------------------------------------------

บางแห่งก็ใช้คำว่า Firewall Rule Re-validate หรือ Firewall Rule-base review อะไรประมาณนี้ เป็นเรื่องเดียวกัน

การทำ Firewall rule review นั้นเป็นส่วนนึงของการทำ Firewall audit โดยปกติ คนที่เป็น auditor จะ review ดูว่ามีการจัดการ rule ที่ไม่เหมาะสมหรือไม่จำเป็นหรือป่าว ยกตัวอย่างที่ผู้เขียนเคยเจอของลูกค้าก่อนทำการ review คือ มี

permit ip any any อยู่บนสุด ยังงี้ไม่ต้องมี  firewall ก็ได้นะ ^^

การทำ Firewall Rule review นั้นทำเพราะอะไร ให้นึกถึงว่าปกติ องค์กรต่างๆที่ใช้ Firewall ในการป้องกันระบบเครือข่ายของตนเองนั้น  ในแต่ละปีๆ admin ก็จะมีการ add, move, delete, modify กันเยอะแยะ แต่มีไม่เยอะหรอกนที่ admin จะกลับไปนั่งดูว่า rule ไหนหมดอายุละ (ในกรณีที่ไม่มี auto disable) หรือ rule ไหนสามารถยุบรวมกันได้, เหล่านี้มันเป็นความเสี่ยงในการถูกโจมตีได้เหมือนกันนะ และก็ทำให้ performance ของ firewall ลดลง 

แล้วเราจะทำอะไรบ้างสำหรับ Rule review เรามาดูกัน 

1. เช็คการซ้ำกันของ object ต่างๆ ทั้งที่เป็นกลุ่มของ host หรือ ip หรือ service ถ้ามีซ้ำกันก็ลบทิ้ง
2. เช็คการหมดอายุของ rule ว่ามี rule ไหนบ้างที่ obsolete หรือ expire ไปแล้วก็ลบทิ้ง
3. มี rule ที่ซ้ำกันบ้างไหม ถ้ามีซ้ำก็ลบทิ้ง
4. มี rule ที่สามารถ merge รวมกันได้ไหม แล้วยังสามารถให้การบริการได้เหมือนเดิม ไม่กระทบผู้ใช้ ก็ทำการรวมกันซะ
5. การจัดวางลำดับของ rule ก็มีผลต่อ performance ของ firewall ผมยกตัวอย่าง ถ้ามี rule ที่เราเก็บ utilize log แล้วเห็นว่ามันมีการใช้บ่อย ก็ให้เลื่อนขึ้นมาไว้บนๆ ซะ เพื่อที่เวลามี traffic วิ่งผ่านจะได้ match ตั้งแต่บนๆ ไม่ต้องไล่เช็คไปถึงข้างล่าง

อันนี้เป็นเบื้องต้น ถ้าเป็นบางแห่งจะมีการใช้ log มารวมพิจารณาด้วยว่า rule ไหน ไม่มีการใช้งานมาเป็นเวลานานเกิน 3-6 เดือน ก็จะมีการออกเอกสารไปยัง requestor ขอทำเรื่องลบ rule นั้นๆ ทิ้ง

ทีนี้ การจะลบ rule ไหนทิ้ง ตามที่เราได้เช็คตามข้อกำหนดด้านบนมาแล้วนั้น ถ้าในองค์กรที่มีมาตรฐานก็จะต้องมีเรื่องของ change management process และ document เข้ามาเกี่ยวข้องอีกพอสมควรเลยก่อนจะดำเนินการลบหรือแก้ไขต่างๆ

ปกติจะมีการ review กันทุกปี ปีละ 1ครั้ง โดยการทำ Firewall Policy Review ให้มีประสิทธิภาพ และประหยัดเวลา ก็ควรนำ Optimize Tools เข้ามาช่วย ยิ่งอย่างของแบงค์ที่ผมเคยอยู่มา Firewall บาง zone มีเป็นหมื่นๆ policy ก็นึกดูว่าถ้าทำด้วยตัวเราเองก็คงไม่ไหวมั้ง 

เอกสารที่น่าสนใจจาก GIAC เกี่ยวกับ Firewall rule review น่าสนใจครับ
https://www.giac.org/paper/gsec/3037/firewall-rule-review/102017

ถ้ามีข้อสงสัยหรือแนะนำสามารถบอกกล่าวได้ตลอดครับ

เพิ่มเติมจากผู้เขียน

การทำ Firewall Rule review นี้บริษัทญี่ปุ่นบางแห่งเขาไม่ทำกัน เพราะการทำงานของ admin จะมีการรีวิว change request จาก requestor ทุกครั้ง ไม่ได้เฉพาะจาก admin หรือ approver อย่างเดียว ว่าเป็นไปตาม checklist ด้านบนรึป่าว ก็เหมือนการรีวิวทุกๆครั้งนะละ เขาเลยไม่มีพวก object ซ้ำกัน หรือ rule ก็ไม่ซ้ำ มีการเรียงลำดับที่ดีอยู่แล้ว

คนที่เป็น Firewall admin หรือ security officer ควรจะมีการเก็บเอกสาร change request form ใส่แฟ้มเก็บไว้เสมอ เพื่อเป็นเอกสารอ้างอิง และสามารถตรวจสอบย้อนหลังได้

การตั้งชื่อ object หรือ group ต่างๆใน firewall ก็เป็นสิ่งนึงที่สำคัญโดยเฉพาะถ้ามีคนที่สามารถแก้ไข Firewall ได้หลายคน ควรจะมีการกำหนด standard ในการตั้งชื่อให้เหมือนกัน

อย่างที่กล่าวข้างต้น ถ้าเป็นไปได้ควรจะมีการ monitor การใช้งาน rule ของ firewall และเก็บเป็นสถิติอย่างชัดเจนเพื่อใช้ในการวิเคราะห์อื่นๆต่อไป

ปล. เขียนจากประสบการณ์การทำงาน ถ้ามีข้อผิดพลาดหรือคำชี้แนะสามารถแจ้งได้เสมอครับ

---------------------------------------------------------------------------------------------------------------
Tag : Howto ทำอย่างไร ทำยังไง Cleanup optimize
---------------------------------------------------------------------------------------------------------------

Comments

Popular posts from this blog

CesarFTP BOF Review / Review การทำ Buffer Overflow CesarFTP

version ภาษาไทย ไว้มีเวลาจะมา update ภายหลังครับ Today I would like to review my old one lesson about buffer overflow before I take the OSCP exam in 2015. I wish you learn basic BOF from this post. CesarFTP is the one ftp software which is vulnerabled to BOF (buffer overflow). 1. The first step I download vulnerabled software from internet and install on WinXP (vm) and then 2. Try to search for exploit in my kali linux  (No, I don't exploit by metasploit just find the start code and try to make it overflow) This original python 1906.py code is as picture below. I have to change "host" ip before do next step. ***Let's take a look at "buffer". That is something I have to modify later.*** but right now I begin with Fuzzing to find how many characters can crash this application ? 3. Control EIP address - try to replace character after  "\n" * 671 by "A" 350 characters and found that Cesar not be crashed. - Let&

My OSCP Review <-> รีวิว ประสบการณ์การสอบ OSCP ( It is just the beginning)

เนื้อหาภาษาไทยสามารถดูได้ด้านล่างนะครับ About me I would like to tell you before that my english writing skill is not good, ^^", but I will try . I was Network Engineer and System Engineer with 10 years working experience and have CCNP, CCNP Security, CCDP, ITIL, MCP and I have experience in ISO27001 for 4 years. Right now I move to be a Penetration Tester in new company for 6 months. Inspiration Actually before getting a new job as pentester I would like to take CEH or ECSA certificate. But after do a new job, my three colleagues have OSCP and they are my model. All of them have an awesome skill. Then I try to find more information about OSCP and found that OSCP is very difficult to pass, no exam dump, no one answer you. Although I have a few experience on hacking but I think I can try and TRY HARDER. OSCP Course There are two course manual, pdf and video that are dependent. After I got them I tried to read from PDF only but not enough, many technics ar

Patch Management และ Hardening คืออะไร/ ยังไง พร้อมวิธีการ ตอนที่ 2

ใครที่ยังไม่ได้อ่านตอนแรก สามารถอ่านได้ที่ Patch Management และ Hardening คืออะไร/ ยังไง พร้อมวิธีการ ตอนที่  1 4. การ Maintenance      หลังจากที่เราทำการ implement เสร็จแล้ว ไม่ใช่ว่าจะจบกันเท่านี้ มันแค่เริ่มต้น It's just the beginning. ก็ต้องมีขั้นตอนในการที่ดูแล และ up-to-date ให้อุปกรณ์ในระบบไม่มีช่องโหว่ต่อไป รวมถึงปรับปรุง template ในการ hardening เป็นประจำด้วย จะกล่าวถึงต่อไปนะ โดยปกติที่ผมเคยทำมา จะมีการกำหนดให้คนนึงที่อาจจะเป็น Security Consult ของแต่ละ platform แต่ละแผนก ในการทำ subscribe ไปยัง vendor ต่างๆ ตามอุปกรณ์ที่ดูแลอยู่เพื่อรับข่าวสาร และได้รับ notification เวลามี security update เพื่อจะนำมาวิเคราะห์ดูว่าระบบที่เราดูแลอยู่นั้นมีช่องโหว่ใหม่ๆ ที่เกี่ยวกับอุปกรณ์ของเราเกิดขึ้นหรือไม่ ถ้ามีก็ต้องนำมาเข้าสู่กระบวนการดังที่กล่าวไปข้างต้น มีคนแล้วก็ต้องมี policy องค์กรก็ต้องมีการกำหนด policy ขึ้นมาเพื่อใช้ควบคุมระยะเวลาที่องค์กรยอมรับความเสี่ยงต่อช่องโหว่ในระดับต่างๆได้ ยกตัวอย่างให้เห็นภาพ ที่ผู้เขียนเคยทำมา เช่น ถ้ามีช่องโหว่เกิดขึ้นใหม่ในระดับ - C