Firewall Basics: কর্পোরেট নেটওয়ার্ক নিরাপত্তায় ফায়ারওয়ালের সঠিক কনফিগারেশন!

Firewall প্রযুক্তি গত তিন দশকে কয়েকটি প্রজন্মের মধ্য দিয়ে বিবর্তিত হয়েছে। প্রথম প্রজন্মের Packet Filter Firewall ১৯৮০ এর দশকে আবির্ভূত হয়, যা শুধু IP ঠিকানা, পোর্ট নম্বর এবং প্রোটোকলের ভিত্তিতে সিদ্ধান্ত নিত। প্রতিটি প্যাকেট আলাদাভাবে মূল্যায়িত হতো, কোনো প্রসঙ্গ বিবেচনা না করেই।

দ্বিতীয় প্রজন্মে এসেছে Stateful Inspection Firewall, যা Check Point এর FireWall-1 দিয়ে জনপ্রিয় হয়। এই ধরনের Firewall একটি Connection Table বজায় রাখে এবং বুঝতে পারে কোন প্যাকেট একটি বৈধ Session এর অংশ। যদি একটি অনুমোদিত আউটগোয়িং কানেকশনের জন্য রিটার্ন প্যাকেট আসে, সেটি স্বয়ংক্রিয়ভাবে পাস হয়।

তৃতীয় প্রজন্ম Application Layer Firewall বা Proxy Firewall, যা সম্পূর্ণ অ্যাপ্লিকেশন পেইলোড বুঝতে পারে। এটি HTTP, FTP, SMTP এর মতো প্রোটোকলের ভেতরের বিষয়বস্তু পরীক্ষা করতে সক্ষম। চতুর্থ প্রজন্ম Next Generation Firewall বা NGFW যা Palo Alto Networks, Fortinet, Check Point এবং Cisco এর আধুনিক পণ্যগুলোর মধ্যে দেখা যায়। NGFW তে অন্তর্ভুক্ত আছে Intrusion Prevention, Application Identification, User Identity Integration, এবং SSL Decryption।

বর্তমানে আমরা পঞ্চম প্রজন্মে প্রবেশ করছি যেখানে Cloud Native Firewall, Firewall as a Service, এবং AI চালিত হুমকি শনাক্তকরণ মূল ভূমিকায় আসছে। SASE বা Secure Access Service Edge ধারণায় Firewall একটি বিতরণ করা ক্লাউড পরিষেবা হিসেবে কল্পিত।

আধুনিক কর্পোরেট পরিবেশে বিভিন্ন ধরনের Firewall একসাথে ব্যবহৃত হয়। Network Firewall সাধারণত একটি ডেডিকেটেড অ্যাপ্লায়েন্স বা ভার্চুয়াল মেশিন যা নেটওয়ার্ক সেগমেন্টের মাঝে বসে। এটি সবচেয়ে পরিচিত ধরন এবং পেরিমিটার সুরক্ষায় ব্যবহৃত হয়।

Host Based Firewall বা Personal Firewall প্রতিটি ডিভাইসে ইনস্টল হয়, যেমন Windows Defender Firewall, iptables Linux এ, কিংবা pf macOS এ। এটি Network Firewall এর সাথে স্তরযুক্ত প্রতিরক্ষার অংশ। Web Application Firewall বা WAF বিশেষভাবে ওয়েব অ্যাপ্লিকেশন রক্ষার জন্য ডিজাইন করা—এটি OWASP Top 10 এর মতো ওয়েব আক্রমণ থেকে রক্ষা করে।

Database Firewall ডেটাবেস সার্ভারের সামনে বসে SQL Injection এবং অননুমোদিত ক্যোয়ারি ব্লক করে। Cloud Firewall যেমন AWS Security Groups, Azure NSG, কিংবা Google Cloud Firewall ক্লাউড পরিবেশে কাজ করে এবং সাধারণত API চালিত। Internal Firewall বা Microsegmentation Firewall ডেটা সেন্টারের ভেতরে ভিন্ন সেগমেন্টের মধ্যে ট্রাফিক নিয়ন্ত্রণ করে। VMware NSX এবং Illumio এই ক্ষেত্রে অগ্রণী।

কার্যকর Firewall কনফিগারেশনের কিছু সর্বজনীন নীতি আছে যা পরিবেশ যাই হোক না কেন প্রযোজ্য। প্রথম এবং সর্বাধিক গুরুত্বপূর্ণ নীতি হলো Default Deny। অর্থাৎ Firewall এর শেষ নিয়মটি হবে সব অননুমোদিত ট্রাফিক ব্লক করা। শুধু সুনির্দিষ্টভাবে অনুমতিপ্রাপ্ত ট্রাফিকই পাস হবে। এর বিপরীত পদ্ধতি Default Allow হাজার গুণ বেশি বিপজ্জনক।

দ্বিতীয় নীতি হলো Least Privilege। প্রতিটি নিয়ম যতটা সম্ভব সংকীর্ণ হতে হবে। উদাহরণ হিসেবে, ওয়েব সার্ভারে শুধু পোর্ট ৪৪৩ খোলা থাকবে নির্দিষ্ট লোড ব্যালান্সারের কাছ থেকে, পোর্ট ২২ শুধু ম্যানেজমেন্ট নেটওয়ার্ক থেকে। সব নেটওয়ার্ক বা সব পোর্টে অনুমতি একটি বিপজ্জনক অভ্যাস।

তৃতীয় নীতি হলো Separation of Duties। নেটওয়ার্ক বিভিন্ন সিকিউরিটি জোনে বিভক্ত করতে হবে—DMZ, Internal, Management, Database—এবং প্রতিটি জোনের মধ্যে ট্রাফিক প্রবাহ স্পষ্টভাবে সংজ্ঞায়িত। কোনো অপ্রয়োজনীয় Cross Zone যোগাযোগ অনুমোদিত হবে না।

চতুর্থ নীতি হলো Defense in Depth। Firewall একা সব আক্রমণ থামাতে পারে না, তাই IDS/IPS, EDR, WAF, এবং নেটওয়ার্ক সেগমেন্টেশন—এই সব একসাথে কাজ করতে হবে। পঞ্চম নীতি হলো Auditability। প্রতিটি নিয়মের পেছনে একটি ব্যবসায়িক যৌক্তিকতা থাকতে হবে এবং সেটি নথিভুক্ত থাকতে হবে। নিয়ম পর্যালোচনা প্রক্রিয়া নিয়মিতভাবে চালাতে হবে।

একটি Firewall নিয়ম তৈরি করার সময় কিছু বাস্তব প্রশ্ন বিবেচনা করতে হয়। কোন ব্যবসায়িক প্রয়োজনের জন্য এই নিয়ম? কোন উৎস থেকে কোন গন্তব্যে? কোন প্রোটোকল এবং পোর্ট? কতদিনের জন্য এই নিয়ম প্রয়োজন? নিয়মটি স্থায়ী না অস্থায়ী?

নিয়মের ক্রম গুরুত্বপূর্ণ। Firewall সাধারণত প্রথম মিলে যাওয়া নিয়ম প্রয়োগ করে। সবচেয়ে নির্দিষ্ট এবং Deny নিয়মগুলো উপরে রাখতে হবে, এবং সবচেয়ে সাধারণ Allow নিয়ম নিচে। উদাহরণ হিসেবে, যদি একটি নির্দিষ্ট IP ব্লক করতে চান কিন্তু সেই IP যে সাবনেটের অংশ সেটি অনুমোদিত, তাহলে Block নিয়মটি Allow নিয়মের উপরে রাখতে হবে।

Object Groups বা Address Objects ব্যবহার করে নিয়ম পরিচালনা সহজ করা যায়। প্রতিটি IP আলাদাভাবে লেখার পরিবর্তে একটি গ্রুপ যেমন Web-Servers তৈরি করে তার মধ্যে IP যোগ করুন। ভবিষ্যতে নতুন সার্ভার যোগ করতে শুধু গ্রুপ আপডেট করলেই হবে, প্রতিটি নিয়ম পরিবর্তন করতে হবে না।

নিয়ম মন্তব্য করা অপরিহার্য। প্রতিটি নিয়মে লেখা থাকবে কেন এটি যুক্ত করা হয়েছে, কে অনুরোধ করেছে, কখন, এবং সংশ্লিষ্ট টিকিট নম্বর। ছয় মাস পরে যখন কেউ নিয়মটি পর্যালোচনা করবেন, এই তথ্য না থাকলে নিরাপদ পরিবর্তন সিদ্ধান্ত নেওয়া কঠিন।

আধুনিক Next Generation Firewall এর কিছু বৈশিষ্ট্য আছে যা সঠিকভাবে ব্যবহার করলে নিরাপত্তা ব্যাপকভাবে বাড়ে। Application Awareness এর মাধ্যমে Firewall শুধু পোর্ট নয়, প্রকৃত অ্যাপ্লিকেশন শনাক্ত করতে পারে। উদাহরণ হিসেবে, পোর্ট ৪৪৩ এ Salesforce, Dropbox, এবং BitTorrent সবই চলতে পারে; NGFW প্রতিটি আলাদাভাবে নিয়ন্ত্রণ করতে পারে।

User Identity Integration ডিরেক্টরি সার্ভিস যেমন Active Directory এর সাথে সংযুক্ত হয় এবং IP ঠিকানা নয় বরং ব্যবহারকারীর নামের ভিত্তিতে নিয়ম প্রয়োগ করে। এর ফলে অর্থ বিভাগের কর্মচারী মাত্র অর্থ অ্যাপ্লিকেশনে অ্যাক্সেস পান, এবং কোথা থেকে লগইন করছেন সেটি গৌণ।

SSL/TLS Decryption আজকের পরিবেশে গুরুত্বপূর্ণ কারণ অধিকাংশ ট্রাফিক এনক্রিপ্টেড। NGFW ট্রাফিক ডিক্রিপ্ট করে পরিদর্শন করে এবং পুনরায় এনক্রিপ্ট করে পাঠায়। তবে এতে গোপনীয়তা এবং পারফরম্যান্সের প্রভাব আছে—ব্যাংকিং এবং স্বাস্থ্য ট্রাফিক ডিক্রিপ্ট না করা সাধারণত ভালো অভ্যাস।

Threat Intelligence Feed এর সাথে ইন্টিগ্রেশন NGFW কে পরিচিত ক্ষতিকর IP, ডোমেইন এবং URL ব্লক করতে সক্ষম করে। প্রতিদিন আপডেট হওয়া এই Feed গুলো আক্রমণকারী C2 সার্ভার, র‍্যানসমওয়্যার ডোমেইন এবং ফিশিং সাইট থেকে রক্ষা করে। Geo Blocking ব্যবহার করে নির্দিষ্ট দেশ থেকে ট্রাফিক ব্লক করা যায়, যা অনেক প্রতিষ্ঠানের জন্য একটি কার্যকর প্রথম স্তরের প্রতিরক্ষা।

বহু বছরের অভিজ্ঞতায় দেখা গেছে কিছু ভুল বারবার ঘটে। Any Any নিয়মগুলো সবচেয়ে বিপজ্জনক—যখন উৎস, গন্তব্য, এবং পোর্ট সবই Any সেট করা থাকে। এই ধরনের নিয়ম অনেক সময় সাময়িক সমাধান হিসেবে যুক্ত হয় কিন্তু কখনো সরানো হয় না।

Shadow Rules বা ছায়া নিয়ম তৈরি হয় যখন একটি নিচের নিয়ম কখনোই সক্রিয় হয় না কারণ উপরের একটি বিস্তৃত নিয়ম তা ঢেকে রাখে। নিয়মিত Firewall অডিট এই ধরনের অপ্রয়োজনীয় নিয়ম খুঁজে বের করে। অব্যবহৃত নিয়ম জমা হতে থাকে যা পর্যালোচনা কঠিন করে। অনেক Firewall এ Hit Count পরিসংখ্যান আছে যা দেখায় কোন নিয়মে কতটি প্যাকেট মিলেছে—দীর্ঘদিন শূন্য হিট থাকা নিয়মগুলো পুনর্বিবেচনার যোগ্য।

ভুল Outbound নীতি একটি বড় সমস্যা। অনেক প্রতিষ্ঠান Inbound কঠোরভাবে নিয়ন্ত্রণ করে কিন্তু Outbound কে উপেক্ষা করে। ফলে আপোস হওয়া অভ্যন্তরীণ হোস্ট C2 সার্ভারের সাথে সহজেই যোগাযোগ করতে পারে। Outbound Filtering সমানভাবে গুরুত্বপূর্ণ।

ম্যানেজমেন্ট ইন্টারফেস ইন্টারনেটে উন্মুক্ত রাখা একটি গুরুতর ভুল, যা বহু বড় ব্রিচের কারণ হয়েছে। Firewall এর ম্যানেজমেন্ট অ্যাক্সেস শুধু একটি ডেডিকেটেড ম্যানেজমেন্ট নেটওয়ার্ক থেকে অনুমোদিত হতে হবে।

Equifax এর ২০১৭ সালের ব্রিচে Firewall এর একটি ভুল কনফিগারেশন ভূমিকা রেখেছিল—Outbound ট্রাফিক যথাযথভাবে পরিদর্শন না হওয়ায় চুরি হওয়া ডেটা মাসের পর মাস ধরে বের হতে পেরেছিল। Target এর ২০১৩ সালের ব্রিচে একটি HVAC ভেন্ডর পোর্টালের মাধ্যমে আক্রমণকারী প্রবেশ করেছিল এবং Network Segmentation এর অভাবে POS সিস্টেমে পৌঁছাতে পেরেছিল।

Capital One এর ব্রিচে একটি ভুল কনফিগার করা WAF SSRF আক্রমণে অরক্ষিত ছিল এবং আক্রমণকারী AWS Metadata Service থেকে ক্রেডেনশিয়াল চুরি করতে সক্ষম হয়। এই ঘটনাগুলো দেখায় যে Firewall নিজে সঠিক নয়; কনফিগারেশন এবং তার সাথে যুক্ত পুরো আর্কিটেকচার সমানভাবে গুরুত্বপূর্ণ।

Colonial Pipeline র‍্যানসমওয়্যার আক্রমণে VPN অ্যাক্সেস MFA ছাড়া অনুমোদিত ছিল। যদিও Firewall ছিল, এটি পরিচয় যাচাইকরণের দুর্বলতা পূরণ করতে পারেনি। SolarWinds আক্রমণে আক্রমণকারীরা বৈধ চ্যানেল ব্যবহার করেছিল, যেখানে Firewall তাদের থামাতে পারেনি কারণ ট্রাফিক বৈধ দেখাচ্ছিল।

কার্যকর Firewall ব্যবস্থাপনার জন্য কয়েকটি বাস্তব পদক্ষেপ অনুসরণ করা যায়। নিয়মিত নিয়ম পর্যালোচনা ত্রৈমাসিক বা ষান্মাসিকভাবে চালাতে হবে, যেখানে প্রতিটি নিয়ম যাচাই করা হবে—এটি কি এখনো প্রয়োজনীয়? এর হিট কাউন্ট কেমন? নথিভুক্ত যুক্তি কী?

Change Management প্রক্রিয়া কঠোরভাবে অনুসরণ করতে হবে। যেকোনো Firewall পরিবর্তন একটি অনুমোদিত পরিবর্তন অনুরোধের মাধ্যমে আসবে, পরীক্ষা পরিবেশে পরীক্ষা করা হবে, এবং তারপর প্রোডাকশনে প্রয়োগ হবে। জরুরি পরিবর্তনের জন্য একটি Fast Track প্রক্রিয়া থাকবে কিন্তু সেগুলোরও পরবর্তীতে পূর্ণাঙ্গ পর্যালোচনা হবে।

Firewall লগ একটি সমৃদ্ধ ডেটা উৎস। সব লগ একটি কেন্দ্রীয় SIEM এ পাঠাতে হবে এবং সেখানে বিশ্লেষণ এবং সংরক্ষণ করতে হবে। অস্বাভাবিক প্যাটার্ন—যেমন সাধারণের চেয়ে বেশি Deny ইভেন্ট, একই উৎস থেকে অনেক পোর্টে স্ক্যান—দ্রুত শনাক্ত করতে হবে।

Backup এবং Disaster Recovery অপরিহার্য। Firewall কনফিগারেশনের নিয়মিত ব্যাকআপ নিতে হবে এবং সেগুলো একটি নিরাপদ এবং পৃথক স্থানে সংরক্ষণ করতে হবে। যদি Firewall ব্যর্থ হয় বা ভুল কনফিগারেশন হয়, দ্রুত পূর্বাবস্থায় ফেরা সম্ভব হবে।

High Availability ক্লাস্টার ব্যবহার করতে হবে যাতে একটি Firewall ফেইল হলে অন্যটি স্বয়ংক্রিয়ভাবে দায়িত্ব নেয়। সফটওয়্যার আপডেট সময়মতো প্রয়োগ করতে হবে কারণ Firewall নিজেই বিভিন্ন CVE তে আক্রান্ত হতে পারে। Fortinet, Palo Alto, Check Point—সবার পণ্যেই গত বছরগুলোতে গুরুতর দুর্বলতা পাওয়া গেছে।