Oracle Listener নিরাপত্তা: পোর্ট 1521 ইন্টারনেটে খুলে রাখা বন্ধ করুন

দুই সপ্তাহ আগে সম্পর্কহীন একটি APEX সমস্যায় সাহায্য করতে গিয়ে একটি প্রোডাকশন Oracle 19c সার্ভারে চারটি পোর্ট পরীক্ষা করেছিলাম। পোর্ট ২২ ফিল্টার করা ছিল - ভালো। পোর্ট 1521 ইন্টারনেটের জন্য পুরো খোলা, আর firewalld আদৌ চলছিল না। অন্য দেশ থেকে, কোনো ক্রেডেনশিয়াল ছাড়া, শুধু একটি পোর্ট টেস্ট দিয়ে এটি বের করতে ত্রিশ সেকেন্ড লেগেছে। এই লেখাটি তার সমাধান: নিজের listener উন্মুক্ত কি না কীভাবে দেখবেন, আর যে পাঁচটি স্তর এটি ঠিকভাবে বন্ধ করে - এমন ক্রমে, যাতে নিজের ডেটাবেজ থেকে নিজেই আটকে না যান।

১. "উন্মুক্ত listener" আসলে কী বোঝায়?

উন্মুক্ত Oracle listener মানে এমন একটি listener প্রসেস, যেখানে এমন নেটওয়ার্ক থেকেও পৌঁছানো যায় যাদের আপনার ডেটাবেজে কোনো কাজ নেই - সবচেয়ে গুরুতরভাবে, পাবলিক ইন্টারনেট। ঝুঁকিটা কেবল পাসওয়ার্ড আন্দাজ করার নয়। ঝুঁকি হলো, listener কারও পাসওয়ার্ড লাগার আগেই কথা বলে।

Listener একজন দালাল। তার পুরো কাজই হলো অপরিচিতদের উত্তর দেওয়া, তারা কোন service চায় বুঝে নেওয়া, আর ইনস্ট্যান্সের হাতে তুলে দেওয়া।

এই সহায়ক স্বভাবটাই সমস্যা। যে অপরিচিত পোর্টে পৌঁছাতে পারে, সে কখনও authenticate না করেই কাজের উত্তর পেয়ে যায়।

২. ষাট সেকেন্ডে যাচাই

দুটি কমান্ড আর একটি বাইরের টেস্ট। প্রথমটি সার্ভারে চালান:

# listener কোথায় bind করা?
ss -lntp | grep -E ':1521|tnslsnr'

# আদৌ কিছু ফিল্টার হচ্ছে কি?
systemctl is-active firewalld

Binding সাবধানে পড়ুন, কারণ এখানেই মানুষ নিজের সিস্টেম নিয়ে ভুল ধারণা করে।

• 127.0.0.1:1521 - কেবল স্থানীয়। হোস্টের বাইরে থেকে কিছুই পৌঁছাতে পারে না।
• 10.0.0.15:1521 - একটি অভ্যন্তরীণ ইন্টারফেসে bind করা। ওই নেটওয়ার্ক থেকে পৌঁছানো যায়।
• *:1521 বা 0.0.0.0:1521 - প্রতিটি ইন্টারফেস, যেকোনো পাবলিক ইন্টারফেসসহ। এটিই সাধারণ পাওয়া।

এখন সবচেয়ে গুরুত্বপূর্ণ অংশ: বাইরে থেকে টেস্ট করুন। Binding বলে listener কী দিচ্ছে, নেটওয়ার্ক কী অনুমতি দিচ্ছে তা নয়।

# নেটওয়ার্কের বাইরের কোনো মেশিন থেকে, পাবলিক IP-র বিরুদ্ধে
nc -zv <public-ip> 1521
# অথবা Windows PowerShell-এ
Test-NetConnection -ComputerName <public-ip> -Port 1521

এটি কানেক্ট হলে আপনার ডেটাবেজ listener ইন্টারনেটে আছে। এ নিয়ে ভাবতে চেঞ্জ উইন্ডোর অপেক্ষা করবেন না।

৩. খোলা 1521 থেকে আক্রমণকারী কী শেখে

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

পৌঁছানো যায় এমন listener নিজের ভার্সন ব্যানার ফাঁস করে। ভার্সন আর প্ল্যাটফর্ম মিলিয়ে পরিচিত দুর্বলতার তালিকা ছোট ও নির্দিষ্ট হয়ে যায়।

Service ও SID নামও প্রায়ই আবিষ্কারযোগ্য, আর সেগুলো খুব কম সময়েই এলোমেলো হয়। ERPPROD, HRPROD বা PACS আক্রমণকারীকে বলে দেয় ডেটাবেজে কী আছে এবং কোন সার্ভারে পরিশ্রম করা লাভজনক।

Service name হাতে পেলে কানেকশনের চেষ্টা শুরু করা যায় - আর যেসব সিস্টেম কেউ পৌঁছানোর কথাই ভাবেনি, সেখানে ডিফল্ট বা দুর্বল অ্যাকাউন্ট এখনও দুঃখজনকভাবে সাধারণ।

এর কিছুতেই দুর্লভ টুল লাগে না। ঠিক এ কারণেই ইন্টারনেটমুখী 1521 যেকোনো অ্যাসেসমেন্টে টিউনিংয়ের খুঁটিনাটি নয়, বরং critical finding হিসেবে গণ্য হয়।

৪. প্রথম স্তর: নেটওয়ার্ক (আগে এটাই করুন)

এই লেখার বাকি সব নিয়ন্ত্রণ defence in depth। আসল সমাধান ফায়ারওয়াল।

আপনার listener কেবল অ্যাপ্লিকেশন ও রিপোর্টিং হোস্ট থেকে কানেকশন নেবে, আর কিছু নয়। Red Hat ঘরানার হোস্টে:

# কেবল নির্দিষ্ট সোর্সকে 1521-এ পৌঁছাতে দিন
firewall-cmd --permanent --new-zone=oracle-clients
firewall-cmd --permanent --zone=oracle-clients --add-source=10.0.0.20/32
firewall-cmd --permanent --zone=oracle-clients --add-source=10.0.0.21/32
firewall-cmd --permanent --zone=oracle-clients --add-port=1521/tcp
firewall-cmd --reload

# এখন কী খোলা আছে, কার জন্য - নিশ্চিত হোন
firewall-cmd --list-all-zones | grep -A6 oracle-clients

গুরুত্ব দিয়ে নেওয়ার মতো একটি সতর্কতা। দূর থেকে যে সার্ভার চালান তাতে ফায়ারওয়াল চালু করাই মানুষের সারা বিকেল আটকে যাওয়ার সাধারণ কারণ।

আগে আপনার SSH পোর্ট এবং 1521 অনুমোদনের নিয়মগুলো লিখুন, যাচাই করুন, আর দ্বিতীয় কানেকশন টেস্ট করার সময় বর্তমান সেশনটি লাইফলাইন হিসেবে খুলে রাখুন। চালু করে আশা করে বসে থাকবেন না।

দ্বিতীয় কাজ: listener-কে প্রতিটি ইন্টারফেসে রাখার বদলে নির্দিষ্ট হোস্টে bind করুন। listener.ora-তে 0.0.0.0-র বদলে হোস্টের নাম স্পষ্ট করে লিখুন, যাতে listener এমন ইন্টারফেসে নিজেকে না দেয় যেখানে তার কাজ ছিল না।

কোনো নির্দিষ্ট ক্লায়েন্টের জন্য সত্যিই পাবলিক IP দরকার হলে সেটি VPN বা SSH টানেলের আলোচনা - পোর্ট পৃথিবীর জন্য খুলে দেওয়ার কারণ নয়।

৫. দ্বিতীয় স্তর: Valid Node Checking

এই নিয়ন্ত্রণের নাম বেশিরভাগ DBA শুনেছেন, চালু করেছেন খুব কম জন। এটি listener-কে ফায়ারওয়াল-নিরপেক্ষ নিজের allow list দেয়।

এটি থাকে sqlnet.ora-তে, যে Oracle home থেকে listener চলে সেখানে:

# $ORACLE_HOME/network/admin/sqlnet.ora
tcp.validnode_checking = yes
tcp.invited_nodes = (10.0.0.20, 10.0.0.21, appsrv1.example.local, localhost)
# tcp.excluded_nodes-ও আছে, তবে allow list সবসময় block list-এর চেয়ে ভালো

তিনটি খুঁটিনাটি ঠিক করে দেয় এটি উপকার করবে না ক্ষতি।

এটি authentication-এর আগেই প্রয়োগ হয়। বাতিল হওয়া ক্লায়েন্টকে listener-ই ফিরিয়ে দেয়, ডেটাবেজ পর্যন্ত সে পৌঁছায় না - তাই brute-force চেষ্টার কথা বলার কেউ থাকে না।

নিজেকে রাখুন। localhost বা নিজের ম্যানেজমেন্ট হোস্ট বাদ দিলে যে টুল দিয়ে ঠিক করবেন সেটিই আটকে যাবে।

এটি কাজ করতে listener রিস্টার্ট লাগে। সেটি নিরাপদ - আমার listener ও TNS ট্রাবলশুটিং গাইডে যেমন লিখেছি, listener রিস্টার্ট প্রতিষ্ঠিত সেশন কখনও ডিসকানেক্ট করে না।

Exclusion list-এর চেয়ে allow list বেছে নিন। কে কানেক্ট করতে পারবে তা একবারের সিদ্ধান্ত; কে পারবে না তার তালিকা কখনও শেষ হয় না।

৬. তৃতীয় স্তর: ADMIN_RESTRICTIONS

ডিফল্টে listener কিছু রানটাইম কনফিগ পরিবর্তন মেনে নেয়। প্রোডাকশন সিস্টেমে আপনি সেটি চান না।

listener.ora-র একটি লাইনেই বন্ধ হয়:

# listener.ora - নিজের listener নাম বসান
ADMIN_RESTRICTIONS_LISTENER = ON

এটি চালু থাকলে চলমান কনফিগ বদলে দেবে এমন lsnrctl set কমান্ড বাতিল হয়। পরিবর্তন করতে হলে ফাইল এডিট করে reload দিতে হয় - অর্থাৎ প্রতিটি পরিবর্তন এমন ফাইলে চিহ্ন রেখে যায় যা আপনি version করতে ও রিভিউ করতে পারেন।

পরিচালনার খরচ কম, অডিটের লাভ বাস্তব। কোনো প্যারামিটার বদলালে বোঝা যায় কেউ ফাইল এডিট করেছে - রানটাইমে নিজে নিজে সরে যায়নি।

৭. চতুর্থ স্তর: Listener Password সেট করবেন না

পুরনো রিলিজে Oracle শেখা মানুষের কাছে এটি অবাক লাগে, কারণ তখন listener password দেওয়াই ছিল স্বাভাবিক পরামর্শ।

Listener password এখন অবচিত। আধুনিক রিলিজ বদলে নির্ভর করে স্থানীয় অপারেটিং সিস্টেম authentication-এর ওপর, আর সেটিই ডিফল্ট এবং শক্ত নিয়ন্ত্রণ।

যুক্তিটা মজবুত। OS authentication মানে listener প্রশাসন কেবল সেই OS অ্যাকাউন্টের পক্ষেই সম্ভব যিনি listener প্রসেসের মালিক, এবং সার্ভারে স্থানীয়ভাবে।

পাসওয়ার্ড উল্টো মনিটরিং স্ক্রিপ্টে পেস্ট হয়, হ্যান্ডওভারে শেয়ার হয়, আর কেউ মনে রাখে না এমন জায়গায় প্লেইন টেক্সটে পড়ে থাকে। তখন যার হাতে সেটি আছে তার জন্যই দূরবর্তী প্রশাসন সম্ভব হয়ে যায়।

তাই এখানে সঠিক কাজ সাধারণত সরিয়ে ফেলা: উত্তরাধিকারসূত্রে পাওয়া সিস্টেমে listener password সেট থাকলে সেটি বাদ দিয়ে স্থানীয় OS authentication ও ফাইল পারমিশনের ওপর নির্ভর করার পরিকল্পনা করুন।

৮. পঞ্চম স্তর: TNS Poisoning ও নিরাপদ Registration

এটি কম পরিচিত, আর আপনার দশ মিনিট মনোযোগ পাওয়ার যোগ্য।

Service registration গতিশীল। ইনস্ট্যান্স তার service listener-এ রেজিস্টার করে, আর ডিফল্টে listener TCP-র মাধ্যমে আসা registration মেনে নেয়।

ওই ডিফল্টই ফাঁক। Listener-এ পৌঁছাতে পারা দূরের কেউ একই service name দাবি করে নকল ইনস্ট্যান্স রেজিস্টার করতে পারে, এরপর listener সেশন সেদিকে পাঠাতে পারে - এই আক্রমণকেই সাধারণত TNS listener poisoning বলা হয়।

নথিভুক্ত প্রতিকার হলো Class of Secure Transports সীমাবদ্ধতা:

# listener.ora - service registration কেবল স্থানীয় IPC-তে
SECURE_REGISTER_LISTENER = (IPC)

স্থানীয় ইনস্ট্যান্স IPC দিয়েই রেজিস্টার করে, তাই বৈধ registration চলতে থাকে আর দূরবর্তী registration বাতিল হয়।

প্রোডাকশনের বাইরে আগে টেস্ট করুন, বিশেষত ক্লাস্টার কনফিগারেশনে যেখানে registration-এর পথ আরও জটিল। আর প্যাচ হালনাগাদ রাখুন - কনফিগ পরিবর্তনটি নিয়ন্ত্রণ, কিন্তু প্যাচই মূল ত্রুটি সরায়।

৯. তারের ওপর এনক্রিপশন

অপরিচিতদের জন্য পোর্ট বন্ধ করলেও প্রশ্ন থাকে - আপনার অনুমোদিত ক্লায়েন্টরা ওই পোর্ট দিয়ে কী পাঠাচ্ছে।

ডিফল্টে Oracle ক্লায়েন্ট ট্রাফিক এনক্রিপ্ট করা নয়। সমতল অভ্যন্তরীণ নেটওয়ার্কে ক্রেডেনশিয়াল ও কোয়েরির ফলাফল প্যাকেট ধরতে পারা যেকোনো ব্যক্তির কাছে পাঠযোগ্য।

দুটি উপায় আছে, আর দুটোর যেকোনোটিই কিছু-না-করার চেয়ে অনেক ভালো।

Native network encryption হালকা কাজ - সার্ভার ও ক্লায়েন্টে sqlnet.ora দিয়েই হয়, সার্টিফিকেট সামলানোর ঝামেলা নেই।

TCPS (TLS) শক্ত উপায়, wallet ও সার্টিফিকেট ব্যবহার করে, আর নিয়ন্ত্রিত পরিবেশ এটিই চাইবে।

ফার্মাসিউটিক্যাল ও ব্যাংকিং সিস্টেমে আমি সাধারণত TCPS সুপারিশ করি, কারণ ট্রান্সপোর্ট নিরাপত্তা প্রমাণযোগ্যভাবে সার্টিফিকেট-ভিত্তিক হলে অডিটের আলোচনা অনেক সহজ হয়। বড় ছবিটি আমি Oracle ডেটাবেজ নিরাপত্তায় আলোচনা করেছি।

১০. Listener লগ: যে ফরেনসিক রেকর্ড কেউ পড়ে না

মনিটরিং ছাড়া hardening একটি অনুমান। সৌভাগ্যক্রমে listener প্রমাণ আগেই রেখে দেয়।

ফাইলসিস্টেম হাতড়ানোর বদলে ADR দিয়ে লগ খুঁজুন:

lsnrctl status        # listener লগের অবস্থান দেখায়
adrci
  show homes
  set home diag/tnslsnr/<host>/listener
  show alert -tail 50

ইন্টারনেটমুখী যেকোনো সিস্টেমে তিনটি প্যাটার্ন grep করার মতো।

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

বারবার service-name ব্যর্থতা। এক ঠিকানা থেকে সারি সারি TNS-12514 প্রায়ই ভাঙা ক্লায়েন্ট নয়, বরং কেউ service name আন্দাজ করছে।

আপনি করেননি এমন registration ইভেন্ট। ৮ নম্বর অংশ মনে রাখলে বোঝা যায় এগুলো তাৎক্ষণিক মনোযোগ দাবি করে।

সম্ভব হলে এই লগ কেন্দ্রীয় কোথাও পাঠান। যে লগ কেবল আক্রান্ত হোস্টেই থাকে, সেটি নির্ভর করার মতো প্রমাণ নয়।

১১. RAC ও SCAN-এর সতর্কতা

ওপরের সবকিছু ক্লাস্টার ডেটাবেজেও প্রযোজ্য, একটি গুরুত্বপূর্ণ সমন্বয়সহ।

RAC পরিবেশে কানেকশন আসে SCAN listener ও node VIP দিয়ে, আর ইনস্ট্যান্স ক্লাস্টারজুড়ে রেজিস্টার করে। একক-ইনস্ট্যান্স মানসিকতায় বানানো allow list সেটি ভেঙে দেবে।

RAC-এ valid node checking ব্যবহার করলে invited তালিকায় প্রতিটি ক্লাস্টার নোড, VIP ও SCAN ঠিকানা এবং আপনার অ্যাপ্লিকেশন হোস্ট থাকতে হবে। একটি বাদ পড়লে সেটি টের পাবেন failover-এর সময় - সবচেয়ে বাজে সময়ে।

আগে প্রোডাকশনের বাইরের ক্লাস্টারে টেস্ট করুন, তারপর নোড ধরে ধরে প্রয়োগ করুন। ওই কানেকশন-পথগুলো কীভাবে মেলে তা আমার RAC 19c গাইডে আছে।

১২. আজই চালানোর মতো চেকলিস্ট

1. ss -lntp | grep 1521 - binding * না নির্দিষ্ট, লিখে রাখুন।
2. systemctl is-active firewalld - inactive হলে সেটাই এক নম্বর finding।
3. নেটওয়ার্কের বাইরে থেকে পাবলিক IP-তে পোর্ট টেস্ট করুন।
4. কিছু চালু করার আগে নামধারী সোর্স থেকে SSH ও 1521 অনুমোদনের ফায়ারওয়াল নিয়ম লিখুন।
5. listener.ora-তে listener-কে প্রতিটি ইন্টারফেসের বদলে নির্দিষ্ট হোস্টে bind করুন।
6. tcp.validnode_checking ও tcp.invited_nodes যোগ করুন - localhost ও নিজের অ্যাডমিন হোস্টসহ।
7. ADMIN_RESTRICTIONS_<listener> = ON সেট করুন।
8. যেকোনো listener password সরান; স্থানীয় OS authentication-এ নির্ভর করুন।
9. প্রোডাকশনের বাইরে টেস্ট করে SECURE_REGISTER_LISTENER = (IPC) যোগ করুন।
10. ট্রানজিটে এনক্রিপশন চালু করুন - অন্তত native encryption, যেখানে জরুরি সেখানে TCPS।
11. listener.log-এ অচেনা সোর্স, বারবার 12514 আর অযাচিত registration দেখুন।
12. শান্ত সময়ে listener রিস্টার্ট দিয়ে নিশ্চিত হোন অ্যাপ্লিকেশনগুলো পরিষ্কারভাবে আবার কানেক্ট করছে।

একক-ইনস্ট্যান্স ডেটাবেজে এর বেশিরভাগই বিশ মিনিটের কাজ। বেশি সময় নেয় কোন হোস্টগুলো allow list-এ থাকবে সেটি ঠিক করা - আর ওই আলোচনাই আসল মূল্য, কারণ এটি কাউকে লিখে ফেলতে বাধ্য করে আসলে কার ডেটাবেজে পৌঁছানোর কথা।

সাধারণ জিজ্ঞাসা (FAQ)

Oracle পোর্ট 1521 ইন্টারনেটে খোলা রাখা কি নিরাপদ?

না। খোলা listener নিজের সম্পর্কে প্রশ্নের উত্তর দেয় কোনো authentication ছাড়াই, তাই যে-ই পোর্টে পৌঁছাতে পারে সে বিনা ক্রেডেনশিয়ালে আপনার ডেটাবেজ ভার্সন ও প্রায়ই service name জেনে ফেলে। ওই তথ্যই লক্ষ্যভিত্তিক আক্রমণের রূপ দেয়, আর পোর্টটি brute-force চেষ্টার লক্ষ্যও হয়ে যায়। ডেটাবেজ listener কেবল প্রয়োজনীয় অ্যাপ্লিকেশন হোস্ট থেকেই পৌঁছানো উচিত।

আমার listener উন্মুক্ত কি না কীভাবে দেখব?

সার্ভারে ss -lntp | grep 1521 চালান - *:1521 বা 0.0.0.0:1521 দেখালে listener প্রতিটি ইন্টারফেসে bind করা। এরপর নেটওয়ার্কের বাইরে থেকে পাবলিক IP-তে পোর্ট টেস্ট করুন। ইন্টারনেট থেকে পৌঁছানো যাচ্ছে আর firewalld inactive - মানে পোর্টটি একেবারেই ফিল্টার হচ্ছে না।

Oracle-এ valid node checking কী?

Valid node checking হলো sqlnet.ora-তে কনফিগার করা listener-স্তরের একটি allow list। tcp.validnode_checking = yes এবং tcp.invited_nodes সেট করলে listener কেবল আপনার নাম করা হোস্টগুলো থেকেই কানেকশন নেয়, বাকি সব বাতিল করে। এটি authentication-এর আগেই প্রয়োগ হয়, তাই বাতিল হওয়া ক্লায়েন্ট ডেটাবেজ পর্যন্ত পৌঁছায় না।

Listener রিস্টার্ট করলে চলমান ইউজাররা ডিসকানেক্ট হয়?

না। Listener কেবল নতুন কানেকশনের মধ্যস্থতা করে - সেশন একবার প্রতিষ্ঠিত হলে listener পথ থেকে সরে যায়। রিস্টার্ট কয়েক সেকেন্ড নতুন কানেকশন আটকায়, কিন্তু আগে থেকে কানেক্টেড সেশনে কখনও হাত দেয় না - এ কারণেই listener hardening বড় আউটেজ উইন্ডো ছাড়াই প্রয়োগ করা যায়।

Listener password সেট করা উচিত?

না। Listener password অবচিত, আর Oracle-এর সুপারিশ হলো স্থানীয় অপারেটিং সিস্টেম authentication - যা আধুনিক রিলিজে ডিফল্টও। এর মানে listener প্রশাসন কেবল সেই OS ইউজারের পক্ষেই সম্ভব যিনি listener প্রসেসের মালিক, এবং সেটিও সার্ভারে স্থানীয়ভাবে - স্ক্রিপ্টে গিয়ে পড়ে থাকা পাসওয়ার্ডের চেয়ে অনেক শক্ত।

TNS listener poisoning কী এবং কীভাবে আটকাব?

এটি এমন আক্রমণ যেখানে দূরের কেউ TCP-র মাধ্যমে আপনার listener-এ একটি নকল ইনস্ট্যান্স রেজিস্টার করে, ফলে listener সেশন সেদিকে পাঠাতে শুরু করে। নথিভুক্ত প্রতিকার হলো Class of Secure Transports সেটিং: listener.ora-তে SECURE_REGISTER_LISTENER = (IPC), যা service registration কেবল স্থানীয় IPC-তে সীমিত করে। সঙ্গে সর্বশেষ প্যাচও প্রয়োগ করুন।