Maltrail

Maltrail एक नेटवर्क ट्रैफ़िक डिटेक्शन सिस्टम है जो ज्ञात दुर्भावनापूर्ण इन्फ्रास्ट्रक्चर के साथ संचार की पहचान करता है और चयनित ट्रैफ़िक विसंगतियों की रिपोर्ट करता है। यह नेटवर्क पर देखे गए डोमेन, URL, IP पते, IP:port जोड़े, और User-Agent मानों को trails नामक संकेतकों के एक सेट से मिलाता है।

एक डिटेक्शन को एक एकल इवेंट के रूप में रिकॉर्ड किया जाता है जिसमें स्रोत, गंतव्य, प्रोटोकॉल, मिलान किया गया trail, वर्गीकरण, और trail स्रोत शामिल होते हैं:```text "2026-08-07 09:14:22.117034" gw 10.13.13.2 57809 1.1.1.1 53 UDP DNS malware.bakewithdavid.com "asyncrat (malware)" (static)

Maltrail इंडिकेटर-आधारित नेटवर्क मॉनिटरिंग के लिए डिज़ाइन किया गया है। इसकी ह्यूरिस्टिक डिटेक्शन ट्रेल मैचिंग को पूरक बनाती है, लेकिन यह एंडपॉइंट टेलीमेट्री या सामान्य-उद्देश्य वाले इंट्रूज़न प्रिवेंशन सिस्टम का विकल्प नहीं है।

## विशेषताएँ

- 3,000 से अधिक बंडल किए गए स्टैटिक फ़ाइलों, 42 पब्लिक-फ़ीड इंटीग्रेशन, और वैकल्पिक ऑपरेटर-आपूर्त किए गए ट्रेल्स को मिलाकर एक पूर्ण ट्रेल बिल्ड।
- libpcap का उपयोग करने वाला एक मल्टीथ्रेडेड Rust सेंसर, वैकल्पिक Linux `PACKET_FANOUT` कैप्चर वर्कर्स के साथ।
- रिपोर्टिंग इंटरफ़ेस, इवेंट इनटेक, और HTTP API प्रदान करने वाला एक Python सर्वर।
- प्लेन-टेक्स्ट कस्टम ट्रेल्स और व्हाइटलिस्ट जिन्हें समीक्षित और वर्ज़न-नियंत्रित किया जा सकता है।
- स्कैनिंग, DNS एक्सहॉशन, DGA-जैसी लुकअप, संदिग्ध डाउनलोड, प्रॉक्सी प्रोब, संदिग्ध User-Agent मान, और संबंधित नेटवर्क गतिविधि के लिए ह्यूरिस्टिक्स।
- लोकल इवेंट लॉगिंग, रिमोट Maltrail लॉगिंग, syslog पर CEF, और Logstash JSON आउटपुट।
- `maltrail-sensor -T` के साथ डिप्लॉयमेंट वैलिडेशन और वैकल्पिक Prometheus मेट्रिक्स।

## विषय-सूची

- [आर्किटेक्चर](#architecture)
- [रिपोर्टिंग इंटरफ़ेस](#reporting-interface)
- [प्रदर्शन](#performance)
- [इंस्टॉलेशन](#installation)
  - [इंस्टॉलर](#installer)
  - [सोर्स से बिल्ड करना](#building-from-source)
  - [Systemd](#systemd)
  - [Docker](#docker)
- [कॉन्फ़िगरेशन](#configuration)
- [ट्रेल्स](#trails)
- [इवेंट्स और API](#events-and-api)
- [ऑपरेशन्स](#operations)
  - [मॉनिटरिंग](#monitoring)
  - [इवेंट रिटेंशन](#event-retention)
- [डॉक्युमेंटेशन](#documentation)
- [योगदान](#contributing)
- [प्रोजेक्ट](#project)
  - [लाइसेंस](#license)
  - [मेंटेनर्स](#maintainers)
  - [प्रायोजक](#sponsors)
  - [प्रस्तुतियाँ और प्रकाशन](#presentations-and-publications)
  - [व्युत्पन्न ब्लैकलिस्ट](#derived-blacklist)
  - [थर्ड-पार्टी इंटीग्रेशन](#third-party-integrations)
  - [आभार](#acknowledgements)

## आर्किटेक्चर

Maltrail में दो स्वतंत्र प्रोसेस होते हैं जो एक ही होस्ट पर या अलग-अलग होस्ट्स पर चल सकते हैं:```text
   ┌──────────┐   events (UDP or file)   ┌──────────┐
   │  sensor  │ ───────────────────────► │  server  │ ◄── browser
   └──────────┘                          └──────────┘
    Rust                                  Python
    libpcap + PACKET_FANOUT               reporting UI + API
    trail matching + heuristics

सेंसर ट्रैफ़िक कैप्चर करता है, ट्रेल मिलान और ह्यूरिस्टिक विश्लेषण करता है, और इवेंट उत्पन्न करता है। यह इवेंट को स्थानीय रूप से लिख सकता है (LOG_DIR), उन्हें किसी रिमोट Maltrail सर्वर पर भेज सकता है (LOG_SERVER), या दोनों कर सकता है। यह syslog (SYSLOG_SERVER) पर CEF और Logstash (LOGSTASH_SERVER) पर JSON भी भेज सकता है।

सर्वर रिमोट इवेंट प्राप्त और संग्रहीत करता है, स्थानीय रूप से उपलब्ध इवेंट लॉग प्रदान करता है, और वेब इंटरफ़ेस तथा API प्रदान करता है।

रिपोर्टिंग इंटरफ़ेस

Maltrail में पता लगाए गए ट्रैफ़िक को एक्सप्लोर करने के लिए ब्राउज़र-आधारित रिपोर्टिंग इंटरफ़ेस शामिल है, जिसमें लाइव अपडेट, फ़ील्ड-जागरूक खोज, रेट्रो हंटिंग, भौगोलिक दृश्य, ट्राइएज, सहेजे गए दृश्य और निर्यात शामिल हैं।

Maltrail रिपोर्टिंग इंटरफ़ेस

यह इंटरफ़ेस server.py द्वारा HTTP_ADDRESS:HTTP_PORT पर प्रदान किया जाता है। यह सादा JavaScript है जिसमें एक ही तृतीय-पक्ष रनटाइम निर्भरता (PapaParse, CSV पार्सिंग के लिए) है और कोई बिल्ड चरण नहीं है। एक समय में एक दिन देखा जाता है, जिसे एक डेट पिकर से चुना जाता है जो उपलब्ध दैनिक लॉग पर इवेंट-घनत्व ग्रिड का भी काम करता है। इवेंट /events से स्ट्रीम किए जाते हैं और ब्राउज़र में थ्रेट्स में एकत्रित किए जाते हैं — प्रत्येक विशिष्ट (source, trail) के लिए एक पंक्ति — जो एक सॉर्ट करने योग्य ग्रिड में विवरण पैनल के साथ दिखाई जाती है।

विशेषता	नोट्स
लाइव मोड	जोड़े गए इवेंट Server-Sent Events (`/live`) के माध्यम से पुश किए जाते हैं और वर्तमान दृश्य में मर्ज किए जाते हैं। जब SSE उपलब्ध न हो, या उन सत्रों के लिए जिन्हें स्ट्रीम सेवा नहीं दे सकती, तो यह दैनिक लॉग के बाइट रेंज को पोल करने पर वापस चला जाता है। नए उच्च-गंभीरता वाले थ्रेट डेस्कटॉप नोटिफिकेशन और एक श्रव्य अलर्ट उठा सकते हैं; दोनों को म्यूट किया जा सकता है
खोज	फ़ील्ड-स्कोप्ड टोकन (`src:` `dst:` `port:` `proto:` `type:` `trail:` `info:` `family:` `tag:` `uid:` `sev:` `dir:` `status:`; `family:interlock` `interlock-1`/`-2` को शामिल करता है, जो एक फ़ीड डंप के विभाजित शार्ड हैं) स्पेस के साथ AND के रूप में संयोजित, बहिष्कृत करने के लिए `-`, `*` वाइल्डकार्ड, CIDR (`src:10.0.0.0/8`), और संख्यात्मक रेंज और तुलनाएँ (`port:>1024`, `count:>=100`)। सक्रिय फ़िल्टर हटाने योग्य चिप्स के रूप में दिखाई देते हैं
रेट्रो हंट	एक संकेतक के लिए सभी बनाए रखे गए दैनिक लॉग खोजता है (`/hunt`), न कि केवल दृश्य में मौजूद दिन। एक दिन सीमा, एक वॉल-क्लॉक बजट और एक नमूना कैप से सीमित; बजट द्वारा काटे गए दिन को पूर्ण दिनों से अलग रिपोर्ट किया जाता है, न कि पूर्ण कुल के रूप में गिना जाता है। एक प्रति-दिन साइडकार इंडेक्स (`LOG_DIR/index/`, `USE_EVENT_INDEX`) स्वीप को हर गैर-मेल खाती पंक्ति को छोड़ने देता है और `/counts` को सटीक बनाता है
विश्व मानचित्र	चयनित दिन के लिए प्रति-देश इवेंट घनत्व (`/geo`), प्रत्येक इवेंट के बाहरी एंडपॉइंट को रखते हुए। जिन इवेंट को बाहरी पते के लिए जिम्मेदार नहीं ठहराया जा सकता, उन्हें अनुमान लगाने के बजाय अनमैप्ड के रूप में रिपोर्ट किया जाता है। ओरिजिन आर्क बनाने के लिए `HOME_LAT` / `HOME_LON` सेट करें
ट्राइएज	प्रति-थ्रेट स्थिति (नया / जाँच में / हल किया गया / गलत सकारात्मक), फ्री-टेक्स्ट नोट्स, टैग, और छिपाना। पंक्ति संदर्भ मेनू से व्हाइटलिस्ट नियम और OSINT पिवट उपलब्ध हैं
सहेजे गए दृश्य	नामित फ़िल्टर प्रीसेट
निर्यात	वर्तमान फ़िल्टर किया गया दृश्य CSV, JSON, या डीफैंग्ड संकेतक के रूप में
रूप-रंग	डार्क और लाइट थीम, और अलग-अलग टेक्स्ट-आकार के चरण

ट्राइएज स्थिति, सहेजे गए दृश्य, टैग और रूप-रंग सेटिंग्स ब्राउज़र (localStorage) में संग्रहीत होती हैं, सर्वर पर नहीं: वे प्रति-ब्राउज़र और प्रति-ओरिजिन होती हैं, और विश्लेषकों के बीच साझा नहीं की जातीं।

नेटवर्क फ़िल्टर से प्रतिबंधित सत्र केवल अपने स्वयं के नेटवर्क से इवेंट देखते हैं, और यह प्रतिबंध इवेंट सूची के साथ-साथ काउंट, मैप और ब्लैकलिस्ट एंडपॉइंट पर भी लागू होता है।

व्यक्तिगत पतों के लिए देश और ASN संवर्धन सर्वर द्वारा stat.ripe.net पर लुकअप किया जाता है, जो परिणामों को कैश करता है और उन्हें अपने स्वयं के /ripe एंडपॉइंट से इंटरफ़ेस को प्रदान करता है; ब्राउज़र Maltrail के अलावा किसी से बात नहीं करता। आउटबाउंड लुकअप को पूरी तरह बंद करने के लिए DISABLE_RIPE_LOOKUPS सेट करें। उनके बिना — या बिना इंटरनेट एक्सेस वाले होस्ट पर — फ़्लैग स्थानीय RIR तालिका से आते हैं और इंटरफ़ेस में बाकी सब कुछ ऑफ़लाइन काम करता है।

प्रदर्शन

प्रदर्शन प्रोसेसर, ट्रैफ़िक संरचना, ट्रेल-सेट आकार, कैप्चर ड्राइवर, और नेटवर्क इंटरफ़ेस पर निर्भर करता है। नीचे दिए गए आंकड़े सेंसर के पैकेट-प्रोसेसिंग पथ को अलग-थलग मापते हैं; वे एंड-टू-एंड लाइव-कैप्चर माप नहीं हैं।

AMD Ryzen 7 PRO 4750U पर ह्यूरिस्टिक्स सक्षम और 1.5 मिलियन-पंक्ति ट्रेल सेट के साथ प्रतिनिधि माप:

ट्रैफ़िक	प्रति पैकेट समय
ICMP echo, 58 बाइट	101 ns
TCP SYN, 70 बाइट	302 ns
बल्क TLS, 1,473 बाइट	402 ns
वार्म कैश के साथ DNS क्वेरी, 93 बाइट	452 ns
मिश्रित ट्रैफ़िक, 866-बाइट औसत	552 ns
HTTP अनुरोध, 169 बाइट	602 ns
अद्वितीय नाम के साथ DNS क्वेरी, 93 बाइट	1,102 ns

समान जनरेट किए गए कैप्चर, कॉन्फ़िगरेशन, और ट्रेल सेट का उपयोग करते हुए ऑफ़लाइन तुलना रन ने परीक्षण किए गए सिस्टमों में सेवानिवृत्त Python सेंसर की तुलना में 14–37× कम स्थिर-अवस्था प्रति-पैकेट लागत मापी। वे आंकड़े पूरी-प्रक्रिया समय को स्थिर अवस्था से अलग करते हैं, क्योंकि ट्रेल लोडिंग एक छोटे रीप्ले पर हावी होती है। पहचान स्वयं अलग से प्रमाणित की जाती है, sensor/tests/replay.rs में 42-केस कॉर्पस द्वारा।

इसे लक्ष्य सिस्टम पर इसके साथ मापें:```bash cargo bench --manifest-path sensor/Cargo.toml --bench hotpath

एक कैप्चर वर्कर डिफ़ॉल्ट रूप से उपयोग किया जाता है। अतिरिक्त वर्कर कैप्चर क्षमता बढ़ा सकते हैं, लेकिन Linux
फ़्लो हैशिंग प्रति-स्रोत स्थिति को वर्कर के बीच विभाजित करती है और इसलिए कुछ
स्कैन ह्यूरिस्टिक्स की संवेदनशीलता कम कर देती है। प्रलेखित परीक्षण में, 91% सिंगल-वर्कर ह्यूरिस्टिक अलर्ट दो
वर्कर के साथ बने रहे, चार के साथ 86%, और आठ के साथ 65%। सटीक ट्रेल मिलान अपरिवर्तित रहा। `CAPTURE_FANOUT` केवल तब बढ़ाएँ जब कैप्चर-ड्रॉप मेट्रिक्स दिखाते हैं कि यह आवश्यक है।

बेंचमार्क कार्यप्रणाली, हार्डवेयर परिणाम, प्रोफाइलर आउटपुट, मेमोरी माप, और लाइव फैनआउट
जाँच [`sensor/docs/REPORT.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/REPORT.md) में प्रलेखित हैं।

## इंस्टॉलेशन

### इंस्टॉलर

इंस्टॉलर बारह Linux वितरणों — Debian, Ubuntu, Fedora, Rocky, AlmaLinux,
Arch, openSUSE Leap और Tumbleweed, और Alpine — साथ ही FreeBSD और macOS पर, प्रत्येक रिलीज़ पर सत्यापित है, जिसका
पूर्ण परिणाम [`docs/compat`](https://github.com/stamparm/maltrail/blob/master/docs/compat) में दर्ज है। Raspberry Pi OS और अन्य 64-बिट ARM सिस्टम
`aarch64` बिल्ड का उपयोग करते हैं; 32-बिट ARM के लिए कोई प्रीबिल्ट सेंसर नहीं है और इसे स्रोत से बनाना होगा।```bash
curl -fsSL https://raw.githubusercontent.com/stamparm/maltrail/master/install.sh | sudo sh

यह निर्भरताएँ इंस्टॉल करता है, /opt/maltrail के अंतर्गत एक प्रबंधित चेकआउट बनाता है, प्रीबिल्ट सेंसर का चेकसम सत्यापित करता है, एक अनविलेज्ड maltrail खाता बनाता है, systemd यूनिट्स इंस्टॉल करता है, लॉग और स्टेट डायरेक्टरीज़ तैयार करता है, और सेंसर तथा सर्वर शुरू करता है। इंस्टॉलर को दोबारा चलाने पर प्रबंधित चेकआउट अपग्रेड हो जाता है।

एलिवेटेड विशेषाधिकारों के साथ इसे चलाने से पहले स्क्रिप्ट की समीक्षा करें। मौजूदा चेकआउट से, ड्राई रन सिस्टम में बदलाव किए बिना कमांड दिखाता है:```bash sh install.sh --dry-run

सामान्य इंस्टॉलर विकल्प:```bash
sh install.sh --role sensor      # Install only the sensor
sh install.sh --ref 3.1.2        # Install a release tag instead of master
sh install.sh --no-service       # Install without changing systemd
sh install.sh --dry-run          # Print commands without applying them
sh install.sh --uninstall        # Remove the managed installation; keep logs and state

डैशबोर्ड इंस्टॉलेशन के बाद http://127.0.0.1:8338 पर उपलब्ध होता है। ध्यान दें कि शिप किया गया HTTP_ADDRESS 0.0.0.0 है, इसलिए यह हर इंटरफ़ेस पर पहुँच योग्य है, केवल लूपबैक पर नहीं — और डिफ़ॉल्ट क्रेडेंशियल admin / changeme! हैं। होस्ट के अविश्वसनीय नेटवर्क पर होने से पहले USERS बदलें, और HTTP_ADDRESS को 127.0.0.1 पर सेट करें (या सर्वर को TLS के साथ रिवर्स प्रॉक्सी के पीछे रखें)।

प्रारंभिक ट्रेल बिल्ड में कई मिनट लग सकते हैं। सेंसर तब तक ट्रेल मैचों का पता नहीं लगाता जब तक कि एक वैध ट्रेल सेट उपलब्ध न हो। systemd यूनिट स्टार्टअप से पहले सेंसर का -T सत्यापन चलाता है ताकि अनुपस्थित विशेषाधिकार, एक अलिखनीय लॉग डायरेक्टरी, या एक अमान्य ट्रेल सेट स्टार्टअप को स्पष्ट रूप से विफल कर दे।

इंस्टॉलर टेस्ट हार्नेस बारह डिस्ट्रीब्यूशन्स को कवर करता है, और "यह इंस्टॉल हो गया" दावा नहीं है: प्रत्येक में सर्वर शुरू किया जाता है और /ping के लिए पूछा जाता है, सेंसर से -T के साथ स्वयं को मान्य करने के लिए कहा जाता है, यूनिट्स की उन पथों के लिए जाँच की जाती है जो रिज़ॉल्व होते हैं, इंस्टॉलर को फिर से चलाया जाता है ताकि यह सिद्ध हो सके कि अपग्रेड ऑपरेटर कॉन्फ़िगरेशन बनाए रखता है, और --uninstall चलाया जाता है। प्रत्येक परिणाम प्रति प्लेटफ़ॉर्म docs/compat में रिकॉर्ड किया जाता है, और वहाँ का पेज उन पंक्तियों से जनरेट किया जाता है बजाय हाथ से लिखे जाने के।

Alpine और अन्य musl सिस्टम्स को -musl सेंसर बिल्ड मिलता है। उन्हें पहले बताया जाता था कि प्रीबिल्ट बाइनरी glibc-लिंक्ड है और अपना स्वयं का कंपाइल करें; सेंसर musl पर मूल रूप से बिल्ड और रन होता है, इसलिए वह एक अनुपस्थित आर्टिफ़ैक्ट था न कि प्लेटफ़ॉर्म सीमा।

सोर्स से बिल्ड करना

सेंसर के लिए Rust 1.74 या नया, libpcap डेवलपमेंट हेडर्स, और सिस्टम के capability टूल्स आवश्यक हैं। सर्वर और ट्रेल अपडेटर के लिए Python 3.6 या नया आवश्यक है।

डिस्ट्रीब्यूशन पैकेज इंस्टॉल करें:```bash

Debian / Ubuntu / Raspberry Pi OS

sudo apt-get install cargo libpcap-dev libcap2-bin python3

RHEL / Fedora

sudo dnf install cargo libpcap-devel libcap python3

openSUSE / SLES

sudo zypper install cargo rust libpcap-devel libcap-progs python311

फिर सेंसर को बनाएं और मान्य करें:```bash
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail

cargo build --release --manifest-path sensor/Cargo.toml

sudo setcap cap_net_raw,cap_net_admin=eip \
  sensor/target/release/maltrail-sensor

sudo install -d -o "$USER" -g "$(id -gn)" -m 750 /var/log/maltrail

sensor/target/release/maltrail-sensor -T
sensor/target/release/maltrail-sensor

सर्वर को किसी अन्य टर्मिनल में या किसी अन्य होस्ट पर प्रारंभ करें:```bash python3 server.py

पूर्वनिर्मित सेंसर बाइनरीज़ वर्तमान रिलीज़ों के साथ SHA-256 चेकसम के साथ संलग्न हैं: Linux `x86_64`
और `aarch64` दोनों glibc और musl के विरुद्ध, macOS Apple silicon और Intel पर, FreeBSD `amd64`, और
Windows `x86_64`।

glibc बिल्ड libpcap को स्टैटिक रूप से लिंक करते हैं और glibc 2.28 को लक्षित करते हैं, इसलिए C लाइब्रेरी ही एकमात्र चीज़ है जिसकी उन्हें आवश्यकता होती है — RHEL 8+, Debian 10+, Ubuntu 18.04+ और Leap 15.x सभी पर कुछ भी इंस्टॉल करने की आवश्यकता नहीं है। musl
बिल्ड पूरी तरह से स्टैटिक हैं, इसलिए Alpine को कुछ भी आवश्यकता नहीं है। Windows बिल्ड 64-बिट है और इसे Windows 10 या बाद के संस्करण के साथ-साथ
[Npcap](https://npcap.com) इंस्टॉल किए जाने की आवश्यकता होती है, तभी यह शुरू होगा — `wpcap.dll` एक लोड-टाइम निर्भरता है,
इसलिए इसके बिना लोडर एक्जीक्यूटेबल को अस्वीकार कर देता है, कैप्चर के समय विफल होने के बजाय। आर्काइव भी यही कहता है।

**3.1.1 और उससे पहले** की बाइनरीज़ ऐसा नहीं करती थीं: वे libpcap को डायनामिक रूप से लिंक करती थीं, और इसे उस नाम से मांगती थीं जो उनका AlmaLinux बिल्ड होस्ट उपयोग करता है। Debian और Ubuntu उसी लाइब्रेरी को पुराने नाम `libpcap.so.0.8` के अंतर्गत प्रदान करते हैं, इसलिए वे बाइनरीज़ शुरू होने से पहले ही रुक जाती हैं —```
./maltrail-sensor: error while loading shared libraries: libpcap.so.1: cannot open shared object file

— उस मशीन पर जिसमें libpcap इंस्टॉल है। install.sh आपके लिए अनुपलब्ध नाम को लिंक कर देता है। मैन्युअल रूप से:```bash

adjust the directory for your architecture: aarch64-linux-gnu, or /usr/lib64 on RPM distributions

sudo ln -sf /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 /usr/lib/x86_64-linux-gnu/libpcap.so.1 sudo ldconfig

### Systemd

प्रदान की गई `packaging/systemd/` यूनिट्स दोनों प्रक्रियाओं को गैर-विशेषाधिकार प्राप्त `maltrail` उपयोगकर्ता के रूप में चलाती हैं। Systemd `/var/log/maltrail` और `/var/lib/maltrail` बनाता है, फ़ाइलसिस्टम एक्सेस को प्रतिबंधित करता है, और सेंसर को `CAP_NET_RAW` और `CAP_NET_ADMIN` प्रदान करता है।

इंस्टॉलर इन यूनिट्स को स्वचालित रूप से कॉन्फ़िगर करता है। किसी मौजूदा सोर्स इंस्टॉलेशन के लिए, [`sensor/docs/INSTALL.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/INSTALL.md) में दी गई मैन्युअल सेवा प्रक्रिया का पालन करें।

सेवा की स्थिति और लॉग इस प्रकार जाँचें:```bash
systemctl status maltrail-sensor maltrail-server
journalctl -u maltrail-sensor -f

Docker

आपूर्त किए गए Compose परिनियोजन को इसके साथ शुरू करें:```bash docker compose -f docker/docker-compose.yml up -d

कंटेनर कॉन्फ़िगरेशन, स्टोरेज, विशेषाधिकार, और हेल्थ चेक को
[`docker/README.md`](https://github.com/stamparm/maltrail/blob/master/docker/README.md) में प्रलेखित किया गया है।

## कॉन्फ़िगरेशन

Maltrail `maltrail.conf` पढ़ता है, जिसमें अलग-अलग `[Sensor]` और `[Server]` सेटिंग्स होती हैं। इंस्टॉलर प्रबंधित कॉन्फ़िगरेशन को `/etc/maltrail.conf` पर रखता है।

अक्सर उपयोग किए जाने वाले सेंसर विकल्पों में शामिल हैं:

| विकल्प | उद्देश्य |
| --- | --- |
| `MONITOR_INTERFACE` | कैप्चर इंटरफ़ेस या इंटरफ़ेस; `any` सभी समर्थित इंटरफ़ेस चुनता है |
| `CAPTURE_FILTER` | BPF कैप्चर फ़िल्टर |
| `CAPTURE_FANOUT` | Linux कैप्चर सॉकेट की संख्या; डिफ़ॉल्ट रूप से एक |
| `CAPTURE_WORKERS` | कैप्चर वर्कर, प्रत्येक में एक सॉकेट; डिफ़ॉल्ट रूप से `CAPTURE_FANOUT`, इसलिए जब तक कोई भी सेट न हो, एक |
| `LOG_DIR` | स्थानीय इवेंट-लॉग निर्देशिका |
| `TRAILS_FILE` | जनरेट किया गया ट्रेल डेटाबेस |
| `LOG_SERVER` | रिमोट Maltrail इवेंट सर्वर |
| `SYSLOG_SERVER` | CEF syslog गंतव्य या गंतव्य |
| `LOGSTASH_SERVER` | Logstash JSON गंतव्य या गंतव्य |
| `STATS_ADDRESS` | Prometheus मेट्रिक्स लिसनर; कॉन्फ़िगर न किए जाने तक अक्षम |
| `UPDATE_PERIOD` | ट्रेल रीफ़्रेश अंतराल |
| `STATIC_TRAILS_URL` | असेंबल किया गया स्टैटिक ट्रेल सेट कहाँ से प्राप्त किया जाता है; नई सामग्री कब आएगी, इसे नियंत्रित करने के लिए इसे किसी दिनांकित रिलीज़ पर पिन करें |
| `USER_WHITELIST` | ऑपरेटर-प्रबंधित संकेतक जिन्हें अलर्ट नहीं करना चाहिए |
| `CUSTOM_TRAILS_DIR` | ऑपरेटर-प्रबंधित ट्रेल निर्देशिका |
| `STATIC_TRAILS_DIR` | ट्रेल्स रिपॉज़िटरी का वैकल्पिक चेकआउट; केवल UI में ट्रेल का स्रोत उद्धरण दिखाने के लिए उपयोग किया जाता है |

`PROCESS_COUNT` सेवानिवृत्त Python सेंसर और लेगेसी इवेंट-लॉग थ्रॉटल पर लागू होता है; यह Rust सेंसर के वर्कर काउंट को **नहीं** सेट करता है। इसके बजाय `CAPTURE_FANOUT` या `CAPTURE_WORKERS` के साथ कैप्चर वर्कर कॉन्फ़िगर करें।

कॉन्फ़िगरेशन बदलने के बाद डिप्लॉयमेंट चेक चलाएँ:```bash
sensor/target/release/maltrail-sensor -T

The check validates configuration, trails, whitelist entries, capture filter, privileges, log storage, update support, and worker settings. A successful check includes positive trail and whitelist counts rather than only confirming that files exist.

Trails

A trail is one indicator — a domain, URL, IP address, IP:port pair, User-Agent, JA3/JA4 fingerprint or certificate hash — together with what it means and where it came from. The updater merges four sources into TRAILS_FILE, in this order:

source	where it comes from
Feeds	`feeds/*.py`, fetched directly by your deployment from each publisher
Custom	`CUSTOM_TRAILS_DIR` and `CUSTOM_TRAILS_URL`, your own indicators
Static	the assembled set from stamparm/trails, fetched from `STATIC_TRAILS_URL`; separately licensed
Engine lists	`data/mass_scanner*.txt`, shipped here because they change rarely

The static trails live in their own repository. Detection content changes tens of times a day; the engine does not, and keeping them together meant updating detection required pulling code and made this repository's history unusable. STATIC_TRAILS_URL points at the newest published set:```text STATIC_TRAILS_URL https://github.com/stamparm/trails/releases/latest/download/trails.csv.gz

इसे किसी विशिष्ट `content-YYYYMMDD-HHMM` रिलीज़ पर इंगित करें ताकि एक संस्करण पिन हो जाए, जिससे एक खराब प्रकाशन तुरंत वैश्विक न हो जाए। यह सेट `TRAILS_FILE` के बगल में कैश किया जाता है, जो ऑफ़लाइन या एयर-गैप्ड पुनर्निर्माण को संभव बनाता है; डाउनलोड करने से पहले प्रकाशित `sha256` की जाँच की जाती है, इसलिए एक डिप्लॉयमेंट जो सामग्री बदलने से अधिक बार अपडेट होता है, 11 MB के बजाय 65 बाइट्स स्थानांतरित करता है, और एक पेलोड जो अपने डाइजेस्ट से मेल नहीं खाता, उसे कैश के पक्ष में अस्वीकार कर दिया जाता है।

`update_trails()` एक नया `TRAILS_FILE` परमाणु रूप से और केवल एक सफल बिल्ड के बाद प्रकाशित करता है। जो फ़ीड कुछ भी वापस नहीं करते हैं, उन्हें नाम से रिपोर्ट किया जाता है, ताकि एक डिप्लॉयमेंट चुपचाप किसी ऐसे स्रोत पर निर्भर न रहे जो चुपचाप सेवानिवृत्त हो गया हो।

`CUSTOM_TRAILS_DIR` के अंतर्गत अपने स्वयं के संकेतक जोड़ें, और जो कुछ भी कभी इवेंट नहीं उठाना चाहिए उसे `USER_WHITELIST` में जोड़ें। दोनों को इंस्टॉलेशन डायरेक्टरी के बाहर रखें ताकि एक अपग्रेड उन्हें अधिलेखित न कर सके।

स्टैटिक ट्रेल योगदान [stamparm/trails](https://github.com/stamparm/trails) पर जाते हैं; नए फ़ीड यहाँ जाते हैं। किसी भी तरह से एक संकेतक को एक वर्गीकरण और एक स्रोत की आवश्यकता होती है जिसे कोई जाँच सके — देखें [Contributing](#contributing)।

## Events and API

Maltrail प्रत्येक डिटेक्शन के लिए एक व्हाइटस्पेस-सेपरेटेड इवेंट रिकॉर्ड करता है, जहाँ किसी मान में स्पेस हो तो CSV कोटिंग का उपयोग करता है:```text
"<time>" <sensor> <src_ip> <src_port> <dst_ip> <dst_port> <proto> <type> <trail> "<info>" <reference>

type फ़ील्ड यह पहचानता है कि क्या मेल खाया, जिसमें DNS, IP, IPORT, URL, PATH, HTTP, UA, PORT, CERT, JA3, और JA4 शामिल हैं। info फ़ील्ड में trail वर्गीकरण होता है, और reference उस स्थिर सूची, फ़ीड, कस्टम स्रोत, या heuristic की पहचान करता है जिसने इसे उत्पन्न किया। JA3/JA4 प्रकार TLS client फ़िंगरप्रिंट पर सक्रिय होते हैं: किसी इम्प्लांट का TLS स्टैक हर पते और डोमेन रोटेशन के बाद भी बचा रहता है, इसलिए उसका hello hash तब भी मेल खाता रहता है जब बाकी सब कुछ जल चुका होता है (abuse.ch SSLBL JA3 फ़ीड द्वारा प्रकाशित)।

संकेतक लुकअप

एक डोमेन, IP पते, या URL को क्वेरी करने के लिए /check का उपयोग करें:```bash curl 'http://127.0.0.1:8338/check?q=www.sub.evil.example'

| `-s` | `--server` | Server URL (default: `http://localhost:8080`) |
| `-t` | `--token` | API token for authentication |
| `-o` | `--output` | Output format: `json`, `yaml`, `table` (default: `table`) |
| `-v` | `--verbose` | Enable verbose output |
| `-q` | `--quiet` | Suppress non-essential output |
| `-h` | `--help` | Show help message |
| `-V` | `--version` | Show version information |

### उदाहरण

```bash
# सर्व उपलब्ध स्कैनर की सूची बनाएं
scanner-cli list

# किसी विशिष्ट लक्ष्य पर स्कैन चलाएं
scanner-cli scan --target https://example.com --scanner xss

# JSON प्रारूप में परिणाम निर्यात करें
scanner-cli scan --target https://example.com --output json > results.json

# कस्टम सर्वर और टोकन के साथ कनेक्ट करें
scanner-cli --server https://api.example.com --token YOUR_TOKEN list

कॉन्फ़िगरेशन

कॉन्फ़िगरेशन फ़ाइल ~/.scanner/config.yaml पर स्थित है:

server: http://localhost:8080
token: your-api-token
output: table
timeout: 30
scanners:
  - xss
  - sqli
  - ssrf

पर्यावरण चर

चर	विवरण
`SCANNER_SERVER`	सर्वर URL को ओवरराइड करें
`SCANNER_TOKEN`	API टोकन सेट करें
`SCANNER_OUTPUT`	डिफ़ॉल्ट आउटपुट प्रारूप सेट करें
`SCANNER_TIMEOUT`	अनुरोध टाइमआउट सेकंड में सेट करें

आर्किटेक्चर

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   CLI       │────▶│   API       │────▶│  Scanner    │
│   Client    │     │   Server    │     │   Engine    │
└─────────────┘     └─────────────┘     └─────────────┘
                           │
                           ▼
                    ┌─────────────┐
                    │  Database   │
                    └─────────────┘

घटक

CLI Client: सर्वर के साथ इंटरैक्ट करने के लिए कमांड-लाइन इंटरफ़ेस
API Server: स्कैन अनुरोधों को संभालने वाला RESTful API
Scanner Engine: विभिन्न सुरक्षा स्कैनर लागू करता है
Database: स्कैन परिणाम और कॉन्फ़िगरेशन संग्रहीत करता है

स्कैनर

XSS स्कैनर

क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरियों का पता लगाता है:

scanner-cli scan --target https://example.com --scanner xss

समर्थित पेलोड प्रकार:

प्रतिबिंबित XSS
संग्रहीत XSS
DOM-आधारित XSS

SQL इंजेक्शन स्कैनर

SQL इंजेक्शन कमजोरियों का पता लगाता है:

scanner-cli scan --target https://example.com --scanner sqli

समर्थित तकनीकें:

ब्लाइंड SQL इंजेक्शन
त्रुटि-आधारित SQL इंजेक्शन
समय-आधारित SQL इंजेक्शन
संघ-आधारित SQL इंजेक्शन

SSRF स्कैनर

सर्वर-साइड अनुरोध जालसाजी (SSRF) कमजोरियों का पता लगाता है:

scanner-cli scan --target https://example.com --scanner ssrf

पोर्ट स्कैनर

खुले पोर्ट और सेवाओं का पता लगाता है:

scanner-cli scan --target https://example.com --scanner port

API संदर्भ

प्रमाणीकरण

सभी API अनुरोधों के लिए प्रमाणीकरण की आवश्यकता होती है। टोकन को Authorization हेडर में शामिल करें:

Authorization: Bearer YOUR_TOKEN

एंडपॉइंट

`GET /api/v1/scanners`

सभी उपलब्ध स्कैनर की सूची बनाएं।

प्रतिक्रिया:

{
  "scanners": [
    {
      "name": "xss",
      "description": "Cross-Site Scripting Scanner",
      "version": "1.0.0"
    },
    {
      "name": "sqli",
      "description": "SQL Injection Scanner",
      "version": "1.0.0"
    }
  ]
}

`POST /api/v1/scan`

एक नया स्कैन शुरू करें।

अनुरोध निकाय:

{
  "target": "https://example.com",
  "scanner": "xss",
  "options": {
    "depth": 3,
    "timeout": 30
  }
}

प्रतिक्रिया:

{
  "scan_id": "abc123",
  "status": "running",
  "target": "https://example.com",
  "scanner": "xss",
  "started_at": "2024-01-15T10:30:00Z"
}

`GET /api/v1/scan/{scan_id}`

किसी विशिष्ट स्कैन की स्थिति और परिणाम प्राप्त करें।

प्रतिक्रिया:

{
  "scan_id": "abc123",
  "status": "completed",
  "target": "https://example.com",
  "scanner": "xss",
  "started_at": "2024-01-15T10:30:00Z",
  "completed_at": "2024-01-15T10:32:15Z",
  "findings": [
    {
      "type": "xss",
      "severity": "high",
      "url": "https://example.com/search?q=<script>alert(1)</script>",
      "parameter": "q",
      "payload": "<script>alert(1)</script>",
      "evidence": "Reflected XSS in search parameter"
    }
  ]
}

`DELETE /api/v1/scan/{scan_id}`

किसी स्कैन को रद्द करें या हटाएं।

प्रतिक्रिया:

{
  "message": "Scan deleted successfully",
  "scan_id": "abc123"
}
``````json
{
  "query": "www.sub.evil.example",
  "found": true,
  "trail": "evil.example",
  "info": "asyncrat (malware)",
  "reference": "(static)",
  "confidence": 100
}

confidence फ़ील्ड (0-100, या अनुपलब्ध होने पर null) बताता है कि स्रोत लिस्टिंग का कितनी मज़बूती से समर्थन करते हैं: एकल फ़ीड के लिए 40, प्रत्येक अतिरिक्त स्वतंत्र रूप से सहमत फ़ीड के लिए +15, अधिकतम 100 तक, और ऑपरेटर की स्वयं की कस्टम और स्टैटिक प्रविष्टियों के लिए पूरे अंक। यह trail-update के समय फ़ीड सहमति से trails.csv के बगल में trails.confidence साइडकार में गणना की जाती है; UPDATE_SERVER से trails खींचने वाले सर्वर के पास स्कोर करने के लिए कोई provenance नहीं होता और वह null रिपोर्ट करता है। इसका उपयोग triage को प्राथमिकता देने के लिए करें - 40 पर एकल-फ़ीड लिस्टिंग firewall नियम पाने से पहले दूसरी नज़र की हकदार है।

एक सबडोमेन लुकअप अपने सूचीबद्ध parent से मेल खा सकता है। URL लुकअप अकेले host की जाँच करने से पहले host/path की जाँच करते हैं। सर्वर memory-mapped trail डेटाबेस पढ़ता है और पुनः आरंभ किए बिना trail अपडेट देखता है।

सार्वजनिक स्टैटिक और फ़ीड trails बिना प्रमाणीकरण के उपलब्ध हैं, जो रिमोट सेंसर द्वारा उपयोग किए जाने वाले /trails endpoint के अनुरूप है। कस्टम trails के लिए अधिकृत सत्र आवश्यक है; अनधिकृत कस्टम-केवल लुकअप को miss के रूप में रिपोर्ट किया जाता है। इवेंट डेटा प्रमाणीकृत रहता है।

Operations

Monitoring

maltrail-sensor -T को deployment और configuration gate के रूप में उपयोग करें। दिया गया systemd unit इसे ExecStartPre के रूप में चलाता है।

यह पुष्टि करने के लिए कि detection स्वयं काम करता है — न कि केवल यह कि प्रक्रियाएँ शुरू होती हैं — चलाएँ:```bash python3 server.py --detect-test

यह एक तैयार किए गए pcap को फिर से चलाता है जिसमें अनुकरण किया गया दुर्भावनापूर्ण ट्रैफ़िक होता है (एक DNS क्वेरी, एक IP, एक
`IP:port`, एक URL पथ और एक `Host` हेडर पर trail हिट्स, साथ ही SQL-injection, traversal, RCE, XSS, proxy-probe,
sinkhole, अनुपस्थित-`Host` और port/web/infection-scanning heuristics) इंस्टॉल किए गए सेंसर के माध्यम से, और यह दावा करता है कि हर अपेक्षित डिटेक्शन सक्रिय होता है। इसे किसी root, इंटरफ़ेस या अपने स्वयं के trail सेट की आवश्यकता नहीं होती है। एक स्वस्थ इंस्टॉल `20/20 detection(s) fired` प्रिंट करता है।

जब `STATS_ADDRESS` कॉन्फ़िगर किया जाता है, तो कम से कम इन Prometheus मेट्रिक्स की निगरानी करें:

| मेट्रिक | परिचालन अर्थ |
| --- | --- |
| `maltrail_up == 0` | कोई capture worker नहीं चल रहा है |
| बढ़ता हुआ `maltrail_capture_dropped_total` | capture ring पैकेट छोड़ रहा है |
| बढ़ता हुआ `maltrail_local_log_errors_total` | इवेंट उत्पन्न हुए लेकिन स्थानीय रूप से लिखे नहीं जा सके |
| बढ़ता हुआ `maltrail_remote_log_errors_total` | इवेंट किसी रिमोट sink तक नहीं पहुँचाए जा सके; `DISABLE_LOCAL_LOG_STORAGE` के साथ वे खो जाते हैं |
| `maltrail_trail_generation` आगे नहीं बढ़ रहा | सक्रिय trail सेट रीफ़्रेश नहीं हो रहा है |
| `maltrail_log_dir_free_bytes` | स्थानीय इवेंट स्टोरेज के लिए शेष क्षमता |
| बढ़ता हुआ `maltrail_state_saturations_total` | एक heuristic state सीमा तक पहुँच गई |
| बढ़ता हुआ `maltrail_throttle_evictions_total` | event-throttle तालिका अपनी सीमा पर है, इसलिए इवेंट कॉन्फ़िगर किए गए समय से पहले एकत्रित किए जा रहे हैं |

State saturation संबंधित heuristic को प्रभावित करता है; सटीक trail मिलान सक्रिय रहता है।

trail रीलोड का अनुरोध करने के लिए `SIGHUP` भेजें या `systemctl reload maltrail-sensor` का उपयोग करें। किसी अन्य प्रक्रिया द्वारा अपडेट की गई trail फ़ाइलें स्वचालित रूप से पहचानी जाती हैं और सेंसर को पुनः आरंभ किए बिना workers को प्रकाशित की जाती हैं।

संक्षिप्त observable store (`USE_CONDENSED_STORAGE`, `meta.sqlite`) सर्वर के novelty और retro-hunt दृश्यों का समर्थन करता है। प्रति-दिन event-log sidecar index (`USE_EVENT_INDEX`,
`LOG_DIR/index/*.sqlite`, डिस्क पर लगभग लॉग आकार का दोगुना) वह है जो `/counts` को सटीक और
`/hunt` को तेज़ बनाता है; यह लॉग से ही वृद्धिशील रूप से बनाए रखा जाता है और
`server.py --rebuild-index` के साथ पुनर्निर्मित किया जा सकता है। सेवानिवृत्त सेंसर के साथ संगतता
[`sensor/docs/COMPATIBILITY.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/COMPATIBILITY.md) में प्रलेखित है।

### इवेंट रिटेंशन

Maltrail इवेंट लॉग को रोटेट या हटाता नहीं है। स्टोरेज आवश्यकताओं और संगठनात्मक नीति के अनुसार रिटेंशन,
आर्काइवल और विलोपन को परिभाषित करने की ज़िम्मेदारी ऑपरेटरों की है।

अनुशंसित प्रथाएँ:

- `LOG_SERVER`,
  `SYSLOG_SERVER`, या `LOGSTASH_SERVER` के साथ टिकाऊ इवेंट प्रति को किसी रिमोट Maltrail सर्वर या SIEM पर भेजें।
- अपेक्षित इवेंट दर के लिए पर्याप्त हेडरूम के साथ `maltrail_log_dir_free_bytes` पर अलर्ट करें।
- बाहरी टूलिंग का उपयोग करके स्थानीय दैनिक लॉग को रोटेट, आर्काइव या हटाएँ।
- रिपोर्टिंग इंटरफ़ेस के लिए आवश्यक फ़ाइलों को `LOG_DIR` में असंपीड़ित रखें; संपीड़ित फ़ाइलों को कहीं और आर्काइव करें।

जब लॉग फ़ाइलसिस्टम भर जाता है, तो सेंसर इवेंट जोड़ नहीं सकता। इवेंट लॉग में ऐसे IP पते और डोमेन भी हो सकते हैं जिन्हें कुछ न्यायक्षेत्रों में व्यक्तिगत डेटा के रूप में विनियमित किया जाता है; रिटेंशन नीति में लागू आवश्यकताओं को ध्यान में रखा जाना चाहिए।

### सिंथेटिक ट्रैफ़िक

यह जाँचने के लिए कि डिटेक्शन और डैशबोर्ड दोनों अभी भी काम करते हैं, वास्तविक ट्रैफ़िक की प्रतीक्षा किए बिना:```bash
python3 server.py --detect-test                      # assert every detection fires, then exit
python3 server.py --detect-test --keep DIR --serve   # ...and keep the events, serving them on :8338

--keep उसी लॉग में sensor/tests/corpus/ को भी रीप्ले करता है और प्रिंट करता है कि डैशबोर्ड जिन आकृतियों को अलग तरह से रेंडर करता है उनमें से किसके पीछे कोई इवेंट है, ताकि गुम आइकन, रंग या ग्लिफ़ अनुमान लगाने के बजाय दिखाई दे। टाइमस्टैम्प इस तरह शिफ्ट किए जाते हैं कि सबसे नया दिन आज हो। एक सेंसर बाइनरी आवश्यक है (cargo build --release --manifest-path sensor/Cargo.toml)।

सार्वजनिक डेमो का डेटा ऐसे ही एक रन से पुनर्जनित किया जाता है:```bash python3 sensor/tools/gen_demo_js.py --from DIR/logs # tops up html/js/demo.js

## दस्तावेज़ीकरण

| दस्तावेज़ | सामग्री |
| --- | --- |
| [`sensor/docs/INSTALL.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/INSTALL.md) | इंस्टॉलेशन, विशेषाधिकार, कॉन्फ़िगरेशन, और समस्या निवारण |
| [`sensor/docs/ARCHITECTURE.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/ARCHITECTURE.md) | सेंसर के आंतरिक तत्व और डेटा प्रवाह |
| [`sensor/docs/COMPATIBILITY.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/COMPATIBILITY.md) | सेवानिवृत्त Python सेंसर से जानबूझकर किए गए अंतर |
| [`sensor/docs/REPORT.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/REPORT.md) | माप, प्रोफ़ाइल, और परीक्षण परिणाम |
| [`sensor/docs/ROADMAP.md`](https://github.com/stamparm/maltrail/blob/master/sensor/docs/ROADMAP.md) | खुले सेंसर कार्य |
| [`SekuriPy Labs`](https://www.sekuripy.hr/labs/maltrail/) | इंजीनियरिंग नोट्स, बेंचमार्क और लेख |

## योगदान

ट्रेल जोड़, फ़ीड रखरखाव, बग रिपोर्ट, दस्तावेज़ीकरण, और सेंसर सुधार स्वागत योग्य हैं।
ट्रेल सबमिशन में एक विश्वसनीय स्रोत शामिल होना चाहिए और सबसे संकीर्ण उपयुक्त
वर्गीकरण का उपयोग करना चाहिए।

कोड सबमिट करने से पहले प्रासंगिक जाँच चलाएँ। पूरा सेंसर गेट यह है:```bash
bash sensor/tools/check.sh

यह फ़ॉर्मेटिंग, चेतावनियों को अस्वीकृत करने वाले Clippy, और डिबग तथा रिलीज़ टेस्ट सूट चलाता है। Python सर्वर सूट को इसके साथ चलाएँ:```bash bash tests/run.sh python3

Windows बिल्ड को Linux से चलाया जा सकता है, जहीं इसके बग पाए गए हैं:```bash
sh sensor/tools/check_windows.sh

यह सेंसर को mingw-w64 के साथ क्रॉस-कंपाइल करता है, Npcap की userspace लाइब्रेरी को उसके इंस्टॉलर से निकालता है (एक NSIS आर्काइव, इसलिए कुछ भी इंस्टॉल नहीं होता), और परिणाम को Wine के अंतर्गत चलाता है — पूरा यूनिट सूट, शिप किए गए कॉन्फ़िगरेशन के विरुद्ध -T, pcap कॉर्पस की नेटिव बाइनरी के साथ बाइट-दर-बाइट तुलना, और सर्वर Windows Python के अंतर्गत /ping का उत्तर देता है। लाइव कैप्चर एकमात्र ऐसी चीज़ है जिसे यह कवर नहीं कर सकता; उसके लिए Npcap के कर्नेल ड्राइवर और एक वास्तविक Windows मशीन की आवश्यकता होती है। पूर्वापेक्षाएँ हैं gcc-mingw-w64-x86-64, wine, और p7zip-full।

प्रोजेक्ट

लाइसेंस

TL;DR: Maltrail MIT-लाइसेंस प्राप्त है, लेकिन Maltrail Trails डेटासेट की अलग शर्तें हैं। स्वतंत्र IOC लुकअप/संदर्भ ठीक है; किसी व्यावसायिक उत्पाद या सेवा में Trails का एक इंटेलिजेंस स्रोत के रूप में व्यवस्थित उपयोग के लिए अनुमति/लाइसेंसिंग की आवश्यकता होती है।

Maltrail MIT लाइसेंस के अंतर्गत वितरित किया जाता है। देखें LICENSE।

यह इंजन है। स्टैटिक ट्रेल सेट अलग शर्तों के अंतर्गत अलग कार्य है: आंतरिक रक्षात्मक उपयोग, अनुसंधान और शिक्षण के लिए निःशुल्क, लेकिन एक व्यावसायिक उत्पाद, सेवा, MSSP या MDR ऑफ़रिंग, या पुनर्वितरित फ़ीड के लिए लाइसेंस की आवश्यकता होती है। एक MIT इंजन सामग्री को बेचने के लिए मुफ़्त नहीं बनाता — किसी ऐसी चीज़ में शिप करने से पहले जिसके लिए आप शुल्क लेते हैं, stamparm/trails में LICENSE.md देखें।

मेंटेनर

Miroslav Stampar (@stamparm)
Mikhail Kasimov (@MikhailKasimov)

प्रायोजक

Sansec (2024–2025)
Sansec (2020–2021)

प्रस्तुतियाँ और प्रकाशन

47वीं TF-CSIRT बैठक, प्राग, 2016 (स्लाइड्स)
Detect attacks on your network with Maltrail, Linux Magazine, 2022 (लेख)
Best Cyber Threat Intelligence Feeds, Silent Push, 2022 (समीक्षा)
Research on Network Malicious Traffic Detection System Based on Maltrail, Nanotechnology Perceptions, 2024 (पेपर)

तृतीय-पक्ष एकीकरण

FreeBSD Port
OPNsense Gateway Plugin
D4 Project
BlackArch Linux
Validin
Maltrail Add-on for Splunk
Maltrail decoder and rules for Wazuh
GScan (केवल trails)
MalwareWorld (केवल trails)
oisd domain blocklist (केवल trails)
NextDNS (केवल trails)
NoTracking (केवल trails)
OWASP Mobile Audit (केवल trails)
Mobile Security Framework MobSF (केवल trails)
pfBlockerNG-devel (केवल trails)
Sansec eComscan (केवल trails)
Palo Alto Networks Cortex XSOAR (trail कनेक्टर)

आभार

Thomas Kristner
Eduardo Arcusa Les
James Lay
Ladislav Baco (@laciKE)
John Kristoff (@jtkdpu)
Michael Münz (@mimugmail)
David Brush
@Godwottery
Chris Wild (@briskets)
Keith Irwin (@ki9us)
Simon Szustkowski (@simonszu)

maltrail v3.2

श्रेणियाँ