ফায়ারওয়াল ও IDS/IPS

Firewalls & IDS/IPS

৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

ফায়ারওয়াল IP/পোর্ট/প্রোটোকল-ভিত্তিক নিয়ম (rule) দিয়ে ট্র্যাফিক অনুমতি/প্রত্যাখ্যান করে — packet-filtering, stateful (সংযোগের অবস্থা মনে রাখে) ও next-gen (অ্যাপ্লিকেশন-স্তর সচেতন) — এই তিন স্তরে বিবর্তিত হয়েছে।
IDS (Intrusion Detection System) শুধু মনিটর করে ও অ্যালার্ট দেয় — সাধারণত traffic-এর একটি কপির উপর কাজ করে (out-of-band)। IPS (Intrusion Prevention System) সরাসরি ট্র্যাফিকের পথে (inline) বসে এবং স্বয়ংক্রিয়ভাবে ব্লক করে।
ডিটেকশন দুই পদ্ধতিতে হয় — Signature-based (পরিচিত আক্রমণ প্যাটার্নের সাথে মেলানো) ও Anomaly-based (স্বাভাবিক বেসলাইন থেকে বিচ্যুতি শনাক্ত করা)।

এই পাঠে যা শিখবেন

ফায়ারওয়ালের তিনটি প্রজন্ম — packet-filtering, stateful, next-gen — এর পার্থক্য
IDS বনাম IPS — মনিটরিং বনাম প্রিভেনশন, out-of-band বনাম inline
Signature-based বনাম anomaly-based ডিটেকশন এবং প্রতিটির সীমাবদ্ধতা
একটি সাধারণ রুল-ভিত্তিক ফায়ারওয়াল কীভাবে ট্র্যাফিক অনুমতি বা প্রত্যাখ্যানের সিদ্ধান্ত নেয়

১ · ফায়ারওয়াল — তিনটি প্রজন্ম

একটি ফায়ারওয়ালFirewallএকটি নেটওয়ার্ক সিকিউরিটি ডিভাইস/সফটওয়্যার যা পূর্বনির্ধারিত নিয়ম অনুযায়ী ইনকামিং ও আউটগোয়িং ট্র্যাফিক পরীক্ষা করে অনুমতি দেয় বা প্রত্যাখ্যান করে। L05-এ শেখা attack surface কমানোর একটি মূল হাতিয়ার — তিনটি প্রজন্মে বিবর্তিত হয়েছে —

Packet-filtering
প্রতিটি প্যাকেট আলাদাভাবে পরীক্ষা করে, শুধু IP/পোর্ট/প্রোটোকলের ভিত্তিতে — সবচেয়ে সহজ ও দ্রুত, কিন্তু সংযোগের প্রেক্ষাপট মনে রাখে না।

Stateful
একটি সক্রিয় সংযোগের অবস্থা (state) ট্র্যাক করে — যেমন বোঝে একটি আউটগোয়িং রিকোয়েস্টের বৈধ রেসপন্স কোনটি, তাই শুধু সেই রেসপন্স অনুমতি দেয়, প্রেক্ষাপটহীন প্যাকেট নয়।

Next-gen (NGFW)
অ্যাপ্লিকেশন-স্তর পর্যন্ত সচেতন — শুধু "পোর্ট ৪৪৩ খোলা" নয়, বুঝতে পারে ঠিক কোন অ্যাপ্লিকেশন সেই ট্র্যাফিক তৈরি করছে এবং তার ভিত্তিতে নিয়ন্ত্রণ করতে পারে।

২ · IDS বনাম IPS

ফায়ারওয়াল ট্র্যাফিক অনুমতি/প্রত্যাখ্যান করে নিয়মের ভিত্তিতে, কিন্তু সন্দেহজনক প্যাটার্ন শনাক্ত করার জন্য আলাদা টুল প্রয়োজন হয় —

IDS (Intrusion Detection System) — ট্র্যাফিক মনিটর করে এবং সন্দেহজনক কিছু পেলে অ্যালার্ট দেয়, কিন্তু নিজে ব্লক করে না। সাধারণত ট্র্যাফিকের একটি কপির উপর out-of-band-এ কাজ করে — তাই এটি ব্যর্থ হলেও মূল ট্র্যাফিক প্রবাহ বাধাগ্রস্ত হয় না।
IPS (Intrusion Prevention System) — একই বিশ্লেষণ করে, কিন্তু সরাসরি ট্র্যাফিকের পথে (inline) বসে এবং সন্দেহজনক ট্র্যাফিক স্বয়ংক্রিয়ভাবে ব্লক করে দেয়।

Inline হওয়ার ট্রেড-অফ

IPS inline হওয়ায় সক্রিয়ভাবে আক্রমণ থামাতে পারে — কিন্তু একটি ভুল-পজিটিভ (false positive) সরাসরি বৈধ ট্র্যাফিক ব্লক করে দিতে পারে (Availability-এর উপর প্রভাব, L01-এর CIA Triad মনে করুন)। IDS এই ঝুঁকি নেয় না, কিন্তু আক্রমণ সক্রিয়ভাবে থামাতে পারে না — শুধু জানায়। অনেক প্রতিষ্ঠান দুটোই একসাথে ব্যবহার করে, স্তরভিত্তিক প্রতিরক্ষার জন্য।

৩ · Signature-based বনাম Anomaly-based ডিটেকশন

IDS/IPS সন্দেহজনক ট্র্যাফিক শনাক্ত করার জন্য দুটি প্রধান পদ্ধতি ব্যবহার করে —

Signature-based — পরিচিত আক্রমণ প্যাটার্নের একটি ডেটাবেসের সাথে ট্র্যাফিক মিলিয়ে দেখে। দ্রুত ও নির্ভুল পরিচিত আক্রমণের জন্য, কিন্তু নতুন/অজানা (zero-day) আক্রমণ ধরতে পারে না।
Anomaly-based — একটি "স্বাভাবিক" আচরণের বেসলাইন শেখে, এবং সেখান থেকে উল্লেখযোগ্য বিচ্যুতি হলে অ্যালার্ট দেয়। নতুন আক্রমণ ধরতে পারে, কিন্তু ভুল-পজিটিভের হার বেশি হতে পারে (স্বাভাবিক কিন্তু অস্বাভাবিক আচরণকেও ফ্ল্যাগ করতে পারে)।

L12-এ আমরা দেখব কীভাবে একটি অতি-দ্রুত পোর্ট স্ক্যান anomaly-based ডিটেকশনের জন্য সহজে ধরা পড়ার মতো — কারণ এই ধরনের আচরণ কোনো "স্বাভাবিক" ব্যবহারকারীর প্যাটার্নের সাথে মেলে না।

৪ · কোড সেল — একটি সাধারণ রুল-ভিত্তিক ফায়ারওয়াল সিমুলেটর

নিচের কোডে আমরা একটি ফায়ারওয়ালের আচরণ সিমুলেট করব — একটি রুলের তালিকা ক্রমানুসারে পরীক্ষা করে, প্রথম যে রুল মিলবে তাই প্রযোজ্য হবে (first match wins), এবং কোনো রুল না মিললে ডিফল্টভাবে প্রত্যাখ্যান (default deny) করা হবে — এটি একটি সম্পূর্ণ ভুয়া, in-memory সিমুলেশন, কোনো বাস্তব নেটওয়ার্ক ট্র্যাফিক এখানে জড়িত নয়।

Python

# প্রতিটি রুল: (action, src_ip_pattern, port) — src_ip_pattern-এ "*" মানে "যেকোনো"
firewall_rules = [
    ("allow", "10.0.0.*",  22),    # অফিস নেটওয়ার্ক থেকে SSH অনুমতি
    ("allow", "*",         443),   # সবার জন্য HTTPS অনুমতি
    ("deny",  "*",         23),    # Telnet সম্পূর্ণ নিষিদ্ধ (L05-এর উচ্চ-ঝুঁকি পোর্ট)
    ("deny",  "*",         3389),  # RDP সম্পূর্ণ নিষিদ্ধ ইন্টারনেট থেকে
]

def ip_matches(pattern, ip):
    if pattern == "*":
        return True
    pattern_prefix = pattern.rstrip("*")
    return ip.startswith(pattern_prefix)

def check_packet(src_ip, port, rules):
    for action, ip_pattern, rule_port in rules:
        if rule_port == port and ip_matches(ip_pattern, src_ip):
            return action
    return "deny"  # default deny — কোনো রুল না মিললে প্রত্যাখ্যান

test_packets = [
    ("10.0.0.5",     22),    # অফিস থেকে SSH -> allow
    ("203.0.113.9",  22),    # বাইরে থেকে SSH -> কোনো allow rule মেলে না -> default deny
    ("203.0.113.9",  443),   # যেকোনো জায়গা থেকে HTTPS -> allow
    ("203.0.113.9",  23),    # Telnet -> explicit deny
    ("198.51.100.7", 3389),  # RDP -> explicit deny
]

print("ফায়ারওয়াল সিদ্ধান্ত রিপোর্ট:\n")
for src_ip, port in test_packets:
    decision = check_packet(src_ip, port, firewall_rules)
    print(f"src={src_ip:<14} port={port:<5} -> {decision.upper()}")

লক্ষ্য করুন — ("10.0.0.5", 22) অনুমোদিত হয়েছে কারণ এটি অফিস নেটওয়ার্ক (10.0.0.*) থেকে এসেছে, কিন্তু ("203.0.113.9", 22) প্রত্যাখ্যাত হয়েছে — একই পোর্ট, কিন্তু ভিন্ন উৎস, এবং কোনো স্পষ্ট allow rule না থাকায় default deny প্রযোজ্য হয়েছে। এটাই "default deny" নীতির শক্তি — যা স্পষ্টভাবে অনুমোদিত নয়, তা স্বয়ংক্রিয়ভাবে প্রত্যাখ্যাত হয়।

মূল কথা · Key takeaway

ফায়ারওয়াল নিয়ম-ভিত্তিক প্রবেশ নিয়ন্ত্রণ করে, IDS/IPS প্যাটার্ন-ভিত্তিক সন্দেহজনক আচরণ শনাক্ত (ও কখনো ব্লক) করে — দুটি ভিন্ন স্তরের প্রতিরক্ষা, একসাথে ব্যবহার করলে অনেক বেশি শক্তিশালী। L07-এ আমরা দেখব কীভাবে VPN এই প্রতিরক্ষার সাথে যুক্ত হয়ে ট্র্যাফিকের গোপনীয়তা ও অখণ্ডতা রক্ষা করে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি e-commerce সাইট, যেখানে প্রতি সেকেন্ডে হাজার হাজার বৈধ রিকোয়েস্ট আসে, কেন একটি IPS বসানোর আগে খুব সাবধানে false-positive rate পরীক্ষা করা উচিত?

যেহেতু IPS inline-এ বসে এবং সন্দেহজনক ট্র্যাফিক স্বয়ংক্রিয়ভাবে ব্লক করে দেয়, একটি উচ্চ false-positive rate মানে বাস্তব গ্রাহকদের বৈধ রিকোয়েস্টও ভুলবশত ব্লক হয়ে যেতে পারে — যা সরাসরি Availability (L01-এর CIA Triad) এবং ব্যবসার রাজস্বের উপর প্রভাব ফেলে। IDS-এ একই ভুল শুধু একটি অপ্রয়োজনীয় অ্যালার্ট তৈরি করত, বৈধ ট্র্যাফিক বন্ধ করে দিত না।

প্র ০২ একটি সম্পূর্ণ নতুন (zero-day) আক্রমণ কৌশল কেন signature-based ডিটেকশন সহজে এড়িয়ে যেতে পারে, কিন্তু anomaly-based ডিটেকশন কিছুটা সুযোগ পায়?

Signature-based ডিটেকশন শুধু পরিচিত আক্রমণ প্যাটার্নের সাথে মেলায় — একটি নতুন কৌশলের কোনো পরিচিত স্বাক্ষর ডেটাবেসে না থাকায় তা মিস হয়ে যায়। Anomaly-based ডিটেকশন প্যাটার্ন চেনে না, বরং "স্বাভাবিক আচরণ থেকে বিচ্যুতি" খোঁজে — তাই নতুন আক্রমণও যদি অস্বাভাবিক নেটওয়ার্ক/সিস্টেম আচরণ তৈরি করে, তা ধরা পড়ার সম্ভাবনা থাকে, যদিও এটি নিশ্চিত নয় এবং false positive-এর ঝুঁকিও বেশি।

প্র ০৩ উপরের কোড সেলের ফায়ারওয়াল সিমুলেটরে, রুলগুলোর ক্রম পরিবর্তন করলে ফলাফল বদলে যেতে পারে কেন ("first match wins" নীতির প্রেক্ষাপটে)?

যেহেতু check_packet ফাংশন রুলগুলো ক্রমানুসারে পরীক্ষা করে এবং প্রথম যেটি মেলে তাই প্রয়োগ করে, রুলের ক্রম গুরুত্বপূর্ণ। উদাহরণস্বরূপ, যদি একটি সাধারণ ("deny", "*", 22) রুল ("allow", "10.0.0.*", 22) রুলের আগে রাখা হতো, তাহলে অফিস নেটওয়ার্ক থেকেও SSH ব্লক হয়ে যেত — কারণ deny রুলটি প্রথমেই মিলে যেত। বাস্তব ফায়ারওয়াল কনফিগারেশনে রুল-অর্ডারিং একটি সাধারণ কিন্তু গুরুত্বপূর্ণ ভুলের উৎস।

অনুশীলন

চিন্তা করুন: একটি প্রতিষ্ঠান তাদের ওয়েব সার্ভারে একটি stateful ফায়ারওয়াল ব্যবহার করছে। একজন আক্রমণকারী সার্ভার থেকে কোনো রিকোয়েস্ট ছাড়াই একটি "রেসপন্স-সদৃশ" প্যাকেট পাঠানোর চেষ্টা করে। একটি simple packet-filtering ফায়ারওয়ালের তুলনায় stateful ফায়ারওয়াল এটি কীভাবে ভিন্নভাবে সামলাবে?

একটি simple packet-filtering ফায়ারওয়াল শুধু IP/পোর্ট দেখে — যদি সেই পোর্ট থেকে ট্র্যাফিক সাধারণত অনুমোদিত হয়, তা পাস করে দিতে পারে, কোনো প্রকৃত অনুরোধ ছিল কি না তা বিবেচনা না করেই। একটি stateful ফায়ারওয়াল জানে কোনো সক্রিয় আউটগোয়িং রিকোয়েস্ট আসলে হয়েছিল কি না — যেহেতু কোনো মিলে যাওয়া "সংযোগ অবস্থা" নেই, এটি এই অযাচিত "রেসপন্স" প্রত্যাখ্যান করবে।
পরীক্ষা করুন: উপরের কোড সেলে firewall_rules-এ একটি নতুন রুল ("allow", "192.168.1.*", 80) শুরুতে যোগ করুন এবং test_packets-এ ("192.168.1.10", 80) যোগ করে Run চাপুন — ফলাফল কী হয়?

("192.168.1.10", 80) প্যাকেটটি নতুন যোগ করা allow রুলের সাথে মিলে যাবে (কারণ IP প্যাটার্ন 192.168.1.* এর সাথে মেলে এবং পোর্ট ৮০), তাই ফলাফল হবে ALLOW — যদিও পোর্ট ৮০-এর জন্য আগের কোনো রুলে সেই নির্দিষ্ট সাবনেট উল্লেখ ছিল না।