اذهب إلى المحتوى

عندما تخرج من منزلك، ستقفل الباب خلفك عادةً، وبطبيعة الحال سيتمكن الأشخاص الذين يملكون مفاتيح الباب فقط من الدخول إلى منزلك، إذ أنك تفعل ذلك لأسبابٍ أمنية. بنفس الطريقة قد نريد التحكُّم بماذا ومن يملك إمكانية الوصول لمختلف أجزاء شبكتنا، وإحدى طرق تطبيق ذلك هي باستخدام قوائم التحكم بالوصول Access Control Lists -أو اختصارًا ACLs.

سنتعمّق في هذا المقال في تطبيق تلك القوائم للتحكم بالوصول للشبكة، إذ سنتناول بنية ACL وكيفية تنفيذها وإمكانية إعداد وتطبيق تلك القوائم؛ كما سنتناول دراسة حالة عمليًا، إذ سنُعِّد قوائم ACL على جهاز بنظام التشغيل الشبكي سيسكو، بحيث يمكنك تطبيق المعرفة المكتسبة من دراسة هذه الحالة على مختلف أجهزة الشركات.

اقتباس

ملاحظة: لا تكون قوائم ACL مفيدةً فقط لتحديد إمكانية الوصول، بل يمكن تطبيقها أيضًا على عدّة نواحٍ أخرى، مثل إعدادات ترجمة عنوان الشبكة Network Address Translation -أو اختصارًا NAT-، ومطابقة الوجهات الممكن قبولها أو التسويق لها ضمن بروتوكولات التوجيه الديناميكي والتوجيه المبني على السياسات وغيرها؛ كما أنها أيضًا ليست حكرًا على الشبكات، بل تُستخدم كذلك ضمن أنظمةٍ أخرى مثل أنظمة الملفات للتحكم بالوصول إلى الملفات والكائنات.

قوائم التحكم بالوصول

ما هي قائمة التحكم بالوصول؟

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

اقتباس

ملاحظة: يمكن استخدام قوائم ACL للتحقق من العديد من الحقول ضمن الرزمة، ومنها حقول في الطبقة الثانية مثل عناوين MAC، والطبقة الثالثة مثل عناوين IPv4، والطبقة الرابعة مثل رقم منفذ TCP، وغيرها. سيقتصر الشرح في هذا المقال على الطبقة الثالثة وما فوق. تُعد معظم قوائم ACL أيضًا عديمة الحالة "stateless"، وهذا يعني أن كل رزمة متدفقة ستُدقّق على حدى على عكس التصفية المعتمدة على الحالة التي تأخذ حالة الاتصال بالحسبان.

هيكلية قوائم ACL

كما ذكرنا مسبقًا ACL هي قائمة، وهذا يعني أنها قائمةٌ تحوي أشياء. نصطلح تقنيًا بأن ACL هي قائمةٌ بمدخلات التحكم بالوصول Access Control Entries -أو اختصارًا ACEs، إذ يحتوي كل مدخل على شرطٍ يطابق رزمةً معينة.

بناءً على هذا الوصف، يمكن تقسيم ACL إلى جزئين أساسيين:

  • معرّف ACL الذي يكون عادةً اسمًا أو رقمًا، وكما سنرى لاحقًا يمكن تعريف قوائم ACL من خلال نوعها.
  • عددٌ من مدخلات التحكُّم بالوصول تُعرَّف عادةً بواسطة سلسلةٍ من الأرقام.

access-control-entry.png

مدخلات التحكم بالوصول ACEs

تشكل ACEs القسم الأكبر من ACL، إذ تحتوي كل قائمة تحكم ACL على واحدٍ أو أكثر من تلك المدخلات التي يسمح بها جهازٌ معين، وبغض النظر عن النوع المحدد لقائمة ACL، يمكننا تحديد مكونات ACE على النحو التالي:

  • معرّف: والذي يكون عادةً رقم السطر، فمثلًا سيمتلك أول ACE ضمن قائمة ACL مُعدَّةٍ على موجّه يعمل بنظام سيسكو رقم السطر 10 افتراضيًا، وسيمتلك ACE التالي رقم السطر 20، وهكذا.
  • حدث: والذي سيُنفَّذ على الرزم التي تتطابق مع المدخل، وتكون عادةً قيمة الحدث، إما الرفض "deny"، أو السماح "permit".
  • يجب في بعض الحالات مطابقة البروتوكول و معلومات المنفذ في رزمة، إذ يمكن مثلًا أن يتطابق مدخل ACE مع كل حركة مرور من نوع IP، بينما يمكن لمدخلٍ آخر أن يتطابق مع حركة مرور من نوع HTTP فقط.
  • المصدر الواجب مطابقته، ويكون عادةً عنوان IP لمصدر الرزمة، الذي يمكن أن يكون عنوانًا مفردًا، أو مجالًا من العناوين، أو مجال شبكة فرعي، ومن الممكن أن يطابق أي عنوان.
  • الوجهة الواجب مطابقتها، وتكون عادةً عنوان IP لوجهة الرزمة، الذي يمكن أن يكون عنوانًا مفردًا، أو مجالًا من العناوين، أو مجال شبكة فرعي، ومن الممكن أن يطابق أي عنوان.

يجب الأخذ بالحسبان اعتماد مكوني المصدر والوجهة على جهة الرزمة المرسلة. ألقٍ نظرةً على المخطط البياني التالي:

lab-setup.png

يمكننا ملاحظة سيناريوهين مختلفين من منظور الموجّه R1:

  1. إذا كان PC1 هو من أنشأ الاتصال إلى PC2 (مثلًا طلب ping من PC1 إلى PC2)، فسيكون مصدر حركة المرور هو العنوان 192.168.1.100 وعنوان الوجهة هو 192.168.2.200.
  2. إذا كان PC2 هو من أنشأ الاتصال إلى PC1 (مثلًا طلب ping من PC2 إلى PC2)، فسيكون مصدر حركة المرور هو العنوان 192.168.2.200 وعنوان الوجهة هو 192.168.1.100.

معالجة ACL

عندما نتحقق من رزمة ما مع قائمة ACL، تُطبَّق قواعد المعالجة التالية:

  • التحقق من مدخلات ACEs ضمن ACL بالترتيب من الأعلى إلى الأسفل، مما يعني أن التحقق من مدخل ACE رقم 10 سيحدث قبل مدخل ACE رقم 20.
  • إذا لم تتطابق الرزمة مع المدخل ACE، يحدث التحقق منها مع المدخل التالي ضمن قائمة ACL.
  • إذا طابقت الرزمة مدخل ACE، يُوقف التحقق مع كامل قائمة ACL، ويُطبَّق الحدث المحدد ضمن هذا المدخل على الرزمة.
  • إذا لم تطابق الرزمة أيًا من المدخلات ضمن قائمة ACL، فسترمي أو ترفض معظم تضمينات قوائم ACL الرزمة بسبب وجود مدخل رفض ضمني في نهاية كل قائمة ACL.

لنأخذ المثال التالي لفهم قواعد المعالجة تلك، فلنتخيل أن لدينا قائمة ACL فيها المدخلات التالية:

- Seq #1: Permit ICMP from 192.168.1.100 to 192.168.2.200
- Seq #2: Deny ICMP from any source to any destination
- Seq #3: Permit HTTP traffic from 192.168.1.100 to any destination
- Seq #4: Permit HTTPS traffic from 192.168.1.0/24 to any destination
  • السؤال الأول: ماذا سيحدث لرزمة ping متوجهة من 192.168.1.100 إلى 192.168.2.200؟
    • الجواب الأول: بما أن طلب ping مبنيٌ على بروتوكول ICMP سيُسمح للرزمة المتوجهة من 192.168.1.100 إلى 192.168.2.200 لأنها تطابق مدخل ACE رقم 1.
  • السؤال الثاني: ماذا سيحدث لرزمة ping متوجهة من 192.168.1.50 إلى 192.168.2.200؟
    • الجواب الثاني: سيجري التحقُّق من الرزمة مع قائمة ACL بدءًا من المدخل رقم 1، وبما أنها لا تطابق هذا المدخل، سيجري التحقُّق مع المدخل التالي (المدخل رقم 2). يرفض هذا المُدخل الثاني رسائل ICMP من أي مصدرٍ لأي وجهة، وبما أن الرزمة الحالية هي طلب ping (أي ICMP) والمصدر يطابق "any" والوجهة أيضًا تطابق "any"، لذلك ستُرفض الرزمة.
  • السؤال الثالث: ماذا سيحدث لرزمة HTTPS متوجهةٍ من 192.168.1.50 إلى 41.1.1.1؟
    • الجواب الثالث: لن تطابق تلك الرزمة أول ثلاثة مُدخلات، لكنها ستطابق المُدخل الرابع لأنها رزمة HTTPS عنوان المصدر لها ضمن مجال العناوين الفرعي 192.168.1.0/24، والوجهة تطابق "any"، لذلك سيُسمح لتلك الرزمة.
  • السؤال الرابع: ماذا سيحدث لرزمة HTTP متوجهة من 192.168.1.50 إلى 41.1.1.1؟
    • الجواب الرابع: لن تطابق تلك الرزمة أي مدخلٍ من المدخلات الأربعة ضمن قائمة ACL (فقط العنوان 192.168.1.100 مسموحٌ له بإرسال طلبات HTTP)؛ لذلك ستُرفض تلك الرزمة على افتراض تطبيق قاعدة "الرفض الضمني" على هذه القائمة.

تطبيق قوائم ACL

إعداد قوائم ACL دون تطبيقها لا قيمة له، فكما لو أنك ركَّبت قفلًا لباب منزلك ولم تقفله عند ذهابك؛ فعند استخدام قوائم ACL للتحكم أو تصفية الوصول للشبكة، تُطبَّق تلك القوائم على واجهات الجهاز، مثل الموجّهات والمبدلات متعددة الطبقات وجدران الحماية وغيرها، ويمكن عمومًا تطبيق ACL باتجاهين على الواجهة:

  • جهة الورود: تنطبق على الرزم القادمة إلى الواجهة.
  • جهة الخروج: تنطبق على الرزم الخارجة من الواجهة.

acl-structure.png

قد يكون من الصعب فهم كيفية تحديد الجهة التي تطبِّق عليها قوائم ACL، لذا سنأخذ المثال الموضّح في الصورة التالية، إذ يتصل PC1 مع الواجهة Fa0/0 الخاصة بالموجّه R1، ويتصل PC2 مع الواجهة Fa0/1 الخاصة بالموجّه R1.

lab-setup.png

لنفرض أننا نريد تطبيق قائمة ACL على R1، بحيث يُسمح فقط لحركة مرور البيانات لطلبات ping من نوع ICMP من PC1 إلى PC2، أين يجب تطبيق تلك القائمة؟

  • أولاً يمكننا تطبيق القائمة ACL على الواجهة Fa0/0 في اتجاه الورود، وذلك لأن حركة مرور طلبات ping من PC1 إلى PC2 تأتي إلى R1 من الواجهة Fa0/0 الخاصة به.
  • يمكننا أيضًا تطبيق القائمة ACL على الواجهة Fa0/1 في اتجاه الخروج، وذلك لأن حركة مرور طلبات ping من PC1 إلى PC2 تخرج من R1 عبر الواجهة Fa0/1 الخاصة به.

هناك طريقةٌ تفيد في فهم اتجاه تطبيق قوائم ACL، وهي أن تتخيل نفسك بدل الموجّه مد ذراعيك جانبًا وتخيل أن حركة مرور البيانات تأتي من أصابعك إلى جسمك وهي اتجاه الورود، بينما حركة مرور البيانات من جسمك إلى أصابعك هي اتجاه الخروج.

دراسة حالة: قوائم ACL على أجهزة بنظام سيسكو

هناك نوعان من قوائم ACL على الأقل على الأجهزة العاملة بنظام سيسكو:

  • قوائم ACL عادية والتي تُطابق مع عنوان المصدر فقط.
  • قوائم ACL مُوسّعة والتي يمكن مطابقتها مع تركيبةٍ من البروتوكولات وعناوين المصدر والوجهة ومنافذ المصدر والوجهة والخيارات وغيرها.

ملاحظة: تمتلك سيسكو أنواعًا أخرى من قوائم ACL، مثل القوائم المبنية على الوقت والقوائم الانعكاسية والديناميكية وغيرها، ولن نناقش تلك الأنواع في هذا المقال.

يمكن تسمية قوائم ACL على الأجهزة العاملة بنظام سيسكو بغض النظر عن نوعها (مثلًا "TEST_ACL")، أو ترقيمها (مثلًا 100)، كما يجب الانتباه عند ترقيم قوائم ACL، إذ أن هناك مجالات أرقام لقوائم ACL العادية والمُوسّعة.

نستخدم عند تعيين عناوين المصدر والوجهة على ACL ضمن ضبط نظام تشغيل سيسكو ما يدعى بالقناع أو يسمى أيضًا القناع المعكوس أو قناع محارف التبديل Wildcard؛ وهو قناع الشبكة الفرعية نفسه لكنه مقلوب، أي تصبح الواحدات "1" أصفارًا "0" وبالعكس، فمثلًا قناع محارف التبديل لقناع الشبكة الفرعية 255.255.255.0 هو 0.0.0.255.

submet-mask.png

ضمن قناع محارف التبديل: الصفر "0" يعني "يجب أن يطابق must match"، بينما الواحد "1" يعني "لا تهتم don’t care"؛ فعلى سبيل المثال، ستطابق الشبكة 10.1.1.0 مع قناع محارف التبديل 0.0.0.3 حركة مرور البيانات من مجال عناوين IP من 10.1.1.1 حتى 10.1.1.3.

wildcard-mask.png

اقتباس

ملاحظة: سيطابق أيضًا 10.1.1.0، ولكن بما أنه عنوان شبكة فهو لا يُعد عنوان مصدرٍ صحيحٍ للرزمة.

سنستخدم الشبكة التالية لتطبيق دراسة الحالة:

lab-setup2.png

يمكنك بناء تلك الشبكة باستخدام برامج، مثل GNS3 أو Packe Tracer. أُعِدت عناوين IP على كل الواجهات ونُفّذ بروتوكول EIGRP على الشبكة ليصبح هناك تواصلٌ بين كافة الأجهزة:

الموجّه R1:

show-ip-interface.png

الموجّه R2:

r2-show-ip.png

الموجّه R3:

r3-show-int.png

لاختبار الاتصال: سنرسل طلب ping إلى R3 من واجهات loopback إلى R2:

r2-ping.png

إنشاء قوائم ACL على نظام تشغيل سيسكو

لنُعدّ الآن قائمة ACL على R1، بحيث تحقق الشروط التالية:

  • السماح لكل حركة مرور للبيانات من نوع ICMP من 192.168.10.0/24 إلى أي وجهة.
  • ينبغي رفض كل حركة مرور البيانات الأخرى من النوع ICMP.
  • ينبغي السماح لكل حركة مرور البيانات في مجال عناوين IP من 192.168.20.0/24 إلى192.168.30.0/24.
  • ينبغي أن تستطيع الأجهزة على الشبكة 192.168.10.0/24 الاتصال مع المضيف 192.168.30.1 باستخدام SSH، وينبغي منع اتصالات Telnet.
  • ينبغي رفض كل حركة مرور البيانات الأخرى.

لإعداد قائمة ACL على جهاز بنظام تشغيل سيسكو نتبع الخطوات التالية:

  • تُعرَّف قائمة ACL بواسطة اسم أو رقم، وتكون القوائم المُعرّفة باسم أسهل في الإعداد. وتكون صيغة أمر إعداد قائمة ACL المُعرفة باسم على النحو التالي:
ip access-list [extended|standard] <ACL name>
  • إعداد مدخلات ACE ضمن ACL باستخدام الصيغة التالية:
[permit|deny] <protocol> <source network> <source wildcard mask> <destination network> <destination wildcard mask> <options>
  • ندخل إلى الواجهة المطلوب إعدادها ونطبق قائمة ACL باستخدام الأمر التالي:
ip access-group <ACL name> [in|out]

فيكون الضبط اللازم لتحقيق ذلك على R1 على النحو التالي:

ip access-list extended EXAMPLE_ACL

permit icmp 192.168.10.0 0.0.0.255 any

deny   icmp any any

permit ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255

permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.1 eq 22

!

interface FastEthernet0/0

ip access-group EXAMPLE_ACL in

!

acl-config.png

لا بُدّ من ملاحظة الأمور التالية في الضبط السابق:

  • أُعدّت قائمة ACL بالاسم "EXAMPLE_ACL"، وهذه القائمة من النوع الموسع لأننا سنحتاج لمطابقة عدة حقول.
  • يمكن استخدام الكلمة المفتاحية "any" لمطابقة أي عنوان.
  • يمكن استخدام الكلمة المفتاحية "host" لمطابقة عنوانٍ معين.
  • يمكننا تحديد المنفذ الذي سيجري مطابقته باستخدام الكلمات المفتاحية، مثل "eq" والتي تعني يساوي، و "gt" والتي تعني أكبر من وغيرها.
  • لم نرفض صراحةً كل حركة مرور البيانات الباقية، إذ سترفض قاعدة "الرفض الضمني" في نهاية كل قائمة ACL في سيسكو أي حركة مرور بيانات لم تتطابق مع تلك القائمة.
  • طبقنا قائمة ACL على جهة الورود للواجهة Fa0/0، ويمكننا أيضًا تطبيقها على جهة الخروج للواجهة Fa0/1.

التحقق من قوائم ACL

يمكننا رؤية ضبط وإحصائيات ACL باستخدام الأمر التالي:

show ip access-lists or show access-lists

show-ip-access-list.png

لاحظ طريقة الترقيم، إذ تبدأ بالرقم 10 ويُضاف كل مدخلٍ جديد أسفل المدخل السابق. يمكننا استخدام الأمر show ip interface لعرض قوائم ACL المطبقة على الواجهة:

inbond-acp-example.png

اقتباس

ملاحظة: يمكن تطبيق قائمتي ACL بالحد الأقصى على الواجهة، واحدةٌ لكل جهة.

تعديل قوائم ACL

تطبيق تلك القائمة أحدث لنا مشكلةً بين R1 و R2:

eigrp.png

أُنهيت علاقة بروتوكول EIGRP لأن قاعدة "الرفض الضمني" تمنع رزم EIGRP في نهاية قائمة ACL، لذا يمكن حل تلك المشكلة عبر التصريح عن السماح لرزم EIGRP ضمن قائمتنا.

تحذير: يجب الحذر عند تعديل قائمة ACL لأن مدخلات ACE ستضاف لأسفل القائمة (قبل قاعدة الرفض الضمني)، لكن يمكننا باستخدام قوائم ACL المعرّفة بأسماء تحديد رقم سطر إضافة المدخل الجديد.

لا يهم في حالتنا هذه مكان إضافة المدخل للسماح بحركة مرور البيانات EIGRP لعدم وجود أي مدخلٍ آخر يؤثر عليها قبل قاعدة الرفض الضمني، مع ذلك سنضيف المدخل "permit eigrp any any" على السطر رقم 5 ضمن القائمة فقط لنرى كيف يمكن إضافة المدخل ضمن أي سطر:

ip-access-list-extended.png

بعد ذلك تكون قد أُعيدت علاقة EIGRP.

اختبار قوائم ACL

يمكننا الآن البدء باختبار قائمة ACL السابقة، ولذلك تذكر أنه لا بُدّ من اختبار ما يجب أن يعمل وما لا يعمل أيضًا.

الاختبار 1: ينبغي السماح لطلب ping من 192.168.10.1 إلى 192.168.30.1 بسبب المدخل في السطر رقم 10 ضمن ACL.

r2-ping-success.png

يمكننا التحقق من العدادات ضمن ACL لنتأكد أن حركة مرور البيانات تلك تطابقت مع قائمة ACL:

show-ip-access-list.png

الاختبار 2: ينبغي أن يفشل طلب ping من 192.168.20.1 إلى 192.168.30.1 بسبب المدخل في السطر رقم 20 ضمن ACL.

r2-ping.png

الاختبار 3: ينبغي السماح لطلب Telnet و SSH من 192.168.20.1 إلى 192.168.30.1 بسبب المدخل في السطر رقم 30 ضمن ACL.

user-access-validation.png

ssh-source1.png

الاختبار 4: ينبغي السماح لطلب SSH من 192.168.10.1 إلى 192.168.30.1 بسبب المدخل في السطر رقم 40 ضمن ACL.

ssh-source.png

الاختبار 5: يبنغي أن يفشل طلب Telnet من 192.168.10.1 إلى 192.168.30.1 بسبب قاعدة الرفض الضمني.

telnet-acl.png

يمكننا التحقق من الإحصائيات على ACL للتأكد أن حركة مرور البيانات قد وصلت بالفعل إلى ACL:

show-ip-access-list.png

ملاحظات مفيدة حول قوائم ACL

تفيدك الملاحظات التالية خلال تضمين قائمة ACL:

  • بما أن المطابقة مع ACL ستتوقف عند أول مدخل يتطابق، فحاول وضع أكثر المدخلات تحديدًا في أعلى قائمة ACL وأكثر المدخلات عموميةً في الأسفل.

فمثلًا إذا وضعنا المدخل التالي:

deny icmp any any

قبل المدخل:

permit icmp host 1.1.1.1 any

ستُرفض حركة مرور البيانات من نوع ICMP من المضيف 1.1.1.1.

  • يجري البحث ضمن قوائم ACL من الأعلى للأسفل، لذلك ينبغي وضع قواعد حركة مرور البيانات ذات فرصة المطابقة الأعلى في أعلى قائمة ACL، إذ سيقلل ذلك من وقت البحث وبالتالي استهلاك الموارد.
  • يمكنك استخدام التعليقات لزيادة قابلية قراءة قوائم ACL، أي حتى تتمكن من فهم ماذا يفعل أحد المدخلات ولماذا أُضيف.
  • حاول تطبيق قوائم ACL بأقرب ما يمكن إلى مصدر حركة مرور البيانات، فلا فائدة من عبور حركة مرور البيانات خلال الشبكة لتُرفض في النهاية، وقد لا تتمكن من تطبيق تلك الملاحظة على قوائم ACL العادية.
  • يمكنك تطبيق قوائم ACL في جهة الورود بدلًا من جهة الخروج، ويُفضَّل ذلك إذ ستُعالج الرزم في الحالة الأولى، مثل البحث ضمن جدول التوجيه قبل التحقُّق منها على قائمة ACL في جهة الخروج، فلا داعي لهدر موارد المعالجة إذا كانت ستُرفض حركة مرور البيانات لاحقًا عدا عن بعض الحالات التي يكون ذلك فيها ضروريًا.

في الختام

شرحنا ضمن هذا المقال قوائم التحكم بالوصول بالتفصيل وركزنا على كيفية استخدامها لتصفية الرزم ضمن الشبكة، ورأينا أيضًا كيف أن قوائم ACL مؤلفة من مدخلات التحكم بالوصول ACEs والتي بدورها تسمح أو تمنع حركة مرور البيانات بناءً على شرطٍ معين.

ناقشنا كيفية معالجة القواعد ضمن قوائم ACL، حيث تحدث من الأعلى للأسفل وتتوقف عند أول تطابق. كما شرحنا كيف يمكن لقوائم ACL أن تُطبَّق على الواجهات إما بجهة الورود أو جهة الخروج. وأخيرًا، درسنا حالة تضمين قوائم ACL على أجهزة بنظام سيسكو وناقشنا بعض الملاحظات المفيدة.

ترجمة -وبتصرف- للمقال "Access Control Lists – Your Guide to Securing Networks with ACL [ Tutorial & Commands ]" لصاحبه Marc Wilson.

اقرأ أيضًا


تفاعل الأعضاء

أفضل التعليقات

لا توجد أية تعليقات بعد



انضم إلى النقاش

يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.

زائر
أضف تعليق

×   لقد أضفت محتوى بخط أو تنسيق مختلف.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   جرى استعادة المحتوى السابق..   امسح المحرر

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • أضف...