Question 1

এটি কি একটি সক্রিয় আক্রমণ?

Accepted Answer

না। এটি সাধারণ GET, HEAD ও OPTIONS অনুরোধ, TLS হ্যান্ডশেক (TLS 1.0 ও 1.1-এর চেষ্টাসহ), Cloudflare-এর DNS-over-HTTPS দিয়ে DNS লুকআপ এবং ১২টি পোর্টে সাধারণ TCP সংযোগ করে। কিছুই এক্সপ্লয়েট করা হয় না, কোনো ফর্ম জমা দেওয়া হয় না এবং কিছুই বদলানো হয় না।

Question 2

আমি কি কোনো ওয়েবসাইট স্ক্যান করতে পারি?

Accepted Answer

শুধুমাত্র সেগুলো যেগুলোর আপনি মালিক বা পরীক্ষা করার জন্য যার অনুমোদন আপনার আছে। অনুমতি ছাড়া তৃতীয় পক্ষের ইনফ্রাস্ট্রাকচার স্ক্যান করা আপনার অবস্থানে অবৈধ হতে পারে।

Question 3

একটি পরীক্ষা কেন "পরীক্ষা করা হয়নি" বলে?

Accepted Answer

কারণ এটি সম্পূর্ণ করা যায়নি - সাধারণত কারণ সেই উৎস থেকে কিছুই সাড়া দেয়নি। এটি সততার সাথে রিপোর্ট করা হয়, পাস হিসেবে নথিভুক্ত করার পরিবর্তে।

Question 4

আমি কি রিপোর্ট এক্সপোর্ট করতে পারি?

Accepted Answer

হ্যাঁ, Markdown বা JSON হিসেবে, এক ঘণ্টা পর্যন্ত: ডাউনলোড যাতে কাজ করে সেজন্য রিপোর্ট ততক্ষণ সার্ভার ক্যাশে থাকে, তারপর মেয়াদ শেষ হয়। কোনো এক্সপোর্টেই মডেল লাগে না। ব্যবহারের রেকর্ডে ফাইন্ডিংয়ের সংখ্যা ও গ্রেড থাকে, ডোমেন নয়।

Question 5

এটি কোন ফাইল ও পোর্ট পরীক্ষা করে?

Accepted Answer

ফাইল: 23টি নির্দিষ্ট পাথ, যার মধ্যে আছে /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env; প্রতিটি কেবল তখনই রিপোর্ট হয় যখন উত্তর সেই ফাইলের নিজস্ব সিগনেচারের সঙ্গে মেলে। /.well-known/security.txt প্রকাশিত থাকলে তা আপনার পক্ষে গণ্য হয়। পোর্ট: 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080-এ একটি সাধারণ TCP সংযোগ, কখনো লগইনের চেষ্টা নয়। ইন্টারনেট থেকে পৌঁছানো যায় এমন ডেটাবেস পোর্ট (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) বা Telnet ক্রিটিক্যাল হিসেবে ধরা হয়।

Question 6

SPF ও DMARC পরীক্ষা কী কী চিহ্নিত করে?

Accepted Answer

দুটি রেকর্ডই পাবলিক DNS থেকে পড়া হয়, যে সাইট ইমেল পাঠায় না তার ক্ষেত্রেও, কারণ এগুলো না থাকলে যে কেউ আপনার ডোমেন থেকে আসার দাবি করে ইমেল পাঠাতে পারে। SPF রেকর্ড না থাকলে মাঝারি; +all থাকা SPF রেকর্ড, যা ইন্টারনেটের সব সার্ভারকে অনুমতি দেয়, উচ্চ। _dmarc-এ DMARC রেকর্ড না থাকলে মাঝারি; p=none (বা p= ট্যাগ না থাকলে) কেবল পর্যবেক্ষণ করে এবং নিম্ন; p=quarantine বা p=reject পাস করে। যে ডোমেন কোনো ইমেলই পাঠায় না, সেটি v=spf1 -all প্রকাশ করতে পারে।

Question 7

এটি কোন কোন সিকিউরিটি হেডার পরীক্ষা করে, আর কোন মান পাস করে?

Accepted Answer

আপনার হোমপেজের রেসপন্সের ছয়টি হেডার। না থাকলে HSTS ও Content-Security-Policy উচ্চ, X-Content-Type-Options ও X-Frame-Options মাঝারি, Referrer-Policy ও Permissions-Policy নিম্ন। Strict-Transport-Security-এ max-age অন্তত 15552000 (১৮০ দিন) হতে হবে: কম হলে নিম্ন, max-age=0 হলে মাঝারি। script-src যদি 'unsafe-inline' অনুমতি দেয়, পলিসি যদি 'unsafe-eval' অনুমতি দেয়, অথবা default-src বা script-src-এ যদি একক * ওয়াইল্ডকার্ড থাকে, তবে Content-Security-Policy দুর্বল (মাঝারি) হিসেবে চিহ্নিত হয়। X-Content-Type-Options হুবহু nosniff হতে হবে। X-Frame-Options হতে হবে DENY বা SAMEORIGIN, আর CSP-তে frame-ancestors থাকলে এটি লাগে না। Referrer-Policy কেবল unsafe-url বা no-referrer-when-downgrade হলে চিহ্নিত হয়। Permissions-Policy শুধু থাকলেই হয়। প্রতিটি অনুপস্থিত বা দুর্বল হেডারের সঙ্গে একটি curl -sI কমান্ড থাকে, যাতে আপনি নিজে যাচাই করতে পারেন।

Question 8

এটি কুকির ফ্ল্যাগ (Secure, HttpOnly, SameSite) কীভাবে যাচাই করে?

Accepted Answer

এটি আপনার হোমপেজের রেসপন্সের প্রতিটি Set-Cookie হেডার পড়ে (সর্বোচ্চ 12টি কুকি) এবং প্রতিটিতে Secure, HttpOnly ও SameSite যাচাই করে। Secure বা HttpOnly না থাকলে মাঝারি; শুধু SameSite না থাকলে নিম্ন, আর Secure ছাড়া SameSite=None আলাদা করে জানানো হয়, কারণ ব্রাউজার এমন কুকি প্রত্যাখ্যান করে। তিনটিই থাকলে কুকিটি পাস করে। সাধারণ সমাধান Secure; HttpOnly; SameSite=Lax (Django-তে: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY ও SESSION_COOKIE_SAMESITE)। স্ক্যান লগ ইন করে না, তাই শুধু লগইনের পরে তৈরি হওয়া কুকি এটি দেখে না। নিজে যাচাই করুন: curl -sI https://your-site/ | grep -i set-cookie

Question 9

CORS যাচাই কীভাবে কাজ করে, আর কখন এটি গুরুতর?

Accepted Answer

এটি আপনার হোমপেজে Origin: https://scanner-probe.example সহ একটি GET অনুরোধ পাঠায় এবং উত্তরে Access-Control-Allow-Origin ও Access-Control-Allow-Credentials পড়ে। Access-Control-Allow-Origin হেডার না থাকলে, অথবা এমন নির্দিষ্ট origin থাকলে যা পরীক্ষার origin ফেরত দেয় না, পাস। পরীক্ষার origin Access-Control-Allow-Credentials: true সহ ফেরত দেওয়া গুরুতর, কারণ লগ ইন করা ব্যবহারকারী যে সাইটেই যান সেটি তাঁর রেসপন্স পড়তে পারে। ক্রেডেনশিয়াল ছাড়া origin ফেরত দেওয়া মাঝারি। ওয়াইল্ডকার্ড * নিম্ন, তবে ক্রেডেনশিয়ালও অনুমোদিত হলে মাঝারি (ব্রাউজার এই সমন্বয় প্রত্যাখ্যান করে)। শুধু হোমপেজ পরীক্ষা করা হয় এবং OPTIONS প্রিফ্লাইট পাঠানো হয় না, তাই আপনার API রুট আলাদাভাবে পরীক্ষা করুন: curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control

Question 10

TLS পরীক্ষা কী যাচাই করে (সার্টিফিকেটের মেয়াদ, TLS 1.0 ও 1.1)?

Accepted Answer

এটি পোর্ট 443-এ সংযোগ করে এবং সার্টিফিকেট চেইন ও হোস্টনেম যাচাই করে। যে সার্টিফিকেট যাচাইয়ে টেকে না তার তীব্রতা উচ্চ, মেয়াদোত্তীর্ণ সার্টিফিকেট এর পাশাপাশি ক্রিটিকাল হিসেবে চিহ্নিত হয়, আর যার 15 দিনের কম বাকি সেটি মাঝারি; অন্যথায় সাবজেক্ট, ইস্যুকারী, মেয়াদ শেষের তারিখ ও SAN নামগুলো পাস হিসেবে দেখানো হয়। আলোচনায় ঠিক হওয়া প্রোটোকল TLS 1.2 বা TLS 1.3 হতে হবে, এর চেয়ে পুরোনো যেকোনোটি উচ্চ। এরপর এটি আলাদাভাবে একটি TLS 1.0 ও একটি TLS 1.1 হ্যান্ডশেক চেষ্টা করে: যে সার্ভার এর কোনোটি গ্রহণ করে সেটি মাঝারি ফাইন্ডিং পায়, কারণ RFC 8996 দুটিকেই অপ্রচলিত ঘোষণা করেছে। স্ক্যানারের নিজের OpenSSL পুরোনো সংস্করণ দিতে না পারলে অনুমান না করে কিছুই রিপোর্ট করা হয় না। nginx-এ সমাধান হলো ssl_protocols TLSv1.2 TLSv1.3; তারিখগুলো নিজে এই কমান্ডে দেখুন: echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates

Question 11

এটি কি যাচাই করে যে HTTP থেকে HTTPS-এ রিডাইরেক্ট হয়?

Accepted Answer

হ্যাঁ। এটি রিডাইরেক্ট অনুসরণ না করে http://your-site/ অনুরোধ করে। কোনো https:// ঠিকানায় 301 বা 308 পাস। HTTPS-এ 302, 303 বা 307 নিম্ন, কারণ ব্রাউজার অস্থায়ী রিডাইরেক্ট মনে রাখে না, তাই প্রতিটি নতুন ভিজিট একটি এনক্রিপশনহীন অনুরোধ দিয়ে শুরু হয়। এনক্রিপশনহীন HTTP-তে পরিবেশিত পেজ (2xx উত্তর) উচ্চ। পোর্ট 80 একেবারেই সাড়া না দিলে সেটি তথ্যমূলক, ব্যর্থতা নয়। nginx-এ সমাধান হলো server { listen 80; return 301 https://$host$request_uri; }, তারপর Strict-Transport-Security যোগ করুন। নিজে এই কমান্ডে দেখুন: curl -I http://your-site/

Question 12

এটি কোন HTTP মেথডগুলো চিহ্নিত করে (TRACE, PUT, DELETE)?

Accepted Answer

এটি আপনার হোমপেজে একটি OPTIONS অনুরোধ পাঠায় এবং Allow হেডার পড়ে, Allow না থাকলে Access-Control-Allow-Methods। TRACE, TRACK, PUT বা DELETE ঘোষিত থাকলে তীব্রতা মাঝারি; শুধু PATCH বা CONNECT নিম্ন; কেবল সাধারণ পড়ার মেথড থাকলে পাস। সার্ভার এই দুটি হেডারের কোনোটিই না পাঠালে কিছু রিপোর্ট হয় না। কোনো মেথড ঘোষিত থাকলেই তা কাজ করে এমন প্রমাণ হয় না, তাই কিছু বদলানোর আগে নিশ্চিত হয়ে নিন। TRACE অনুরোধের হেডার, কুকি সহ, প্রেরকের কাছে ফেরত পাঠাতে পারে (Cross-Site Tracing)। nginx ডিফল্টভাবে TRACE প্রত্যাখ্যান করে; Apache-এ TraceEnable Off সেট করুন। PUT ও DELETE কেবল যেসব API রুটের দরকার সেগুলোতে সীমিত রাখুন, অথেনটিকেশনের পেছনে। নিজে এই কমান্ডে দেখুন: curl -X OPTIONS -i https://your-site/

Question 13

এটি ডিরেক্টরি লিস্টিং ("Index of /") কীভাবে ধরে?

Accepted Answer

এটি 7টি পাথ অনুরোধ করে: /, /static/, /assets/, /uploads/, /images/, /files/ এবং /backup/। যে পাথ HTTP 200 দিয়ে এমন পেজ ফেরত দেয় যার টাইটেল বা প্রধান হেডিং "Index of /" দিয়ে শুরু, সেটি মাঝারি তীব্রতায় রিপোর্ট হয় (CWE-548), কারণ লিস্টিং এমন ফাইল দেখিয়ে দেয় যেগুলোর কোথাও লিংক নেই, যেমন ব্যাকআপ, এক্সপোর্ট ও পুরোনো সংস্করণ। কোনো পাথ এমন না করলে পরীক্ষা পাস; সাইটে পৌঁছানো না গেলে এটি সম্পন্ন হয়নি হিসেবে দেখানো হয়। nginx-এ সমাধান হলো autoindex off; (এটিই ডিফল্ট, তাই স্পষ্টভাবে লেখা autoindex on খুঁজুন), Apache-এ Options -Indexes, তারপর সংবেদনশীল সবকিছু ওয়েব রুটের বাইরে সরান। নিজে এই কমান্ডে দেখুন: curl -s https://your-site/uploads/ | head -20

Question 14

এটি কি মিশ্র কনটেন্ট আর HTTP দিয়ে পাঠানো ফর্ম ধরে?

Accepted Answer

হ্যাঁ, হোমপেজে। সার্ভার যেভাবে HTML পাঠায় সেভাবেই এটি পড়ে (কোনো JavaScript চালানো হয় না) এবং যেসব script, link, iframe বা img ট্যাগের src বা href http:// দিয়ে শুরু, সেগুলোর তালিকা দেয়। এর কোনোটি .js বা .css ফাইল হলে ফলাফল মাঝারি, কারণ পথে বদলে দেওয়া স্ক্রিপ্ট বা স্টাইলশিট আপনার HTTPS পেজের ভেতরে চলে; শুধু ছবি ও ফ্রেম হলে নিম্ন; একটিও না থাকলে পাস (CWE-311)। যে ফর্মের action http:// দিয়ে শুরু, সেটি উচ্চ হিসেবে দেখানো হয় (CWE-319), কারণ এতে যা লেখা হয়, পাসওয়ার্ডসহ, সব এনক্রিপশন ছাড়া যায়। সমাধান: এই URLগুলো https:// করুন বা রিলেটিভ করুন, আর নিরাপত্তা জাল হিসেবে Content-Security-Policy: upgrade-insecure-requests হেডার যোগ করুন। নিজে যাচাই করুন: curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"

Question 15

এটি robots.txt আর security.txt-এ কী পরীক্ষা করে?

Accepted Answer

robots.txt: এটি /robots.txt আনে এবং উত্তর HTTP 200 সহ টেক্সট ফাইল হলে প্রথম 8000 অক্ষরের Disallow লাইনগুলো পড়ে। যে Disallow পাথে admin, internal, private, backup, config, staging, test, api, secret, dev শব্দগুলোর কোনোটি থাকে সেটি নিম্ন হিসেবে দেখানো হয় (CWE-200): robots.txt সবার জন্য খোলা এবং শুধু নিয়ম মানা ক্রলারদের দূরে থাকতে বলে, তাই এই পাথগুলো লিখে রাখা মানে সেগুলোর বিজ্ঞাপন দেওয়া। লগইন দিয়ে সেগুলো সুরক্ষিত করুন, আর পেজ সার্চের বাইরে রাখতে noindex ব্যবহার করুন। security.txt: এটি /.well-known/security.txt চায়, যা RFC 9116 নির্ধারিত জায়গা, এবং ফাইলে Contact: লাইন থাকলে তা আপনার পক্ষে গোনে। ফাইল না থাকলে নম্বর কাটে না। RFC 9116 একটি Expires: ফিল্ডও বাধ্যতামূলক করে, যা স্ক্যান যাচাই করে না, তাই দুটোই প্রকাশ করুন, যেমন Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z। নিজে যাচাই করুন: curl -s https://your-site/.well-known/security.txt

Question 16

CAA যাচাই কী খোঁজে এবং CAA রেকর্ড কীভাবে যোগ করব?

Accepted Answer

এটি আপনার দেওয়া হোস্ট নামের CAA রেকর্ড (RFC 8659) Cloudflare-এর DNS-over-HTTPS দিয়ে খোঁজে। রেকর্ড পেলে যাচাই পাস হয় এবং প্রমাণে সর্বোচ্চ 5টি দেখায়; একটিও না পেলে "No CAA record" কম গুরুত্বে জানায়, কারণ তখন যেকোনো পাবলিক সার্টিফিকেট কর্তৃপক্ষ (CA) ওই নামের জন্য সার্টিফিকেট দিতে পারে। CAA রেকর্ডে আপনি আসলে যে CA ব্যবহার করেন সেগুলোর তালিকা থাকে, যেমন your-site. IN CAA 0 issue "letsencrypt.org", সঙ্গে রিপোর্ট পেতে 0 iodef "mailto:security@your-site"। প্রতিটি ব্যবহৃত CA-এর জন্য একটি issue লাইন যোগ করুন, আর ওয়াইল্ডকার্ড সার্টিফিকেট অন্য CA থেকে আসার কথা হলে একটি issuewild লাইন। নিজে যাচাই করুন: dig CAA your-site

Question 17

www বা কোনো সাবডোমেন স্ক্যান করলে CAA, SPF বা DMARC নেই বলে কেন দেখায়?

Accepted Answer

প্রতিটি DNS যাচাই ঠিক আপনার দেওয়া নামেই চলে, তাই www.example.com খোঁজা হয় www.example.com হিসেবেই, example.com হিসেবে নয়, আর তিনটি রেকর্ড আলাদাভাবে উত্তরাধিকার পায়। CAA: যে সার্টিফিকেট কর্তৃপক্ষ www.example.com-এ CAA রেকর্ড পায় না, সে উপরে example.com-এ গিয়ে সেটি ব্যবহার করে (RFC 8659, অনুচ্ছেদ 3), তাই সাবডোমেনে "No CAA record" ভুল সতর্কতা হতে পারে। DMARC: প্রাপকেরা সাংগঠনিক ডোমেনের নীতিতে ফিরে যায়, যা sp= দিয়ে সাবডোমেনের জন্য আলাদা নীতি ঠিক করতে পারে (RFC 9989, যা RFC 7489-এর জায়গা নিয়েছে), তাই _dmarc.www.example.com-এ রেকর্ড না থাকলেও সাধারণত _dmarc.example.com সেটি ঢেকে দেয়। SPF: এতে উত্তরাধিকার নেই (RFC 7208), তাই ওই নামের জন্য "No SPF record" ঠিক; যে হোস্ট নাম ইমেইল পাঠায় না সেটি v=spf1 -all প্রকাশ করতে পারে। ব্যর্থ DNS খোঁজও রেকর্ড নেই হিসেবে দেখায়। www ছাড়া মূল ডোমেনও স্ক্যান করুন, অথবা dig CAA example.com ও dig TXT _dmarc.example.com দিয়ে নিশ্চিত হন

ওয়েবসাইট সিকিউরিটি স্ক্যান

সম্পর্কে ওয়েবসাইট সিকিউরিটি স্ক্যান

এটি কী করে

এটি যেভাবে কাজ করে

কোনো ফলাফল বানানো নয়

গ্রেড কীভাবে হিসাব হয়

ভুল সতর্কতা এড়ানো

একটি পরিষ্কার রিপোর্ট কোনো সার্টিফিকেট নয়

শুধু আপনার নিজের জিনিসই স্ক্যান করুন

প্রশ্নাবলী