سؤال REJECT vs DROP عند استخدام iptables


هل هناك أي سبب لماذا أريد أن يكون

iptables -A INPUT -j REJECT

بدلا من

iptables -A INPUT -j DROP

81
2017-07-04 09:49


الأصل




الأجوبة:


كقاعدة عامة ، استخدم REJECT عندما تريد أن يعرف الطرف الآخر أن المنفذ غير قابل للوصول "استخدم DROP للوصلات إلى المضيفين الذين لا تريد أن يراها الأشخاص.

عادة ، يجب أن تستخدم جميع قواعد الاتصالات داخل شبكة LAN الخاصة بك REJECT. بالنسبة إلى الإنترنت ، باستثناء الهويات الموجودة على خوادم معينة ، عادةً ما يتم إسقاط الاتصالات من الإنترنت.

باستخدام DROP يجعل الاتصال يبدو وكأنه عنوان IP غير مشغول. قد تختار الماسحات الضوئية عدم متابعة فحص العناوين التي تبدو غير مشغولة. بالنظر إلى أنه يمكن استخدام NAT لإعادة توجيه الاتصال على جدار الحماية ، فإن وجود خدمة معروفة لا يشير بالضرورة إلى وجود خادم على عنوان.

يجب أن يتم تمرير الهوية أو رفضها على أي عنوان يقدم خدمة SMTP. ومع ذلك ، فقد انخفض استخدام عمليات البحث عن الهوية من خلال خدمة SMTP خارج الاستخدام. هناك بروتوكولات الدردشة التي تعتمد أيضا على خدمة معرف العمل.

تعديل: عند استخدام قواعد DROP:  - سيتم إسقاط الحزم UDP وسيكون السلوك هو نفس الاتصال بمنفذ unfirewalled بدون خدمة.  - ستقوم حزم TCP بإرجاع ACK / RST وهو نفس الاستجابة التي يستجيب لها المنفذ المفتوح الذي لا يحتوي على خدمة عليه. سوف تستجيب بعض أجهزة التوجيه مع و ACK / RST نيابة عن الخوادم التي هي أسفل.

عند استخدام قواعد REJECT ، يتم إرسال حزمة ICMP تشير إلى أن المنفذ غير متوفر.


73
2017-07-04 16:40



هذا ليس صحيحا. حتى عندما تقول القاعدة "DROP" سيستمر النظام في الرد على الحزمة الواردة مع TCP SYN / ACK كما لو كان مفتوحًا. لإسقاط حزمة حقًا ، يحتاج النظام إلى الرد باستخدام TCP RST / ACK - الذي لا توجد له قاعدة جدار حماية. على هذا النحو ، فإن أفضل إعداد للجدار الناري هو واحد يتم فيه إعادة توجيه المنافذ المحددة فقط. ستقوم القاعدة DROP بالإعلان عن جدار الحماية الخاص بك وسوف تعرف الماسحات الضوئية في المنفذ أنك تقوم بجدار ناري على شيء ما وتواصل مساعدتك على الإمساك بجدار الحماية الخاص بك. - Dagelf
Dagelf انظر تعديلي. لا يشير RST / ACK إلى الماسحات الضوئية التي تقوم بجدار ناري على أي شيء. في حين قد يستمر بعض المتسللين في التحقيق بعد هذه الاستجابة ، يجب أن يعتمد ذلك على معرفة خدماتك وليس استجابة الجدار الناري. من المؤكد أنه انخفض عدد وطول الأشعة أعيش. - BillThor
نقطتي هي أنه يمكن اكتشافه من الخارج سواء كنت تقوم بجدار ناري لشيء ما أو ليس بسبب حقيقة أن مكدس TCP الخاص بك يتصرف بشكل مختلف عند انخفاض DROP من عندما لا يكون لديك خدمة تعمل في المقام الأول! - Dagelf
لا يغير من حقيقة أن هناك شبكات بوتنات تستفيد من الفرق ومراقبة المنافذ الخاصة بك نتيجة لذلك. - Dagelf
Dagelf أين تحصل على المعلومات التي يرسلها DROP استجابة؟ هذه أخبار كبيرة وتتعارض مع كل ما شاهدته وقيل لي. هل لديك رابط للوثائق التي تصف هذا السلوك؟ - Score_Under


والفرق هو أن هدف REJECT يرسل استجابة رفض إلى المصدر ، بينما لا يرسل هدف DROP أي شيء.

يمكن أن يكون هذا مفيدًا ، على سبيل المثال. لخدمة الهوية. إذا كنت تستخدم REJECT ، فلا يحتاج العملاء إلى انتظار انتهاء الوقت.

المزيد عن هذا: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html


25
2017-07-04 09:59



هدف DROP لا يرسل أي شيء. تحقق من تعليقي على الإجابة المقبولة واذهب للبحث في الموضوع بنفسك إذا كنت مهتمًا بالتفاصيل! - Dagelf


عادة ، تريد تجاهل تحقيقات من المهاجمين إلى منافذ معينة ، والتي يعني أنك لا تريد أن ترسل مرة أخرى "رفض الاتصال". "الاتصال رفض" يعني: "هناك خادم هنا" ، وربما يعطي المزيد من المعلومات ، في حين أن إسقاط حزمة لا يعطي أدلة حول إصدارات البرامج ، أو نقاط الضعف المحتملة أو حتى حقيقة أن الخادم يستمع إليك IP.

ما ورد أعلاه واحد من الأسباب الرئيسية لاستخدام DROP بدلاً من REJECT.


8
2017-07-04 13:09



بدون قواعد iptables ، يكون المنفذ مغلقًا افتراضيًا REJECT. إذا قمت بإسقاط كل منفذ ، فسيكون ذلك بديلاً جيدًا (يظهر المضيف الخاص بك لأسفل) ولكن إذا قمت بإسقاط منافذ معينة فقط فإنك تقوم بالفعل بتقديم معلومات أكثر من REJECT. إذا استخدم شخص ما مجسًا شاملاً مثل nmap ، فستظهر المنافذ المحددة التي تسقط الحزم "مصفاة" ، مما يعني أنها تعرف أن لديك خدمة هناك تخبئها. - Raptor007


أرى الكثير من الإجابات المتضاربة هنا ونظرًا لأن هذه هي المقالة الأولى في Google التي تحتوي على الكلمات الرئيسية المناسبة ؛ هنا هو التفسير الصحيح.
انه سهل:

DROP لا يفعل شيئا على الإطلاق مع الحزمة. لا يتم إعادة توجيهها إلى المضيف ، ولا يتم الرد عليها. تقول صفحة عناوين IPtables أنها تسقط الحزمة على الأرض ، أي أنها لا تفعل أي شيء مع الحزمة.

REJECT يختلف إلى DROP أنه يرسل حزمة مرة أخرى ، ولكن الجواب كما لو كان الخادم يقع على IP ، ولكن ليس لديه منفذ في حالة الاستماع. سترسل IPtables RST / ACK في حالة TCP أو UDP وهو منفذ وجهة ICMP يتعذر الوصول إليه.


6
2018-01-11 12:29



+1 من قبلي ، لكن الإجابات لا تختلف حقًا. يتفقون جميعا ، بقدر ما أستطيع أن أرى ، باستثناء الداغلف - من هو على خطأ. - MadHatter
حسنًا ، إليك حيلة صغيرة بالنسبة لك بعد ذلك: نفذ "nmap localhost". الآن اختيار أي منفذ ليس "فتح" ... وإضافة قاعدة "لا يفعل شيئا" ، على سبيل المثال: "iptables -I INPUT -p tcp --dport 888 -j DROP". الآن "nmap localhost" مرة أخرى. ماذا ترى؟ ... - Dagelf


إذا كنت تحاول إخفاء وجود جهازك بالكامل ، -j DROPانه لائق. على سبيل المثال ، قد تستخدم هذا لتطبيق قائمة سوداء.

إذا كنت تحاول إخفاء حقيقة أن المنفذ مفتوح ، يجب عليك محاكاة السلوك الذي قد يحدث إذا لم يكن المنفذ مفتوحًا:

  • TCP: -p tcp -j REJECT --reject-with tcp-reset
  • UDP: -p udp -j REJECT --reject-with icmp-port-unreachable

إذا رأى ماسح منفذ أن بعض المنافذ تقوم بإسقاط الحزم بينما يقوم معظمها برفضها ، يمكن أن يفترض أن الحزم المسقطة موجودة على منافذ مفتوحة ولكنها مخفية.


3
2017-08-13 01:29



ماذا لو قمت بفتح بعض المنافذ (أي 22 و 25 و 53 و 80 و 443) ثم قمت بإخراج كل شيء آخر؟ الآن ما إذا كان لدي MySQL أو PostgreSQL أو SQLite أو Cassandra قيد التشغيل ... لا يمكن للماسحة أن تخبر ، أليس كذلك؟ - Alexis Wilke
AlexisWilke في هذه الحالة ، المعلومات الإضافية الوحيدة التي تعطيها الماسح الضوئي للمنفذ هي أن لديك نوعًا من جدار الحماية في مكانه مع سياسة DROP الافتراضية. - Raptor007


على الرغم من الكثير من الإجابات الصحيحة ، فقط سنتاتي:

هنا هو PoC قصير FW.IDS-DROP-مقابل-يرفضون لي لهذا الموضوع فيما يتعلق بقواعد نظام الحظر (جدار الحماية ، IDS ، الخ).

قريبا:

  • DROP يمكن استخدامها للدخولاء المتكررين ، إذا تم حظر جميع المنافذ (لذا يبدو أن الخادم منخفض على جانب الدخيل)
  • REJECT --reject-with tcp-reset هو أفضل خيار لحظر متعدد المنافذ ، لأنه يبدو أنه يتصرف كمنفذ مغلق حقيقي
  • إذا كانت بعض المنافذ ترد على ذلك (يعرف المتسلل أن المضيف على قيد الحياة) ، DROP و REJECT (بدون tcp-reset) سيعطي للدخيل "إشارة" أن هناك شيئًا منعزلاً (بحيث يمكن أن يحفزه على مواصلة "الهجوم" على أمل توفير البيانات المطلوبة في مرحلة ما)

0
2017-09-20 16:49





نعم ، باستخدام DROP لا معنى له. استخدم REJECT.

حتى عندما تقول القاعدة "DROP" فإن النظام لا يزال يرد على SYN الوارد مع TCP RST / ACK - وهو السلوك الافتراضي للمنافذ التي لا تعمل بها خدمات. (لا يسجل tcpdump et al هذا.)

في حالة تشغيل خدمة ، يتم استيفاء SYN بواسطة TCP SYN / ACK.

نظرًا لأن DROP لا يستجيب كما هو معتاد مع TCP SYN / ACK ، ولكن مع RST / ACK بدلاً من ذلك ، فإن القاعدة DROP ستعلن عن جدار الحماية الخاص بك وسيعرف الماسح الضوئي للمنافذ أنك تقوم بجدار ناري على شيء ما ، وقد تستمر في توجيهك في الآمال من اصطياد جدار الحماية الخاص بك إلى أسفل.

هذا هو nmap الآن يمكنه الإبلاغ عن "تمت تصفيته" بدلاً من "مغلق" على سبيل المثال:

$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
1111/tcp filtered lmsocialserver

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -D INPUT 1

على هذا النحو ، فإن إعداد جدار الحماية "غير المرئي" الوحيد هو جهاز يجلس فيه جهاز مخصص بين أجهزتك ويعيد توجيه المنافذ بشكل انتقائي فقط.

إذا كنت ترغب بالفعل في الفوضى مع الماسحات الضوئية الأساسية ، يمكنك إجراء اتصالات TCP TARPIT ، والتي تحدد إطار TCP إلى 0 بحيث لا يمكن نقل أي بيانات بعد فتح الاتصال ، مع تجاهل الطلبات لإغلاق الاتصال ، مما يعني أن الماسح الضوئي يجب أن ينتظر لإنهاء مهلة الاتصال ، إذا كانت تريد التأكد. ولكن من الممتع أن يكتشف أحد المهاجمين ذلك ويجعل مهنته قصيرة جدًا.

كل الأشياء التي تم وضعها في الاعتبار ، ربما تكون أفضل من مجرد استخدام REJECT - أو وضع جهاز توجيه منفذ مخصص بين الخادم الخاص بك والإنترنت.

أو مجرد تشغيل الخدمات على الأجهزة التي تواجه الإنترنت والتي لا تتطلب جدار الحماية.

عموما ، REJECT هو الأفضل لخوادم الويب ، لأن أي خدمة تحاول الوصول إليها (غالباً ما تكون في الغالب ، أنت) ستحصل بسرعة على رد ولن يبقى المستخدمون أو الخدمات الأخرى في انتظار التساؤل عما إذا كان هناك انقطاع في الشبكة.


-3



هذه الإجابة غير صحيحة. يمكن أن تظهر بسهولة مع tcpdump أن قاعدة DROP ستؤدي إلى عدم إرسال النظام لأي إجابة - كما هو متوقع. والبيان الخاص بك "لإسقاط حزمة حقا ، يحتاج النظام إلى الرد مع TCP RST / ACK" لا معنى له لأن الرد على أي شيء من الواضح أنه لا "إسقاط حزمة حقا". إذا قمت "بإسقاط" حزمة بالفعل ، فأنت لا تجيب ، وهذا هو التأثير الواضح لقاعدة DROP. - Juliane Holzt
هل يمكن أن تقدم مصدرا للادعاء ذلك DROP سيصدر أ SYN/ACK؟ لم أر هذا على جهازي أبدا. - motobói
Dagelf تقول مقالتك "DROP (ويعرف أيضا باسم DENY، BLACKHOLE) منع حزمة من تمرير. إرسال أي استجابة." - JeanT
لا يرسل الرد العادي ، لكنه يرسل واحدة كما هو موضح ، بغض النظر. - Dagelf
المستند الذي ترتبط به "إسقاط ... لا ترسل استجابة"، ولا ، على قدر استطاعتي ، دعم ادعائك ذلك DROP يعيد SYN/ACK. أنا أيضا ، لم أر هذا السلوك تحت أي إصدار من iptables. إذا كان لديك مصدر يدعم مطالبتك ، فسيكون من المفيد جدًا رؤيته ؛ بالتأكيد ، فإن مقالب الحزمة لقد فعلت للتو لا تدعم مطالبتك. - MadHatter