RADIUS Accounting: সেশন, ব্যবহার এবং অডিট লগ ট্র্যাকিং

এই গাইডটি RADIUS accounting-এর উপর একটি বিস্তৃত প্রযুক্তিগত রেফারেন্স প্রদান করে — এটি কীভাবে WiFi সেশন শুরু, বন্ধ এবং অন্তর্বর্তীকালীন-আপডেট ডেটা রেকর্ড করে, কী কী অ্যাট্রিবিউট ক্যাপচার করা হয় এবং কীভাবে সেই ডেটা সিকিউরিটি অডিটিং, GDPR কমপ্লায়েন্স এবং ক্যাপাসিটি প্ল্যানিংয়ের জন্য ব্যবহার করা যায়। এটি নেটওয়ার্ক অপারেশন এবং সিকিউরিটি টিমের জন্য অপরিহার্য পাঠ যাদের WiFi অথেন্টিকেশন ইভেন্ট থেকে ডিফেনসিবল অডিট ট্রেইল প্রয়োজন, এবং ভেন্যু অপারেটরদের জন্য যারা সেশন ডেটাকে SIEM প্ল্যাটফর্ম এবং অ্যানালিটিক্স ড্যাশবোর্ডে একীভূত করতে চান।

📖 9 মিনিট পাঠ📝 2,044 শব্দ🔧 2 উদাহরণ❓ 3 প্রশ্ন📚 9 মূল শব্দসমূহ

🎧 এই গাইডটি শুনুন

ট্রান্সক্রিপ্ট দেখুন

Welcome back to the Purple Technical Briefing. I'm your host, and today we're diving into a critical, yet often misunderstood, component of enterprise WiFi infrastructure: RADIUS Accounting. Specifically, how we track sessions, monitor usage, and build robust audit logs. If you're an IT manager, a network architect, or a venue operations director, this is for you. We're skipping the academic theory and getting straight into the practical application.

Let's start with the fundamentals. For the CTO who needs the 60-second elevator pitch: what is RADIUS accounting, and how does it differ from RADIUS authentication?

Simply put, authentication is the bouncer at the door checking your ID. Accounting is the bartender tracking how long you stay and how much you consume. Authentication uses UDP port 1812 and handles the who and how of network access. Accounting uses UDP port 1813 and meticulously records the what, when, and how much. It tracks when a session starts, when it stops, how many bytes were transferred, and what IP address was assigned to the client device.

So it's the audit trail. But how exactly does it capture this data? What's the mechanism?

It relies on three primary packet types sent from the Network Access Server — usually your Access Point or Wireless Controller — to the RADIUS server. These are called Accounting-Request packets. First, you have the Start packet. This is sent the moment a user successfully connects. It establishes the baseline record in the accounting database, capturing the user identity, device MAC address, assigned IP address, and the AP the user connected to. Then, you have the Stop packet, sent when the user disconnects, containing the final cumulative statistics for the entire session.

That sounds straightforward. Start and Stop. Job done.

Not quite. Relying only on Start and Stop packets is a significant operational risk. Consider this: what happens if a guest connects in a hotel and stays connected for three days? If you only rely on Start and Stop, you have zero visibility into their usage for those three days. Or worse, what if the Access Point loses power? It never sends the Stop packet, and you're left with a stale session in your database that looks like it's still active indefinitely.

So what's the solution?

The third packet type: the Interim-Update. This is critical, and it's the most commonly misconfigured element in RADIUS accounting deployments. You configure the Wireless Controller to send an update every, say, 15 minutes during an active session. It acts as a heartbeat and provides a running snapshot of current usage — bytes transferred, session duration, and packet counts. If the RADIUS server stops receiving interim updates from a particular session, you know the session is dead, even if you never received a Stop packet. The rule of thumb here is simple: No Interim, No Insight.

Now let's talk about the data itself. What specific attributes are we looking at in these packets that are so valuable for audit logs and compliance reporting?

There are several key ones. The Acct-Session-Id is the primary key that ties the Start, Interim-Update, and Stop packets together into a coherent session record. Without this, you can't correlate the three packet types. Then you have the Calling-Station-Id, which is typically the client's MAC address — the hardware identifier of the device. The Framed-IP-Address is the IP address assigned to the client for that session. The Acct-Input-Octets and Acct-Output-Octets track the volume of data received from and sent to the client. And the Acct-Terminate-Cause, included in Stop packets, tells you why the session ended — whether the user manually disconnected, hit an idle timeout, or the carrier was lost.

How do we use those attributes in a real-world scenario? Let's take GDPR compliance or a lawful intercept request.

This is precisely where RADIUS accounting proves its return on investment. Let's say law enforcement approaches a retail chain and says: an IP address on your guest WiFi was used to access malicious content last Tuesday at 2 PM. Who was it? If you only have firewall logs, you just have an IP address. But IP addresses change constantly with DHCP. You need to tie that IP to a specific device at a specific point in time. So, you query your RADIUS accounting database. You look for a session where the Framed-IP-Address matches the IP from the firewall log, and where the timestamp of the incident falls between the session's Start time and Stop time. That record will give you the Calling-Station-Id — the MAC address of the device. You've just tied the network layer to the device layer. That's your complete audit trail.

Let's look at another scenario: a large hotel property. The hospitality sector is particularly exposed here. A 300-room hotel with conference facilities might have thousands of concurrent WiFi sessions. The operations team needs to understand peak usage periods for capacity planning, while the compliance team needs to demonstrate that guest data is handled appropriately under GDPR.

In this environment, RADIUS accounting provides both. The session data feeds into a WiFi analytics platform, which translates raw bytes and session durations into footfall metrics and bandwidth consumption trends. Simultaneously, the same data feeds into a compliance reporting module that can demonstrate to auditors exactly what data was collected, for how long it was retained, and how it was secured.

So, to make all of this happen, we need to get this data out of the RADIUS server and into systems where we can query and act on it. How should teams be architecting that pipeline?

The first rule is: don't leave the logs sitting in flat text files on the RADIUS server. Configure the server to write accounting data to a structured relational database — PostgreSQL or MySQL are common choices. From there, you have two primary consumption paths. First, forward the logs to your SIEM — Splunk, Microsoft Sentinel, or IBM QRadar — using Syslog or a REST API. This enables your security team to correlate WiFi authentication events with firewall blocks, intrusion detection alerts, or data loss prevention triggers. Second, feed the data into your analytics platform. Purple's WiFi Analytics, for example, can ingest this session data and transform it into actionable insights about footfall, dwell time, and capacity utilisation.

Now let's talk about the common pitfalls. Where do deployments go wrong?

Two main failure modes. First, as we've discussed, failing to enable Interim-Updates at all. This is surprisingly common. Administrators configure authentication correctly but never touch the accounting settings. Second, and this is equally damaging, setting the Interim-Update interval too aggressively. If you have 10,000 concurrent users and you set the interval to 1 minute, you are generating 10,000 database write operations per minute just for accounting updates. That will saturate your RADIUS server's I/O capacity very quickly. The sweet spot for most enterprise deployments is 10 to 15 minutes. It provides sufficient granularity for operational visibility without creating an unsustainable write load.

Let's run through a rapid-fire set of scenarios.

Scenario one: A venue manager reports that the analytics dashboard shows users connected for 48 hours, but the venue is closed overnight.

That's a stale session problem. The Access Points aren't sending Stop packets — likely due to a power cycle or network interruption — and the sessions are never being closed in the database. The fix is to implement a dead-session cleanup script on the RADIUS server. Any session that hasn't received an interim update within two to three times the configured interval should be automatically closed.

Scenario two: A retail chain's security team says firewall logs only show IP addresses, making it impossible to audit which specific point-of-sale terminal accessed a suspicious external IP.

Ensure the Access Points are configured to include the Framed-IP-Address attribute in the RADIUS accounting packets, and integrate that RADIUS accounting database with the SIEM to correlate IP address to MAC address.

Scenario three: The RADIUS server is experiencing high CPU load during peak hours, causing authentication delays.

Check the interim update interval first. If it's set to 1 or 2 minutes across a large estate, increase it to 15 minutes. Also verify that the accounting database has appropriate indexes on the Acct-Session-Id and User-Name columns. Unindexed tables will cause full table scans on every write, which is catastrophic at scale. And consider separating your authentication and accounting workloads onto dedicated server instances.

To wrap up, here are the key takeaways for any IT manager or network architect implementing or auditing their RADIUS accounting infrastructure.

First: RADIUS accounting is distinct from authentication. It tracks session data, not access decisions. Both are essential, but they serve different operational and compliance purposes.

Second: Always enable Interim-Updates. Without them, you have no visibility into active sessions and no mechanism to detect stale records.

Third: The three attributes you must always capture are Acct-Session-Id, Framed-IP-Address, and Calling-Station-Id. These three form the foundation of any meaningful audit trail.

Fourth: Export your accounting data. Don't leave it in flat files. Write to a structured database, forward to a SIEM, and feed into an analytics platform.

Fifth: Design for scale. A 15-minute interim update interval is the right balance for most enterprise deployments. Adjust based on your specific compliance requirements and infrastructure capacity.

The bottom line is this: RADIUS accounting is not a nice-to-have. In any regulated environment — hospitality, retail, healthcare, public sector — it is the foundation of your WiFi audit trail. Get it right, and you have a powerful tool for security, compliance, and operational intelligence. Get it wrong, and you have a gap in your audit trail that could prove very costly.

Thank you for listening to the Purple Technical Briefing. Until next time.

এক্সিকিউটিভ সামারি

এন্টারপ্রাইজ IT এবং নেটওয়ার্ক অপারেশন টিমের জন্য, WiFi নেটওয়ার্কে ইউজারদের অথেন্টিকেট করা যুদ্ধের অর্ধেক মাত্র। একবার একটি ডিভাইস কানেক্ট হয়ে গেলে, সেই ডিভাইসটি কী করে — কতক্ষণ কানেক্টেড থাকে, কতটা ডেটা ব্যবহার করে এবং কখন ডিসকানেক্ট হয় — তা বোঝা সিকিউরিটি, ক্যাপাসিটি প্ল্যানিং এবং রেগুলেটরি কমপ্লায়েন্সের জন্য অত্যন্ত গুরুত্বপূর্ণ। এখানেই RADIUS accounting অপরিহার্য হয়ে ওঠে। যেখানে RADIUS অথেন্টিকেশন নেটওয়ার্ক অ্যাক্সেসের কে এবং কীভাবে পরিচালনা করে, সেখানে RADIUS accounting অত্যন্ত সতর্কতার সাথে কী, কখন এবং কতটা রেকর্ড করে।

এই গাইডটি RADIUS accounting-এর একটি প্রযুক্তিগত গভীর বিশ্লেষণ প্রদান করে, Start, Stop এবং Interim-Update প্যাকেটগুলোর মেকানিজম এবং সেগুলোকে মূল্যবান করে তোলা অ্যাট্রিবিউটগুলো অন্বেষণ করে। এটি রূপরেখা দেয় যে কীভাবে Hospitality , Retail এবং অন্যান্য সেক্টরের ভেন্যু অপারেটররা শক্তিশালী অডিট ট্রেইল বজায় রাখতে, GDPR কমপ্লায়েন্স নিশ্চিত করতে এবং SIEM প্ল্যাটফর্ম বা WiFi Analytics সিস্টেমে অ্যাকশনেবল ইন্টেলিজেন্স সরবরাহ করতে এই ডেটা ব্যবহার করতে পারেন। RADIUS accounting আয়ত্ত করার মাধ্যমে, নেটওয়ার্ক আর্কিটেক্টরা র সেশন লগকে কৌশলগত সম্পদে রূপান্তর করতে পারেন যা অপারেশনাল দক্ষতা বাড়ায় এবং ঝুঁকি কমায়।

টেকনিক্যাল ডিপ-ডাইভ

RADIUS Accounting বনাম RADIUS Authentication

RADIUS (Remote Authentication Dial-In User Service), যা RFC 2865 -এ সংজ্ঞায়িত এবং RFC 2866 -এ অ্যাকাউন্টিংয়ের জন্য বর্ধিত, একটি ক্লায়েন্ট-সার্ভার মডেলে কাজ করে। একটি সাধারণ এন্টারপ্রাইজ WiFi ডিপ্লয়মেন্টে, Access Point (AP) বা Wireless LAN Controller (WLC) Network Access Server (NAS) — RADIUS ক্লায়েন্ট হিসেবে কাজ করে। RADIUS সার্ভার (যেমন, FreeRADIUS, Cisco ISE, Aruba ClearPass) রিকোয়েস্ট গ্রহণ এবং প্রসেস করে।

অথেন্টিকেশন এবং অ্যাকাউন্টিংয়ের মধ্যে পার্থক্য মৌলিক:

মাত্রা	RADIUS Authentication	RADIUS Accounting
উদ্দেশ্য	পরিচয় যাচাই করা এবং অ্যাক্সেস মঞ্জুর/প্রত্যাখ্যান করা	সেশন ব্যবহার এবং অ্যাক্টিভিটি রেকর্ড করা
UDP পোর্ট	1812	1813
RFC রেফারেন্স	RFC 2865	RFC 2866
প্যাকেট টাইপ	Access-Request, Access-Accept, Access-Reject	Accounting-Request (Start/Stop/Interim)
ক্যাপচার করা ডেটা	ক্রেডেনশিয়াল, VLAN অ্যাসাইনমেন্ট, পলিসি	সেশন টাইম, ট্রান্সফার করা বাইট, IP অ্যাড্রেস
কমপ্লায়েন্স ভূমিকা	অ্যাক্সেস কন্ট্রোল	অডিট ট্রেইল, লফুল ইন্টারসেপ্ট

যারা বড় পরিসরে Guest WiFi ডিপ্লয় করছেন, তাদের জন্য উভয় ফাংশনই প্রয়োজনীয় — তবে অ্যাকাউন্টিং আপনাকে কমপ্লায়েন্ট এবং ডিফেনসিবল রাখতে সাহায্য করে।

তিনটি অ্যাকাউন্টিং প্যাকেট টাইপ

RADIUS accounting তিনটি প্রাথমিক Accounting-Request প্যাকেট টাইপের উপর নির্ভর করে, যার প্রতিটি Acct-Status-Type অ্যাট্রিবিউট দ্বারা সংজ্ঞায়িত:

Start (Acct-Status-Type = 1): যখন একজন ইউজার সফলভাবে কানেক্ট হন এবং একটি সেশন শুরু হয় তখন NAS দ্বারা পাঠানো হয়। এটি অ্যাকাউন্টিং ডেটাবেসে বেসলাইন রেকর্ড স্থাপন করে, ইউজারের পরিচয়, ডিভাইসের MAC অ্যাড্রেস, বরাদ্দকৃত IP অ্যাড্রেস এবং ইউজার যে AP-তে কানেক্ট হয়েছেন তা ক্যাপচার করে।
Interim-Update (Acct-Status-Type = 3): একটি অ্যাক্টিভ সেশনের সময় পর্যায়ক্রমে পাঠানো হয়। এই প্যাকেটগুলো বর্তমান ব্যবহারের রানিং স্ন্যাপশট প্রদান করে — ট্রান্সফার করা বাইট, সেশনের সময়কাল এবং প্যাকেট সংখ্যা। এগুলো সেশনটি এখনও সচল আছে কিনা তা নিশ্চিত করতে হার্টবিট হিসেবে কাজ করে এবং ডিসকানেকশনের জন্য অপেক্ষা না করেই দীর্ঘস্থায়ী সেশনগুলোর ভিজিবিলিটি প্রদান করে।
Stop (Acct-Status-Type = 2): যখন সেশন শেষ হয় তখন পাঠানো হয় — তা ইউজারের ডিসকানেক্ট করা, AP রিবুট, আইডল টাইমআউট বা সেশন টাইমআউটের কারণেই হোক না কেন। এতে পুরো সেশনের চূড়ান্ত, ক্রমবর্ধমান পরিসংখ্যান থাকে।

চিত্র ১: একটি WiFi সেশন জুড়ে RADIUS accounting প্যাকেট লাইফসাইকেল।

মূল অ্যাকাউন্টিং অ্যাট্রিবিউট

সেশনগুলো কার্যকরভাবে ট্র্যাক করতে এবং ডিফেনসিবল অডিট লগ তৈরি করতে, NAS নির্দিষ্ট অ্যাট্রিবিউটসহ Accounting-Request প্যাকেটগুলো পূরণ করে। নিম্নলিখিতগুলো অপারেশনালভাবে সবচেয়ে গুরুত্বপূর্ণ:

অ্যাট্রিবিউট	বিবরণ	কমপ্লায়েন্স প্রাসঙ্গিকতা
Acct-Session-Id	NAS দ্বারা জেনারেট করা অনন্য সেশন আইডেন্টিফায়ার	Start, Interim এবং Stop রেকর্ডগুলোর মধ্যে সম্পর্ক স্থাপনের জন্য প্রাইমারি কি
User-Name	অথেন্টিকেটেড পরিচয় (ইউজারনেম বা MAC অ্যাড্রেস)	সেশনকে একটি নির্দিষ্ট ইউজার বা ডিভাইসের সাথে ম্যাপ করে
NAS-IP-Address	রিপোর্টিং AP বা WLC-এর IP অ্যাড্রেস	নেটওয়ার্ক সেগমেন্ট এবং ফিজিক্যাল লোকেশন শনাক্ত করে
Framed-IP-Address	ক্লায়েন্ট ডিভাইসে বরাদ্দকৃত IP অ্যাড্রেস	ফায়ারওয়াল এবং ওয়েব প্রক্সি লগের সাথে সম্পর্ক স্থাপনের জন্য গুরুত্বপূর্ণ
Calling-Station-Id	ক্লায়েন্ট ডিভাইসের MAC অ্যাড্রেস	অডিট ট্রেইলের জন্য ডিভাইস-লেয়ার পরিচয়
Called-Station-Id	AP এবং SSID-এর MAC অ্যাড্রেস	ইউজার কোন নির্দিষ্ট রেডিও এবং নেটওয়ার্কে কানেক্ট হয়েছেন তা শনাক্ত করে
Acct-Input-Octets	ক্লায়েন্ট থেকে প্রাপ্ত বাইট	ব্যান্ডউইথ মনিটরিং এবং ক্যাপাসিটি প্ল্যানিং
Acct-Output-Octets	ক্লায়েন্টে পাঠানো বাইট	ব্যান্ডউইথ মনিটরিং এবং ক্যাপাসিটি প্ল্যানিং
Acct-Session-Time	সেকেন্ডে সেশনের সময়কাল	ডোয়েল টাইম অ্যানালিটিক্স এবং বিলিং
Acct-Terminate-Cause	সেশন শেষ হওয়ার কারণ	ট্রাবলশুটিং এবং অ্যানোমালি ডিটেকশন

যারা 802.1X Authentication নিয়ে কাজ করছেন, তাদের জন্য User-Name অ্যাট্রিবিউটে EAP এক্সচেঞ্জ থেকে অথেন্টিকেটেড পরিচয় থাকবে, যা শুধুমাত্র MAC Authentication Bypass (MAB)-এর তুলনায় আরও সমৃদ্ধ অডিট ট্রেইল প্রদান করে।

ইমপ্লিমেন্টেশন গাইড

একটি শক্তিশালী RADIUS accounting ইনফ্রাস্ট্রাকচার ডিপ্লয় করার জন্য NAS এবং RADIUS সার্ভার উভয় স্তরেই সতর্ক কনফিগারেশন প্রয়োজন। একটি নির্ভরযোগ্য অ্যাকাউন্টিং পাইপলাইন স্থাপনের জন্য নিচে একটি ভেন্ডর-নিরপেক্ষ পদ্ধতি দেওয়া হলো।

ধাপ ১: NAS কনফিগার করুন (Access Points / Controllers)

NAS কনফিগারেশনেই বেশিরভাগ ডিপ্লয়মেন্ট ব্যর্থ হয়। অ্যাডমিনিস্ট্রেটররা প্রায়ই অথেন্টিকেশন সঠিকভাবে কনফিগার করেন কিন্তু অ্যাকাউন্টিং ডিফল্ট সেটিংসে রেখে দেন বা পুরোপুরি নিষ্ক্রিয় করে দেন।

অ্যাকাউন্টিং সার্ভার সংজ্ঞায়িত করুন: RADIUS সার্ভারের IP অ্যাড্রেস এবং UDP পোর্ট 1813-এর জন্য শেয়ার্ড সিক্রেট নির্দিষ্ট করুন। হাই-অ্যাভেইল্যাবিলিটি ডিপ্লয়মেন্টে, প্রাইমারি সার্ভার আনরিচেবল হলে ডেটা লস রোধ করতে একটি সেকেন্ডারি অ্যাকাউন্টিং সার্ভার কনফিগার করুন।
Interim Updates সক্ষম করুন: এটি সবচেয়ে গুরুত্বপূর্ণ কনফিগারেশন ধাপ। একটি উপযুক্ত ইন্টারভাল সেট করুন — এন্টারপ্রাইজ ডিপ্লয়মেন্টের জন্য সাধারণত ১০ থেকে ১৫ মিনিট। ছোট ইন্টারভাল (যেমন, ১ মিনিট) আরও বিস্তারিত ডেটা প্রদান করে কিন্তু স্কেলে অস্থিতিশীল রাইট লোড তৈরি করে; দীর্ঘ ইন্টারভাল (যেমন, ৩০ মিনিট) ওভারহেড কমায় কিন্তু অ্যাক্টিভ সেশনগুলোর ভিজিবিলিটিতে দেরি করে।
টাইম সিনক্রোনাইজেশন নিশ্চিত করুন: সমস্ত NAS ডিভাইস এবং RADIUS সার্ভারে NTP কনফিগার করুন। অডিট লগ এবং SIEM কোরিলেশনের জন্য সঠিক টাইমস্ট্যাম্প অপরিহার্য। ৫ মিনিটের ক্লক ড্রিফট একটি লফুল ইন্টারসেপ্ট পরিস্থিতিতে অডিট ট্রেইলকে অবৈধ করে দিতে পারে।

ধাপ ২: RADIUS সার্ভার কনফিগার করুন

ডেটাবেস ইন্টিগ্রেশন: ফ্ল্যাট টেক্সট ফাইলের পরিবর্তে একটি স্ট্রাকচার্ড রিলেশনাল ডেটাবেসে (যেমন, PostgreSQL, MySQL) অ্যাকাউন্টিং ডেটা লগ করার জন্য RADIUS সার্ভার কনফিগার করুন। স্ট্রাকচার্ড স্টোরেজ দক্ষ কুয়েরি, ইনডেক্সিং এবং ডাউনস্ট্রিম সিস্টেমের সাথে ইন্টিগ্রেশন সক্ষম করে। নিশ্চিত করুন যে Acct-Session-Id, User-Name, Framed-IP-Address এবং সেশন শুরুর টাইমস্ট্যাম্পে ইনডেক্স রয়েছে।
ডেটা রিটেনশন পলিসি: আপনার কমপ্লায়েন্স প্রয়োজনীয়তার সাথে সামঞ্জস্যপূর্ণ স্বয়ংক্রিয় আর্কাইভ বা পার্জ স্ক্রিপ্ট ইমপ্লিমেন্ট করুন। GDPR আর্টিকেল 5(1)(e) অনুযায়ী ডেটা প্রয়োজনের বেশি সময় রাখা যাবে না; তবে, অনেক বিচারব্যবস্থায় লফুল ইন্টারসেপ্ট রেগুলেশন (যেমন, যুক্তরাজ্যের Investigatory Powers Act 2016) ১২ মাস পর্যন্ত ডেটা রাখার প্রয়োজন হতে পারে।

ধাপ ৩: ডেটা পাইপলাইন তৈরি করুন

অ্যাকাউন্টিং ডেটার মান সর্বাধিক করতে, এটি কনজাম্পশন প্ল্যাটফর্মে এক্সপোর্ট করতে হবে যেখানে এটি কুয়েরি, কোরিলেট এবং ভিজ্যুয়ালাইজ করা যায়।

SIEM ইন্টিগ্রেশন: Syslog বা একটি REST API ব্যবহার করে আপনার SIEM-এ (যেমন, Splunk, Microsoft Sentinel, IBM QRadar) লগ ফরোয়ার্ড করতে RADIUS সার্ভার বা আন্ডারলায়িং ডেটাবেস কনফিগার করুন। এটি সিকিউরিটি টিমকে ফায়ারওয়াল ব্লক, ইনট্রুশন ডিটেকশন অ্যালার্ট বা ডেটা লস প্রিভেনশন ট্রিগারগুলোর সাথে WiFi অথেন্টিকেশন ইভেন্টগুলোর সম্পর্ক স্থাপন করতে সক্ষম করে।
অ্যানালিটিক্স ইন্টিগ্রেশন: র বাইট এবং MAC অ্যাড্রেসগুলোকে ফুটফল, ডোয়েল টাইম এবং পিক ইউজেজ পিরিয়ড সম্পর্কিত অ্যাকশনেবল ইনসাইটে রূপান্তর করতে Purple-এর WiFi Analytics -এর মতো প্ল্যাটফর্মে সেশন ডেটা সরবরাহ করুন। এটি বিশেষ করে Retail এবং Hospitality অপারেটরদের জন্য মূল্যবান যাদের প্রকৃত ব্যবহারের প্যাটার্নের সাথে স্টাফিং এবং ইনফ্রাস্ট্রাকচার ইনভেস্টমেন্ট সামঞ্জস্যপূর্ণ করতে হয়।

চিত্র ২: Access Points থেকে SIEM এবং অ্যানালিটিক্স প্ল্যাটফর্মে RADIUS accounting ডেটা পাইপলাইন।

বেস্ট প্র্যাকটিস

সর্বদা Interim Updates ব্যবহার করুন। শুধুমাত্র Start এবং Stop প্যাকেটের ওপর নির্ভর করা অপারেশনাল ব্লাইন্ড স্পট তৈরি করে। একটি ড্রপড কানেকশন বা AP পাওয়ার ফেইলিয়র একটি Stop প্যাকেট পাঠানো রোধ করতে পারে, যার ফলে ডেটাবেসে অনির্দিষ্টকালের জন্য একটি স্টেল সেশন থেকে যেতে পারে। Interim updates এই স্টেল সেশনগুলো শনাক্ত করার এবং বন্ধ করার মেকানিজম প্রদান করে। থাম্ব রুল: যদি একটি সেশন কনফিগার করা ইন্টারভালের দুই থেকে তিন গুণের মধ্যে কোনো অন্তর্বর্তীকালীন আপডেট না পাঠায়, তবে সেটিকে শেষ হয়ে গেছে বলে গণ্য করুন।

DHCP লগের সাথে RADIUS Accounting-এর সম্পর্ক স্থাপন করুন। RADIUS accounting Framed-IP-Address প্রদান করে, কিন্তু কিছু পরিবেশে DHCP লিজ টাইম সেশনের সময়কালের চেয়ে কম হতে পারে। RADIUS লগের পাশাপাশি DHCP লগ বজায় রাখা আরও স্থিতিস্থাপক অডিট ট্রেইল প্রদান করে, বিশেষ করে উচ্চ-ঘনত্বের ভেন্যুগুলোতে যেখানে IP অ্যাড্রেস রিসাইক্লিং ঘন ঘন হয়।

RadSec দিয়ে ট্রান্সপোর্ট সুরক্ষিত করুন। প্রথাগত RADIUS ট্রাফিক ন্যূনতম এনক্রিপশন সহ UDP-এর মাধ্যমে স্থানান্তরিত হয় — শুধুমাত্র ইউজার পাসওয়ার্ড ফিল্ডটি অস্পষ্ট (obfuscated) থাকে। ডিস্ট্রিবিউটেড ডিপ্লয়মেন্টে, বিশেষ করে যেগুলি একাধিক সাইট বা ক্লাউড-হোস্টেড RADIUS সার্ভার জুড়ে বিস্তৃত, ট্রানজিটে অ্যাকাউন্টিং ডেটা সুরক্ষিত করতে RadSec (TLS-এর ওপর RADIUS, RFC 6614-এ সংজ্ঞায়িত) বা IPsec টানেল ব্যবহার করুন। কার্ডহোল্ডার ডেটা পরিচালনা করে এমন যেকোনো নেটওয়ার্কের জন্য এটি PCI DSS 4.0-এর অধীনে একটি প্রয়োজনীয়তা।

অ্যাকাউন্টিং কিউ (Queue) মনিটর করুন। যদি RADIUS সার্ভার আনরিচেবল হয়ে যায়, NAS ডিভাইসগুলো স্থানীয়ভাবে অ্যাকাউন্টিং প্যাকেটগুলো কিউতে রাখবে। এই কিউ-এর দৈর্ঘ্য মনিটর করুন; কিউ পূর্ণ হয়ে গেলে প্যাকেট ড্রপ হবে এবং অডিট ডেটা হারিয়ে যাবে। কিউ ডেপথের ওপর অ্যালার্টিং কনফিগার করুন এবং হাই-অ্যাভেইল্যাবিলিটি ডিপ্লয়মেন্টের জন্য একটি সেকেন্ডারি অ্যাকাউন্টিং সার্ভার ইমপ্লিমেন্ট করুন।

স্কেলে অথেন্টিকেশন এবং অ্যাকাউন্টিং সার্ভার আলাদা করুন। ৫,০০০-এর বেশি কনকারেন্ট ইউজারের ডিপ্লয়মেন্টে, অ্যাকাউন্টিং থেকে আসা রাইট লোড অথেন্টিকেশন রেসপন্স টাইমকে ধীর করে দিতে পারে। আলাদা ডেটাবেস ইনস্ট্যান্সসহ ডেডিকেটেড অ্যাকাউন্টিং সার্ভার এই সমস্যা প্রতিরোধ করে।

ট্রাবলশুটিং এবং ঝুঁকি প্রশমন

স্টেল সেশন সমস্যা

লক্ষণ: RADIUS ডেটাবেস দেখাচ্ছে যে একজন ইউজার ৪৮ ঘণ্টা ধরে কানেক্টেড আছেন, কিন্তু ভেন্যু রাতারাতি বন্ধ হয়ে গেছে।

মূল কারণ: NAS একটি Stop প্যাকেট পাঠাতে ব্যর্থ হয়েছে — সাধারণত পাওয়ার ফেইলিয়র, AP রিবুট বা নেটওয়ার্ক ইন্টারাপশনের কারণে — এবং প্যাকেটটি কখনও RADIUS সার্ভার দ্বারা প্রাপ্ত হয়নি।

প্রশমন: RADIUS সার্ভারে একটি ডেড-সেশন ক্লিনআপ স্ক্রিপ্ট ইমপ্লিমেন্ট করুন। স্ক্রিপ্টটি পর্যায়ক্রমে এমন অ্যাক্টিভ সেশনগুলোর জন্য স্ক্যান করবে যেখানে শেষ প্রাপ্ত প্যাকেট (Start বা Interim-Update) একটি নির্দিষ্ট থ্রেশহোল্ডের (যেমন, অন্তর্বর্তীকালীন আপডেট ইন্টারভালের ২.৫ গুণ) চেয়ে পুরনো। এই থ্রেশহোল্ড অতিক্রম করা সেশনগুলো একটি সিন্থেটিক Stop রেকর্ড দিয়ে জোরপূর্বক বন্ধ করা উচিত, যেখানে টার্মিনেশন কারণ হিসেবে 'Lost-Carrier' বা 'Admin-Reset' উল্লেখ থাকবে।

হাই RADIUS সার্ভার CPU এবং I/O লোড

লক্ষণ: পিক আওয়ারে অথেন্টিকেশন রেসপন্স টাইম কমে যায়; RADIUS সার্ভার উচ্চ CPU এবং ডিস্ক I/O রিপোর্ট করে।

মূল কারণ: হাজার হাজার AP জুড়ে একটি অত্যন্ত ঘন ঘন অন্তর্বর্তীকালীন আপডেট ইন্টারভাল (যেমন, ১ মিনিট) ডেটাবেস রাইটের একটি অস্থিতিশীল ভলিউম তৈরি করে।

প্রশমন: অন্তর্বর্তীকালীন আপডেট ইন্টারভাল ১৫ মিনিটে বাড়ান। যাচাই করুন যে অ্যাকাউন্টিং ডেটাবেসে উপযুক্ত ইনডেক্স রয়েছে। অথেন্টিকেশন এবং অ্যাকাউন্টিংকে ডেডিকেটেড সার্ভার ইনস্ট্যান্সে আলাদা করার কথা বিবেচনা করুন। উচ্চ-ভলিউম অ্যাকাউন্টিং ডেটার জন্য রিলেশনাল ডেটাবেসের চেয়ে টাইম-সিরিজ ডেটাবেস (যেমন, InfluxDB) বেশি উপযুক্ত কিনা তা মূল্যায়ন করুন।

অ্যাকাউন্টিং রেকর্ডে Framed-IP-Address অনুপস্থিত

লক্ষণ: RADIUS accounting রেকর্ড বিদ্যমান, কিন্তু Framed-IP-Address ফিল্ডটি খালি বা অনুপস্থিত, যা IP-টু-MAC কোরিলেশন অসম্ভব করে তোলে।

মূল কারণ: DHCP ক্লায়েন্টকে একটি IP অ্যাড্রেস বরাদ্দ করার আগেই NAS হয়তো Start প্যাকেট পাঠাচ্ছে। IP শুধুমাত্র DHCP এক্সচেঞ্জ শেষ হওয়ার পরেই পাওয়া যায়।

প্রশমন: প্ল্যাটফর্মটি সাপোর্ট করলে DHCP অ্যাসাইনমেন্টের পর পর্যন্ত Start প্যাকেট পাঠানো বিলম্বিত করতে NAS কনফিগার করুন। বিকল্পভাবে, Interim-Update প্যাকেটগুলোর ওপর নির্ভর করুন, যা DHCP অ্যাসাইনমেন্টের পরে পাঠানো হয় এবং এতে Framed-IP-Address থাকবে। আপনার অডিট কুয়েরিতে এটি নিশ্চিত করুন যে Start রেকর্ডে IP না থাকলে Interim-Update রেকর্ডগুলো চেক করা হচ্ছে।

ROI এবং ব্যবসায়িক প্রভাব

শক্তিশালী RADIUS accounting ইমপ্লিমেন্ট করা তিনটি দিক থেকে পরিমাপযোগ্য ব্যবসায়িক মূল্য প্রদান করে:

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

ক্যাপাসিটি প্ল্যানিং এবং ইনফ্রাস্ট্রাকচার ROI। সময়ের সাথে সাথে Acct-Input-Octets এবং Acct-Output-Octets ট্রেন্ড বিশ্লেষণ করে, নেটওয়ার্ক আর্কিটেক্টরা ব্যান্ডউইথ ব্যবহারের প্যাটার্ন, পিক ইউজেজ পিরিয়ড এবং সর্বোচ্চ লোড তৈরি করা নির্দিষ্ট AP বা SSID-গুলো শনাক্ত করতে পারেন। এই ডেটা সরাসরি WAN আপগ্রেড সিদ্ধান্ত এবং AP প্লেসমেন্ট কৌশলগুলোকে প্রভাবিত করে, যা নিশ্চিত করে যে ইনফ্রাস্ট্রাকচার ইনভেস্টমেন্ট সেখানেই করা হচ্ছে যেখানে এটি সবচেয়ে বেশি প্রভাব ফেলে। Transport হাব এবং বড় ভেন্যুগুলোর জন্য, এটি উল্লেখযোগ্য ক্যাপিটাল এক্সপেন্ডিচার সাশ্রয় করতে পারে।

উন্নত অ্যানালিটিক্স এবং ভেন্যু ইন্টেলিজেন্স। যখন RADIUS সেশন ডেটা Purple-এর WiFi Analytics এবং Sensors -এর মতো প্ল্যাটফর্মের সাথে যুক্ত করা হয়, তখন র অ্যাকাউন্টিং ডেটা ভেন্যু ইন্টেলিজেন্সে রূপান্তরিত হয়। সেশনের সময়কাল থেকে প্রাপ্ত ডোয়েল টাইম মেট্রিক্স, Calling-Station-Id হিস্ট্রি থেকে রিটার্নিং ভিজিটর শনাক্তকরণ এবং কনকারেন্ট সেশন কাউন্ট থেকে পিক অকুপেন্সি অ্যানালিটিক্স — সবই সহজলভ্য হয়। Hospitality অপারেটরদের জন্য, এই ডেটা সরাসরি স্টাফিং মডেল, F&B প্লেসমেন্ট এবং মার্কেটিং পার্সোনালাইজেশন কৌশলগুলোকে প্রভাবিত করে। WiFi ইনফ্রাস্ট্রাকচার কীভাবে এই ক্ষমতাগুলোকে সমর্থন করে সে সম্পর্কে আরও প্রসঙ্গের জন্য, Wireless Access Points এবং Modern Hospitality WiFi Solutions সংক্রান্ত আমাদের গাইডগুলো দেখুন।

মূল শব্দ ও সংজ্ঞা

RADIUS Accounting

The process of collecting and recording data about user network resource consumption, including session start and end times, data volume transferred, and IP address assignment. Defined in RFC 2866.

Essential for billing, capacity planning, GDPR compliance, and maintaining security audit trails in any enterprise WiFi deployment.

Acct-Status-Type

A RADIUS attribute (Attribute ID 40) that indicates the purpose of an accounting packet. Values include Start (1), Stop (2), and Interim-Update (3).

Used by the RADIUS server to determine whether to create a new session record, update an existing one, or close it. The most fundamental attribute in any accounting packet.

Interim-Update

A periodic RADIUS accounting packet sent by the NAS during an active session to report current usage statistics, including bytes transferred and session duration.

Critical for tracking long-lived sessions and detecting stale sessions if a client disconnects unexpectedly without sending a Stop packet.

Acct-Session-Id

A unique string generated by the NAS to identify a specific user connection instance. This value is consistent across all accounting packets (Start, Interim-Update, Stop) for the same session.

The primary key used to correlate all accounting records belonging to the same session. Without this, it is impossible to reconstruct a complete session history.

NAS (Network Access Server)

The device — typically a Wireless Access Point or Wireless LAN Controller — that controls physical access to the network and acts as the RADIUS client, generating and sending accounting packets.

The NAS is responsible for the accuracy and completeness of accounting data. Misconfiguration at the NAS level (e.g., disabled accounting, missing attributes) cannot be remediated at the RADIUS server level.

Framed-IP-Address

The IP address assigned to the client device for the duration of the session, included in RADIUS accounting packets.

Critical for correlating RADIUS accounting logs with other network logs such as firewall, web proxy, or DNS logs. The absence of this attribute makes IP-to-device correlation impossible.

Calling-Station-Id

Typically the MAC address of the client device connecting to the network, formatted as a colon-separated hexadecimal string (e.g., AA:BB:CC:DD:EE:FF).

Used to identify the specific hardware device, regardless of the IP address it is assigned. The device-layer anchor of the audit trail.

Acct-Terminate-Cause

An attribute included in Stop packets that specifies the reason a session ended. Common values include User-Request, Lost-Carrier, Idle-Timeout, Session-Timeout, and Admin-Reset.

Valuable for troubleshooting connectivity issues and for anomaly detection — for example, a high rate of Lost-Carrier terminations on a specific AP may indicate a hardware or interference problem.

RadSec

RADIUS over TLS (Transport Layer Security), defined in RFC 6614. Provides encrypted and authenticated transport for RADIUS packets, replacing the traditional UDP-based transport.

Required in any deployment where RADIUS traffic traverses untrusted networks (e.g., internet-connected cloud RADIUS servers). Increasingly mandated by PCI DSS 4.0 for cardholder data environments.

কেস স্টাডিজ

A 300-room hotel with conference facilities is deploying a new guest WiFi network. The IT manager needs to ensure that the deployment meets GDPR requirements for data minimisation and audit trail completeness, while also providing the marketing team with dwell time and repeat visitor analytics. The hotel uses a cloud-hosted RADIUS server and Cisco Meraki APs.

The deployment should be configured as follows. On the Meraki dashboard, navigate to Network-wide > RADIUS servers and add the cloud RADIUS server on port 1813 with a strong shared secret. Enable accounting and set the interim update interval to 15 minutes. On the RADIUS server, configure accounting to write to a PostgreSQL database with the following schema: session_id (primary key), user_name, nas_ip, framed_ip, calling_station_id, called_station_id, session_start, session_end, input_octets, output_octets, terminate_cause. Implement a data retention policy that automatically archives records older than 12 months to cold storage and purges records older than 24 months, documented in the hotel's GDPR Record of Processing Activities. Configure a Purple WiFi Analytics integration to ingest the session data, enabling the marketing team to access dwell time reports and repeat visitor frequency dashboards. Ensure NTP is synchronised across all Meraki APs and the RADIUS server to within 1 second.

বাস্তবায়ন সংক্রান্ত নোট: This scenario demonstrates the dual-purpose nature of RADIUS accounting: compliance and analytics. The 15-minute interim update interval is appropriate for a hotel environment where sessions can last days. The PostgreSQL schema design ensures that all GDPR-relevant fields are captured while avoiding unnecessary data collection. The 12/24-month retention policy balances the UK Investigatory Powers Act requirements with GDPR data minimisation principles.

A retail chain with 150 stores needs to comply with PCI DSS 4.0 requirements for network access monitoring. Their point-of-sale terminals use MAC Authentication Bypass (MAB) on the WiFi network. The security team has received a request from their QSA (Qualified Security Assessor) to demonstrate that they can identify which specific POS terminal accessed the payment network at any given time, using only a source IP address and timestamp from a firewall log.

The solution requires a three-component integration. First, verify that all Wireless LAN Controllers are configured to include the Framed-IP-Address attribute in RADIUS accounting packets. This is not always enabled by default and must be explicitly configured. Second, integrate the RADIUS accounting database with the SIEM platform (e.g., Splunk). Create a lookup table in Splunk that maps Framed-IP-Address and session time ranges to Calling-Station-Id (MAC address). Third, create a Splunk saved search that accepts a source IP and timestamp as inputs and returns the corresponding MAC address, NAS-IP-Address (identifying the store and AP), and User-Name from the RADIUS accounting records. The QSA can then be demonstrated this workflow: given a firewall log entry showing source IP 10.5.12.44 at 14:23:07 on a specific date, the search returns the MAC address of the POS terminal, the AP it was connected to, and the store location.

বাস্তবায়ন সংক্রান্ত নোট: This scenario highlights the critical role of the Framed-IP-Address attribute in bridging the gap between network-layer identity (IP address) and device-layer identity (MAC address). The SIEM lookup table approach is the industry-standard method for this type of correlation. Note that in environments with very short DHCP lease times, the correlation must use a time-range query rather than a point-in-time lookup, as the same IP may have been assigned to multiple devices within a short window.

দৃশ্যপট বিশ্লেষণ

Q1. A hotel IT manager notices that the WiFi analytics dashboard shows very few active users during the day, even though the lobby and restaurant are visibly busy. However, the historical reports for the previous day show a massive spike in data usage. The RADIUS server logs confirm that Start packets are being received, but the database shows very few Interim-Update records. What is the most likely misconfiguration, and how would you resolve it?

💡 ইঙ্গিত:Consider how data usage is reported during an active session versus at the point of disconnection.

প্রস্তাবিত পদ্ধতি দেখুন

The most likely cause is that Interim-Updates are disabled or not configured on the Wireless LAN Controller. Without interim updates, the RADIUS server only receives a Start packet when the user connects and a Stop packet when they disconnect. The analytics dashboard cannot display current usage because no in-session data is being reported. Once users leave and disconnect, the Stop packets arrive with the total accumulated data, causing the delayed spike in historical reports. The resolution is to enable Interim-Updates on the WLC and set an appropriate interval — 15 minutes is recommended for a hotel environment. After enabling, verify that the RADIUS server is receiving Interim-Update packets by checking the accounting database for records with Acct-Status-Type = 3.

Q2. During a security incident investigation, your SIEM has flagged that an IP address on the guest WiFi network accessed a known command-and-control server at 09:47:23 on a specific date. You need to identify the physical device responsible. Your DHCP lease time is set to 30 minutes. Describe the exact query logic you would use against the RADIUS accounting database to identify the device.

💡 ইঙ্গিত:IP addresses are not static. You must use a time-range query, not a point-in-time lookup, and account for DHCP lease recycling.

প্রস্তাবিত পদ্ধতি দেখুন

You must query the RADIUS accounting database for sessions where: (1) the Framed-IP-Address equals the flagged IP address, AND (2) the session_start timestamp is earlier than or equal to 09:47:23, AND (3) either the session_end timestamp is later than or equal to 09:47:23, OR the session_end is NULL (session still active at query time). If multiple sessions match (possible with a 30-minute DHCP lease), review the Interim-Update records to confirm which session was actively reporting usage at 09:47:23. The matching session record will contain the Calling-Station-Id (MAC address of the device) and the User-Name (authenticated identity, if 802.1X was used). Cross-reference the MAC address with your device inventory or DHCP server logs to identify the physical device and its owner.

Q3. You are the network architect for a conference centre that hosts events with up to 8,000 concurrent WiFi users. Your current RADIUS server is experiencing database write saturation during peak events, causing authentication delays of 3-5 seconds. Your current interim update interval is set to 2 minutes. Describe a multi-step remediation plan that addresses both the immediate performance issue and the underlying architectural risk.

💡 ইঙ্গিত:Consider both configuration changes and architectural changes. The goal is to maintain audit trail completeness while reducing write load.

প্রস্তাবিত পদ্ধতি দেখুন

The remediation plan should address three layers. First, as an immediate fix, increase the interim update interval from 2 minutes to 15 minutes on all Wireless Controllers. This reduces the accounting write load by approximately 87% (from one write per 2 minutes to one per 15 minutes per session), which should immediately relieve the database I/O pressure. Second, separate the authentication and accounting workloads onto dedicated server instances. The authentication server handles Access-Request/Accept/Reject packets, while a dedicated accounting server handles Accounting-Request packets and writes to a separate database. This prevents accounting write load from affecting authentication response times. Third, for the underlying architectural risk, evaluate whether a time-series database (e.g., InfluxDB or TimescaleDB) is more appropriate than a relational database for the accounting workload. Time-series databases are optimised for high-volume sequential writes and time-range queries, which matches the accounting data pattern exactly. Migrate accounting writes to the time-series database while retaining the relational database for compliance reporting queries.

মূল বিষয়সমূহ

✓RADIUS accounting (RFC 2866) is distinct from authentication: it records session usage data — duration, bytes transferred, IP assignment — rather than making access control decisions.
✓The three packet types — Start, Interim-Update, and Stop — must all be configured and operational for a complete audit trail. Interim-Updates are the most commonly missed configuration.
✓The Acct-Session-Id, Framed-IP-Address, and Calling-Station-Id attributes form the minimum viable audit trail, enabling IP-to-device correlation for compliance and security investigations.
✓Stale sessions (caused by missing Stop packets) must be managed with a dead-session cleanup script using the 2.5x interim update interval rule.
✓RADIUS accounting data must be exported to a structured database and integrated with a SIEM and analytics platform to deliver its full compliance and operational value.
✓For PCI DSS, GDPR, and lawful intercept compliance, the ability to tie an IP address to a MAC address at a specific point in time is the core requirement that RADIUS accounting fulfils.
✓At scale (5,000+ concurrent users), separate authentication and accounting server instances and consider a time-series database for accounting writes to prevent performance degradation.