एक्सेस लॉग में मिले हमलों के मामले

 (nishtahir.com)
1 पॉइंट द्वारा GN⁺ 2024-01-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 10 साल से ज़्यादा समय तक self-hosting किए गए public IP के access logs में credential discovery से लेकर IoT डिवाइसों पर command injection तक, इंटरनेट पर exposed services को रोज़ाना मिलने वाली attack attempts दिखाई देती हैं
  • सबसे आम pattern .env, .aws/credentials, .git/config, backup/, test/ जैसे paths में झांकने वाली configuration file और directory discovery थी, और कुछ requests ने Mozlila/5.0 जैसे typo वाले User-Agent का इस्तेमाल किया
  • Shellshock attempts ने User-Agent में Bash function के रूप वाला payload डालकर /etc/passwd पढ़ने की कोशिश की, और कई CGI paths को बार-बार guess किया
  • LuCI और Zyxel को निशाना बनाने वाले attacks ने routers और embedded devices के web interfaces में commands inject करके remote scripts और कई architectures के binaries download कर execute करने की कोशिश की
  • public Internet पर expose की जाने वाली चीज़ों को कम करें, ज़रूरी tools और directories पर authentication और IP restrictions लगाएं, और IoT devices को updated रखें तथा संभव हो तो public network से अलग करें

public Internet पर exposed services को मिलने वाला traffic

  • 10 साल से ज़्यादा समय तक self-hosting करते हुए अपने data का सीधा ownership रखने और cloud host के अलावा दूसरे platforms पर निर्भरता घटाने का अनुभव जारी रखा
  • public Internet पर IP expose करते ही बड़ी मात्रा में malicious traffic आने लगता है, और access logs देखकर यह trace किया जा सकता है कि हाल में किस तरह के attacks हुए
  • यह analysis किसी security expert की forensic जांच से ज़्यादा एक जिज्ञासु developer के observations जैसा है
  • सावधानी के तौर पर attacker IP addresses और कुछ attackers द्वारा इस्तेमाल किए गए अपमानजनक expressions को mask किया गया है

credentials और configuration files की खोज

  • सबसे आम attack directory traversal के ज़रिए credentials ढूंढने की कोशिश था, और खास तौर पर .env file requests बहुत दिखीं
    • request path examples में /laravel/.env, /backend/.env, /api/.env, /.env, //.env आदि शामिल हैं
    • .env को आम तौर पर application secrets रखने वाली file माना जाता है
  • AWS से जुड़ी files और Git repository configuration भी discovery targets में शामिल थे
    • examples में /aws.yml, /.env.bak, /info.php, /.aws/credentials, /config/aws.yml, /.git/config आदि हैं
  • गलती से छूट गई हो सकने वाली common directories भी बार-बार request की गईं
    • examples में /old/, /new/, /test/, /backup/, /temp/ आदि हैं
  • कुछ User-Agent में Mozilla/5.0 का typo लगने वाला Mozlila/5.0 मौजूद था
    • GitHub search results से संकेत मिलता है कि यह typo किसी common tool से बना और copy-paste हुआ हो सकता है
  • remote access tools या configuration tools खोजने वाली requests भी साथ में देखी गईं
    • examples में /actuator/gateway/routes, /hudson, /ui/login.action, /?XDEBUG_SESSION_START=phpstorm आदि हैं
  • public Internet पर सिर्फ़ वही न्यूनतम चीज़ें expose करें जो बिल्कुल ज़रूरी हों, और अगर tools या directories expose करनी पड़ें तो authentication layer और संभव हो तो specific IP restriction लगाना ज़रूरी है

Shellshock attempts

  • कई requests Shellshock vulnerability को target करती दिखती हैं
  • यह attack उन web servers पर arbitrary command execution को target करता है जो vulnerable Bash version से CGI scripts चलाते हैं
    • CGI program शुरू होने पर request content से environment variables set किए जाते हैं, और HTTP_USER_AGENT उनमें से एक है
    • () { :; }; जैसे characters शामिल हों तो Bash इसे execute किए जाने वाले function के रूप में interpret करता है
  • असली logs के User-Agent में इस तरह का payload मौजूद था
    • () { ignored; }; echo Content-Type: text/html; echo ; /bin/cat /etc/passwd
    • () { ignored; }; Bash function definition का रूप है
    • echo Content-Type: text/html; echo ; HTTP response का Content-Type और खाली line print करता है
    • /bin/cat /etc/passwd user account information वाली /etc/passwd की contents print करने की command है
  • अगर attack सफल होता तो user credentials access और server पर arbitrary code execution तक बात जा सकती थी
  • attackers ने directory traversal की तरह /cgi-bin/status, /cgi-bin/stats, /cgi-bin/test, /cgi-bin/status/status.cgi, /test.cgi, /debug.cgi, /cgi-bin/test-cgi जैसे common paths guess किए

LuCI को target करने वाला command injection

  • एक request OpenWRT routers के web interface LuCI को target करती दिखती है
  • attack URL की structure country field में command inject करके remote server से shell script tenda.sh download और execute करने की थी
    • URL decoding के बाद command का flow /tmp में जाना, file delete करना, wget से script लेना, execute permission देना और फिर execute करना था
  • downloaded script में additional binaries download और execute करने की कोशिश करने वाली content थी
    • target architecture names लगने वाले mips, mpsl, x86_64, arm, arm5, arm6, arm7, i586, i686, powerpc, sh4, m68k, sparc आदि शामिल थे
    • कई architectures के binaries try करने का तरीका ऐसा लगता है जैसे attacker target device का architecture न जानने की स्थिति में attack scope बढ़ाना चाहता हो
  • आगे की जांच के लिए environment से incompatible binary download करके Ghidra में देखा गया
    • शुरुआत में केवल 3 functions थे और string data ज़्यादा नहीं था
    • बड़े data area में $Info: This file is packed with the UPX executable packer और UPX 3.94 strings मिले
  • यह UPX से compressed ELF binary था, और अगर UPX header या packed binary modified न हो तो upx -d से unpack किया जा सकता है
    • वास्तव में upx -d mips चलाने के बाद file size 34932 से 93732 हो गया, और ज़्यादा strings देखी जा सकीं
  • unpacked binary की strings में M-SEARCH * HTTP/1.1, ST: urn:dial-multiscreen-org:service:dial:1, और Huawei devices upgrade के लिए XML payload शामिल था
    • यह network में DIAL protocol support करने वाले devices खोजने की UPnP command लगती है
    • XML payload command injection के लिए vulnerable Huawei devices scan करने के लिए configured दिखता है
    • यह behavior Mirai botnet के हिस्से के रूप में identified दिखता है
  • referenced yeye.mips file fetch करने की कोशिश पर उपलब्ध नहीं थी
    • server पर nmap चलाने के नतीजे में open ports केवल 22/tcp ssh और 646/tcp filtered ldp मिले

Zyxel को target करने वाला command injection

  • दूसरी request के GET URL में shell command थी, और ${IFS} shell substitution हटाने पर वह आसानी से पढ़ी जा सकती है
    • cleaned command का flow /tmp में जाना, *mips* files हटाना, huhu.mips download करना, execute permission देना और फिर zyxel.selfrep argument के साथ execute करना था
  • यह attack Zyxel devices के zhttpd exploit को target करता दिखता है
  • इस बार binary packed नहीं थी, इसलिए Ghidra में strings सीधे देखी जा सकीं
    • strings में M-SEARCH * HTTP/1.1, DIAL-related ST header, skyljne.arm, skyljne.arm5, skyljne.arm6, skyljne.arm7, skyljne.mips, skyljne.mpsl, skyljne.x86_64, skyljne.sh4 आदि दिखे
    • Huawei devices को target करके huhu.mips download कर selfrep.huawei के रूप में execute करने वाला XML payload भी शामिल था
  • एक और string में /goform/set_LimitClient_cfg पर POST भेजने की command थी
    • Cookie: user=admin header के साथ mac parameter में command inject करके huhu.mpsl download और execute करने की कोशिश थी
    • Akamai article के अनुसार यह vulnerability routers को target करती है, और खास authentication/authorization checks न होने के कारण pre-authentication के बिना exploit की जा सकती है
  • माना गया कि यह binary बहुत संभव है कि Mirai botnet का agent हो
    • कुछ sources Linux Medusa से संबंध की संभावना भी mention करते हैं

operations perspective से response

  • देखे गए logs पूरे data का केवल एक हिस्सा हैं, और रोज़ाना try किए जाने वाले दूसरे exploits भी बहुत हैं
  • devices, खास तौर पर IoT devices, को up to date रखना महत्वपूर्ण है
  • संभव हो तो IoT devices को public Internet पर सीधे expose नहीं करना चाहिए
  • अगर उन्हें expose करना ही पड़े तो उन्हें जितना संभव हो separate VLAN में isolate करना चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-29
Hacker News की राय

  • दिलचस्प बात यह है कि कुछ हमलावर नए जारी हुए certificates ढूंढने के लिए Certificate Transparency logs पर नजर रखते लगते हैं
    अगर नया server किसी नए IP पर एक हफ्ते से ज्यादा चलने दें, तो access logs में बस कुछ random probing दिखती है, लेकिन Let’s Encrypt certificate लेने के करीब एक घंटे बाद कई बार ऐसा हुआ कि लेख में बताए गए जैसे सैकड़ों requests अचानक आने लगे
    निष्कर्ष यह है कि नई services को जितनी जल्दी हो सके—आदर्श रूप से internet पर expose करने से पहले ही—secure कर देना चाहिए

    • public exposure के पहले ही पल से सामने कम-से-कम basic authentication जैसा कुछ रखना चाहिए, ऐसा लगता है
      या फिर अपना certificate authority इस्तेमाल करके, switch-over से पहले self-signed certificates और mTLS इस्तेमाल करने का तरीका भी है
      उदाहरण के लिए, अगर कोई software admin account बनाने, DB connection जैसी initial setup screen को वैसा ही expose करता है, तो यह शुरू से environment variables, config files या dedicated secret-management tools के जरिए सेट करने के तरीके से ज्यादा जोखिम भरा हो जाता है
    • हाल में Certificate Transparency logs देखे थे, और जानना चाहता हूं कि CT logs query करने के लिए कोई सुविधाजनक tool या तरीका है क्या
      जैसे किसी खास अवधि के अंदर domains search करना
      Cloudflare का Merkle Town[0] overview देखने के लिए उपयोगी है, लेकिन CT logs को आसानी से query करने का तरीका अभी नहीं मिला, और ct-woodpecker[1] भी promising लगता है
      [0] https://ct.cloudflare.com/
      [1] https://github.com/letsencrypt/ct-woodpecker
    • wildcard certificates ज्यादा इस्तेमाल करना भी उपयोगी है। सिर्फ CT logs से attack करने के लिए specific subdomain पता लगाना मुश्किल हो जाता है
    • यह अक्सर हमलावर नहीं, बल्कि urlscan.io जैसी services होती हैं जो CT logs monitor करते हुए malware ढूंढने के लिए web crawl करती हैं
    • मैं कई services खुद host करता हूं, लेकिन उन्हें सीधे internet पर expose करना पूरी तरह छोड़ दिया है
      आजकल VPN इतने अच्छे हैं कि मन शांत रहता है, और photo hosting या backup जैसी चीजें खास तौर पर publicly expose नहीं करना चाहता

  • जब मैंने खुद host की हुई site manage करनी शुरू की थी, तो access logs भी देखता था, और कुछ समय तक ऐसा intrusion detection system भी इस्तेमाल किया जो data इकट्ठा कर आने वाली attack attempts दिखाता था
    आखिरकार logs को proactively review करना और intrusion detection system के लिए पैसे देना, दोनों छोड़ दिए; यह समय की बर्बादी और ध्यान भटकाने वाला काम था
    आम vulnerabilities और attacks का अच्छा summary material आसानी से मिल जाता है, उसे server administration का baseline बना लेना चाहिए। common web server technologies के लिए best-practices guides बहुत हैं, और उन्हें 100% लागू करना ही आपको लगभग सभी attackers से बहुत आगे कर देता है
    इसके बाद समय और resources का अच्छा उपयोग है जितना हो सके तेज patch cycle को प्राथमिकता देना। ज्यादातर attacks publicly known vulnerabilities को निशाना बनाते हैं
    logs खास तौर पर तब उपयोगी होते हैं जब problem होने के बाद diagnosis करना हो। log analysis software से store/search करके successful attacks का root cause ढूंढने में 2–3 बार मदद मिली, और हर बार वजह वही known vulnerability थी जिसे बहुत देर से patch किया गया था

    • अगर हर मामले में देर से patch की गई known vulnerability ही थी, तो सिर्फ patches पर निर्भर रहने वाला तरीका कभी न कभी fail होना तय है। यह 0-day vulnerability भी हो सकती है, या attacker ज्यादा तेज हो सकता है
      समाधान है defense-in-depth, और personal services खुद host करते समय इसे ज्यादातर मामलों में काफी आसानी से लागू किया जा सकता है
      front में firewall लगाएं या VPN/Tailscale के पीछे छिपाएं, और automated attacks जिस /phpmyadmin/ को target करते हैं उसकी जगह /mawer/phpmyadmin/ जैसे subfolder में छिपा दें तो 99.9% उसे नहीं ढूंढ पाएंगे। इसे security by obscurity कहते हैं और सिर्फ इसी पर भरोसा नहीं करना चाहिए, लेकिन additional layer के तौर पर यह बहुत उपयोगी है
      apps को sandbox में रखें और server isolate करें ताकि compromise होने पर भी दूसरी जगह move करना मुश्किल हो, और logs रखें ताकि यह पता चल सके कि attack हुआ या नहीं और सफल हुआ या नहीं
      मुख्य बात यह है कि patch हो या firewall, एक ही defense mechanism पर निर्भर नहीं रहना चाहिए। आखिरकार उनमें से कोई एक fail होगा
    • सबसे तेज patch cycle को प्राथमिकता देने वाली बात पर जिज्ञासा है। patch timing तय करते समय आप tools इस्तेमाल करते हैं, या time interval के आधार पर करते हैं, यह जानना चाहता हूं
      अभी मैं हर quarter packages update करने की कोशिश[0] करता हूं, लेकिन अगर कोई tool known vulnerabilities बताकर तुरंत response लेने में मदद करे तो अच्छा होगा
      [0] यहां “कोशिश” का मतलब है कि अगर latest version में ऐसी compatibility breakage हो जिसे अपनाना मुश्किल हो, या X.0.0 release हो जिस पर अभी भरोसा नहीं है, तो तुरंत upgrade नहीं कर पाता

  • लेखक ने कहा है कि वे security expert नहीं हैं, इसलिए एक छोटी correction करूं तो, शुरुआती उदाहरण credentials/configuration probing हैं, directory traversal नहीं
    मेरी समझ में directory traversal वह term है जब attacker web root से “escape” करता है या server को normal directory के बाहर की files serve कराने के लिए trick करता है

    • अगर तरीका ऐसी files include कराने का है जिन्हें असल में host नहीं होना चाहिए, तो technically दोनों हो सकता है। उदाहरण के लिए "/../../passwd/etc" जैसा case

  • कम-से-कम मेरे अनुभव में, ऐसे attacks का बड़ा हिस्सा hostile nation-state actors से आता है, यह मुख्य बात है
    विवादास्पद होगा, लेकिन जिन problem countries से आपका कोई लेन-देन नहीं है, उनके पूरे IP ranges block करना उपयोगी हो सकता है। ऐसा करके मैंने एक नई service पर आने वाली probing attempts को 100% रोक दिया था

    • यह मुख्य समस्या नहीं है; बस कई लोग उस क्षेत्र के legitimate users को भी block नहीं करना चाहते
    • अच्छा होता अगर nation-state actors किसी दूसरे देश के servers खरीदकर वहीं से attacks चलाने का कोई तरीका बिल्कुल न रखते
    • 15 साल से ज्यादा पहले, जब हम जिन छोटे local businesses को host करते थे उनके server logs देख रहे थे, तो निष्कर्ष निकाला कि APNIC IP addresses सभी block कर सकते हैं
    • मुझे लगता है geo-blocking आखिरकार legitimate traffic रोकती है और दृढ़ attacker को बस proxy इस्तेमाल करने पर मजबूर करती है, है ना
    • ऐसा करें तो United States और Netherlands को block करना पड़ेगा
      मेरे server पर आने वाली probing ज्यादातर United States से आती है, और काफी पीछे दूसरे नंबर पर Netherlands है। शायद ज्यादातर AWS और दूसरे datacenters से आती है

  • मैं एप्लिकेशन/प्रोडक्ट security में काम करता हूँ, और कई सालों तक अरबों डॉलर वैल्यू वाली कंपनियों के WAF मैनेज किए हैं
    DNS को Cloudflare पर ले जाएँ और साइट पर कुछ WAF rules लगा दें। उदाहरण के लिए, bot score 2 से कम हो तो managed challenge लगाना, या attack score किसी खास value पर हो तो handle करना। खर्च भी शायद लगभग न के बराबर होगा और कई समस्याएँ हल हो जाएँगी
    लेकिन production में ले जाने से पहले ज़रूर test करें। एक test domain रखना भी अच्छा है। WAF कोई सर्वसमाधान नहीं है, बल्कि अस्थायी उपाय जैसा है; अगर app खुद attacks झेलने के लिए harden नहीं है, तो कितने भी advanced WAF या bot protection इस्तेमाल कर लें, उसे बचाया नहीं जा सकता

    • जिन लोगों को इसकी जानकारी नहीं है, उनके लिए: https://blog.cloudflare.com/waf-for-everyone/
      Free Managed Ruleset शायद default रूप से deploy होता है, और Cloudflare change log यहाँ maintain करता है: https://developers.cloudflare.com/waf/change-log
    • self-hosting करने वाले के तौर पर, मैं CloudFlare के WAF और mutual TLS rules का इस्तेमाल करके सिर्फ उन legit callers को पास होने देता हूँ जिन्हें मैं जानता हूँ
      यह बहुत अच्छे से काम करता है। access करने वाले सिर्फ परिवार के लोग हैं, इसलिए setup भी आसान था, और हर किसी को अपना unique certificate मिला है जिसे ज़रूरत पड़ने पर revoke किया जा सकता है
    • आजकल मैं आम तौर पर केवल internal applications मैनेज करता हूँ, इसलिए attack surface public services की तुलना में काफी छोटा है
      लगता है आप इस क्षेत्र को अच्छी तरह जानते हैं, इसलिए जिज्ञासा है: क्या आपने Azure infrastructure और Cloudflare को साथ में इस्तेमाल करने वाले solutions भी मैनेज किए हैं? अगर हाँ, तो OWASP जैसी सामान्य चीज़ों के अलावा ऐसी कौन-सी बातें हैं जिन्हें लोग अक्सर miss कर देते हैं?
    • standard WordPress site के लिए यह ठीक बैठता है, और extra layer के तौर पर GuardGiant और Sucuri plugins जोड़ सकते हैं
    • app के आगे WAF लगाकर काम खत्म मान लेना सूअर पर lipstick लगाने से अलग नहीं है
      अगर किसी company को किसी वजह से ऐसी चीज़ चलानी ही पड़े जो up-to-date नहीं है, तो शायद इसकी ज़रूरत हो सकती है, लेकिन आखिरकार यह सिर्फ अस्थायी उपाय है

  • मैं करीब 1 साल से खुद design किया हुआ 400-line का HTTP/S server self-host कर रहा हूँ, और खुले हुए 3 ports (22, 80, 443) पर आने वाला attack traffic हैरान करने वाली मात्रा में है
    हालांकि attackers असल में क्या करने की कोशिश कर रहे हैं, यह analyze करने का समय नहीं निकाला था; यह post कई खाली जगहें भर देती है
    /var/log/auth.log में दिखने वाली अजीब चीज़ों को भी इसी तरह analyze करना अच्छा रहेगा
    code पूरा open source है और server-side state भी नहीं है, फिर भी attackers का मुझे target करना अजीब लगता है। attacker को सबसे अच्छा जो मिल सकता है वह $5/month VPS का root access और ऐसे domain की temporary defacement है जहाँ कोई आता ही नहीं

    • यह सब automated bots हैं। कोई खास तौर पर परवाह नहीं कर रहा
      अगर आप सबसे जाने-पहचाने 3 ports खोलते हैं तो connections आएँगे ही; उन्हें यह भी नहीं पता कि आप क्या चला रहे हैं और न ही उन्हें फर्क पड़ता है
    • आपके VPN तक access मिल जाए तो यह दूसरी machines पर attack शुरू करने के लिए अच्छा base बन सकता है, और traces छिपाने के लिए एक और layer जोड़ सकता है
      malware hosting या cryptocurrency miner चलाना भी संभव है
    • port 22 पर सिर्फ अपने IP को allow करके बाकी सब block करने पर विचार किया जा सकता है
      मेरा ISP असल में IP बहुत कम बदलता है, और अगर बदले तो hosting web admin panel में login करके rule update कर सकता हूँ

  • हर server पर fail2ban ज़रूर चलाता हूँ, और expose की गई site functionality के type के हिसाब से attacks पकड़ने के लिए custom jails भी जोड़ता हूँ
    हालांकि fail2ban के बाकी defaults अभी भी common attacks रोकने के लिए पर्याप्त हैं या नहीं, यह check किए काफी समय हो गया है। बाद में देखने के लिए यह link bookmark कर लेना चाहिए

    • अगर system में इतनी आसानी से target की जा सकने वाली vulnerability exposed है, तो fail2ban आपको नहीं बचा पाएगा

  • मैं भी अपनी self-hosted service के access logs देखता हूँ, और इस analysis में एक detail साफ तौर पर missing है
    malicious requests का बड़ा हिस्सा आम लोगों द्वारा GitHub जैसी जगहों से आसानी से मिलने वाले security scanners चलाने से आता है। ये आम तौर पर sophisticated attacks नहीं होते; ऐसे project instances server पर requests मारते रहते हैं, response देखते भी नहीं और यह भी परवाह नहीं करते कि rate limit लगी है या नहीं
    कुछ attacks सीधे IP को target नहीं करते, बल्कि domains और subdomains monitor करते हैं, और periodically उसी IP range से वही scan repeat करते हैं
    मेरी पुरानी job में Turkey के एक single static IP से लगातार repeated scans आते थे, तो team ने उसे “Turk” कहना शुरू कर दिया था; अजीब request pattern दिखने पर incident response में पहले यह check करने का step शामिल हो गया था कि वही हमारे service को छेड़ रहा है या नहीं

  • अगर आप AWS में ऐसे logs देख रहे हैं, तो कृपया VPC के आगे AWS WAF लगाना बेहतर होगा
    यह महँगा नहीं है और ऐसी situation में काफी headaches कम करने में मदद करता है। भले ही service तक पहुँचने वाली हर चीज़ को block न कर पाए, फिर भी बहुत मददगार हो सकता है

    • अच्छा suggestion है, लेकिन default rule set से सावधान रहना चाहिए। हमने SOC 2 compliance की वजह से AWS WAF enable किया था
      कुछ overactive rules ने app के कुछ हिस्सों को चुपचाप खराब कर दिया
      एक request body rule था जो request body में "localhost" होने पर block करता था, और एक rule ऐसा भी था जो User-Agent header न होने वाली requests को block करता था। पहले हम API requests में User-Agent require नहीं करते थे, इसलिए root cause मिलने तक कुछ users की पूरी API टूट गई
    • post में बताए गए attacks किसी भी modern web application के लिए समस्या नहीं होंगे। इसलिए समझ नहीं आता कि WAF क्यों जोड़ना चाहिए
    • AWS WAF default rules इस्तेमाल करना इतना आसान नहीं है। हमारे application में बहुत-सी legitimate requests और IPs block हो गए थे
      क्या block हो रहा है यह समझना और पहले validate करना ज़रूरी है; वरना कुछ cases में customers खो सकते हैं
    • सच में, WAF अक्सर मदद से ज़्यादा नुकसान करता है
      यह आसानी से bypass हो जाता है, फिर भी security होने का भ्रम देता है; performance cost भी बड़ी है और legitimate traffic block करने की संभावना भी काफी है: https://www.macchaffee.com/blog/2023/wafs/
    • WAF अक्सर बहुत broad तरीके से block करता है, और कभी-कभी कारण भी अस्पष्ट होता है
      उदाहरण के लिए, हमारी university के researchers Twitter data पर research करते हैं, लेकिन tweets के छोटे random sample से links follow करने भर की वजह से university IP ज्यादातर WAFs में block हो जाता है

  • कभी-कभी लगता है कि इन हमलों में से किसी एक का ठीक से जवाब देने वाला Express सर्वर बनाकर किसी का समय बर्बाद कराया जाए तो मज़ेदार होगा
    लेकिन ऐसा करने पर मेरा समय भी बर्बाद होगा