Firewall Untuk Server Putera.com

[crypto.md5 1]

Taklah, memang masalah Bandwith ni aku rasa, sbb tu aku nak ko guide admin implement LRP untuk double confirm, sebab admin dah Shunning (features dlm PIX) ip penyerang tu, web putera pun dia tak dibenarkan access lagi atau apa jua jenis connection telah di- shun. Aku nak buat config untuk admin, tapi, belum pasti keadaan server2 kat sana, servis apa yg running dan sebagainya.

PIX 501= SOHO

PIX 506E= SOHO

PIX 515E= Small to Medium Business

PIX 525= Enterprise

PIX 535= Enterprise / ISP level

[Ehc 0]

Taklah, memang masalah Bandwith ni aku rasa, sbb tu aku nak ko guide admin implement LRP untuk double confirm, sebab admin dah Shunning (features dlm PIX) ip penyerang tu, web putera pun dia tak dibenarkan access lagi atau apa jua jenis connection telah di- shun.

'shun' tak kena cara pun boleh kena tembak jugak, insyaAllah aku cuba guide. kalau si penembak pun guna bandwith serupa bandwith server, mampu ke dia antar 'DoS' ? tak sebak line dia dulu ke ? maaf aku tanya macam nak belajar DoS la pulak.

ok, aku sertakan sedikit dari iptables untuk DROP terus IP peng'DoS' untuk pelbagai laluan,

$INSERT="-I"

$1="<ip peng'DoS>'

iptables $INSERT INPUT -s $1 -j DROP

iptables $INSERT INPUT -p tcp -s $1 -j REJECT --reject-with tcp-reset

iptables $INSERT OUTPUT -d $1 -j DROP

iptables $INSERT OUTPUT -p tcp -d $1 -j REJECT --reject-with tcp-reset

iptables $INSERT FORWARD -d $1 -j DROP

iptables $INSERT FORWARD -p tcp -d $1 -j REJECT --reject-with tcp-reset

iptables $INSERT INPUT -s $1 -j DROP

iptables $INSERT OUTPUT -d $1 -j DROP

iptables $INSERT FORWARD -d $1 -j DROP

dengan maksud ada skrip sebelum tu, bila IP penembak dikesan maka rules diatas diaktifkan.

[crypto.md5 1]

Kalau attacker tu guna sama bandwith, no hal, tapi kalau attack brutal seperti yg azuan test, line t1 vs sdsl 2mb, attacker masih rileks sebab bandwith dia cukup, mmg ada sedikit sebanyak ganggu line dia, tapi its nothing compared to yg bandwidth rendah. Shunning bermaksud no more connection for that ip, even access ke web putera pun tak dibenarkan

iptables $INSERT INPUT -s $1 -j DROP
iptables $INSERT INPUT -p tcp -s $1 -j REJECT --reject-with tcp-reset
iptables $INSERT OUTPUT -d $1 -j DROP
iptables $INSERT OUTPUT -p tcp -d $1 -j REJECT --reject-with tcp-reset
iptables $INSERT FORWARD -d $1 -j DROP
iptables $INSERT FORWARD -p tcp -d $1 -j REJECT --reject-with tcp-reset

iptables $INSERT INPUT -s $1 -j DROP
iptables $INSERT OUTPUT -d $1 -j DROP
iptables $INSERT FORWARD -d $1 -j DROP

Jadi jika attacker serang, iptables akan drop & reset dia punya connection? admin, boleh cuba implement sekarang kalau ada masa, bz aku tengok admin sekarang hehehe. IDS sensor dalam pix pun ada reset, tapi sayangnya certain attack x dapat detect

ip audit name attackpolicy attack action alarm drop reset

[crypto.md5 1]

Just to alert you the latest threat admin, sekarang sudah 24/02/2007, any latest news admin?

Cisco Applied Intelligence Response: Identifying and Mitigating Exploitation of Multiple Vulnerabilities in Cisco ASA/PIX/FWSM Firewalls

Cisco Response

Vulnerability Characteristics

Multiple vulnerabilities exist within Cisco PIX, ASA and FWSM products. Most of the vulnerabilities may result in a Denial of Service (DoS) condition, while one vulnerability results in privilege escalation and one has the potential for remote code execution. With the exception of the local privilege escalation vulnerability, all vulnerabilities can be exploited remotely without authentication or user interaction. The following information provides a vulnerability summary.

Malformed Hypertext Transfer Protocol (HTTP) request DoS vulnerability (Cisco Bug ID CSCsd75794): Cisco PIX, ASA, and FWSM products are affected. The likely attack vector is TCP port 80 traffic that transits the device.

Malformed Session Initiation Protocol (SIP) messages DoS vulnerability (Cisco Bug ID CSCsg80915, CSCse27708, CSCsd97077): Cisco PIX, ASA, and FWSM products are affected. The likely attack vector is UDP port 5060. An attacker could use spoofed packets to exploit the vulnerability.

Malformed auth-proxy requests using Secure Hypertext Transfer Protocol (HTTPS) DoS vulnerability (Cisco Bug ID CSCsg50228): The FWSM product is affected. The likely attack vector is TCP port 443. This is configuration dependent and will not be covered in this document.

Long auth-proxy request vulnerability (Cisco Bug ID CSCsd91268): The FWSM product is affected. This could result in a DoS or potentially remote code execution. Likely attack vectors are TCP ports 80 and 443. This is configuration dependent and will not be covered in this document.

Device Directed packet processing DoS vulnerability (Cisco Bug ID CSCse85707): The FWSM product is affected.

Device Directed Secure Hypertext Transfer Protocol (HTTPS) processing DoS vulnerability (Cisco Bug ID CSCsf29974): The FWSM product is affected. The likely attack vector is TCP port 443.

Malformed SNMP request DoS vulnerability (Cisco Bug ID CSCse52679): The FWSM product is affected. The likely attack vector is UDP port 161. An attacker could use spoofed packets to exploit the vulnerability.

Malformed TCP Packet DoS vulnerability (Cisco Bug ID CSCsh12711): The Cisco ASA and PIX Firewall products are affected. The attack vector is an inspected TCP stream.

Untuk maklumat lebih lanjut, click link di bawah

http://cisco.com/en/US/products/products_s...00807e24b9.html

Edited February 24, 2007 by crypto.md5

[gegule 0]

aper citer topik nih. kekadang aku nengok website nih down. ada kena mengena dengan attack dari outside ker?

[crypto.md5 1]

Ntahlah Bro.. kekadang aku rasa ragu2 nak teruskan topic ni kat public, seperti kat link ni http://forum.putera.com/tanya/index.php?show...mp;#entry429897 , rasa cam bersalah pulak aku alert latest threat kat public.. mungkin main PM saja lepas ni.

[dinnor 0]

Ntahlah Bro.. kekadang aku rasa ragu2 nak teruskan topic ni kat public, seperti kat link ni http://forum.putera.com/tanya/index.php?show...mp;#entry429897 , rasa cam bersalah pulak aku alert latest threat kat public.. mungkin main PM saja lepas ni.

bro crypto.md5,aku salute ko sbb byk bantu pasal firewall kat website nii..

cuma aku harap ko teruskan laa post kat sini berita2 ataupon perkembangan terbaru,

jgn dok main PM je,

sbb aku nak tahu dan nak belajar gak nii..

lain laa klu admin yg suruh ko PM

camner shanai???

[Shanai 31]

bro crypto.md5,aku salute ko sbb byk bantu pasal firewall kat website nii..

cuma aku harap ko teruskan laa post kat sini berita2 ataupon perkembangan terbaru,

jgn dok main PM je,

sbb aku nak tahu dan nak belajar gak nii..

lain laa klu admin yg suruh ko PM

camner shanai???

dilema yg paling besar ialah putera.com menumpang bandwidth orang lain. Bandwidth yg di-sponsor.

kalau bandwidth sendiri, saya tak kisah kalau semua orang nak hantar atau nak gasak dgn apa-apa script pun.

Kalau dah tahu kita duduk rumah orang, takkan kita nak heret tuan rumah sekali ke dalam risiko.

[crypto.md5 1]

dilema yg paling besar ialah putera.com menumpang bandwidth orang lain. Bandwidth yg di-sponsor.

kalau bandwidth sendiri, saya tak kisah kalau semua orang nak hantar atau nak gasak dgn apa-apa script pun.

Kalau dah tahu kita duduk rumah orang, takkan kita nak heret tuan rumah sekali ke dalam risiko.

Yup, i agree with that one... , & jangan salah sangka dengan keupayaan pix, orang cisco tengok nanti siap aku, eheheh, masalah sebenarnya disini ialah bandwidth, tu lah kesimpulannya

[slaughters 1]

Yup, i agree with that one... , & jangan salah sangka dengan keupayaan pix, orang cisco tengok nanti siap aku, eheheh, masalah sebenarnya disini ialah bandwidth, tu lah kesimpulannya

So ape penyelesaian agaknya yang boleh digunakan ??

[crypto.md5 1]

Even guna IPTABLES pun mungkin sama result, sebab masa ujian PIX tak down/K.O, sebaliknya masih hidup, tidak restart dengan sendirinya. Solutionnya kena tambah Bandwidth lebih tinggi.

[azuan 2]

Ehc, aku penah test rules lebih kurang macam ko provide tu, masalahnya walaupun firewall dah denied incoming dari semua IP sebenarnya, masalahnya serangan berupa ala-ala SYN attack. aku berminat nak test rules yang ko buat tu kalau ko nak. kasik tau aku kalau ko setuju.

[gegule 0]

sorry, but any update for this topic? any solution has been done?

[crypto.md5 1]

Banyak lagi vulnerabilities belum ditest, seperti ip fragmentation,etc.. kita tinggalkan dulu attack yg dalam kategori bandwidth consumption attack sbb dah tau bandwidth rendah. Hehehe, terpulang pada admin.

[FryShadow 90]

maaf menyampuk

just nak pandangan dari pakar2 kat sini , mana lagi bagus implementation firewall secara hardware based kah atau software based kah yang rasanya memberi result yang boleh dibanggakan ?

ni termasuk la cost2 yang berkaitan

[TRUNASUCI 15]

maaf menyampuk

just nak pandangan dari pakar2 kat sini , mana lagi bagus implementation firewall secara hardware based kah atau software based kah yang rasanya memberi result yang boleh dibanggakan ?

ni termasuk la cost2 yang berkaitan

depends pada poket/bajet..

kalau loaded pakai hardware.. kalau ciput pakai software

even software pun kene pair ngan good hardware at least NIC yg bagus ( mcm yg aku ckp masa ceramah aritu )..

[gegule 0]

yerp ikut bajet & cara penggunaan connection kat situ. kekadang kalo nak kata software firewall akan crash kalau kena attack pun susah gaks pasai ader gaks hardware firewall yang bleh sampai rosak gaks program dier kalau kena attack bertalu talu. tapi senang citer hardware firewall memang ader kelebihan yang lebih

[FryShadow 90]

okie..

kalau bajet besar tentulah companny tu cari firewall yang hardware based rite. pape pon aku masih mengkaji kemampuan software based ngan hardware based ni..

kalau software based guna hardware2 yang power pon boleh tahan kot kekebalan dia hehe..

just my 2 cents

//"Scan2 jugak.. sendirik server berlubang2 tak terpatch nampak!!"

[crypto.md5 1]

Vulnerability Alert

Cisco Applied Intelligence Response: Identifying and Mitigating Exploitation of the Vulnerability In Crypto Library

There is a vulnerability in a third-party cryptographic library component of certain Cisco products when processing a malformed Abstract Syntax Notation One (ASN.1) object when it processes malformed IKE, GDOI, SSH, HTTPS, SIP-TLS, and TIDP packets. This vulnerability can be exploited remotely without authentication and without end-user interaction. Successful exploitation of this vulnerability may cause the affected device to crash. The following protocols are attack vectors for exploitation.

* IKE protocol using UDP port 500

* Group Domain of Interpretation (GDOI) protocol using UDP port 848

* SSH protocol using TCP port 22

* HTTPS protocol using TCP port 443

* SIP-TLS protocol using TCP port 5060

* Threat Information Distribution Protocol (TIDP) using TCP port 5354

In the case of IKE and GDOI, this vulnerability is susceptible to exploitation through spoofed attacks. This vulnerability has been assigned CVE name CVE-2006-3894.

Cisco ASA, PIX, and FWSM Firewalls

Mitigation: Transit Access Control Lists

In an effort to protect the network from traffic that enters the network at ingress access points, which may include Internet connection points, partner and supplier connection points, or VPN connection points, administrators should deploy transit ACLs (tACLs) to perform policy enforcement. Administrators can construct a tACL by explicitly permitting only authorized traffic to enter the network at ingress access points or permitting authorized traffic to transit the network in accordance with existing security policies and configurations.

The tACL policy denies unauthorized IKE packets on UDP port 500, GDOI packets on UDP port 848, SSH packets on TCP port 22, HTTPS packets on TCP port 443, SIP-TLS packets on TCP port 5060 or TIDP packets on TCP port 5354 sent to affected devices. In the following example, 192.168.1.0/24 is the network IP address space used by the affected devices and the host at 192.168.100.1 is considered a trusted source that requires access to the affected devices. Care should be taken to allow required traffic for routing and administrative access prior to denying all unauthorized traffic.

Additional information about tACLs is available at Transit Access Control Lists: Filtering at Your Edge.

!

!-- Include any explicit permit statements for trusted sources that require access

!-- on the vulnerable port(s)

!

access-list transit-acl-policy extended permit udp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 500

access-list transit-acl-policy extended permit udp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 848

access-list transit-acl-policy extended permit tcp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 22

access-list transit-acl-policy extended permit tcp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 443

access-list transit-acl-policy extended permit tcp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 5060

access-list transit-acl-policy extended permit tcp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 5354

!

!-- The following vulnerability-specific access control entries (ACEs) can aid

!-- in identification of attacks

!

access-list transit-acl-policy extended deny udp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 500

access-list transit-acl-policy extended deny udp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 848

access-list transit-acl-policy extended deny tcp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 22

access-list transit-acl-policy extended deny tcp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 443

access-list transit-acl-policy extended deny tcp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 5060

access-list transit-acl-policy extended deny tcp host 192.168.100.1 192.168.1.0 255.255.255.0 eq 5354

!

!-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance with

!-- existing security policies and configurations

!

!-- Explicit deny for all other IP traffic

!

access-list transit-acl-policy extended deny ip any any

!

!-- Apply tACL to interface(s) in the ingress direction

!

access-group transit-acl-policy in interface outside

Mitigation: Anti-Spoof Protection Using Unicast RPF

Attackers can exploit the cryptographic library vulnerability described in this document using spoofed IP packets. Administrators can deploy and configure Unicast RPF as a protection mechanism against anti-spoofing. Unicast RPF is configured at the interface level and can detect and drop packets that lack a verifiable IP source address. Administrators should not rely on Unicast RPF to provide 100 percent anti-spoofing protection because spoofed packets may enter the network through a Unicast RPF-enabled interface if an appropriate return route to the source IP address exists. In an enterprise environment, Unicast RPF might be enabled at the Internet edge and the internal access layer on the user-supporting Layer 3 interfaces.

For additional information about the configuration and use of Unicast RPF, reference the Cisco Security Appliance Command Reference for ip verify reverse-path.

Maklumat lanjut di:

http://cisco.com/en/US/products/products_a...0080847c96.html