Subscription bombing தாக்குதலைத் தடுப்பது எப்படி?

Subscription bombing என்றால் என்ன?

Subscription bombing என்பது உங்கள் signup form-ஐப் பயன்படுத்தி மற்றொருவரின் inbox-ஐ மின்னஞ்சல்களால் நிரப்பும் ஒரு தாக்குதல் ஆகும். தாக்குதல் நடத்துபவர் பாதிக்கப்பட்டவரின் மின்னஞ்சல் முகவரியை எடுத்து, குறுகிய கால இடைவெளியில் நூற்றுக்கணக்கான அல்லது ஆயிரக்கணக்கான பாதுகாப்பு இல்லாத படிவங்களில் (forms) சமர்ப்பிப்பார். அந்தத் தளங்கள் ஒவ்வொன்றும் அந்த முகவரிக்கு ஒரு வரவேற்புச் செய்தியையோ அல்லது உறுதிப்படுத்தல் செய்தியையோ அனுப்பும். இந்தச் செய்திகள் அனைத்தும் சேர்ந்து, பாதிக்கப்பட்டவர் உண்மையில் படிக்க வேண்டிய மின்னஞ்சல்களை மறைத்துவிடும்.

அந்த inbox-க்குச் சொந்தமான நபரே இந்தத் தாக்குதலின் இலக்கு. inbox சந்தா உறுதிப்படுத்தல் செய்திகளால் நிரம்பும்போது, தாக்குதல் நடத்துபவர் அந்த நபரின் அட்டையைப் பயன்படுத்திப் பணம் செலவழிப்பார் அல்லது அவர்களின் கணக்குகளில் ஒன்றின் கடவுச்சொல்லை (password) மாற்றுவார். வங்கியிடமிருந்து வரும் மோசடி எச்சரிக்கை (fraud alert) மின்னஞ்சல் வந்து சேரும். ஆனால், அதே மணிநேரத்தில் வந்த இரண்டாயிரம் செய்திகளுக்கு அடியில் அது புதைந்துவிடுவதால், சரியான நேரத்தில் யாரும் அதைக் கவனிப்பதில்லை.

இந்தத் தாக்குதலைச் செய்வதற்கு உங்கள் server ஒரு கருவியாகப் பயன்படுத்தப்படுகிறது. உங்கள் server-ல் எதுவும் பழுதடையவில்லை. உங்கள் கணக்கு எதுவும் breached செய்யப்படவில்லை. யாரோ ஒருவர் ஒரு பொதுவான படிவத்தில் ஒரு முகவரியை உள்ளீடு செய்துள்ளார்; உங்கள் மென்பொருள் அதற்கு என்ன கட்டளையிடப்பட்டதோ அதைச் செய்துள்ளது: அது அந்த முகவரிக்கு மின்னஞ்சலை அனுப்பியுள்ளது. இதனால்தான் இதைத் தாக்குதல் என்று கண்டறிவது கடினமாக உள்ளது. உங்கள் logs-ல் எந்த ஊடுருவலும் (intrusion) இருக்காது, ஏனெனில் அங்கு எந்த ஊடுருவலும் நடக்கவில்லை.

இந்தத் தாக்குதல் உங்கள் தரப்பில் எவ்வாறு தெரிகிறது

இது இரண்டு வடிவங்களில் நிகழ்கிறது.

சத்தமான வடிவம் ஒரு திடீர் தாக்குதல் (burst). சில நிமிடங்களுக்குள் நூற்றுக்கணக்கான POST கோரிக்கைகள் ஒரே படிவத்தை (form) வந்தடையும். இவை பல வெவ்வேறு source IP முகவரிகளிலிருந்து வரும், மேலும் நீங்கள் இதுவரை மின்னஞ்சல் அனுப்பாத டொமைன்களைக் கொண்டிருக்கும். இதைக் கவனித்தால் எளிதாகக் கண்டறியலாம்.

அமைதியான வடிவம் எளிதில் கவனிக்கப்படாமல் போகக்கூடியது. தாக்குதல் நடத்துபவர் ஆயிரக்கணக்கான பாதிப்புள்ள படிவங்களின் பட்டியலை வைத்திருப்பார். எனவே உங்கள் படிவத்திற்கு ஒரு மணி நேரத்திற்கு ஒன்று அல்லது இரண்டு பதிவுகள் மட்டுமே வரும். Jye Cusch இந்த வகையான தாக்குதலைப் பற்றி விவரித்துள்ளார். அவர் இயக்கும் தளத்தில் எந்தவிதமான traffic அதிகரிப்பும் இல்லை, ஆனால் அவரது பார்வையாளர்களின் நேரத்திற்குப் பொருந்தாத நேரங்களில் தொடர்ந்து பதிவுகள் வந்தன. ஒரு படிவத்தைப் பொறுத்தவரை இது சாதாரணமானதாகத் தோன்றும், ஏனெனில் அது மிகக் குறைந்த அளவிலேயே செயல்படுகிறது. தாக்குதல் நடத்துபவரின் பட்டியலில் உள்ள அனைத்து படிவங்களிலும் நடக்கும் மொத்த பாதிப்பே உண்மையான சேதம்.

இரண்டு வடிவங்களும் தாக்குதலுக்குப் பிறகு ஒரு பொதுவான அடையாளத்தைக் கொண்டிருக்கும்: அதன் பிறகு எதுவும் நடக்காது. அந்த முகவரிகள் ஒருபோதும் உறுதிப்படுத்தப்படாது (confirm). அவை ஒரு செய்தியைத் திறப்பதில்லை, எந்த இணைப்பையும் கிளிக் செய்வதில்லை. உறுதிப்படுத்தப்பட்ட opt-in பட்டியலில் அவை unconfirmed நிலையில் நிரந்தரமாக இருக்கும். இந்தத் தேக்கமே உங்களுக்குக் கிடைக்கும் மிகத் தெளிவான ஆதாரமாகும்.

உங்கள் access log-ல் நிமிடத்திற்கு எத்தனை பதிவுகள் வருகின்றன என்பதைக் கணக்கிடுவதன் மூலம் தொடங்கவும்.

sudo awk '/POST \/subscription\/form/ {print substr($4, 2, 17)}' \
  /var/log/nginx/access.log | uniq -c | sort -rn | head

$4 என்பது இயல்புநிலை combined log format-ல் உள்ள அடைப்புக்குறிக்குள் இருக்கும் timestamp ஆகும். எனவே இது ஒவ்வொரு நிமிடத்திற்கும் பதிவுகளின் எண்ணிக்கையை, அதிகபட்ச எண்ணிக்கையிலிருந்து வரிசைப்படுத்தி அச்சிடும். பொதுவாக ஒரு நாளைக்கு நான்கு பதிவுகள் பெறும் ஒரு படிவத்தில், ஒரு நிமிடத்திற்கு அறுபது பதிவுகள் வந்தால், அது இயல்பான செயல்பாடு அல்ல.

Confirmed opt-in: அதிக தாக்கத்தை ஏற்படுத்தும் பாதுகாப்பு முறை

Confirmed opt-in, பொதுவாக double opt-in என்று அழைக்கப்படுகிறது. ஒரு மின்னஞ்சல் முகவரிக்கு அனுப்பப்படும் செய்தியில் உள்ள இணைப்பை (link) பயனர் கிளிக் செய்யும் வரை, அந்த முகவரி சந்தாதாரராகக் கருதப்படாது என்பதே இதன் பொருள். இதைச் செயல்படுத்தினால், சமர்ப்பிக்கப்பட்ட ஒவ்வொரு முகவரிக்கும் ஒரே ஒரு செய்தி மட்டுமே அனுப்பப்படும். அந்த முகவரி பட்டியலில் சேராதவரை, அதற்கு எந்தவொரு பிரச்சாரச் செய்தியோ (campaign) அல்லது வரவேற்புச் செய்தியோ (welcome sequence) அனுப்பப்படாது.

listmonk, the self-hosted newsletter server-ல் இது ஒவ்வொரு பட்டியலுக்கும் (per-list) தனித்தனியாக அமைக்கப்படும் அமைப்பாகும்: ஒரு பட்டியல் single opt-in அல்லது double opt-in ஆக இருக்கலாம். இதற்கிடையேயான வேறுபாட்டை ஆவணங்கள் தெளிவாக விளக்குகின்றன. Double opt-in பட்டியலில், சந்தாதாரர்கள் "தங்களுக்கு வரும் உறுதிப்படுத்தல் மின்னஞ்சலை கிளிக் செய்வதன் மூலம் சந்தாவை வெளிப்படையாக ஏற்க வேண்டும். அதுவரை, அவர்களுக்கு பிரச்சாரச் செய்திகள் அனுப்பப்படாது." ஒரு சந்தாதாரர் unconfirmed நிலையில் இருப்பார், கிளிக் செய்தவுடன் confirmed நிலைக்கு மாறுவார், மேலும் opt-in பட்டியலில் உள்ள confirmed சந்தாதாரர்களுக்கு மட்டுமே பிரச்சார மின்னஞ்சல்கள் செல்லும்.

இது உங்களுக்கு என்ன பலனைத் தருகிறது என்பதைத் தெளிவாகப் புரிந்துகொள்ளுங்கள். Confirmed opt-in உங்கள் பங்களிப்பை பூஜ்ஜியமாக்காது. இது ஒரு முகவரிக்கு அனுப்பப்படும் செய்திகளின் எண்ணிக்கையை ஒன்றாகக் கட்டுப்படுத்துகிறது. பாதிக்கப்பட்டவர் அந்த ஒரு செய்தியைப் பெறுவார், ஆயிரம் தளங்களிலிருந்து தலா ஒரு செய்தி வருவதுதான் முழுத் தாக்குதலும். Confirmed opt-in எதை நீக்குகிறது என்றால், அதற்குப் பிந்தைய அனைத்தையும் தான்: உங்கள் பட்டியல் சுத்தமாக இருக்கும், மேலும் முதல் செய்தியை வேண்டாத ஒருவருக்கு நீங்கள் இரண்டாவது செய்தியை அனுப்ப மாட்டீர்கள்.

இன்னும் இரண்டு அமைப்புகள் முக்கியமானவை, ஆனால் இரண்டையும் மறந்துவிடுவது எளிது. முதலாவதாக, உறுதிப்படுத்தல் மின்னஞ்சல்களை மீண்டும் அனுப்புவதைக் கட்டுப்படுத்துங்கள் (cap resends). ஒரே முகவரியைச் சமர்ப்பித்து ஒவ்வொரு முறையும் புதிய உறுதிப்படுத்தல் மின்னஞ்சலைப் பெற முடிந்தால், தாக்குதல் நடத்துபவருக்கு ஆயிரம் படிவங்கள் தேவையில்லை, ஏனெனில் உங்கள் படிவமே ஆயிரம் செய்திகளை அனுப்பிவிடும். அந்தப் பட்டியலில் ஏற்கனவே unconfirmed நிலையில் உள்ள ஒரு முகவரிக்கு, குறைந்தது ஒரு நாளைக்காவது எந்தச் செய்தியும் செல்லக்கூடாது. இரண்டாவதாக, உறுதிப்படுத்தப்படாத வரிசைகளை (unconfirmed rows) கால அட்டவணைப்படி நீக்குங்கள். முப்பது நாட்களாக உறுதிப்படுத்தப்படாத ஒரு முகவரி, நிலுவையில் உள்ள சந்தாதாரர் அல்ல. அதை வைத்திருப்பது, பிற்காலத்தில் தற்செயலாக ஏதேனும் மின்னஞ்சல் அதற்குச் செல்வதற்கான வாய்ப்பை மட்டுமே உருவாக்கும்.

Reverse proxy-ல் signup form-க்கான rate limit-ஐ அமைத்தல்

இந்த வரம்பை (limit) application-க்குள் வைப்பதற்குப் பதிலாக, அதற்கு முன்பாகவே அமைக்கவும். Proxy-ல் தடுக்கப்படும் ஒரு கோரிக்கை (request), database connection-ஐத் திறக்காது; SMTP (simple mail transfer protocol) பரிமாற்றத்தையும் தொடங்காது. Application-க்குள் ஒரு வரம்பை அமைத்தால், அது ஏற்கனவே ஒரு worker process மற்றும் query-ஐப் பயன்படுத்திய பிறகுதான் இயங்கும். பல stack-களில், abuse check நடப்பதற்கு முன்பே செய்தி queue-ல் சேர்க்கப்பட்டுவிடும். Proxy-ல் அமைக்கப்படும் வரம்பு, application upgrade செய்யப்பட்டாலும் நீடிக்கும், ஏனெனில் அது நீங்கள் மாற்றும் code-ல் இல்லை.

கீழே உள்ள உதாரணம் nginx-ஐப் பற்றியது. நீங்கள் எந்த reverse proxy-ஐப் பயன்படுத்தினாலும், directive பெயர்கள் மாறினாலும், இந்த அடிப்படை யோசனை பொருந்தும்.

இதை http block-ல், /etc/nginx/conf.d/signup-limit.conf போன்ற ஒரு கோப்பில் சேர்க்கவும்:

map $request_method $signup_key {
    POST    $binary_remote_addr;
    default "";
}

limit_req_zone $signup_key zone=signup:10m rate=2r/m;
limit_req_status 429;
limit_req_log_level warn;

map உண்மையான வேலையைச் செய்கிறது. ஒரு கோரிக்கையின் key காலியாக இருந்தால் nginx அதைக் கணக்கிடாது, எனவே POST கோரிக்கைகள் மட்டுமே zone-க்குள் நுழையும். ஒரு பயனர் signup பக்கத்தை பலமுறை ஏற்றினாலும் அவருக்கு எந்தப் பாதிப்பும் இல்லை. அந்த map இல்லையென்றால், பக்கத்தை இருமுறை refresh செய்பவர், எதையும் சமர்ப்பிக்கும் முன்பே தனது வரம்பைத் தீர்த்துவிடுவார்.

$binary_remote_addr என்பது client முகவரியின் சுருக்கப்பட்ட வடிவம், இதனால்தான் 10 megabyte zone-ல் சுமார் 160,000 முகவரிகளைச் சேமிக்க முடியும். rate=2r/m முப்பது வினாடிகளுக்கு ஒருமுறை சமர்ப்பிக்க அனுமதிக்கிறது. limit_req_status 429, nginx-ன் இயல்பான 503-க்கு பதிலாக HTTP 429 Too Many Requests-ஐத் திருப்பித் தருகிறது; இதுவே சரியான code மற்றும் client library எதிர்பார்ப்பதும் இதுவே.

பிறகு உங்கள் தளத்திற்கான server block-ல்:

location = /subscription/form {
    limit_req zone=signup burst=3 nodelay;
    proxy_pass http://127.0.0.1:9000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

burst=3 nodelay, பொத்தானை இருமுறை அழுத்துபவர்களை அனுமதிக்கிறது, ஆனால் நான்காவது கோரிக்கையை queue செய்யாமல் உடனடியாக நிராகரிக்கிறது.

sudo nginx -t && sudo systemctl reload nginx

nginx -t, configuration file /etc/nginx/nginx.conf test is successful-ஐக் காட்ட வேண்டும். இப்போது form-ஐ ஐந்து முறை விரைவாகச் சமர்ப்பித்து, error log-ஐக் கவனிக்கவும்:

sudo tail -f /var/log/nginx/error.log

தடுக்கப்பட்ட ஒவ்வொரு கோரிக்கைக்கும் ஒரு வரி எழுதப்படும், நீங்கள் தேடும் string இதுதான்:

2026/08/13 09:14:22 [warn] 812#812: *4412 limiting requests, excess: 3.400 by zone "signup", client: 203.0.113.10, server: news.example.com, request: "POST /subscription/form HTTP/1.1", host: "news.example.com"

எந்த வரியும் இல்லை என்றால், வரம்பு செயல்படுத்தப்படவில்லை என்று அர்த்தம். பொதுவாக limit_req, கோரிக்கை சென்றடையாத ஒரு location block-ல் இருப்பதால் இது நிகழ்கிறது. எனவே curl -si -X POST https://news.example.com/subscription/form-ஐச் சிலமுறை இயக்கி, 429 கிடைப்பதை உறுதி செய்யவும்.

IP அடிப்படையிலான வரம்பைச் சார்ந்திருப்பதற்கு முன் இரண்டு சிக்கல்களைத் தெரிந்துகொள்வது அவசியம்.

CDN அல்லது மற்றொரு proxy-க்குப் பின்னால் இருந்தால், $binary_remote_addr என்பது அந்த proxy-ஆகவே இருக்கும். அனைத்துப் பார்வையாளர்களும் ஒரே bucket-ல் விழுவார்கள், எனவே ஒவ்வொரு நிமிடத்தின் முதல் சில சமர்ப்பிப்புகள் மற்ற அனைவரையும் முடக்கிவிடும். இதைச் சரிசெய்ய real IP module-ஐப் பயன்படுத்தவும்: உங்கள் CDN-ன் ஒவ்வொரு published range-க்கும் set_real_ip_from-ஐச் சேர்க்கவும் (Cloudflare-ன் முகவரிகள் cloudflare.com/ips-ல் உள்ளன) மற்றும் real_ip_header CF-Connecting-IP-ஐப் பயன்படுத்தவும். உங்கள் access log-ல் $remote_addr-ஐப் படித்து, அது CDN-ன் முகவரியாக இல்லாமல் பார்வையாளரின் முகவரியாக இருப்பதை உறுதி செய்யவும்.

IPv6 முகவரி அடிப்படையிலான வரம்பை பலவீனமாக்குகிறது. $binary_remote_addr முழு /128-ஐயும் வைத்திருக்கிறது, ஆனால் ஒரு residential IPv6 ஒதுக்கீடு பொதுவாக /64 அல்லது அதற்கு மேல் இருக்கும். ஒரு தாக்குதல் நடத்துபவர் பயன்படுத்தக்கூடிய முகவரிகளை விட இது மிக அதிகம், ஒவ்வொன்றிற்கும் தனித்தனி வரம்பு இருக்கும். Endpoint-க்கு ஒரு உச்சவரம்பாக (ceiling) இரண்டாவது zone-ஐச் சேர்க்கவும். இது ஒரு constant-ஐ அடிப்படையாகக் கொண்டிருக்க வேண்டும், இதனால் எத்தனை source முகவரிகள் இருந்தாலும் form-க்கு ஒரு பொதுவான வரம்பு இருக்கும்:

map $request_method $signup_total_key {
    POST    "signup";
    default "";
}

limit_req_zone $signup_total_key zone=signup_total:1m rate=30r/m;

limit_req zone=signup_total burst=10 nodelay;-ஐ அதே location-ல் சேர்க்கவும். உங்கள் தளத்தின் அதிகபட்ச பயன்பாட்டு நேரத்தை விட சற்று அதிகமாக இந்த வரம்பை அமைக்கவும். இது ஒரு கடுமையான கட்டுப்பாடு: தாக்குதலின் போது உண்மையான signup-களும் தடுக்கப்படலாம். இது சரியான சமரசம், ஏனெனில் இல்லையெனில் உங்கள் server மின்னஞ்சல்களை அனுப்பிக்கொண்டிருக்கும்.

ஏன் ஒரு முகவரிக்கு (per-address) விதிக்கப்படும் வரம்பை proxy-ல் அமைக்க முடியாது

மின்னஞ்சல் முகவரி POST body-க்குள் வருகிறது, Nginx கோரிக்கையின் body-ஐ பகுப்பாய்வு (parse) செய்வதில்லை. limit_req_zone பயன்படுத்தக்கூடிய ஒவ்வொரு மாறியும் (variable) கோரிக்கை வரி (request line), தலைப்புகள் (headers) அல்லது இணைப்பு (connection) ஆகியவற்றிலிருந்தே பெறப்படுகிறது. எனவே, "இந்த முகவரிக்கு ஒரு நாளைக்கு ஒரு உறுதிப்படுத்தல் மட்டுமே அனுப்பப்பட வேண்டும்" போன்ற விதியை, body-ஐ வாசிக்கும் முதல் அங்கமான உங்கள் application-லேயே அமைக்க வேண்டும்.

முகவரியை query string-க்கு மாற்றி $arg_email-ஐப் பயன்படுத்தும் முயற்சியைத் தவிர்க்கவும். அவ்வாறு செய்தால், ஒவ்வொரு சந்தாதாரரின் முகவரியும் உங்கள் access log-ல் plain text வடிவில் பதிவாகும், மேலும் அதனுடன் இணைக்கப்பட்ட log shipper-களுக்கும் செல்லும். இது rate limit-ஐச் சரிசெய்யும் முயற்சியில், தனியுரிமைச் சிக்கலை (privacy problem) உருவாக்கும்.

இதில் ஒரு விதிவிலக்கு உண்டு. Nginx JavaScript module ஆன njs, request body-ஐ வாசித்து அதிலிருந்து ஒரு மாறியை அமைக்க முடியும்; இது proxy மட்டத்திலேயே முகவரி அடிப்படையிலான key-ஐ உருவாக்க வழிவகுக்கும். இது ஒரு சாத்தியமான வழிதான், ஆனால் இது உங்கள் request path-ல் புதிய code-ஐச் சேர்க்கிறது. பெரும்பாலான தளங்களுக்கு, ஒரு முகவரிக்கு ஏற்கனவே உறுதிப்படுத்தல் நிலுவையில் உள்ளதா என்பதைத் தெரிந்திருக்கும் database-க்கு அருகிலேயே இந்த வரம்பை அமைப்பது சிறந்தது. அதே நேரத்தில், proxy-ஆனது தனக்குச் சாதகமான per-IP மற்றும் per-endpoint வரம்புகளைக் கவனித்துக்கொள்ளும்.

சமர்ப்பிக்கப்பட்ட உரையை மீண்டும் பதிவிட வேண்டாம்

தாக்குதல் நடத்துபவர் வழங்கிய எந்தவொரு சரத்தையும் (string) உங்கள் செய்தியில் சேர்க்க வேண்டாம். இதற்கு இரண்டு முக்கிய காரணங்கள் உள்ளன, இவை இரண்டும் நடைமுறையில் பயன்படுத்தப்படுகின்றன.

உங்கள் உறுதிப்படுத்தல் மின்னஞ்சல், படிவத்தில் உள்ள பெயரைப் பயன்படுத்தி வாசகரை வரவேற்கிறது என்றால், தாக்குதல் நடத்துபவர் தனது செய்தியை அந்தப் பெயர் புலத்தில் (name field) உள்ளிடுவார். உங்கள் server அந்த உரையை பாதிக்கப்பட்டவருக்கு உங்கள் domain-லிருந்து, உங்கள் DKIM (DomainKeys Identified Mail) கையொப்பத்துடன் அனுப்பும். உங்கள் தளம் மற்றவர்களின் தவறான பயன்பாட்டிற்கான விநியோக சேவையாக மாறிவிடும், மேலும் மின்னஞ்சலைப் பெறுபவர் உங்கள் domain-ஐ அதில் காண்பார்.

இரண்டாவது காரணம் மிகவும் ஆபத்தானது. சமர்ப்பிக்கப்பட்ட ஏதேனும் ஒரு புலம் (field) கைமுறையாக மின்னஞ்சல் தலைப்பில் (mail header) இணைக்கப்பட்டால், அந்தப் புலத்தில் உள்ள ஒரு புதிய வரி (newline character) தாக்குதல் நடத்துபவர் விரும்பும் தலைப்புகளைச் சேர்க்க வழிவகுக்கும், இதில் Bcc-ம் அடங்கும். நவீன மின்னஞ்சல் நூலகங்கள் (mail libraries) தலைப்பு மதிப்புகளில் புதிய வரிகளை நிராகரிக்கின்றன. ஆனால், shell script மூலம் sendmail-க்கு உரையை அனுப்பும் நிரல்கள் பெரும்பாலும் அவ்வாறு செய்வதில்லை.

பாதுகாப்பான உறுதிப்படுத்தல் செய்தியில் உங்கள் தளத்தின் பெயர், ஒரு இணைப்பு மற்றும் ஒரு வாக்கிய விளக்கம் மட்டுமே இருக்க வேண்டும். மின்னஞ்சல் முகவரி, மின்னஞ்சல் பரிமாற்ற முகவர் (MTA) கோரும் இடத்தில், அதாவது To தலைப்பில் மட்டுமே இருக்க வேண்டும். இதைச் சோதிக்க: பெயர் புலத்தில் ஒரு புதிய வரி மற்றும் ஒரு வெளிப்படையான இணைப்பை உள்ளிட்டு படிவத்தைச் சமர்ப்பிக்கவும். பின்னர், நீங்கள் பெறும் செய்தியை less மூலம் அதன் மூல வடிவில் (raw message) படித்து, அவை எதுவும் அதில் இல்லை என்பதை உறுதிப்படுத்தவும்.

அதே நேரத்தில், வெற்றிப் பக்கத்தில் (success page) அனைத்து முகவரிகளுக்கும் ஒரே செய்தியைக் காட்டவும். ஒரு முகவரிக்கு "நீங்கள் ஏற்கனவே சந்தா செலுத்திவிட்டீர்கள்" என்றும், மற்றொன்றுக்கு "உங்கள் இன்பாக்ஸைச் சரிபார்க்கவும்" என்றும் காட்டும் பக்கம், உங்கள் படிவத்தை ஒரு உறுப்பினர் சரிபார்ப்பு கருவியாக மாற்றிவிடும். இதைத் தவறான நபர்கள் தங்கள் வசம் உள்ள முகவரிப் பட்டியலைச் சோதிக்கப் பயன்படுத்தக்கூடும்.

எந்த bot check-ஐப் பயன்படுத்த வேண்டும்?

செயல்திறனைத் தேர்ந்தெடுப்பது போலவே, அணுகல்தன்மையையும் (accessibility) கருத்தில் கொண்டு தேர்வு செய்யுங்கள். பார்வையற்ற பயனர்களால் படங்களைத் தேர்ந்தெடுக்கும் captcha-வைச் செய்ய முடியாது, சாதாரணக் கேட்கும் திறன் கொண்டவர்களுக்கும் அதன் audio fallback கடினமாக இருக்கலாம். ஒரு உண்மையான பயனர் பதிவு செய்வதைத் தடுக்கும் பாதுகாப்பு முறை, ஒரு செலவாகவே கருதப்படுகிறது. முயற்சி செய்ய வேண்டிய வரிசையில் நான்கு விருப்பங்கள் கீழே கொடுக்கப்பட்டுள்ளன.

Browser-ல் Proof of work. Browser ஒரு hash-ஐக் கணக்கிடும், அதை server எளிதாகச் சரிபார்க்கும்; பயனர் எதையும் தீர்க்க வேண்டியதில்லை. listmonk-ல் Settings, பின் Security பகுதிக்குச் சென்றால் ALTCHA-வைப் பயன்படுத்தலாம், இதற்கு எந்த மூன்றாம் தரப்பு சேவையும் தேவையில்லை. ஆகஸ்ட் 2026 நிலவரப்படி, கைவிடப்பட்ட hCaptcha விருப்பத்திற்குப் பதிலாக listmonk இதைத்தான் பரிந்துரைக்கிறது. அதிகப்படியான சமர்ப்பிப்புகளைச் செய்யும் தாக்குதல் நடத்துபவர் மீதுதான் இதற்கான கணக்கீட்டுச் சுமை விழும்.

நிர்வகிக்கப்படும் non-interactive check. Cloudflare Turnstile பெரும்பாலான பார்வையாளர்களுக்கு எதையும் காட்டாது, அதன் சமிக்ஞைகள் சந்தேகத்திற்குரியதாக இருக்கும்போது மட்டுமே சவாலை முன்வைக்கும். இது பயனுள்ளது, ஆனால் உங்கள் signup பாதையில் ஒரு மூன்றாம் தரப்பு சேவையைச் சேர்க்கிறது.

Honeypot field. ஒரு பயனர் பார்க்க முடியாத, ஆனால் அறியாத bot நிரப்பும் ஒரு text input. உங்கள் form-ல் பயன்படுத்தப்படாத ஒரு பெயரை இதற்கு இடவும், மேலும் autocomplete="off", tabindex="-1" மற்றும் aria-hidden="true" ஆகியவற்றை அமைக்கவும்; இதனால் password manager இதை நிரப்பாது, screen reader இதை வாசிக்காது. email2 அல்லது address என்று பெயரிடப்பட்ட field-ஐ browser தானாக நிரப்பிவிடும், அப்போது உண்மையான பயனர்களை நீங்கள் நிராகரிக்க நேரிடும்.

<div style="position:absolute; left:-9999px;" aria-hidden="true">
  <label for="hp_ref">Leave this field empty</label>
  <input type="text" id="hp_ref" name="hp_ref" autocomplete="off" tabindex="-1">
</div>

Time-to-submit check. பக்கம் உருவாகும்போது ஒரு signed timestamp-ஐ hidden field-ல் வைக்கவும், இரண்டு வினாடிகளுக்குள் வரும் சமர்ப்பிப்பை நிராகரிக்கவும். ஒரு மனிதரால் form-ஐப் படித்து, முகவரியை அவ்வளவு வேகமாகத் தட்டச்சு செய்ய முடியாது. அந்த timestamp-ஐ sign செய்யவும், இல்லையெனில் bot பழைய timestamp-ஐ அனுப்பிவிடும்.

நீங்கள் எதைத் தேர்ந்தெடுத்தாலும் சரிபார்க்க வேண்டிய ஒன்று: token ஒருமுறை மட்டுமே பயன்படுத்தப்பட வேண்டும். ஒரு script ஒருமுறை check-ஐத் தீர்த்துவிட்டு, அந்த token-ஐ ஆயிரம் முகவரிகளுக்கு எதிராக மீண்டும் பயன்படுத்தினால், அந்த check ஒரு browser ஒருமுறை இயங்கியதை மட்டுமே உறுதிப்படுத்துகிறது.

துஷ்பிரயோக அறிக்கை (abuse report) வருவதற்கு முன்பே அதை எப்படிக் கண்டறிவது?

ஹோஸ்டிங் வழங்குநரின் துஷ்பிரயோகப் பிரிவு (abuse desk) தெரிவிக்கும் வரை காத்திருக்காமல், உங்கள் சொந்த வரைபடங்களே (graphs) உங்களுக்குத் தெரிவிக்க வேண்டும். இரண்டு விஷயங்களைக் கவனிக்கவும்.

பதிவுக்கோப்பில் (log) ஒவ்வொரு மூல முகவரியிலிருந்தும் (source address) வரும் சமர்ப்பிப்புகளைக் கணக்கிடுங்கள்:

sudo awk '/POST \/subscription\/form/ {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

பிறகு, Nginx ஏற்கனவே எழுதும் அதே limiting requests வரிகளை fail2ban-ஐப் படிக்கச் செய்து, மீண்டும் மீண்டும் தவறு செய்பவர்களைத் தடை (ban) செய்யுங்கள். இதற்கெனவே fail2ban ஒரு filter-ஐ வழங்குகிறது. /etc/fail2ban/jail.d/nginx-limit-req.local-ஐ உருவாக்குங்கள்:

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
port     = http,https
logpath  = /var/log/nginx/error.log
findtime = 600
maxretry = 10
bantime  = 3600

sudo systemctl reload fail2ban
sudo fail2ban-client status nginx-limit-req

இதன் status வெளியீடு, அந்த jail-ன் filter மற்றும் தற்போது தோல்வியடைந்த மற்றும் தடைசெய்யப்பட்ட எண்ணிக்கையைக் காட்டும். அமைதியான ஒரு நாளில் Currently banned: 0 என்பது சரியான நிலையாகும். jail காட்டப்படவில்லை என்றால், fail2ban அந்த கோப்பை ஏற்றவில்லை என்று அர்த்தம்; அப்போது sudo fail2ban-client -d | grep nginx-limit-req கட்டளையைப் பயன்படுத்தி அது உண்மையில் எந்த உள்ளமைவைப் (configuration) புரிந்துகொண்டது என்பதைப் பார்க்கலாம். வழங்கப்பட்ட filter அனைத்து limit_req மண்டலங்களுடனும் பொருந்தும். /etc/fail2ban/filter.d/nginx-limit-req.local-ன் [Definition] பகுதியில் ngx_limit_req_zones = signup-ஐ அமைப்பதன் மூலம், உங்கள் signup மண்டலத்திற்கு மட்டும் இதைச் சுருக்கலாம். jail கோப்பின் அமைப்பு மற்றும் ban கட்டளைகள் குறித்த கூடுதல் விவரங்களுக்கு Ubuntu 24.04-க்கான fail2ban வழிகாட்டியை பார்க்கவும்.

இரண்டாவது அறிகுறி ஒரு விகிதமாகும் (ratio); இதற்குப் புதிய மென்பொருள் தேவையில்லை: சமர்ப்பிப்புகளை உறுதிப்படுத்தல்களால் (confirmations) வகுக்க வேண்டும். ஆரோக்கியமான ஒரு பட்டியலில், முகவரியைச் சமர்ப்பிக்கும் பெரும்பாலானோர் அந்த இணைப்பைக் கிளிக் செய்வார்கள்; பொதுவாக இது பாதியைக் காட்டிலும் அதிகமாக இருக்கும். சமர்ப்பிப்புகள் அதிகரிக்கும் அதே வேளையில் இந்த விகிதம் சரிந்தால், உங்கள் தளம் தவறாகப் பயன்படுத்தப்படுகிறது என்று அர்த்தம். நீங்கள் ஏற்கனவே அறிக்கைகளை உருவாக்கும் கால அட்டவணையின்படி, கடந்த ஒரு மணி நேரத்தில் உருவாக்கப்பட்ட unconfirmed சந்தாதாரர்களின் எண்ணிக்கையை, confirmed சந்தாதாரர்களின் எண்ணிக்கையுடன் ஒப்பிட்டுப் பாருங்கள்.

இதற்கான விலை: sender reputation மற்றும் blocklists

இதுதான் ஒரு தொந்தரவை நிதி இழப்பாக மாற்றும் பகுதி.

Bombing-க்கு பயன்படுத்தப்படும் முகவரிப் பட்டியல்கள் திருடப்பட்டவை (harvested). இத்தகைய பட்டியல்களில் spamtraps இருக்கும்: இவை எதற்கும் பதிவு செய்யாத முகவரிகள், அனுமதியின்றி மின்னஞ்சல் அனுப்பும் நபர்களைக் கண்டறியவே இவை வெளியிடப்படுகின்றன. உங்கள் உறுதிப்படுத்தல் மின்னஞ்சல் (confirmation message) ஒன்றில் பட்டால், சில blocklist இயக்குநர்கள் அதை மட்டுமே ஆதாரமாகக் கொண்டு உங்களை முடக்கிவிடுவார்கள்.

உங்கள் மின்னஞ்சலை வேண்டாத பெறுநர்கள் unsubscribe செய்ய மாட்டார்கள். அவர்கள் "report spam" என்பதைத்தான் கிளிக் செய்வார்கள். பிப்ரவரி 2024 முதல் அமலில் உள்ள Google-ன் bulk sender விதிகளின்படி, ஒரு நாளைக்கு 5,000 அல்லது அதற்கு மேற்பட்ட மின்னஞ்சல்களை Gmail-க்கு அனுப்பும் நிறுவனங்கள், Postmaster Tools-ல் spam புகார் விகிதத்தை 0.3%-க்கு கீழ் வைத்திருக்க வேண்டும். சிறிய அளவில் அனுப்பும் நபர்களுக்கு இந்த எண் பொருந்தாது என்றாலும், அதே புகார் சமிக்ஞைதான் உங்கள் மின்னஞ்சல்களை spam folder-க்கு அனுப்பும் வடிகட்டிகளைத் தூண்டுகிறது. இந்தத் தாக்குதலில் பயன்படுத்தப்படும் போலி முகவரிகள் hard bounce ஆகும். அதிகரிக்கும் hard-bounce விகிதம், ஒவ்வொரு பெரிய மின்னஞ்சல் சேவை நிறுவனத்திடமும் உங்கள் நற்பெயரைக் கெடுக்கும் ஒரு சமிக்ஞையாகும்.

நீங்கள் உங்கள் சொந்த mail server-ஐ VPS-ல் mailcow மூலம் இயக்கினால், இந்தத் தடை உங்கள் IP முகவரி மற்றும் domain-ஐப் பாதிக்கும். Spamhaus போன்ற நிறுவனங்களின் பட்டியலிலிருந்து நீக்கப்பட, நீங்கள் படிவத்தை நிரப்பி காத்திருக்க வேண்டும். நீங்கள் காத்திருக்கும் அந்த நேரத்தில், உங்கள் முக்கியமான invoices மற்றும் password reset மின்னஞ்சல்கள் எதுவும் சேராது. மாறாக, நீங்கள் ஒரு shared provider மூலம் மின்னஞ்சல் அனுப்பினால், அவர்கள் உங்கள் விளக்கத்தைக் கேட்பதற்கு முன்பே உங்கள் கணக்கை முடக்கிவிடுவார்கள். ஏனெனில், உங்கள் traffic அந்த IP-ல் உள்ள மற்ற அனைத்து பயனர்களுக்கும் ஆபத்தானது.

இதனுடன் ஒப்பிடும்போது, நீங்கள் செய்ய வேண்டிய வேலை மிகச் சிறியது. இன்று முதலே confirmed opt-in வசதியைச் செயல்படுத்துங்கள், ஏனெனில் இது ஒவ்வொரு பட்டியலுக்கும் ஒருமுறை செய்யும் அமைப்பாகும். அடுத்து, proxy rate limit-ஐச் சேர்க்கவும், இது ஒரு கோப்பில் மாற்றம் செய்து reload செய்வதன் மூலம் முடிந்துவிடும். Bot check மற்றும் alerting வசதிகளை இந்த வாரத்திற்குள் செய்து முடிக்கலாம்.

FAQ

Double opt-in முறை subscription bombing-ஐத் தடுக்குமா?

இது உங்கள் மின்னஞ்சல் பட்டியலைத் தேவையற்ற முகவரிகளால் நிரப்பப்படுவதைத் தடுக்கிறது. சமர்ப்பிக்கப்பட்ட ஒவ்வொரு முகவரிக்கும் ஒரு செய்தியை மட்டுமே இது அனுப்புவதால், இதுவே நீங்கள் செய்யக்கூடிய மிக முக்கியமான பாதுகாப்பு நடவடிக்கையாகும். ஆனால், இது பாதிக்கப்பட்டவரின் இன்பாக்ஸ் நிரம்புவதைத் தடுக்காது; ஏனெனில், ஆயிரக்கணக்கான தளங்களிலிருந்து தலா ஒரு செய்தி வீதம் அனுப்பப்படுவதே இந்தத் தாக்குதல். எனவே, உங்கள் proxy-ல் IP அடிப்படையிலான rate limit-ஐயும், உறுதிப்படுத்தல் செய்திகளை மீண்டும் அனுப்புவதற்கு ஒரு வரம்பையும் அமைக்கவும். இதன் மூலம், ஒரே முகவரி இருமுறை சமர்ப்பிக்கப்பட்டாலும் இரண்டாவது செய்தி அனுப்பப்படாது.

உண்மையான சந்தாதாரர்கள் சேரும் நாளுக்கும், bombing தாக்குதலுக்கும் உள்ள வித்தியாசத்தை எப்படி அறிவது?

சமர்ப்பித்த பிறகு என்ன நடக்கிறது என்பதைக் கவனியுங்கள். உண்மையான சந்தாதாரர்கள் மின்னஞ்சலை உறுதிப்படுத்துவார்கள்; அது பெரும்பாலும் சில மணிநேரங்களுக்குள் நடக்கும். Bombing தாக்குதலில், உறுதிப்படுத்தப்படாத, திறக்கப்படாத மற்றும் கிளிக் செய்யப்படாத முகவரிகளின் குவியல் மட்டுமே மிஞ்சும். மேலும், இந்தச் சமர்ப்பிப்புகள் வழக்கத்திற்கு மாறாக இருக்கும்: நீங்கள் இதுவரை பார்த்திராத source முகவரிகள், நீங்கள் வழக்கமாக மின்னஞ்சல் அனுப்பாத recipient domains, மற்றும் உங்கள் வாசகர்களின் செயல்பாட்டு நேரத்தைப் பின்பற்றாமல் நாள் முழுவதும் சீராக வரும் சமர்ப்பிப்புகள் போன்றவை தாக்குதலின் அறிகுறிகளாகும்.

சமர்ப்பிக்கப்பட்ட முகவரிகளை நான் நீக்க வேண்டுமா?

ஆம். முப்பது நாட்களுக்கு மேலாக உறுதிப்படுத்தப்படாத பதிவுகளை நீக்கிவிடுங்கள். இதை கைமுறையாகச் செய்யாமல், ஒரு கால அட்டவணையின்படி தானியங்கி முறையில் செய்யுங்கள். அந்த முகவரிகளுக்கு மன்னிப்புக் கடிதமோ அல்லது "இது நீங்கள்தானா?" என்ற செய்தியோ அனுப்ப வேண்டாம். ஏற்கனவே பல செய்திகளால் பாதிக்கப்பட்ட ஒருவருக்கு, நீங்கள் அனுப்பும் அந்தச் செய்தியும் தேவையற்றதாகவே அமையும். ஒருவேளை அந்த முகவரிகளில் ஏதேனும் spamtraps இருந்தால், நீங்கள் அனுப்பும் அந்தப் பதில் செய்தி, blocklist இயக்குபவர் எதிர்பார்த்துக் கொண்டிருக்கும் உறுதிப்படுத்தலாக அமைந்துவிடும்.

Rate limiting உண்மையான சந்தாதாரர்களைத் தடுக்குமா?

ஒரு IP முகவரியிலிருந்து முப்பது வினாடிகளுக்கு ஒரு சமர்ப்பிப்பு மற்றும் அதிகபட்சமாக மூன்று என்ற வரம்பு, ஒரு படிவத்தை நிரப்பும் சாதாரண நபருக்குத் தெரியாது. ஆனால், ஒரே NAT (network address translation) gateway-க்கு பின்னால் உள்ள அலுவலகம் போன்ற இடங்களில் பல உண்மையான நபர்கள் ஒரே IP-ஐப் பயன்படுத்தும்போது, அல்லது உங்கள் proxy பார்வையாளரின் IP-க்கு பதிலாக உங்கள் CDN-ன் IP-ஐப் பார்க்கும்போது இது சிக்கலாகலாம். எதையும் இறுக்கும் முன் உங்கள் access log-ல் உள்ள $remote_addr-ஐப் படியுங்கள். உங்கள் தளத்தின் மிக அதிகப்படியான பயன்பாடு உள்ள நேரத்தை விட, இந்த வரம்பை அதிகமாக வைத்திருங்கள்.

தாக்குதலுக்குப் பிறகு எனது sending IP blocklist-ல் உள்ளது. நான் முதலில் என்ன செய்ய வேண்டும்?

எந்தவொரு கோரிக்கையையும் விடுக்கும் முன், அந்த IP-யிலிருந்து மின்னஞ்சல் அனுப்புவதை நிறுத்துங்கள். Campaign queue-ஐ இடைநிறுத்துங்கள், படிவத்தைச் சரிசெய்யுங்கள், மற்றும் உறுதிப்படுத்தப்படாத முகவரிகளை நீக்குங்கள். ஏனெனில், delisting செய்த பிறகு மீண்டும் அதே போன்ற traffic உருவானால், முதல் முறையை விட வேகமாக மீண்டும் blocklist-ல் சேர்க்கப்படுவீர்கள். அதன் பிறகு, நீங்கள் எந்தப் பட்டியலில் உள்ளீர்கள் என்பதைக் கண்டறியுங்கள். பெரும்பாலான இயக்குநர்கள் உங்கள் IP முகவரியைக் கொண்டு சரிபார்க்கும் பக்கத்தை வைத்துள்ளனர்; அவர்களின் நீக்க நடைமுறையைப் பின்பற்றுங்கள். இதற்கான காத்திருப்பு காலம் சில நாட்கள் ஆகலாம். அந்த நேரத்தில் உங்கள் SPF (sender policy framework) record மற்றும் DKIM signing ஆகியவை சரியாகச் செயல்படுகின்றனவா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.