آشنایی با IPTABLES قسمت دوم(1238 مجموع کلمات موجود در متن) (8296 بار مطالعه شده است) آشنایی
با iptables
بخش
دوم
مقدمه State
machine یا
ماشین وضعیت بخش مخصوصی از iptables
است.
در
حـقیـقـت نــام اصـلی ایـن بـخش connection
tracking machine است.
Connection tracking به
Netfilter
ramework اجـازه
مـیدهـد تـا وضعیت یــک
اتصال خاص را تشخیص دهد.
Firewallهایی
کــه connection
tracking را
انجام مـیدهند، با نام
stateful
firewals معروف
هستند.
این
نوع firewall
ها
معمولا نسبت به firewall
های
not-stateful
امنیت
بیـشـتری را ارایه میدهند.
زیرا
به ما اجازه میدهند تا
ممجموعـه قـوانـیـن (rule-set)
هـای
مـحـکم تـری را تـعـریف کنیم و انعطاف
پذیری بالاتری نیز دارند.
بسته
ها در داخل iptables
مـیتـوانـنـد
بـه چهار نوع متفاوت از اتصالات پیگیری
شده به نام NEW,
ESTABLISHED, RELATED و
INVALID
وابسته
باشند کـه تمامی ایـن مـوارد
را بـه تـفـصیل بـرایتان تشریح خـواهیم
کرد.
با
استفاده از یک match
به
نام --state
میتوانـیم
تعیین کـنـیم که یک اتصال چگونه جلسه
(session)
جدید
را آغاز کند.
در
مــورد match
ها
در قـسمتهای بعد به
تفصیل توضیح خواهیم داد.
عمل
connection
tracking تــوســط
چـارچوبی در کـرنـل به نـام conntrack
انـجـام
میشود.
Conntrack میتواند
هم به عـنـوان یـک module
و
هم بـه عـنوان یک بخش داخلی کامپایل شده
در کـرنـل اجرا شود.
Connection tracking تماما
در زنجیره ی PREROUTING
اسـتـعمال
مـیشود، بـه جـز بـخشی
که مربوط به بستههای
تـولید شده ی local
است
که در زنجیره ی OUTPUT،
connection
tracking را
به کار میبرند.
این
جملات به این معناست که اگر در یک جـریـان
از اتصال مــا یــک
initial
packet ارسال
کنیم، اتصال در زنجیره OUTPUT
به
حالت NEW
میرود،
و هرگاه یک بـــســتــهی
return
دریافت
کنیم، اتصال در زنـجـیـره ی PREROUTING
بــه
حــالت ESTABLISHED
تغییر
حالت میدهد و غیره.
بنابراین
کلیه تغییر حالت ها در زنجیره های OUTPUT
و
PREROUTING
انجام
میشود.
ورودی
هایconntrack
اکـنـون
اجـازه دهـید نـگـاهـی مختصر به یکی از
ورودیهای conntrack
و
اینکه چگونه آنها را از proc/net/ip_conntrack/
بـخـوانـیـم،
بیندازیم.
اگـر
moduleی
به نام ip_conntrack
را
بارگذاری کــرده بـاشـیـد، بـا اجـرای
فـرمـان زیر خروجیهای
مربوطه نمایش داده میشود:
# cat /proc/net/ip_conntrack tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \ dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \ dport=32775 use=2
این
مثال تمام اطلاعاتی را که module
مربوط
بــه conntrack
بــرای
دانـسـتن ایـنـکه یـک اتصال مخصوص در چه
وضعیتی است، را در خود نگه میدارد،
شامل میشود.
ابتدا
پروتکل مربوطه که در اینجا tcp
است
نشان داده شده است، سپس مقدار
مشابه عددی آن در مبنای ۱۰(عدد
۶برای TCP)،
سپس زمان حیات این اتصال،
سپس حالت واقعی اتصال.
در
مثال ما بستهی مورد نظر
در وضعیت SYN_SENT
بــوده
است، سـپس آدرس IP
مبدا
و مقصد و شماره پورت مبدا و مقصد.
بعد
از آن یک کلمهی کلیدی
را میبینید کـه بـیـانگر
این است که ترافـیک بـازگشتـی از ایـن
اتـصال دیـده نـشـده اسـت (هیچ
پاسخی دریافت نشده است.)
در
نـهـایت یـک سـری اطلاعاتـی را کـه مـا
از بسته های بازگشتی انتظار داریـم مشاهده
میکنید.
هـمانـطور
کـه مـیبینـید آدرس IP
مـبـدا
و مقصد جایشان عوض شده است و این انتظاری
است که ما از بسته های بازگشتی داریم،
زیرا مبدا و مقصد جایشان عوض شده است.
ورودی
های پیگیری اتصال ممکن است یک سری مقادیر
مختلف را نیز به همراه داشته باشند که
تماما در سرآیندهای conntrack
در
فایلهای linux/include/netfilter-ipv4/ip_conntrack*.h/
در
دسـترس هستند.این
مقادیر به اینکه ما از چه زیر پروتکل هایی
از IP
استفاده مـیکنیم،
وابسته هستند.
پروتکل
های TCP،
UDP
یا
ICMP
مقادیر
پیش فرض خاصی را که در
linux/include/netfilter-ipv4/ip_conntrack.h
هستند
را نگه میدارند.
وضعیت
های User-Land
همانطور
که دیدید، بسته به نوع پروتکل مورد استفاده،
بسته ها در وضعیت های خاص خود قرار
میگیرند.
در
صورتیکه در خارج از کرنل تنها چهار حالت
خاص در نظر گرفته میشود.
حالات
معتبر عبارتند از NEW,
ESTABLISHED, RELATED و
INVALID.
جدول
۱ بطور خلاصه این حالات را توصیف میکند.
این
حالات به همراه --state
برای
تطابق بسته هایی که بر پایه حالت اتصالشان
پیگیری میشوند، استفاده
میشوند.
بدین
ترتیب دیگر لازم نیست که تمام پورت های
بالای 1024
را
برای اینکه اجازه دهیم تمام ترافیک به
شبکه ی کحلی ما برگردد، باز کنیم.
اتصالات
TCP
پـیـشتر
در مــورد سـه مـرحلهی
ایـجـاد اتـصـال TCPصحبت
کردیم.
اکنون
مسئله این است که عمل پیگردی اتصال به چه
صورت به آن نگاه میکند.
اساسا
پیگردی اتصال برای تـمـام اتـصـالات بـه
یک صورت مشابه انجام میشود.
اگر
به شکل زیر دقت کنید، میبینید
که جـریــان بیـن دو
مـاشـیـن در هـر مرحله در چه وضعیتی قرار
میگیرد.
همانطور
که میبینید، کد مربوط
به پیگردی اتصال، اتــصــال TCP
را
دقیقا از نقطه نــظر یـک کاربر دنبال
نمیکند.
ابتدا
با دیدن یک بسته ی SYN
اتصال
را به عنوان یک اتصال NEW
در
نــظـــر مــیگیرد
و ســپــس هنگامی کـه بستهی
SYN/ACK
ارسال
میشود، آن را به
ESTABLISHED
در
نظر میگیرد.
با
این کار به بــســتههــای
NEW
و
ESTABLISHED
اجــازه
مـیدهید تـا شـبـکه را
ترک کنند و تـنـها بستههای
ESTABLISHED
به
شـبـکـه بـازگـردنـد.
بـالـعکس،
اگـر مـا برقراری اتصال کامل را به عنوان
NEW
در
نظر بگیریم، هرگز قادر نخواهیم بود تا
اتصالات خارجی به شبکه ی داخلی را متوقف
کنیم، زیرا باید به بسته های NEW
اجازه
دهیم تا به شبکه برگردند.
حالت
|
توضیح
|
NEW
|
این
حالت بــه مــا مــیگوید
کــه ایــن بسته اولین بسته ای است که
ما میبینیم.
بدین
معنی که اولین بسته ای که conntrck
از
یــک اتـصال مشاهده کند، با این حالت
مطابق میشود.
در
اینجا معمولا اولین بسته ی SYN
مـطـابقـت
داده میشود.
اما
بعضی مواقع این بسته یک بستهی
SYN
نیست
و ممکن است مشکلاتی را بـه همراه داشته
باشد، ولی برای برچیدن اتصالاتی که به
وسیله ی firewall
ها
مفقود شـدهاند
یـا اتصالاتی که زمانشان تمام شده است
ولی به درستی بسته نشدهاند،
مفید میباشد.
|
ESTABLISHED
|
ایـن
وضعیت زمانی دیده میشود
که انتقال بستهها
در دو مـسیر صورت میگیرد
و تمام بستهها
را بـه طــور ادامـهدار
تـطابق مـیدهـد.
این
نوع اتصالات از لحاظ پی بردن به آنها
راحت تر هستند.
تـنها
کاری که لازم است انجام شود این است که
یک میزبان بستهای
را ارسال کند و مـیزبان دیگر به آن پاسخ
دهد.
پیام
های خطای ICMP
و
بسته های تغییر مسیر داده شده نیز
میتوانند
از نوع ESTABLISHED
در
نظر گرفته شوند.
|
RELATED
|
این
وضعیت یکی از وضعیتهای
نـیـرنـگ آمـیـز مـحـسوب میشود.
یک
اتصال RELATED
مـحـسوب
میشود،
هـرگـاه این اتـصال مربوط به یک اتصال
ESTABLISHED
باشد.
برای
ایجاد یـک اتـصـال RELATED
ابتدا
باید یک اتصال ESTABLISHED
ایجاد
شود ، سپس این اتـــصال یـک اتصال
RELATED
تولید
کند.
چیزی
مشابه parent-chield
در
پروسهها.
البته
conntrack
بـایـد
این اتصال را از نوع RELATED
بشناسد.
بعضی
از بهترین مثالها
از این نوع اتصال، اتــصــالات FTP-data
مـیباشد
که به عنوان RELATED
به
پورت کنترل FTP
و
اتـصـالات DCC
کـه
از طــریــق IRC
انتشار
مییابند،
میباشند.
البته
بیشتر پروتکلهای
TCP
یا
UDP
که
بـر این مکانیزم تکیه دارند
کمی پیچیدهتر
هستند و اطلــاعــات مـربوط به اتصال
را داخل بار مفید سگمنتهای
دادهی
TCP
یا
UDP
ارســال
مـیکنند
و از این رو به module
های
کمکی مخصوصی نیاز دارند تا بتوانند به
درستی درک شوند.
|
INVALID
|
این
حالتی است که بسته شناسایی نمیشود
یا اینکه هیچ حالت خاصی را دربرنمیگیرد.
این
حالت برای اهداف خاصی مثل مواقعی که
سیستم خارج از حافظه در حال اجراست یا
پیغام هـای خـطای ICMP
کـه
بـه هیچ اتصال خاصی پاسخ نداده اند، در
نظر گرفته شده است.
به
طور عمومی بهتر است
اینگونه بسته ها را DROP
کرد.
|
جدول
۱:
حالتهای
بستهها
شکل
۱:حالات
اتصال TCPاز
دید firewall
همانطور
که دیدید، از نگاه کاربر خیلی ساده به نظر
میآید.
در
صورتیکه ساختمان کــامـــل آن از دید
کرنل کمی پیچیدهتر
است.
اجازه
دهید با یک مثال جلو برویم.
ملاحظه
کنید که حالات اتصال چگونه در جــدول
proc/net/ip_conntrack/
تغییر
میکند.حالت
اول به محض دریافت اولین بستهی
SYN
در
یک اتصال گزارش داده میشود:
tcp
6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
dport=1031 use=1
هــمانطور
کــه از ورودی بـالا مـیبیـنـید،
یـک بسته ی SYN
ارسال
شده است (SYN_SENT
flag) و
هیچ پاسخی ارسال نشده است([UNREPLIED]).
حالت
دیگر را هنگامیکه
بسته ی دیگری را در جهت دیگر میبینیم،
به دست میآید.
tcp
6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
use=1
اکنون
بسته ای متناظر با SYN/ACK
را
در بازگشت گرفتهایم.
بـه
محض رسیدن این بسته، وضعیت مجدد تغییر
کرده و این بار SYN_RECV.
SYN_SENT به
ما میگوید
که بستهی
SYN
به
درستی پاسخ داده شده است و بسته ی SYN/ACK
نیز
بطور صحیح از طریق firewall
پذیرفته
شده است.
بعلاوه
این ورودی پـیـگـردی اتصال ترافیک را در
دو جهت دیده است و از این رو دیگر پرچم
[UNREPLIED]
دیده
نمیشود.
مرحله
ی پایانی زمانی است که بسته ی پایانی ACK
دیده
میشود.
tcp
6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
sport=23 dport=1031 use=1
در
آخرین مثال، آخرین مرحله یعنی بسته ی ACK
دریافت
شده است و اتـصال یه حالت ESTABLISHED
وارد
شده است.
وقتی
یک اتصال TCP
بسته
میشود،
مراحل زیر را طی میکند.
شکل
۲ و۳:
حالات
اتصال TCPدر
هنگام بسته شدن
همانطور
که میتوانید
ببینید، اتصال تا زمانی که آخرین بسته ی
ACK
ارسال
نشده است، بسته نخواهد شد.
دقت
داشته باشید که این شکل بسته شدن یک اتصال
را در شرایط نرمال نشان میدهد.
یک
اتصال ممکن است از طریق ارسال RST(reset)
بسته
شود.
PDF Version
مترجم:
ایرج
هدایتی shotorbaan@yahoo.co.uk منبع
:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
|