Te zgjerojm limitet e iptables

Jemi ne nje nga temat me * ketu ne albanianwizard.org, them me * sepse ky eshte nje koncept origjinal i patrajtuar me pare, koncepti eshte te kthejm Iptables firewall ne IPS (Intrusion Prevention System), dhe shkrimi eshte paksa i nje niveli te avancuar (kjo edhe pse jane koncepte te reja dhe jo diçka e perditshme) keshtu qe nese nuk  keni informacione se ç’fare jane:
buffer overflow
sql injection
CSS (XSS)
Local File Inclusion , RFI (remote file inclusion) dhe nuk keni te qarte –string te iptables atehere eshte me mire te kaloni ne teme tjeter pasi ne kete teme nuk do te sqarojm sulmet por metoden se si mund te “bllokohen” keto sulme, gje qe e kthen iptables ne nje IPS, por ky eshte thjesht nje koncept dhe shume sulme te alteruara mund te rezultonin te sukseshme edhe mbas metodave mbrojtese qe mund te aplikojm (e shohim me poshte), por kjo vetem ne rastet kur perdoret buffer overflow (stack\heap – overflow), ne rastet e tjera mbrojtja eshte shume efikase.

iptables VS buffer overflow
Sulmet me te rrezikshme sot, nuk jane ato qe i drejtohen sistemit, apo nje platforme por ato qe i drejtohen drejtpersedrejti vet aplikacionit ,  le te shohim sebashku dhe arsyen.
Nje firewall ne pergjithesi do te shkoj dhe do te monitoroj portat qe jane te mbyllura, apo te filtruara dhe do te anashkaloj monitorimin e portave 80\22\25 etj ku nje server ofron sherbimet e veta “duke ja lene ne dore” keshtu sigurine vet aplikacionit qe eshte duke perdorur porten. [gabim ky qe lejon shumicen e sulmeve qe ndodhin sot]
Kjo sjell qe keto sulme nga ana tjeter te jene te suksesshme dhe ne sisteme jo te rregulluara (not hardened) edhe te pakapshme.
Te shohim disa rregulla qe mund ti impostojm iptables kunder disa sulmeve normale.

Iptables VS buffer overflow

Ky edhe pse sulm goxha i vjeter ne ‘moshe’ eshte edhe ne kete moment shume i perdorur dhe tipik per nje root account.

Shfrytezohet nje aplikacion i koduar ne C\C++ zakonisht dhe nje funksion malloc()  strcat() scanf() , strcpy() i pa kontrolluar me ane te se cilit arrihet ne zona te memorjes qe nuk duhet te jene te aksesueshme, duke ber “rishkrim” te ketyre zonave ne RAM e rjedhimisht nese hyet ne zona te rezervuara te memorjes si ato te sistemit operativ atehere mund te modifikosh pid-t e proçeseve e keshtu dhe uid (root @ uid= 0) dhe sistemi kompromentohet.
Rasti tipik eshte nje reverse shell qe lidhet me makinen e sulmuar.
Keto lloj sulmesh jane shume te veshtira per tu kapur, edhe nese nje sistem ka firewall dhe antivirus nuk ka shance kunder nje exploiti 0-day. Nje zgjidhje ne keto raste do te ishte nje fwsnort i integruar me snort + iptables normalisht dhe te shpresonim qe sulmi te njihej nga snort, ose me sakt snort te kete te regjistruar ne db shellin qe eshte duke perdorur sulmuesi.
Po marrim nje rast se si mund te bllokojm nje te tille nga porta 443 ku dihet qe per te bere overflow e mbushim hapesiren e memorjes me karaktere ç’faredo pastaj kur jemi ne hapesiren e duhur perdorim shellcode (ku shumica e atyre qe perdoren jane ne db e snort)
iptables -I INPUT 1 -p tcp –dport 443 -m string –string “AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA” -j DROP
Ne kete rast vihet re mire pjesa me “AAAA” e cila nuk do ishte e zakonshme, ne keto raste keshtu qe kjo lloj lidhjeje do te duhej te ndalohej.
Nje menyre per ta anashkaluar gjithsesi eshte qe ta mbushesh me BBBB ose CCCC ose me ABDEF… keshtu qe siç e thashe do te duhej nje snort i konfiguruar mire per tu marre me keto lloj sulmesh, por ne shumicen e rasteve kodi i exploitit perdoret nga worme, boote keshtu qe pjesa me siper mund te jete shume efektive.

iptables VS sql Injection

LoL, ne kete rast nuk kemi ç’fare te sqarojm, shkoni tek nje PKSH-crew dhe do jete gjeja e pare qe do u mesojn, ne keto raste duhet te evitojm string si “select, union, from, apo karaktere null”, dikush i zgjuar eshte duke menduar tani, se edhe nese ne bllokojm union, select etj etj duke njohur mire iptables mendon po sikur ti fus ne hexadecimal karakteret e sql injection?
Dhe ben mire te mendoj keshtu pasi mund ti behet evazion kesaj metode mbrojtese por per fat te mire iptables ka dhe opcionin –hex-string dhe per ta bllokuar nje null character ne hex do te ishte diçka e tille:
iptables -I INPUT 1 -p tcp –dport 1433  -m string –hex-string “‘|00|” –algo bm -m string –hex-string
“-|00|-|00|” –algo bm -j REJECT
Siç e shohim porta qe monitorohet eshte 1433, pra e mysql-s . Me sa me shume opcione gjithperfshirese, aq me pak do te ishin shanset per te pasur nje sulm te suksesshem, e ne kete rast duke marre parasysh nje server dhe 2000 website te hostuara ne te, do te ishte nje LAJM MADHESHTOR per klientet qe do e ndienin veten nen nje sherbim perfekt.

iptables VS Local File Inclusion

Ne keto raste, perdoret nje fail psh nje php dhe me ane te tij mund te aksesohet nje fail tjeter ne direktori, psh e zeme se faili yne skedari.php ka nje rresht ku shkruhet ky funksion:

 require("./../".$_GET["emriskedarit"]);

Duke pare thjesht me browser nje file te tille dhe duke perfituar nga ndonje funksion mund te shkojm direkt tek:

file.php?shko_tek=../../../../../../../etc/passwd%00
Ose mund te jete nje config.php, ose mund te jete nje /etc/shadow%00
Thame qe per keto perdorim browserin keshtu qe porta per tu monitoruar eshte 80 (web-server).
Keshtu qe:
iptables -I INPUT 1 -p tcp –dport 80 -m string –string “/etc/shadow” –algo bm -j REJECT
ose
iptables -I INPUT 1 -p tcp –dport 80 -m string –string “../../” –algo bm -j REJECT

iptables VS CSS (XSS) dhe RFI

Ketu besoj se imagjiononi vet…

shembull kunder Cross Site Scripting

iptables -I INPUT 1 -p tcp –dport 80 -m string –string “<>” –algo bm -j REJECT

Shembull kunder Remote File Inclusion
iptables -I INPUT 1 -p tcp –dport 80 -m string –string “=http://” –algo bm -j REJECT

Leave a Reply

Your email address will not be published. Required fields are marked *