ফায়ারওয়াল ও প্যাকেট ফিল্টারিং
এই পাঠে যা শিখবেন
- একটি স্টেটলেস প্যাকেট-ফিল্টারিং ফায়ারওয়াল কীভাবে কাজ করে — নিয়ম, ম্যাচিং ক্রম ও ডিফল্ট-ডিনাই
- স্টেটফুল ফায়ারওয়াল কীভাবে কানেকশন স্টেট ট্র্যাক করে রুল-লিস্টের জটিলতা কমায়
- স্টেটলেস ও স্টেটফুল ফিল্টারিং-এর মধ্যে ব্যবহারিক পার্থক্য একটি প্রকৃত উদাহরণে দেখা
- Python দিয়ে উভয় ধরনের ফিল্টার বাস্তবায়ন করে সরাসরি তুলনা করা
১ · ফায়ারওয়াল ও স্টেটলেস প্যাকেট ফিল্টারিং
ফায়ারওয়ালFirewallএকটি নিয়মভিত্তিক সিস্টেম যা নেটওয়ার্ক ট্রাফিক পরীক্ষা করে সিদ্ধান্ত নেয় কোন প্যাকেট অনুমোদিত (allow) আর কোনটি প্রত্যাখ্যাত (deny)। একটি নিয়মের তালিকা অনুযায়ী নেটওয়ার্ক ট্রাফিক ফিল্টার করে। সবচেয়ে সহজ ধরনের ফায়ারওয়াল — স্টেটলেস প্যাকেট ফিল্টারStateless Packet Filterপ্রতিটি প্যাকেট স্বাধীনভাবে, কোনো কানেকশন স্টেট ছাড়াই, শুধু তার হেডার ফিল্ড (source/dest IP, পোর্ট, প্রোটোকল) দিয়ে যাচাই করে। — প্রতিটি প্যাকেটের হেডার ফিল্ড (উৎস/গন্তব্য IP, উৎস/গন্তব্য পোর্ট, প্রোটোকল) একটি নিয়মের তালিকার বিপরীতে যাচাই করে, কোনো কানেকশনের "স্টেট" বা ইতিহাস মনে না রেখেই — প্রতিটি প্যাকেট সম্পূর্ণ বিচ্ছিন্নভাবে বিবেচিত হয়।
২ · স্টেটফুল ফায়ারওয়াল — কানেকশন স্টেট ট্র্যাকিং
আজকের দিনে বেশি প্রচলিত স্টেটফুল ফায়ারওয়ালStateful Firewallচলমান কানেকশনের স্টেট ট্র্যাক করে, যাতে একটি বৈধভাবে শুরু হওয়া কানেকশনের রিটার্ন ট্রাফিক স্পষ্ট কোনো নিয়ম ছাড়াই স্বয়ংক্রিয়ভাবে অনুমোদিত হয়। চলমান কানেকশনগুলোর স্টেট ট্র্যাক করে (M5/L24-এ দেখা TCP-এর কানেকশন-স্টেট ধারণার সাথে সরাসরি যুক্ত)। এর মানে, যদি ভেতরের নেটওয়ার্ক থেকে একটি ডিভাইস বৈধভাবে একটি বাইরের সার্ভারের সাথে কানেকশন শুরু করে, ফায়ারওয়াল সেই কানেকশন মনে রাখে — আর সেই কানেকশনের রিটার্ন ট্রাফিক স্বয়ংক্রিয়ভাবে অনুমোদিত হয়ে যায়, প্রতিটি সম্ভাব্য রিপ্লাইয়ের জন্য একটি করে স্পষ্ট (explicit) ইনবাউন্ড নিয়ম লেখার দরকার ছাড়াই — এটি রুল-লিস্টের জটিলতা স্টেটলেস ফিল্টারিং-এর তুলনায় উল্লেখযোগ্যভাবে কমিয়ে দেয়।
প্রতিটি প্যাকেট আলাদাভাবে যাচাই, কোনো ইতিহাস মনে রাখে না — রিটার্ন ট্রাফিকের জন্যও আলাদা নিয়ম দরকার।
চলমান কানেকশন মনে রাখে — বৈধ কানেকশনের রিটার্ন ট্রাফিক স্বয়ংক্রিয়ভাবে অনুমোদিত।
শুধু প্রয়োজনীয় ট্রাফিক স্পষ্টভাবে অনুমোদন, বাকি সব ডিফল্টে ব্লক (least-privilege নীতির নেটওয়ার্ক প্রয়োগ)।
একটি নিরাপদ ফায়ারওয়াল নীতি সাধারণত ডিফল্ট-ডিনাই অনুসরণ করে — শুধু নির্দিষ্টভাবে প্রয়োজনীয় ট্রাফিক স্পষ্টভাবে অনুমোদন (allow) করা হয়, বাকি সবকিছু ডিফল্টভাবে প্রত্যাখ্যাত (deny) থাকে। এটি প্রতিটি সম্ভাব্য ক্ষতিকর জিনিস আলাদা করে চিহ্নিত করে ব্লক করার চেষ্টার (যা কখনো সম্পূর্ণ হতে পারে না) চেয়ে অনেক বেশি নির্ভরযোগ্য — cybersecurity কোর্সের least-privilege নীতিরই একটি নেটওয়ার্ক-স্তরের প্রয়োগ।
# স্টেটলেস বনাম স্টেটফুল প্যাকেট ফিল্টার -- একটি সত্যিকারের সিমুলেশন
# ------------------------------------------------------------
# ধাপ ১ -- স্টেটলেস প্যাকেট ফিল্টার
# rules: (allow, protocol, dest_port) -- ক্রমানুসারে যাচাই হয়, প্রথম ম্যাচ জেতে, শেষে ডিফল্ট-ডিনাই
# ------------------------------------------------------------
stateless_rules = [
(True, "TCP", 443), # HTTPS আউটবাউন্ড অনুমোদিত
(True, "TCP", 80), # HTTP আউটবাউন্ড অনুমোদিত
(True, "UDP", 53), # DNS কোয়েরি অনুমোদিত
# -- তালিকায় আর কোনো ম্যাচ না থাকলে ডিফল্ট-ডিনাই প্রয়োগ হবে --
]
def filter_packet(protocol, dest_port, rules):
"""স্টেটলেস ফিল্টার -- প্রতিটি প্যাকেট স্বাধীনভাবে যাচাই, ক্রমানুসারে প্রথম ম্যাচ জেতে।"""
for allow, rule_protocol, rule_port in rules:
if protocol == rule_protocol and dest_port == rule_port:
return allow
return False # ডিফল্ট-ডিনাই -- তালিকায় কোনো ম্যাচ না পেলে ব্লক
# ------------------------------------------------------------
# ধাপ ২ -- স্টেটফুল ফায়ারওয়াল (M5/L24-এর TCP কানেকশন স্টেটের সাথে যুক্ত)
# established_connections: বৈধভাবে ভেতর থেকে শুরু হওয়া কানেকশনের 5-tuple
# ------------------------------------------------------------
established_connections = set()
def outbound_connect(src_ip, src_port, dst_ip, dst_port, protocol, rules, connections):
"""ভেতরের ডিভাইস একটি বাইরের সার্ভারের সাথে কানেকশন শুরু করছে।"""
allowed = filter_packet(protocol, dst_port, rules)
if allowed:
connections.add((src_ip, src_port, dst_ip, dst_port, protocol))
return allowed
def inbound_stateful_check(src_ip, src_port, dst_ip, dst_port, protocol, rules, connections):
"""স্টেটফুল যাচাই -- এটি কি কোনো established কানেকশনের রিটার্ন ট্রাফিক?"""
reversed_tuple = (dst_ip, dst_port, src_ip, src_port, protocol) # রিটার্ন ট্রাফিকে src/dst উল্টে যায়
if reversed_tuple in connections:
return True # established কানেকশনের রিটার্ন ট্রাফিক -- কোনো এক্সপ্লিসিট ইনবাউন্ড নিয়ম ছাড়াই অনুমোদিত
return filter_packet(protocol, dst_port, rules) # নাহলে সাধারণ স্টেটলেস নিয়ম প্রয়োগ
# ------------------------------------------------------------
# দৃশ্যপট -- ভেতরের একটি ডিভাইস (192.168.1.10) একটি HTTPS সার্ভারের (93.184.216.34:443) সাথে সংযুক্ত হয়
# ------------------------------------------------------------
internal_ip, internal_port = "192.168.1.10", 51000
server_ip, server_port = "93.184.216.34", 443
connect_ok = outbound_connect(internal_ip, internal_port, server_ip, server_port, "TCP",
stateless_rules, established_connections)
print("আউটবাউন্ড HTTPS কানেকশন অনুমোদিত?", connect_ok)
# সার্ভার থেকে রিটার্ন ট্রাফিক আসছে (src/dst উল্টে গেছে) -- ইনবাউন্ড দিক থেকে পোর্ট 51000-এ কোনো এক্সপ্লিসিট নিয়ম নেই
return_traffic_stateless = filter_packet("TCP", internal_port, stateless_rules)
return_traffic_stateful = inbound_stateful_check(server_ip, server_port, internal_ip, internal_port,
"TCP", stateless_rules, established_connections)
print("\nসার্ভার থেকে রিটার্ন ট্রাফিক (dest_port=51000, কোনো এক্সপ্লিসিট নিয়ম নেই):")
print(" স্টেটলেস ফিল্টার অনুমোদন করে কি?", return_traffic_stateless)
print(" স্টেটফুল ফায়ারওয়াল অনুমোদন করে কি?", return_traffic_stateful)
inbound_stateful_check শুধুমাত্র তখনই স্বয়ংক্রিয়ভাবে অনুমোদন করে যখন ট্রাফিকটি
রিভার্সড 5-tuple (src/dst উল্টানো) মিলিয়ে দেখে যে এটি কোনো বৈধভাবে ভেতর থেকে শুরু হওয়া কানেকশনের
উত্তর — এটি কোনো নির্বিচার (blanket) অনুমতি নয়, বরং একটি নির্দিষ্ট, ইতিমধ্যে-অনুমোদিত কানেকশনের প্রেক্ষিতেই
কাজ করে।
স্টেটলেস ফিল্টারিং সহজ কিন্তু প্রতিটি সম্ভাব্য রিটার্ন ট্রাফিকের জন্য আলাদা নিয়ম দরকার করে (অথবা এতটাই অনুমোদনশীল হতে হয় যে নিরাপত্তা দুর্বল হয়ে যায়) — স্টেটফুল ফায়ারওয়াল কানেকশনের স্টেট মনে রেখে এই সমস্যার একটি ব্যবহারিক, নিরাপদ সমাধান দেয়, যা আজকের প্রায় সব ফায়ারওয়াল ডিফল্টভাবে ব্যবহার করে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ শুধুমাত্র স্টেটলেস ফিল্টার ব্যবহার করে রিটার্ন ট্রাফিক অনুমোদন করতে হলে প্রশাসককে কী করতে হতো, এবং সেটির ঝুঁকি কী?
প্রশাসককে হয় প্রতিটি সম্ভাব্য ইনবাউন্ড রিটার্ন-পোর্টের জন্য আলাদা নিয়ম লিখতে হতো (অসম্ভব, কারণ ক্লায়েন্ট পোর্ট সাধারণত এলোমেলোভাবে বরাদ্দ হয়, M5/L22-এর এফিমেরাল পোর্ট রেঞ্জ থেকে), অথবা একটি বিস্তৃত রেঞ্জের সব ইনবাউন্ড পোর্ট খুলে দিতে হতো — যা কার্যত ফায়ারওয়ালের সুরক্ষাকে অকার্যকর করে দেয়, কারণ তখন যেকোনো বাইরের সোর্স সেই খোলা পোর্টগুলোতে সরাসরি ট্রাফিক পাঠাতে পারবে।
প্র ০২ স্টেটফুল ফায়ারওয়াল কি ভেতর থেকে বাইরে শুরু হওয়া প্রতিটি কানেকশনই সবসময় অনুমোদন করে দেয়?
না — আউটবাউন্ড কানেকশনও প্রথমে সাধারণ স্টেটলেস-স্টাইল নিয়মের বিপরীতে যাচাই হয় (উপরের কোডে
outbound_connect প্রথমে filter_packet কল করে)। স্টেটফুল আচরণটি শুধু এরপর
প্রযোজ্য — একবার একটি কানেকশন বৈধভাবে অনুমোদিত ও ট্র্যাক করা হলে, তার নির্দিষ্ট রিটার্ন ট্রাফিকই
স্বয়ংক্রিয়ভাবে অনুমোদিত হয়, অন্য কোনো এলোমেলো ইনবাউন্ড ট্রাফিক নয়।
প্র ০৩ ডিফল্ট-ডিনাই নীতি কেন "শুধু ক্ষতিকর জিনিস ব্লক করা" নীতির চেয়ে বেশি নিরাপদ বলে বিবেচিত হয়?
"শুধু ক্ষতিকর জিনিস ব্লক করা" নীতির জন্য প্রতিটি সম্ভাব্য হুমকি আগে থেকে চিহ্নিত করতে হয় — কিন্তু নতুন হুমকি বা অপ্রত্যাশিত ট্রাফিক প্যাটার্ন সবসময় আসতে পারে, যা এই তালিকায় নাও থাকতে পারে। ডিফল্ট-ডিনাই উল্টো দিক থেকে কাজ করে — শুধু জানা, প্রয়োজনীয় ট্রাফিক স্পষ্টভাবে অনুমোদন করা হয়, তাই একটি সম্পূর্ণ নতুন, অচেনা হুমকিও স্বয়ংক্রিয়ভাবে ব্লকড থাকে, কারণ এটি অনুমোদিত তালিকায় নেই।
অনুশীলন
-
পরীক্ষা করুন: উপরের কোড সেলে
stateless_rulesথেকে(True, "TCP", 443)এন্ট্রিটি সরিয়ে দিন এবং আবার Run চাপুন —connect_ok-এর ফলাফল কীভাবে বদলায়, আর এর ফলে স্টেটফুল চেকের ফলাফলও কীভাবে প্রভাবিত হয়?connect_okএখনFalseহবে (আউটবাউন্ড HTTPS-ই আর অনুমোদিত নয়), এবং যেহেতুoutbound_connect-এ কানেকশনটিestablished_connections-এ যোগই হবে না, তাই পরবর্তী স্টেটফুল রিটার্ন-ট্রাফিক চেকও স্বয়ংক্রিয়ভাবে ব্যর্থ হবে (সাধারণ স্টেটলেস নিয়মে ফিরে যাবে, যা এখনও পোর্ট ৫১০০০-এর জন্য কোনো নিয়ম খুঁজে পাবে না) — এটি দেখায় স্টেটফুল ট্র্যাকিং শুধুমাত্র প্রথমে বৈধভাবে অনুমোদিত কানেকশনের ক্ষেত্রেই কাজ করে। -
চিন্তা করুন: M6/L32-এর FTP প্রোটোকলের কথা মনে করুন, যেখানে ডেটা কানেকশনের পোর্ট সেশনের আগে থেকে জানা থাকে না — এই ধরনের প্রোটোকলের জন্য শুধুমাত্র সাধারণ স্টেটফুল ফিল্টারিং কেন যথেষ্ট নাও হতে পারে?
সাধারণ স্টেটফুল ফিল্টারিং একটি নির্দিষ্ট 5-tuple কানেকশন ট্র্যাক করে, কিন্তু FTP-এর মতো প্রোটোকলে ডেটা কানেকশনের পোর্ট নম্বর কন্ট্রোল কানেকশনের ভেতরে (অ্যাপ্লিকেশন-লেয়ার ডেটাতে) নেগোশিয়েট হয় — একটি সাধারণ ফায়ারওয়াল সেই অ্যাপ্লিকেশন-লেয়ার বিষয়বস্তু না বুঝলে নতুন ডেটা কানেকশনের পোর্ট আগে থেকে জানতে পারবে না। এই কারণে বাস্তব ফায়ারওয়ালগুলো প্রায়ই "অ্যাপ্লিকেশন-অ্যাওয়্যার" (protocol-aware) inspection যোগ করে, যা এই পাঠের সরলীকৃত মডেলের বাইরের একটি বিষয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ পরবর্তী পাঠ — VPN ও IPsec — কীভাবে এনক্রিপ্টেড টানেল অবিশ্বস্ত নেটওয়ার্কের উপর দিয়ে নিরাপদ যোগাযোগ সম্ভব করে।
- Cloud Computing & DevOps কোর্স সঙ্গী কোর্স ক্লাউডে সিকিউরিটি গ্রুপ ও নেটওয়ার্ক ACL কীভাবে ব্যবহারিকভাবে কনফিগার করা হয় তা শিখতে দেখুন।
- Cybersecurity & Ethical Hacking কোর্স সঙ্গী কোর্স ফায়ারওয়াল বাইপাস কৌশল ও পরবর্তী প্রজন্মের (NGFW) ফায়ারওয়াল সক্ষমতা বিস্তারিত জানতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps ও Computer Networks — সব এক জায়গায়।