লিনাক্সে নেটফিল্টার এবং সুরিকাটা বাস্তবায়নের সম্পূর্ণ নির্দেশিকা

ইনফরমটেক ডিজিটাল » মানে » লিনাক্সে নেটফিল্টার এবং সুরিকাটা বাস্তবায়নের সম্পূর্ণ নির্দেশিকা

আপনি যদি GNU/Linux ( নিরাপত্তা ও গোপনীয়তার জন্য সেরা লিনাক্স ডিস্ট্রিবিউশন ) ব্যবহার করে নেটওয়ার্ক নিয়ে কাজ করেন এবং প্রচলিত স্ট্যাটিক ফায়ারওয়ালের বাইরে যেতে আগ্রহী হন, তাহলে সম্ভবত আপনি জানতে আগ্রহী যে, প্রোপাইটারি হার্ডওয়্যারে বিপুল পরিমাণ অর্থ ব্যয় না করে কীভাবে Netfilter, NFQUEUE এবং Suricata-কে একত্রিত করে একটি সত্যিকারের নমনীয় IDS/IPS তৈরি করা যায় । এই আর্টিকেলে আমরা ঠিক এই বিষয়টিই অন্বেষণ করব, যেখানে লো-লেভেল উপাদান (কার্নেল, কিউ, C) এবং হাই-লেভেল টুলস (Suricata, রুলস, MySQL, Memcached, pfSense)-এর সমন্বয় ঘটানো হবে।

এর পেছনের মূল ধারণাটি অত্যন্ত শক্তিশালী: কার্নেল ( লিনাক্স কার্নেল কীভাবে অপ্টিমাইজ করতে হয় তা দেখুন ) ইউজার স্পেসে প্যাকেট কিউ করতে পারে এবং একটি কাস্টম প্রোগ্রামকে সেগুলোর সাথে কী করতে হবে তা সিদ্ধান্ত নিতে দেওয়া—এই বিষয়টিকে কাজে লাগানো। এটি ট্র্যাফিক ফিল্টারিং (অ্যাডভান্সড ফায়ারওয়ালিং, আইপিএস), ডাইনামিক রাউটিং, অথবা বিজনেস লজিক ইন্টিগ্রেট করার (ডাটাবেস, ক্যাশ, ওয়েব অ্যাপ্লিকেশন অ্যাটাক ডিটেকশন, ভিওআইপি, ইত্যাদি) জন্য ব্যবহার করা যেতে পারে। আর যদি আমরা একটি মাল্টি-প্রসেস আইডিএস/আইপিএস ইঞ্জিন হিসেবে সুরিকাটা যোগ করি, তাহলে ল্যাব থেকে শুরু করে হাই-ট্র্যাফিক ডেটা সেন্টার পর্যন্ত বিভিন্ন পরিবেশের জন্য আমরা একটি অত্যন্ত শক্তিশালী সমন্বয় পেয়ে যাই।

NFQUEUE এবং Netfilter: ফায়ারওয়ালকে ব্যবহারকারীর স্থানে উন্নীত করা

একটি সাধারণ GNU/Linux সিস্টেমে, Netfilter/iptables (বা nftables) নিয়মগুলি সাধারণত স্ট্যাটিক পলিসি হিসাবে ব্যবহৃত হয় যা সম্পূর্ণরূপে কার্নেল স্পেসে থাকে । ফ্রন্টএন্ড এবং অ্যাপ্লায়েন্সগুলি (Netfilter বা BSD-এর Packet Filter-এর উপর ভিত্তি করে তৈরি অনেক সমাধান সহ) কনফিগারেশনটি টেক্সট, XML, বা SQLite ফাইলে সংরক্ষণ করে, এবং যখন কিছু পরিবর্তিত হয়, তখন তারা নিয়মগুলি পুনরায় তৈরি এবং লোড করে। এটি নমনীয়, কিন্তু এর কার্যপ্রণালী ফায়ারওয়ালের এক ধরনের স্ন্যাপশট হিসাবেই থেকে যায়, যেখানে সামান্য কিছু ডাইনামিক পরিবর্তন (যেমন প্রতি সেকেন্ডে সংযোগের সীমা, conntrack, দেশ মেলানো, উপলব্ধ থাকলে লেয়ার ৭ ইত্যাদি) করা হয়।

NFQUEUE যা প্রস্তাব করে তা একটি যুগান্তকারী পরিবর্তন: কার্নেলের চূড়ান্ত সিদ্ধান্ত নেওয়ার পরিবর্তে, আমরা সেই সিদ্ধান্তটি একটি ইউজার প্রসেসের উপর অর্পণ করতে পারি । কার্নেল প্যাকেটটিকে একটি নম্বরযুক্ত কিউতে রাখে, এবং libnetfilter_queue লাইব্রেরি ব্যবহারকারী একটি অ্যাপ্লিকেশন সেটি গ্রহণ করে, বিশ্লেষণ করে এবং একটি রায় দেয়: গ্রহণ, বর্জন, বা এমনকি পলিসি রাউটিংয়ের জন্য চিহ্নিত করা। এটি অনেকটা ফায়ারওয়ালের উপরে C, Python, বা Perl-এ লেখা একটি প্রোগ্রামযোগ্য 'বিচারক' থাকার মতো।

এর সৌন্দর্য হলো এই যে, আমাদের প্রোগ্রাম কার্নেলকে সাড়া দেওয়ার আগে আক্ষরিক অর্থেই যা খুশি তাই করতে পারে: যেমন /dev/urandom, একটি ডাটাবেস, একটি ওয়েব সার্ভিস, একটি ডিস্ট্রিবিউটেড ক্যাশে, বা একটি জটিল অ্যালগরিদম কোয়েরি করা । স্থাপত্যের দিক থেকে, ফায়ারওয়ালটি তখন কেবল কিছু স্থির নিয়মের সমষ্টি না থেকে একটি পাইপলাইনে পরিণত হয়, যেখানে নেটফিল্টার, কিউ এবং ব্যবহারকারীর অ্যাপ্লিকেশনগুলো একটি পাজলের টুকরোর মতো একে অপরের সাথে মিলে যায়।

NFQUEUE দুটি অংশ নিয়ে গঠিত: iptables-এর NFQUEUE টার্গেট , যা প্যাকেটগুলোকে একটি নির্দিষ্ট কিউ-তে পাঠায়, এবং libnetfilter_queue ইউজার লাইব্রেরি , যা আপনাকে সেই প্যাকেটগুলো পড়তে এবং একটি সিদ্ধান্ত জানাতে সাহায্য করে। এটি tcpdump-এর মতো কোনো সাধারণ স্নিফার নয়: এখানে প্যাকেটটি কোন পথে যাবে, তা আমরা সরাসরি নির্ধারণ করতে পারি।

NFQUEUE সহ বেসিক iptables কনফিগারেশন

iptables-এর দৃষ্টিকোণ থেকে, NFQUEUE ব্যবহার করা বেশ সহজবোধ্য: আপনি যে চেইনটি নিয়ে কাজ করতে আগ্রহী, সেখানে একটি নিয়ম যোগ করে নির্দিষ্ট শর্ত পূরণকারী প্যাকেটগুলোকে (যেমন সোর্স/ডেস্টিনেশন আইপি, পোর্ট, স্টেট, এবং উপলব্ধ থাকলে GeoIP বা layer7-এর মতো অতিরিক্ত মডিউল ইত্যাদি) কিউ-তে পাঠান।

উদাহরণস্বরূপ, যদি আমরা হোস্টে আসা সমস্ত পিং NFQUEUE-তে পাঠাতে চাই:

iptables -I ইনপুট -p icmp -j NFQUEUE

এটি আগত ICMP প্যাকেটগুলিকে কিউ 0-তে পাঠায় (যদি না অন্য কিছু নির্দিষ্ট করা থাকে)। আমরা `--queue-num 3`-এর মতো কিছু ব্যবহার করে অন্য একটি কিউ নির্দিষ্ট করতে পারি । কাউন্টার সহ নিয়মগুলি তালিকাভুক্ত করার সময় (`iptables -L -n -v -x`), আমরা কাউন্টারগুলি বাড়তে দেখব, যা নির্দেশ করে যে প্যাকেটগুলি কিউতে যুক্ত হচ্ছে । একটি গুরুত্বপূর্ণ বিষয়: যদি কিউতে প্যাকেট থাকে এবং কোনো ব্যবহারকারী প্রক্রিয়া সেগুলি গ্রহণ ও প্রক্রিয়া না করে, তবে ডিফল্ট আচরণ হলো সেগুলিকে প্রত্যাখ্যান করা, তাই নকশা অনুযায়ী, একটি অ্যাপ্লিকেশন ব্যর্থতার ফলে ট্র্যাফিক ব্লক হয়ে যায়।

libnetfilter_queue এর বিরুদ্ধে প্রোগ্রামিং: C তে "হ্যালো ওয়ার্ল্ড"

ইউজার স্পেস থেকে কিউতে যোগ দেওয়ার জন্য libnetfilter_queue লাইব্রেরিটি ব্যবহৃত হয় (যা আবার libnfnetlink-এর উপর নির্ভরশীল)। ডেবিয়ানের মতো ডিস্ট্রিবিউশনগুলিতে, কেবল ডেভেলপমেন্ট প্যাকেজগুলি ইনস্টল করুন:

apt-get ইনস্টল করুন libnfnetlink-dev libnetfilter-queue-dev gcc

সর্বদা প্যাকেট গ্রহণকারী একটি ন্যূনতম প্রোগ্রামের কাঠামোতে কয়েকটি অত্যন্ত সুস্পষ্ট ধাপ রয়েছে: লাইব্রেরিটি খোলা, বিদ্যমান হ্যান্ডলারগুলোকে আনবাইন্ড করা, AF_INET প্রোটোকলের সাথে বাইন্ড করা, একটি কলব্যাক ফাংশনসহ কিউ তৈরি করা, কপি মোড নির্ধারণ করা এবং একটি রিসিভ লুপে প্রবেশ করা । কিউতে থাকা প্রতিটি প্যাকেটের জন্য কলব্যাকটি এক্সিকিউট হয়, যা আইডিটি এক্সট্র্যাক্ট করে এবং ভারডিক্ট রিটার্ন করে।

কার্যত, কার্যপ্রবাহটি অনেকটা এইরকম: হ্যান্ডেলটি পাওয়ার জন্য `nfq_open`, এটিকে পরিষ্কার করার জন্য `nfq_unbind_pf`, AF_INET-এর সাথে যুক্ত করার জন্য `nfq_bind_pf`, কিউ ০-তে কলব্যাকটি রেজিস্টার করার জন্য `nfq_create_queue`, আমরা মেটাডেটা চাই নাকি পুরো প্যাকেটটি চাই তা নির্দেশ করার জন্য `nfq_set_mode`, ডেসক্রিপ্টরের উপর `recv()` দিয়ে একটি লুপ, এবং প্রতিটি প্যাকেট প্রসেস করার জন্য `nfq_handle_packet` । প্রক্রিয়া শেষে, `nfq_destroy_queue` দিয়ে কিউটি ধ্বংস করা হয় এবং `nfq_close` দিয়ে হ্যান্ডেলটি বন্ধ করা হয়।

এই ধরণের "হ্যালো ওয়ার্ল্ড" NFQUEUE এর প্রভাবের একটি পরিষ্কার পরিমাপের সুযোগ করে দেয়। যদি আমরা উদাহরণটি এরকম কিছু দিয়ে সংকলন করি:

gcc -o nftest code.c -lnfnetlink -lnetfilter_queue

এবং যদি আমরা একটি iperf থেকে ট্র্যাফিক কিউ করি (উদাহরণস্বরূপ, INPUT এবং OUTPUT-এ TCP পোর্ট 5001), আমরা দেখতে পাব যে যে কোড কেবল প্যাকেট গ্রহণ করে তা একটি গিগাবিট নেটওয়ার্কে পারফরম্যান্সকে প্রায় প্রভাবিত করে না । তবে, একটি গুরুত্বপূর্ণ বিষয় আছে: কলব্যাকে তথ্য প্রিন্ট করা (printf, fflush, ইত্যাদি) থ্রুপুটকে উল্লেখযোগ্যভাবে ক্ষতিগ্রস্ত করে, যা স্ক্রিন ডিবাগিং সহ এবং ছাড়া iperf-এর তুলনা করলে দেখা যায়।

উন্নত NFQUEUE বিকল্প: বাইপাস, ব্যালেন্স এবং ফেইল-ওপেন

NFQUEUE-তে বেশ কিছু গুরুত্বপূর্ণ iptables অপশন অন্তর্ভুক্ত রয়েছে, যেগুলো কিউ-এর ডিফল্ট আচরণ পরিবর্তন করে। প্রোডাকশন বা হাই-পারফরম্যান্স পরিবেশে প্রবেশের আগে এই অপশনগুলো সম্পর্কে জেনে রাখা উচিত, কারণ এগুলো ইউজার অ্যাপ্লিকেশনের ব্যর্থতা বা কিউ পূর্ণ হওয়াকে কীভাবে সামলানো হয়, তার ওপর প্রভাব ফেলে ।

`--queue-bypass` কমান্ডটি আপনাকে এটি নিশ্চিত করতে সাহায্য করে যে, যদি কোনো প্রসেস কিউ-তে লিসেন না করে, তাহলে প্যাকেটগুলো ড্রপ না হয়ে আইপিটেবলস চেইনের পরবর্তী হপে ফরোয়ার্ড হয়ে যাবে। এটি তখন কাজে আসতে পারে যখন আপনি চান যে ইউজার সার্ভিসটি অনুপলব্ধ থাকলে সিস্টেমটি "ফেইল ওপেন" হয়ে যাক, যদিও নিরাপত্তার দৃষ্টিকোণ থেকে এটি একটি দ্বিধারী তলোয়ারের মতো।

`--queue-balance` অপশনটি আপনাকে প্যাকেটগুলোকে বিভিন্ন কিউ-এর মধ্যে (যেমন, ০ থেকে ৩) ভাগ করে দেওয়ার সুযোগ দেয় এবং এরপর একাধিক স্বাধীন প্রসেস বা থ্রেডকে প্রতিটি কিউ থেকে প্যাকেট গ্রহণ করতে দেয় । নেটফিল্টারের কোড নিশ্চিত করে যে একই ফ্লো থেকে আসা প্যাকেটগুলো সবসময় একই কিউ-তে জমা হয়, যা সিদ্ধান্ত গ্রহণের যুক্তিতে সামঞ্জস্য বজায় রাখাকে অনেক সহজ করে তোলে।

এছাড়াও `--fail-open` মোড রয়েছে , যা নিয়ন্ত্রণ করে যে ইউজার প্রসেস খুব ধীর গতিতে চলার কারণে কিউ পূর্ণ হয়ে গেলে কী ঘটবে। এটি সক্রিয় করলে কার্নেল প্যাকেটগুলো ফেলে না দিয়ে সরাসরি গ্রহণ করে, যা ব্যাপক ট্র্যাফিক বিঘ্ন প্রতিরোধ করে। আবারও, এটি একটি নিরাপত্তা সমস্যা হতে পারে, কারণ আমরা যদি প্রতিটি ক্ষেত্রে আলাদাভাবে সিদ্ধান্ত নিতে চাই, তাহলে সিদ্ধান্তের প্যাকেট হারিয়ে যাওয়ার অর্থ হলো সেই উদ্দেশ্য পূরণে ব্যর্থ হওয়া।

কিউগুলোতে কী ঘটছে তা নিরীক্ষণ করার জন্য, নেটফিল্টার /proc/net/netfilter/nfnetlink_queue নামক সিউডো-এফএস-এ তথ্য প্রকাশ করে , যা স্ক্রিপ্ট বা মনিটরিং টুল থেকে সহজেই কোয়েরি করা যায়।

ব্যবসায়িক যুক্তি একীভূতকরণ: মেমক্যাশেড এবং মাইএসকিউএল দিয়ে পরীক্ষা করা

একবার "হ্যালো ওয়ার্ল্ড" প্রক্রিয়াটি নিয়ন্ত্রণে চলে এলে, পরবর্তী স্বাভাবিক পদক্ষেপ হলো বাহ্যিক সিস্টেমগুলিতে কল করার মাধ্যমে কলব্যাকটিকে আরও সমৃদ্ধ করা । একটি সাধারণ পরীক্ষায়, সোর্স আইপি অ্যাড্রেসটি কোনো ব্যাকএন্ডে (যেমন একটি MySQL ডাটাবেস বা একটি Memcached ক্যাশে) উপস্থিত আছে কি না, তার উপর ভিত্তি করে একটি প্যাকেট গ্রহণ করা হবে নাকি প্রত্যাখ্যান করা হবে, সেই সিদ্ধান্ত নেওয়া হয়।

Memcached-এর ক্ষেত্রে, ডেমনটি ইনস্টল করা হয় (apt-get install memcached) এবং একটি কী (key), যেমন authorized , আমাদের কাঙ্ক্ষিত আইপি অ্যাড্রেস দিয়ে লোড করা হয়। আমরা একটি সাধারণ echo এবং netcat ব্যবহার করে এটি করতে পারি, এবং তারপর একটি get কমান্ডের মাধ্যমে যাচাই করে নিতে পারি যে মানটি সঠিকভাবে সংরক্ষিত হয়েছে। এরপর, NFQUEUE প্রোগ্রামটি প্যাকেট আইডি পাওয়ার পাশাপাশি NFQNL_COPY_PACKET ব্যবহার করে সম্পূর্ণ প্যাকেটটি গ্রহণ করে , আইপি হেডারটি (struct iphdr) বের করে নেয়, এবং inet_ntop ব্যবহার করে সোর্স অ্যাড্রেসটিকে একটি স্ট্রিং-এ রূপান্তর করে।

প্রতিটি প্যাকেটের সাথে সংযোগ খোলার সময় অপচয় এড়াতে, মেমক্যাশড সংযোগটি শুধুমাত্র একবার মেইন মেথডে (memcached_create, memcached_server_list_append, memcached_server_push) ইনিশিয়ালাইজ করা হয় এবং হ্যান্ডলারটি গ্লোবাল ভেরিয়েবলে সংরক্ষণ করা হয়। কলব্যাকে, কাঙ্ক্ষিত কী (key) দিয়ে memcached_get কল করা হয়, সোর্স আইপি অ্যাড্রেসটি প্রাপ্ত মানের সাথে তুলনা করা হয়, এবং যদি তারা মিলে যায়, তাহলে NF_ACCEPT রিটার্ন করা হয়; অন্যথায়, NF_DROP রিটার্ন করা হয়। যদি কী-টি বিদ্যমান না থাকে বা কোনো ত্রুটি থাকে, তবে একটি রক্ষণশীল নীতি হিসেবে প্যাকেটটি ড্রপ করা হয়।

iperf ব্যবহার করলে, এই কৌশলটি একটি গিগাবিট নেটওয়ার্কে থ্রুপুট প্রায় ১৪০ মেগাবিট/সেকেন্ডে কমিয়ে দেয় এবং দেখা যায় যে কিউ-তে লস বা ক্ষতি হতে শুরু করে (যা, উদাহরণস্বরূপ, কোডের মধ্যেই থাকা সিম্বলের মাধ্যমে নির্দেশিত হয়)। অন্য কথায়, প্রতি প্যাকেটের জন্য একটি ক্যাশ সার্ভিস কল করার ফলেই একটি উল্লেখযোগ্য খরচ হয়, যদিও অপ্টিমাইজ করা হলে মাঝারি ট্র্যাফিক ভলিউমের জন্য এটি কার্যকর থাকে।

MySQL-এর ক্ষেত্রে পদ্ধতিটি একই রকম কিন্তু আরও জটিল: সার্ভার এবং ক্লায়েন্ট লাইব্রেরি ইনস্টল করা হয়, authorized(ip varchar(50)) নামের একটি সাধারণ টেবিল সহ একটি ডাটাবেস (উদাহরণস্বরূপ, nfqueue) তৈরি করা হয় এবং অনুমোদিত আইপি অ্যাড্রেসটি ইনসার্ট করা হয়। প্রোগ্রামে, স্টার্টআপের সময় `mysql_init` এবং `mysql_real_connect` চালানো হয় , এবং কলব্যাকে, `select * from authorized where ip like 'xxxx'`-এর মতো একটি কোয়েরি তৈরি করা হয়। যদি কোয়েরিটি সফলভাবে এক্সিকিউট হয় এবং একটি রো খুঁজে পাওয়া যায়, তাহলে প্যাকেজটি গ্রহণ করা হয়; অন্যথায়, এটি বাতিল করা হয়।

MySQL কোয়েরি ক্যাশিং চালু থাকলে পরীক্ষায় প্রায় ১৮৮ মেগাবিট/সেকেন্ড গতি পাওয়া যায় , যা কোয়েরি ক্যাশিং বন্ধ করলে কমে ১০৩ মেগাবিট/সেকেন্ডে নেমে আসে। এই সংখ্যাগুলো গিগাবিট থেকে অনেক কম হলেও, তা প্রমাণ করে যে সবচেয়ে সাদামাটা পদ্ধতিতেও (সিঙ্গেল-থ্রেডেড, অপটিমাইজেশন ছাড়া) ডাটাবেস-চালিত বা ক্যাশিং-ভিত্তিক সিদ্ধান্তের মাধ্যমে যথেষ্ট পরিমাণ ট্র্যাফিক সামলানো সম্ভব।

কর্মক্ষমতা, মাল্টিথ্রেডিং এবং সিপিইউ ব্যবহার

iperf, Memcached, এবং MySQL দিয়ে করা পরীক্ষাগুলো স্পষ্টভাবে দেখায় যে, পারফরম্যান্সের সর্বোচ্চ সীমাটি মূলত NFQUEUE-এর নিজের দ্বারা ততটা নির্ধারিত হয় না, যতটা ইউজার স্পেসে আমরা যে লজিক যোগ করি এবং যেভাবে তা প্রয়োগ করি, তার দ্বারা নির্ধারিত হয়। একটি এক্সিকিউটেবল যা শুধুমাত্র NF_ACCEPT রিটার্ন করে, তা অনায়াসে প্রায় এক গিগাবিট গতি অর্জন করে; কিন্তু যেই মুহূর্তে আমরা I/O বা নেটওয়ার্ক কল যুক্ত করি, থ্রুপুট কমে যায় এবং NFQUEUE মেশিন, Memcached ডেমন বা MySQL-এর সিপিইউ তার সর্বোচ্চ সীমায় পৌঁছে যায়।

স্থাপত্যগত দৃষ্টিকোণ থেকে, এর দুটি তাৎপর্য রয়েছে। একদিকে, এটি নিশ্চিত করে যে বিপুল পরিমাণ ট্র্যাফিকের ক্ষেত্রে ফায়ারওয়ালের সিদ্ধান্ত ব্যবহারকারী অ্যাপ্লিকেশনগুলোর ওপর ছেড়ে দেওয়া সম্পূর্ণ সম্ভব , যদি প্রতিটি কলের প্রকৃত খরচ বিবেচনায় রাখা হয়। অন্যদিকে, এটি প্রমাণ করে যে প্ল্যাটফর্মের সর্বোচ্চ সক্ষমতার কাছাকাছি পৌঁছাতে হলে মাল্টিথ্রেডিং বা মাল্টিপ্রসেসিং অবশ্যই বিবেচনা করতে হবে । NFQUEUE একাধিক কিউ-এর মধ্যে ট্র্যাফিক বিতরণের সুযোগ দেয়; আমরা আমাদের অ্যাপের একাধিক কপি চালু করতে পারি, যার প্রতিটি ভিন্ন ভিন্ন কিউ-তে লিসেন করবে, এবং pthreads বা ব্যাপক ফোর্কের ঝামেলা ছাড়াই একাধিক কোরের সুবিধা নিতে পারি।

আরেকটি সুস্পষ্ট অপ্টিমাইজেশন হতে পারে NFQUEUE-এর মধ্য দিয়ে কোন ট্র্যাফিক যাবে তা সীমিত করা । পরীক্ষাগুলোতে, সম্পূর্ণ iperf ফ্লো-টি কিউতে জমা হচ্ছিল, কিন্তু বাস্তব পরিস্থিতিতে, আমরা কেবল NEW স্টেটের প্যাকেটগুলোকে কিউতে রাখতে পারি, ESTABLISHED/RELATED প্যাকেটগুলোকে যেতে দিতে পারি, এবং এই ব্যয়বহুল লজিকটি লগইন বা সন্দেহজনক প্যাটার্নের জন্য সংরক্ষিত রাখতে পারি।

পরিশেষে, CPU ব্যবহার এবং থ্রেড ডিজাইন গুরুত্বপূর্ণ: যদি ব্যবহারকারীর প্রক্রিয়াটি সংক্ষিপ্ত হয়, তাহলে সারিটি পূর্ণ হয়ে যায় এবং আমাদের ফেইল-ওপেন বা ড্রপ গ্রহণের মতো জিনিসগুলি অবলম্বন করতে হয়, যার ফলে এই পদ্ধতির লক্ষ্যবস্তুতে থাকা সূক্ষ্ম নিয়ন্ত্রণের কিছুটা অংশ হারিয়ে যায়।

নেটফিল্টার ব্র্যান্ডিং সহ গতিশীল রাউটিং

NFQUEUE শুধুমাত্র "accept" বা "throw" বলার মধ্যেই সীমাবদ্ধ নয়। এটি প্যাকেটে নেটফিল্টার (fwmark) ফ্ল্যাগ প্রয়োগ করতে এবং সেগুলোকে ip rule ও iproute2-এর সাথে একত্রিত করে অত্যন্ত নমনীয়, প্রায় লাইটওয়েট VRF-ধাঁচের পলিটিক্যাল রাউটিং স্কিম তৈরি করতেও ব্যবহার করা যায়।

মোটামুটিভাবে বলতে গেলে, পদ্ধতিটি হলো: /etc/iproute2/rt_tables- এ কয়েকটি রাউটিং টেবিল সংজ্ঞায়িত করা , যেমন স্লো এবং ফাস্ট; প্রতিটি টেবিলকে একটি ভিন্ন ডিফল্ট রুট বরাদ্দ করা (একটি ফাইবারের মাধ্যমে এবং অন্যটি আরও সীমিত লিঙ্কের মাধ্যমে); আইপি রুল ব্যবহার করে নির্দিষ্ট করা যে fwmark 1 যুক্ত প্যাকেটগুলো ফাস্ট টেবিলে যাবে, fwmark 2 যুক্তগুলো স্লো টেবিলে যাবে, ইত্যাদি; এবং সবশেষে, ভারডিক্ট ফেরত দেওয়ার আগে NFQUEUE ব্যবহার করে প্যাকেটগুলোকে যথাযথভাবে চিহ্নিত করা ।

কলব্যাক থেকে একটি ভারডিক্ট সেট করার জন্য `nfq_set_verdict2` ব্যবহৃত হয় , যা `nfq_set_verdict`-এর মতোই, কিন্তু এটি আপনাকে এমন একটি ভারডিক্ট ভ্যালু সেট করার সুযোগ দেয় যা `ip rule` পরবর্তীতে দেখতে পাবে। এই সবকিছুকে একত্রিত করে, আপনি এমন একটি আইপি রাউটার তৈরি করতে পারেন যা যেকোনো মানদণ্ডের উপর ভিত্তি করে রাউট করার সিদ্ধান্ত নেয়: যেমন জোড়/বিজোড় প্যাকেট সাইজের মতো অদ্ভুত বিষয় থেকে শুরু করে ট্র্যাফিক প্রেডিকশন অ্যালগরিদম, সোশ্যাল মিডিয়া ইভেন্ট বা মনিটরিং সিস্টেম থেকে পাওয়া সিগন্যালের মতো বাহ্যিক ইনপুট পর্যন্ত ।

এর ফলে এমন একটি সিস্টেম তৈরি হয় যেখানে কার্নেল স্বাভাবিক হারে প্যাকেট ফরওয়ার্ড করতে থাকে, কিন্তু প্রতিটি ফ্লো কোন পথে যাবে সেই দায়িত্ব বাহ্যিক সফটওয়্যারের ওপর ছেড়ে দেওয়া হয়, যা স্ট্যাটিক নিয়ম পরিবর্তন না করেই রিয়েল টাইমে তার সিদ্ধান্ত বদলাতে পারে।

NFQUEUE এবং Suricata: GNU/Linux-এ উচ্চ-স্তরের IPS

উপরের সবগুলোই C-তে হাতে প্রোগ্রাম করা যায়, কিন্তু যখন অনুপ্রবেশ শনাক্তকরণ এবং ডিপ প্যাকেট ইন্সপেকশনের প্রশ্ন আসে, তখন সাধারণত একটি উন্নত IDS/IPS ইঞ্জিনের উপর নির্ভর করাই বুদ্ধিমানের কাজ । এখানেই সুরিকাটার আগমন, যার জন্মই হয়েছিল স্নর্টের একটি মাল্টি-প্রসেস বিকল্প হিসেবে, যাতে শুরু থেকেই IPS সক্ষমতা রয়েছে এবং যা বর্তমানে উপলব্ধ অসংখ্য সিপিইউ কোরকে কাজে লাগানোর উপর বিশেষভাবে মনোনিবেশ করে ।

সুরিকাটা সম্পূর্ণ নতুনভাবে লেখা হয়েছে এবং GPLv2 লাইসেন্সের অধীনে বিতরণ করা হয় ; ওপেন ইনফরমেশন সিকিউরিটি ফাউন্ডেশন (OISF) এর ইঞ্জিন এবং নিয়ম ও ডকুমেন্টেশনের একটি বেশ ব্যাপক ইকোসিস্টেম রক্ষণাবেক্ষণ করে। স্নর্ট ২.এক্স-এর মতো নয়, যেটি একটি সিঙ্গেল-থ্রেডেড কোর পেয়েছিল এবং তার উপর প্যাচ করা হয়েছিল, সুরিকাটাকে একাধিক থ্রেডের মধ্যে কাজের চাপ ভাগ করে দেওয়ার জন্য ডিজাইন করা হয়েছিল: ক্যাপচার, ডিকোডিং, ডিটেকশন এবং আউটপুট, যেখানে বিভিন্ন লোড-শেয়ারিং কৌশল ব্যবহার করা হয়।

কার্যকরী পর্যায়ে, সুরিকাটা IPv6-এর জন্য নেটিভ সাপোর্ট, লেয়ার ৭ ইন্সপেকশন (HTP লাইব্রেরির মাধ্যমে অত্যন্ত উন্নত HTTP), পোর্ট-নিরপেক্ষ প্রোটোকল শনাক্তকরণ , ফ্লো রিকনস্ট্রাকশন এবং একাধিক TCP কানেকশনে ছড়িয়ে থাকা একটি আক্রমণের বিভিন্ন পর্যায়কে সম্পর্কযুক্ত করার জন্য সেশন ভ্যারিয়েবলের (ফ্লোবিটস) একটি অত্যন্ত শক্তিশালী সিস্টেম প্রদান করে।

এর একটি অতিরিক্ত শক্তি হলো Snort রুলসের সাথে এর সামঞ্জস্যতা এবং Sourcefire VRT ও Emerging Threats সিগনেচার সেট (ফ্রি ET Open এবং বাণিজ্যিক ET Pro সংস্করণ) উভয়ই ব্যবহার করার ক্ষমতা। অধিকন্তু, এটি SIEM, ELK, Splunk এবং অন্যান্য সিস্টেমের সাথে ইন্টিগ্রেশনের জন্য ইভেন্টগুলোকে অত্যন্ত দরকারি ফরম্যাটে (fast.log, eve.json-এ JSON) এক্সপোর্ট করে।

লিনাক্সে আইপিএস হিসেবে সুরিকাটা: ক্যাপচার মোড এবং এনএফকিউইইউ

GNU/Linux-এ, ট্র্যাফিক কীভাবে ইন্টারসেপ্ট করা হচ্ছে তার উপর নির্ভর করে Suricata বিভিন্ন মোডে কাজ করতে পারে: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … প্রত্যেকটির নিজস্ব সুবিধা এবং প্রয়োজনীয়তা রয়েছে। বিশুদ্ধ IPS স্তরে, সবচেয়ে গুরুত্বপূর্ণ দুটি হলো NFQUEUE এবং AF_PACKET।

NFQ (NFQUEUE) মোডে , কার্যপ্রবাহটি পূর্বে বর্ণিতটির মতোই: একগুচ্ছ iptables নিয়ম প্যাকেটগুলোকে একটি কিউ-তে পাঠায়; ইউজার স্পেসে চলমান Suricata সেই কিউ থেকে পড়ে, তার নিয়ম অনুযায়ী বিষয়বস্তু পরীক্ষা করে এবং কার্নেলকে একটি সিদ্ধান্ত ফেরত পাঠায়: NF_ACCEPT, NF_DROP, বা NF_REPEAT। অতিরিক্ত চিহ্ন বা পরিবর্তন প্রয়োগ করার পর প্যাকেটটিকে একই iptables টেবিলে পুনরায় অন্তর্ভুক্ত করতে তৃতীয়টি ব্যবহার করা যেতে পারে।

এই মোডটি খুবই নমনীয় এবং বিদ্যমান পরিকাঠামোতে প্রয়োগ করা সহজ , কারণ এর জন্য শুধুমাত্র নির্দিষ্ট কিছু পয়েন্টে (যেমন, ফরওয়ার্ড, ইনপুট, আউটপুট) নিয়মগুলো পরিবর্তন করতে হয় এবং বাকি সবকিছু অপরিবর্তিত রাখতে হয়। এর অসুবিধা হলো NFQUEUE-এর মধ্য দিয়ে প্যাকেট আদান-প্রদানের অতিরিক্ত ওভারহেড, যার প্রভাব পূর্বেই উল্লেখিত হয় যদি প্যাকেটের পরিমাণ খুব বেশি হয় অথবা নিয়মগুলো রিসোর্স-ইনটেনসিভ হয়।

AF_PACKET মোডে , সুরিকাটা নেটওয়ার্ক ইন্টারফেসের কাছাকাছি কাজ করে এবং AF_PACKET সকেটের মাধ্যমে প্যাকেট কপি করে। এটি একটি অনেক দ্রুততর জিরো-কপি পদ্ধতি , কিন্তু এর জন্য সিস্টেমটিকে দুটি ইন্টারফেসসহ একটি গেটওয়ে হিসেবে কাজ করতে হয় এবং NIC-গুলোর মধ্যে ফরওয়ার্ডিং পর্যায়ে ট্র্যাফিক ব্লক করতে হয়: অর্থাৎ, যে প্যাকেটটি ব্লক করতে হবে, সেটি ইনপুট ইন্টারফেস থেকে আউটপুট ইন্টারফেসে পাঠানো হয় না।

উভয় মোডেই সুরিকাটাকে নেটফিল্টারের সাথে যুক্ত করা যায়, কিন্তু NFQUEUE বিশেষত সেইসব পরিস্থিতিতে ভালোভাবে কাজ করে যেখানে আমরা সমস্ত iptables লজিক (পলিসি, রেঞ্জ, পূর্ববর্তী রুল) পুনরায় ব্যবহার করতে চাই এবং শুধুমাত্র সেই ট্র্যাফিক সুরিকাটাতে পাঠাতে চাই যা আমরা গভীরভাবে পরীক্ষা করতে আগ্রহী।

সোর্স কোড থেকে সুরিকাটার মৌলিক ইনস্টলেশন

যারা প্যাকেজ ব্যবহার না করে সুরিকাটা কম্পাইল করতে পছন্দ করেন, তাদের জন্য ডেবিয়ান/উবুন্টু-ধরনের ডিস্ট্রিবিউশনগুলিতে প্রক্রিয়াটি হলো প্রথমে কম্পাইলেশন ডিপেন্ডেন্সিগুলি (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev, ইত্যাদি) ইনস্টল করা, অফিসিয়াল ওয়েবসাইট থেকে টারবলটি ডাউনলোড করা এবং ক্লাসিক ./configure, make, make install চালানো ।

কনফিগার করার পর্যায়ে, স্ক্রিপ্টটি নির্দেশ করবে কোন কোন সাপোর্ট ফিচার চালু করা হয়েছে: AF_PACKET হ্যাঁ/না, PF_RING, NFQUEUE হ্যাঁ/না, NFLOG, IPFW, libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP ইত্যাদির জন্য সাপোর্ট। যদি আমরা সেই মোডে কাজ করতে চাই , তবে NFQUEUE চালু আছে কিনা এবং আমাদের কাঙ্ক্ষিত ক্যাপচার লাইব্রেরিটি খুঁজে পাওয়া গেছে কিনা, তা যাচাই করা জরুরি।

বাইনারিটি ইনস্টল করার পরে, আপনি `/etc/suricata`-তে একটি ডিফল্ট কনফিগারেশন স্থাপন করতে `make install-conf` এবং `/etc/suricata/rules`-এ এক সেট উদীয়মান হুমকি (Emerging Threats) নিয়ম ডাউনলোড ও স্থাপন করতে `make install-rules` চালাতে পারেন। এরপর `suricata-update`-এর মতো টুল ব্যবহার করে এই সেটগুলি আপডেট করা যেতে পারে।

Red Hat/CentOS সিস্টেমে কার্যপ্রণালীটি একই রকম; এক্ষেত্রে ডিপেন্ডেন্সিগুলোর (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel, ইত্যাদি) জন্য yum বা dnf ব্যবহার করা হয় এবং তারপর একই ধাপগুলো অনুসরণ করে কম্পাইল করা হয়। পারফরম্যান্সের কারণে, ethtool ব্যবহার করে ক্যাপচার ইন্টারফেসে LRO/GRO নিষ্ক্রিয় করে রাখাও বাঞ্ছনীয় , কারণ এই অফলোড ফাংশনগুলো IDS পর্যায়ে প্যাকেজগুলোর দৃশ্যমানতাকে প্রভাবিত করতে পারে।

সুরিকাটা কনফিগারেশন: YAML, ভেরিয়েবল এবং থ্রেডিং

সুরিকাটার প্রধান কনফিগারেশন /etc/suricata/suricata.yaml ফাইলে থাকে । এটি বেশ পাঠযোগ্য এবং প্রচুর মন্তব্যসহ একটি YAML ফাইল, যেখানে লগ পাথ এবং রুল সেট থেকে শুরু করে টার্গেট অপারেটিং সিস্টেম পলিসি এবং থ্রেডিং প্যারামিটার পর্যন্ত সবকিছু সংজ্ঞায়িত করা হয়।

মৌলিক ফিল্ডগুলোর মধ্যে একটি হলো `default-log-dir` , যা নির্দিষ্ট করে দেয় লগ ফাইলগুলো কোথায় সংরক্ষিত হবে (ডিফল্টরূপে, `/var/log/suricata`)। `vars` সেকশনের অধীনে `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS`, এবং `SSH_PORTS`-এর মতো ভ্যারিয়েবল রয়েছে, যেগুলো রুলগুলোতে সংক্ষিপ্ত রূপ হিসেবে কাজ করে। `HOME_NET` সাধারণত সেই লোকাল নেটওয়ার্ক রেঞ্জ দিয়ে কনফিগার করা হয় যাকে আমরা সুরক্ষিত করতে চাই, অন্যদিকে `EXTERNAL_NET` সাধারণত `!HOME_NET` হিসেবে সংজ্ঞায়িত করা হয়।

এর আরেকটি গুরুত্বপূর্ণ অংশ হলো হোস্ট-ওএস-পলিসি (host-os-policy) , যা সুরিকাটাকে (Suricata) বলে দেয় যে নির্দিষ্ট আইপি রেঞ্জগুলোতে কোন অপারেটিং সিস্টেম চলবে। এর ফলে এটি টিসিপি (TCP) কীভাবে পুনর্বিন্যাস করবে বা নির্দিষ্ট নেটওয়ার্ক স্ট্যাকের আচরণ কীভাবে ব্যাখ্যা করবে, তা সামঞ্জস্য করতে পারে । এতে স্ট্যাকের পার্থক্যের (যেমন উইন্ডোজ বনাম লিনাক্স ইত্যাদি) উপর ভিত্তি করে প্রোটোকল এড়ানো আরও কঠিন হয়ে পড়ে। নির্দিষ্ট রেঞ্জগুলোকে উইন্ডোজ, লিনাক্স, বিএসডি, ভিস্তা, উইন্ডোজ ২০০৩ ইত্যাদির মতো ক্যাটাগরিতে ভাগ করা যায়।

থ্রেডিং প্রসঙ্গে, থ্রেডিং সেকশনটি আপনাকে সিপিইউ অ্যাফিনিটি এবং ডিটেকশন থ্রেডের সংখ্যা সূক্ষ্মভাবে নিয়ন্ত্রণ করার সুযোগ দেয়। ডিফল্টরূপে, `set-cpu-affinity` সাধারণত নিষ্ক্রিয় থাকে, যা সিস্টেম শিডিউলারকে কোরগুলোর মধ্যে থ্রেডগুলো বন্টন করতে দেয়। `detect-thread-ratio` প্যারামিটারটি নির্দেশ করে যে প্রতিটি উপলব্ধ কোরের জন্য কতগুলো ডিটেকশন থ্রেড তৈরি করা হবে; একটি ৮-কোরের মেশিনে `detect-thread-ratio: 1.5` সেট করা থাকলে, সুরিকাটা ১২টি ডিটেকশন থ্রেড তৈরি করবে, সাথে ক্যাপচার এবং ম্যানেজমেন্ট থ্রেডও থাকবে।

ডেমনটি চালু হলে এই সম্পূর্ণ মডেলটি আউটপুটে প্রতিফলিত হয়: ফ্লো ম্যানেজার এবং স্ট্যাটিস্টিকস ম্যানেজারের পাশাপাশি একটি ক্যাপচার থ্রেড (যেমন, pcap) এবং একাধিক ডিটেক্টর থ্রেডও দেখা যায়। এই মাল্টি-প্রসেস আর্কিটেকচারের কারণেই সুরিকাটা ১০/৪০ গিগাবিট/সেকেন্ড লিঙ্কের ক্ষেত্রে সিঙ্গেল-থ্রেডেড ইঞ্জিনের চেয়ে অনেক ভালোভাবে স্কেল করতে পারে ।

সুরিকাটাতে নিয়ম এবং স্বাক্ষর আপডেট

সুরিকাটা আক্রমণের ধরণ, অস্বাভাবিক আচরণ এবং প্রোটোকলের অপব্যবহার শনাক্ত করতে রুল সেটের উপর নির্ভর করে। স্নর্ট ফরম্যাটে রুল গ্রহণ করার পাশাপাশি , এর সবচেয়ে প্রচলিত ইকোসিস্টেমটি হলো উদীয়মান হুমকির (Emerging Threats) ইকোসিস্টেম: ইটি ওপেন (বিনামূল্যে) এবং ইটি প্রো (বাণিজ্যিক), যার রুলগুলো বর্তমান হুমকিগুলোর জন্য বিশেষভাবে তৈরি।

অনেক আধুনিক ডিস্ট্রিবিউশনে `suricata-update` টুলটি অন্তর্ভুক্ত থাকে , যা রুল ম্যানেজমেন্টকে সহজ করে তোলে: এটি সোর্স আপডেট করে, নির্দিষ্ট প্রোভাইডারদের সক্ষম বা অক্ষম করে এবং সিগনেচার সেটের সর্বশেষ সংস্করণ ডাউনলোড করে। একটি সাধারণ ওয়ার্কফ্লো হলো `suricata-update` ইনস্টল করা (উদাহরণস্বরূপ, pip-এর মাধ্যমে), ET Open ডাউনলোড করার জন্য প্রথম `suricata-update` চালানো, `suricata-update list-sources` দিয়ে সোর্সগুলোর তালিকা দেখা, `ptresearch/attackdetection`, `oisf/trafficid`, বা `sslbl/ssl-fp-blacklist`-এর মতো অতিরিক্ত সোর্সগুলো সক্ষম করা, এবং রুলস ফাইলটি পুনরায় তৈরি করার জন্য আবার `suricata-update` চালানো।

suricata.yaml ফাইলটিকে সঠিক রুলস পাথের দিকে নির্দেশ করার জন্য পরিবর্তন করা হয়, এবং সেখান থেকে Suricata অ্যালার্ট ইভেন্ট তৈরি করা শুরু করবে যা fast.log (দ্রুত, পাঠযোগ্য টেক্সট) এবং eve.json (খুব সম্পূর্ণ তথ্য সহ স্ট্রাকচার্ড JSON) ফাইলে লগ করা হবে । এই শেষোক্ত ফরম্যাটটি ড্যাশবোর্ড, কোরিলেশন সিস্টেম বা কাস্টম স্ক্রিপ্টে ডেটা সরবরাহের জন্য বিশেষভাবে উপযোগী।

সিগনেচারের পাশাপাশি, সুরিকাটা একাধিক প্রোটোকলের জন্য ডিকোডার এবং পার্সার অন্তর্ভুক্ত করে , যার ফলে এটি পোর্টের উপর কম নির্ভরশীল হয়: এটি নন-স্ট্যান্ডার্ড পোর্টের মাধ্যমে গেলেও HTTP ট্র্যাফিক শনাক্ত করতে পারে এবং বিভিন্ন পোর্ট ও এনক্যাপসুলেশন লেভেলে (মিশ্র IPv4/IPv6 টানেল সহ) SSH, TLS, DNS ইত্যাদি সনাক্ত করতে পারে।

ব্যবহারিক ব্যবহার: ওয়েব শোষণ সনাক্তকরণ থেকে শুরু করে স্বয়ংক্রিয় ব্লকিং পর্যন্ত

হোস্টিং পরিবেশ বা ডেটা সেন্টারে সবচেয়ে কাঙ্ক্ষিত ব্যবহারগুলোর মধ্যে একটি হলো ওয়েব অ্যাপ্লিকেশন (যেমন, ওয়ার্ডপ্রেস এবং এর প্লাগইন)-এর দুর্বলতা কাজে লাগানোর প্রচেষ্টা রিয়েল টাইমে শনাক্ত করা এবং স্বয়ংক্রিয়ভাবে প্রতিক্রিয়া জানানো, যা সাধারণত ফায়ারওয়ালে উৎস আইপি ব্লক বা ব্ল্যাকলিস্ট করার মাধ্যমে করা হয়।

সুরিকাটা, হালনাগাদ করা নিয়ম দ্বারা চালিত হয়ে, ইউআরএল, প্যারামিটার, এইচটিটিপি পেলোড, এবং এমনকি পরিচিত এক্সপ্লয়েটের সাথে মিলে যাওয়া রিকোয়েস্ট সিকোয়েন্সের বিরুদ্ধে নির্দিষ্ট অ্যাটাক প্যাটার্ন শনাক্ত করতে সক্ষম । এই আইডিএস প্যাসিভ মোডে কাজ করতে পারে এবং একটি সুইচ পোর্ট (SPAN) থেকে মিররিংয়ের মাধ্যমে ট্র্যাফিক গ্রহণ করতে পারে, কিন্তু একটি আইপিএস হিসেবে কাজ করতে এবং অ্যাটাক ব্লক করতে হলে, এটিকে ফরওয়ার্ডিং প্লেনের সাথে ইন্টিগ্রেট করতে হয়।

দুটি প্রচলিত পদ্ধতি রয়েছে: IDS-কে একটি অনলাইন ব্রিজ হিসেবে সেট আপ করা, যাতে ট্র্যাফিক ফিজিক্যালি মেশিনটির মধ্য দিয়ে যায় (প্ল্যাটফর্মের উপর নির্ভর করে iptables, AF_PACKET, বা PF ব্যবহার করে), অথবা টপোলজি অপরিবর্তিত রেখে API, স্ক্রিপ্ট, বা NFQUEUE-এর মাধ্যমে সেন্ট্রাল ফায়ারওয়ালের অ্যাকশনের সাথে মিররিং-কে একত্রিত করা । প্রথম পদ্ধতিটি ডিটেকশন এবং ব্লকিং-এর মধ্যবর্তী ল্যাটেন্সি কমিয়ে আনে, তবে এর জন্য নেটওয়ার্কের "মাঝখানে" আরেকটি উপাদান যুক্ত করতে হয়; দ্বিতীয়টি অধিকতর নমনীয়তা এবং স্থিতিস্থাপকতা প্রদান করে, কিন্তু অর্কেস্ট্রেশনে আরও জটিলতা নিয়ে আসে।

একটি ইন্ট্রুশন ডিটেকশন সিস্টেম (IDS)-এর পক্ষে কোনো দুর্বল ওয়ার্ডপ্রেস প্লাগইন কাজে লাগানোর প্রচেষ্টা শনাক্ত করা এবং তারপর সরাসরি বা কোনো সংশ্লিষ্ট উপাদানের মাধ্যমে আক্রমণকারীর আইপি অ্যাড্রেসকে একটি iptables ব্ল্যাকলিস্টে যুক্ত করা সম্পূর্ণ সম্ভব। এটি Suricata-র JSON আউটপুট এবং iptables/nftables কল করা স্ক্রিপ্টের মাধ্যমে করা যেতে পারে , অথবা এর কিছু লজিক NFQUEUE-এর উপর অর্পণ করেও করা যায়, যেখানে ইঞ্জিনটি নিজে বা এর সাথে যুক্ত কোনো প্রসেস বাইরের কোনো তালিকা আপডেট হওয়ার জন্য অপেক্ষা না করেই তাৎক্ষণিকভাবে সিদ্ধান্ত নেয়।

এটি আপনাকে এমন হুমকির উপর মনোযোগ দিতে সাহায্য করে যা সত্যিই গুরুত্বপূর্ণ (শোষণ, বর্ধনের প্রচেষ্টা, খুব আক্রমণাত্মক স্ক্যান), বেসিক পোর্ট স্ক্যানের মতো ব্যাকগ্রাউন্ড নয়েজ উপেক্ষা করে বা কেবল লগ করে, যা অনেক প্রসঙ্গে নিজেরাই উদ্বেগজনক নয়।

Pfsense-এ Suricata: ইন্টিগ্রেটেড IDS/IPS সহ ওপেনসোর্স ফায়ারওয়াল

পালো অল্টোর মতো একটি প্রোপাইটারি হাই-এন্ড ফায়ারওয়াল কেনার সামর্থ্য সবার থাকে না বা সবাই তা কিনতে চায়ও না। অনেক ক্ষেত্রে, pfSense এবং Suricata-এর মতো ওপেন-সোর্স সলিউশন সেট আপ করা বেশি আকর্ষণীয় , যা উন্নত ফায়ারওয়ালের চাহিদা (মাল্টি-ওয়ান, ভিল্যান, ভিপিএন, ন্যাট, ইত্যাদি) এবং IDS/IPS উভয়ই পূরণ করে।

FreeBSD এবং Packet Filter-এর উপর ভিত্তি করে তৈরি Pfsense, ভার্চুয়ালাইজড এনভায়রনমেন্টের (Proxmox, KVM, ইত্যাদি) সাথে বিশেষভাবে ভালোভাবে কাজ করে। তবে এর একটি ব্যতিক্রম হলো, লোডের কারণে পারফরম্যান্সের সমস্যা এবং ক্র্যাশ এড়াতে চাইলে KVM মেশিনে Virtio-এর পরিবর্তে E1000 কার্ড ব্যবহার করার পরামর্শ দেওয়া হয় , যদি না আপনি Netgate-এর সুপারিশগুলো অনুসরণ করেন (System > Advanced > Networking-এ হার্ডওয়্যার চেকসাম অফলোড নিষ্ক্রিয় করে রিস্টার্ট করুন; তবে মনে রাখবেন, খুব বেশি লোডের ক্ষেত্রে এটি যথেষ্ট নাও হতে পারে)।

Pfsense-এ Suricata সহ একটি ল্যাবের জন্য ন্যূনতম হার্ডওয়্যারের প্রয়োজনীয়তা সামান্যই হতে পারে (১টি ৫০০ মেগাহার্টজ সিপিইউ, ১ জিবি র‍্যাম, ৪ জিবি ডিস্ক), কিন্তু গুরুত্বপূর্ণ ব্যবহারের জন্য কমপক্ষে ২টি সিপিইউ, ৪ জিবি র‍্যাম এবং ১৬ জিবি স্টোরেজ রাখার পরামর্শ দেওয়া হয় । সেই সাথে একাধিক নেটওয়ার্ক ইন্টারফেস থাকাও জরুরি (একটি WAN-এর জন্য, আরেকটি LAN-এর জন্য; এবং একাধিক WAN বা জটিল VLAN চাইলে আরও বেশি)।

pfSense ইনস্টল করা খুব দ্রুত: আপনি ISO থেকে বুট করেন, লাইসেন্স গ্রহণ করেন, ইনস্টল করার জন্য নির্বাচন করেন, আপনার ভাষা এবং কীবোর্ড লেআউট নির্বাচন করেন, পার্টিশনটি স্বয়ংক্রিয়ভাবে ছেড়ে দেন (যদি আপনি সম্পূর্ণ ডিস্ক ব্যবহার করতে চান তবে অটো UFS), এবং কয়েক মিনিটের মধ্যে সিস্টেমটি তার প্রথম বুটের জন্য প্রস্তুত। কনসোলটি ইন্টারফেস বরাদ্দ, পুনরায় চালু, শেল চালু ইত্যাদির জন্য একটি মেনু অফার করে।

ল্যাবে, যেমন VirtualBox-এ, WAN-এর মাধ্যমে ওয়েব ইন্টারফেসে প্রবেশ করতে (ইউজারনেম admin, পাসওয়ার্ড pfsense) এবং প্রাথমিক উইজার্ডটি সম্পন্ন করার জন্য কনসোল থেকে pfctl -d কমান্ডের মাধ্যমে Pfsense ফায়ারওয়ালটি সাময়িকভাবে নিষ্ক্রিয় করা একটি সাধারণ পদ্ধতি । এই উইজার্ডের ধাপগুলো হলো: সাধারণ ডেটা, NTP সার্ভার, WAN কনফিগারেশন (ল্যাবে সাধারণত DHCP-ই যথেষ্ট), LAN, অ্যাডমিন পাসওয়ার্ড পরিবর্তন এবং কনফিগারেশন প্রয়োগ।

অ্যাক্সেস স্থিতিশীল হয়ে গেলে, আপনি WAN ফায়ারওয়ালে একটি নিয়ম তৈরি করতে পারেন যা যেকোনো উৎস থেকে pfsense IP অ্যাড্রেসে HTTPS-এর অনুমতি দেবে এবং নিয়মগুলোকে দৃশ্যত সংগঠিত করার জন্য বর্ণনামূলক বিভাজক যোগ করতে পারেন (উদাহরণস্বরূপ, "ফায়ারওয়াল অ্যাক্সেস")। এছাড়াও, আপনি যদি RFC1918 অ্যাড্রেসযুক্ত কোনো টেস্ট এনভায়রনমেন্টে থাকেন, তবে WAN-এ প্রাইভেট নেটওয়ার্ক ব্লক করার অপশনটি নিষ্ক্রিয় করে রাখাই শ্রেয় , যাতে আপনাকে ক্রমাগত `pfctl -d` ব্যবহার করতে না হয়।

pfSense-এ Suricata ইনস্টলেশন এবং ওভারভিউ

pfSense বেস চালু হয়ে গেলে, Suricata ইনস্টল করা খুবই সহজ। এর জন্য আপনাকে শুধু System > Package Manager > Available Packages- এ গিয়ে Suricata খুঁজে বের করে প্যাকেজটি ইনস্টল করতে হবে। এই প্রক্রিয়ায় বেশ কয়েকটি ফাইল ডাউনলোড হয় এবং আপনার হার্ডওয়্যারের ওপর নির্ভর করে এতে কিছুটা সময় লাগতে পারে, তবে ওয়েব ইন্টারফেসের মাধ্যমে এতে সম্পূর্ণ সহায়তা পাওয়া যায়।

একবার ইনস্টল হয়ে গেলে, সার্ভিসেস ট্যাবে একটি সুরিকাটা এন্ট্রি দেখা যায়, যেখানে আপনি ইন্টারফেস (WAN, LAN, VLAN, ইত্যাদি) অনুযায়ী ইনস্ট্যান্স কনফিগার করতে পারেন, কোন রুল সেট ব্যবহার করবেন তা বেছে নিতে পারেন, IDS বা IPS মোড সক্রিয় করতে পারেন এবং পারফরম্যান্স ও লগিং প্যারামিটার অ্যাডজাস্ট করতে পারেন। অপশনের পরিসর ব্যাপক (শুধু কনফিগারেশনের উপরই পুরো আর্টিকেল লেখার মতো), কিন্তু সুবিধা হলো, লিনাক্সে যেসব কাজের জন্য ম্যানুয়াল YAML এডিটিং-এর প্রয়োজন হয়, তার অনেক কিছুই এখানে ফর্ম এবং চেকবক্সের মাধ্যমে সম্পন্ন করা হয়।

গুরুত্বপূর্ণ দ্রষ্টব্য: ল্যাব পরিবেশে pfSense অ্যাডমিনিস্ট্রেশন সরাসরি ইন্টারনেটে উন্মুক্ত করে দেওয়ার প্রলোভন থাকলেও, প্রোডাকশনে স্ট্যাটিক আইপি অ্যাড্রেসে অ্যাক্সেস সীমাবদ্ধ রাখা, রিমোট ম্যানেজমেন্টের জন্য ভিপিএন ব্যবহার করা এবং যেকোনো মূল্যে ওয়েব কনসোলকে অরক্ষিত রাখা থেকে বিরত থাকা অত্যন্ত জরুরি । pfSense খুবই নমনীয়, কিন্তু এটিকে এর প্রকৃত গুরুত্বপূর্ণ ভূমিকা থেকেই বিবেচনা করতে হবে।

pfSense-এ Suricata সক্রিয় করা থাকলে, এমন একটি পরিবেশ তৈরি হয় যেখানে ট্র্যাফিক ফায়ারওয়ালিং এবং NAT-এর জন্য pfSense-এর মধ্য দিয়ে যায়, এবং Suricata তার নিজস্ব নিয়ম অনুযায়ী তা পরীক্ষা করে IPS মোডে ব্লক করতে পারে । একটিমাত্র ওয়েব ইন্টারফেস থেকে পরিচালিত এই সমন্বয়টি ছোট ও মাঝারি আকারের নেটওয়ার্কে DPI সুরক্ষা স্থাপনকে ব্যাপকভাবে সহজ করে তোলে।

অনেক স্থাপনার ক্ষেত্রে, এটি Pfsense/Suricata-এর সাথে একটি SIEM বা কেন্দ্রীভূত লগ প্ল্যাটফর্মের সংযোগ দ্বারা পরিপূরক হয়, যা ইভেন্টগুলির সাথে সম্পর্ক স্থাপন এবং বৃহত্তর প্রচারণা সনাক্ত করার জন্য কাঠামোগত আউটপুট ফর্ম্যাটের সুবিধা গ্রহণ করে।

সুরিকাটাতে ইভেন্ট পর্যবেক্ষণ এবং উদাহরণ লগ

একবার সুরিকাটা চালু হয়ে গেলে, ইভেন্টগুলি default-log-dir দ্বারা নির্ধারিত পাথে লগ করা হয়, যা সাধারণত /var/log/suricata হয়ে থাকে । fast.log ফাইলটি একটি সংক্ষিপ্ত টেক্সট ফরম্যাট ব্যবহার করে, যাতে টাইমস্ট্যাম্প, রুল আইডি, ক্লাসিফিকেশন এবং প্রায়োরিটি থাকে, যা টার্মিনাল থেকে (tail -f) দ্রুত পরিদর্শনের জন্য উপযুক্ত।

উদাহরণস্বরূপ, ভুল TCP চেকসামযুক্ত ট্র্যাফিকের সম্মুখীন হলে, আমরা এই ধরনের লাইন দেখতে পারি: তারিখ ও সময়সহ টাইমস্ট্যাম্প, তারপরে রুল আইডেন্টিফায়ার (যেমন, 1:2200074:1), "SURICATA TCPv4 invalid checksum" মেসেজ, ক্লাসিফিকেশন, প্রায়োরিটি এবং সোর্স-ডেস্টিনেশন IP/পোর্ট পেয়ার। এই ধরনের অ্যালার্ট প্যাকেটের অখণ্ডতার সমস্যা বা ফাঁকি দেওয়ার প্রচেষ্টা দ্রুত শনাক্ত করতে সাহায্য করে ।

eve.json ফাইলটিতে JSON ফরম্যাটে একই ইভেন্টগুলো থাকে, যেখানে timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto-এর মতো ফিল্ড এবং action, gid, signature_id, rev, signature, category, ও severity সহ একটি alert সাবফাইল থাকে। এই ফরম্যাটটি Logstash, Fluentd, Filebeat বা অন্য যেকোনো লগ এজেন্টের মাধ্যমে সহজেই গ্রহণ করা যায় , যা শুধুমাত্র প্লেইন টেক্সট ব্যবহারের চেয়ে অনেক বেশি সমৃদ্ধ অ্যানালিটিক্সের সুযোগ করে দেয়।

যখন একটি মাল্টি-কোর সার্ভারে (যেমন, ৮টি কোর) সুরিকাটা স্থাপন করা হয়, তখন htop-এর মতো টুলগুলিতে থ্রেড মোডে থ্রেড কম্প্রেশন সহজেই দৃশ্যমান হয়, যেখানে এক বা একাধিক ক্যাপচার থ্রেড (pcap, AF_PACKET, বা NFQ) এবং কোর জুড়ে বিস্তৃত বিপুল সংখ্যক ডিটেকশন থ্রেড দেখা যায়। যখন ট্র্যাফিকের পরিমাণ প্ল্যাটফর্মের সীমার কাছাকাছি চলে আসে, তখন detect-thread-ratio এবং CPU affinity সমন্বয় করলে থ্রুপুট এবং ল্যাটেন্সির উপর উল্লেখযোগ্য প্রভাব পড়তে পারে।

প্রোডাকশনে ডেপ্লয় করার আগে, কোন রুল সেটগুলো সক্রিয় থাকবে তা সূক্ষ্মভাবে সমন্বয় করতে কিছু সময় ব্যয় করার পরামর্শ দেওয়া হয় , যাতে ফলস পজিটিভের বন্যা এড়ানো যায়, যা বৈধ ট্র্যাফিককে ব্লক করতে পারে বা লগগুলোকে জঞ্জালে পরিণত করতে পারে। Suricata-update আপনাকে সংবেদনশীলতা এবং ব্যবহারযোগ্যতার মধ্যে একটি যুক্তিসঙ্গত ভারসাম্য খুঁজে পেতে সম্পূর্ণ ক্যাটাগরি বা স্বতন্ত্র রুল নিষ্ক্রিয় করার সুযোগ দেয়।

বিশেষ অ্যাপ্লিকেশন: ভিওআইপি, অডিও বিশ্লেষণ, এবং সৃজনশীল NFQUEUE

চিরাচরিত ব্যবহার (ওয়েব পরিষেবা সুরক্ষা, ম্যালওয়্যার সনাক্তকরণ, ডিডিওএস বিশ্লেষণ) ছাড়াও, নেটফিল্টার ও এনএফকিউই জুটি ভিওআইপি-র মতো ক্ষেত্রে বেশ কিছু সৃজনশীল সমাধানের সুযোগ করে দেয়। উদাহরণস্বরূপ, একটি অ্যান্টি-স্পিট (আইপি টেলিফোনির মাধ্যমে স্প্যাম) ফিল্টার অথবা আরটিপি স্ট্রিমে অশ্লীল শব্দ সেন্সর করার জন্য একটি সিস্টেম তৈরি করা সম্ভব।

মূল ধারণাটি হলো: পোর্ট অথবা প্রোটোকল শনাক্তকরণের মাধ্যমে RTP ট্র্যাফিক চিহ্নিত করে তা NFQUEUE-তে পাঠানো; ইউজার অ্যাপ্লিকেশন থেকে librtp-এর মতো কোনো লাইব্রেরি ব্যবহার করে RTP স্ট্রিমটি পুনর্গঠন করা , WAV ফরম্যাটে অডিওটি বের করে আনা এবং তা কোনো তৃতীয় পক্ষের দেওয়া সিন্থেসিস বা রিকগনিশন লাইব্রেরির মতো কীওয়ার্ড শনাক্তকরণ ইঞ্জিনে (ওয়ার্ডস্পটিং) পাঠানো।

শনাক্তকৃত শব্দগুলোর উপর ভিত্তি করে, NFQUEUE প্রসেসটি স্ট্রিমে একটি বিপ শব্দ যোগ করে প্লেব্যাককে অনুমতি দেওয়া, ব্লক করা, বা এমনকি পরিবর্তন করার সিদ্ধান্ত নিতে পারে , যদিও পরেরটির জন্য RTCP, প্যাকেট সিকোয়েন্স এবং টাইমিংয়ের উপর অত্যন্ত সূক্ষ্ম নিয়ন্ত্রণের প্রয়োজন হয়—যা প্রায় একটি ম্যান-ইন-দ্য-মিডল পদ্ধতির মতো। এটি সহজসাধ্য নয়, কিন্তু তাত্ত্বিকভাবে একই কিউ এবং ভারডিক্ট সিস্টেম ব্যবহার করে এটি পুরোপুরি অর্জনযোগ্য।

এটা সত্যি যে, এর কিছু কাজ একটি সাধারণ স্নিফারের মাধ্যমে কোনো এক্সটার্নাল প্রসেসরে ডেটা পাঠিয়ে এবং তারপর SIP সিগন্যালিং-এর ওপর ভিত্তি করে অথবা একটি SBC (যেমন অ্যাস্টারিস্ক, কামাইলিও ইত্যাদি)-এর মাধ্যমে করা যেতে পারে। NFQUEUE ব্যবহারের ক্ষেত্রে পার্থক্য হলো , একাধিক কম্পোনেন্টের মধ্যে সমন্বয় সাধন করা বা সিগন্যালিং লেয়ারের কলটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করার প্রয়োজন ছাড়াই RTP ফ্লো-এর ওপর পদক্ষেপটি তাৎক্ষণিক এবং সরাসরি হতে পারে ।

এই দৃশ্যকল্পগুলো GNU/Linux + Netfilter + Suricata + থার্ড-পার্টি লাইব্রেরির সমন্বয়ের সম্ভাবনা স্পষ্টভাবে তুলে ধরে: এর বিষয় শুধু পোর্ট এবং আইপি অ্যাড্রেস ব্লক করা নয়, বরং একটি ১০০% মুক্ত সফটওয়্যার ইকোসিস্টেম ব্যবহার করে রিয়েল টাইমে জটিল ট্র্যাফিক সিদ্ধান্তগুলো সমন্বয় করা ।

ছোট সি প্রোগ্রাম যা সর্বদা প্যাকেট গ্রহণ করে থেকে শুরু করে NFQUEUE, Pfsense, ডাটাবেস এবং ক্যাশের সাথে সমন্বিত একটি মাল্টিপ্রসেস সুরিকাটা স্থাপনা পর্যন্ত পুরো যাত্রাটি দেখলে, এই প্রযুক্তি স্ট্যাকটি সহজ গতিশীল ফায়ারওয়াল থেকে শুরু করে ডেটা সেন্টার-স্কেল IDS/IPS আর্কিটেকচার পর্যন্ত সবকিছু তৈরি করতে যে নমনীয়তা প্রদান করে তা উপলব্ধি করা যেতে পারে, যেখানে প্রকৃত গভীর পরিদর্শন ক্ষমতা এবং ক্রমবর্ধমান জটিল আক্রমণের স্বয়ংক্রিয় প্রতিক্রিয়া রয়েছে।