yuna_admirer
21-07-2003, 04:44
Grrru
Tức quá, ngồi nguyên buổi tối dịch cho bà con nghe + bình loạn một vài câu chơi, hỏng ngờ máy bị treo và em chưa seo :D.
thôi đành để bà con tự xem vậy :
Cisco routers and switches running Cisco IOS® software and configured to process Internet Protocol version 4 (IPv4) packets are vulnerable to a Denial of Service (DoS) attack. Multiple IPv4 packets with specific protocol fields sent directly to the device may cause the input interface to stop processing traffic once the input queue is full. No authentication is required to process the inbound packet. Processing of IPv4 packets is enabled by default. Devices running only IP version 6 (IPv6) are not affected. A workaround is available.
Affected Products
This issue affects all Cisco devices running Cisco IOS software and configured to process Internet Protocol version 4 (IPv4) packets. Cisco devices which do not run Cisco IOS software are not affected. Devices which run only Internet Protocol version 6 (IPv6) are not affected.
Details
Cisco routers are configured to process and accept Internet Protocol version 4 (IPv4) packets by default. Multiple IPv4 packets with protocol type 53 (SWIPE), 55 (IP Mobility), 77 (Sun ND), or 103 (Protocol Independent Multicast - PIM) which is handled by the processor on a Cisco IOS device may force the device to incorrectly flag the input queue on an interface as full, which will cause the router to stop processing inbound traffic on that interface. This can cause routing protocols to drop due to dead timers.
Routers that have the PIM process running are not affected by traffic with protocol type 103. This process will be created when PIM is configured on any interface of the router. An interface with PIM enabled will have one of the following three commands in the interface configuration: ip pim dense-mode, ip pim sparse-mode, or ip pim sparse-dense-mode.
On Ethernet interfaces, Address Resolution Protocol (ARP) times out after a default time of four hours, and no traffic can be processed. The device must be rebooted to clear the input queue on the interface, and will not reload without user intervention. The attack may be repeated on all interfaces causing the router to be remotely inaccessible. A workaround is available, and is documented in the Workarounds section.
The following two Cisco vulnerabilities are documented in DDTS: CSCea02355 ( registered customers only) affects all Cisco routers running Cisco IOS software. This documents the flaw with protocols 53, 55, and 77. CSCdz71127 ( registered customers only) was introduced by an earlier code revision, and documents an input queue vulnerability to protocol 103 with a device which is not configured for PIM. Any version of software which has the fix for CSCdx02283 ( registered customers only) is vulnerable.
Registered customers can find more details using the Bug Toolkit at http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl ( registered customers only) .
To identify a blocked input interface, use the show interfaces command and look for the Input Queue line. If the current size (in this case, 76) is larger than the maximum size (75), the input queue is blocked.
Use the show buffers command and look for the prot field. Below are two examples:
Router#show interface ethernet 0/0
Ethernet0/0 is up, line protocol is up
Hardware is AmdP2, address is 0050.500e.f1e0 (bia 0050.500e.f1e0)
Internet address is 172.16.1.9/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:41, output 00:00:07, output hang never
Last clearing of "show interface" counters 00:07:18
Input queue: 76/75/1091/0 (size/max/drops/flushes); Total output drops: 0
!--- The 76/75 shows that this is blocked
Router#show buffers input-interface ****** 0/0 packet
Buffer information for Small buffer at 0x612EAF3C
data_area 0x7896E84, refcount 1, next 0x0, flags 0x0
linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0
if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None)
inputtime 0x0, outputtime 0x0, oqnumber 65535
datagramstart 0x7896ED8, datagramsize 728, maximum size 65436
mac_start 0x7896ED8, addr_start 0x7896ED8, info_start 0x0
network_start 0x7896ED8, transport_start 0x0
source: 10.0.0.1, destination: 192.168.10.10, id: 0xAAB8, ttl: 41, prot: 103
!--- prot: 103 is proof that this is one of the attack packets
Workarounds
AFTER APPLYING THE WORKAROUND the input queue depth may be raised with the "hold-queue <new value> in" interface command -- the default size is 75. This will allow traffic flow on the interface. The device may then be reloaded at a convenient time to release the blocked packets.
Cisco recommends that all IOS devices which process IPv4 packets be configured to block traffic directed to the router from any unauthorized source with the use of Access Control Lists (ACLs). This can be done at multiple locations, and it is recommended that you review all methods and use the combination which fits your network best. Legitimate traffic is defined as management protocols such as telnet, snmp or ssh, and configured routing protocols from explicitly allowed peers. All other traffic destined to the device should be blocked at the input interface. Traffic entering the network should also be carefully evaluated and filtered at the network edge if destined to an infrastructure device. Although network service providers must often allow unknown traffic to transit their network, it is not necessary to allow that same traffic destined to their network infrastructure. Several white papers have been written to assist in deploying these recommended security best practices.
ACLs can have performance impact on certain platforms, so care should be taken when applying the recommended workarounds.
Transit ACLs
The following access list is specifically designed to block attack traffic. Note that the attack traffic can include spoofed source addresses. This access list should be applied to all interfaces of the device, and should include topology-specific filters. This could include filtering routing protocol traffic, management protocols, and traffic destined for the internal network. Protocol 103 is Protocol Independent Multicast (PIM), which is a commonly deployed application in multicast networks. Interfaces with PIM enabled have not been found to be vulnerable to exploit traffic with protocol 103; PIM traffic may be permitted to those select devices.
access-list 101 deny 53 any any
access-list 101 deny 55 any any
access-list 101 deny 77 any any
access-list 101 deny 103 any any
!--- insert any other previously applied ACL entries here
!--- you must permit other protocols through to allow normal
!--- traffic -- previously defined permit lists will work
!--- or you may use the permit ip any any shown here
access-list 101 permit ip any any
Prior to deploying ACLs that filter transit traffic, a classification ACL can be used to help identify required permit statements. A classification ACL is an ACL that permits a series of protocols. Displaying access-list entry hit counters helps determine required protocols: entries with zero packets counted are likely not required. Classification access-lists are detailed in the link below for infrastructure access-lists.
Receive ACLs
For distributed platforms, receive path access lists may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the c12000 and 12.0(24)S for the c7500. The receive access lists protect the device from harmful traffic before the traffic can impact the route processor. The CPU load is distributed to the line card processors and helps mitigate load on the main route processor. The white paper entitled "GSR: Receive Access Control Lists" will help you identify and allow legitimate traffic to your device and deny all unwanted packets:
http://www.cisco.com/warp/public/707/racl.html
Infrastructure ACLs
Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection ACLs:
http://www.cisco.com/warp/public/707/iacl.html
Được trích trong Cisco Advisory
Hix, tiếng anh hơi lùng bùng, các bạn nào hiểu thì đọc, hỏng hiểu thì cũng cố đọc.
IOS của TGA Router hiện đang dùng là mới nhất, 12.3 1a, fix gòi, hihi (đã test).
Tin này làm xáo trộn bà con Security thế giới mấy hôm nay, từ ngày 17/7/2003 thì phải.
Bài kế típ tui post một vài đoạn shell Code cho bà con tham khảo chơi.
Còn ai có kiến thức về lập trình Socket thì ngối viết một vài đoạn DoS nho nhỏ chơi :D, thích thì đem đến TGA thực tập DoS router của Yuna. Còn không thì tham khảo cái này
http://anticode.antionline.com/download.php
Xem thêm trên AO bà con kháo nhau nè
http://www.antionline.com/showthread.php?s=&threadid=246198
ISP và IXP fix nhanh đi :D, kêu mấy ông bên SE qua support, kẻo Internet Việt Nam down mấy ngày thì khổ thân anh em + thegioiao lắm (kinh doanh Internet mà lỵ). Nếu sợ tốn tiền mua IOS thì qua đây chép cho - mà hình như bản Bugtraq của CIsco nó cho free đó.
Cuối cùng nếu bí quá thì làm ơn đặt dùm cái ACL block hết 4 cái protocol đó lại.
Bực mình vì bài viết dài và hay của mình hix hix, đi theo cái PC bị treo. www.potay.com
Tức quá, ngồi nguyên buổi tối dịch cho bà con nghe + bình loạn một vài câu chơi, hỏng ngờ máy bị treo và em chưa seo :D.
thôi đành để bà con tự xem vậy :
Cisco routers and switches running Cisco IOS® software and configured to process Internet Protocol version 4 (IPv4) packets are vulnerable to a Denial of Service (DoS) attack. Multiple IPv4 packets with specific protocol fields sent directly to the device may cause the input interface to stop processing traffic once the input queue is full. No authentication is required to process the inbound packet. Processing of IPv4 packets is enabled by default. Devices running only IP version 6 (IPv6) are not affected. A workaround is available.
Affected Products
This issue affects all Cisco devices running Cisco IOS software and configured to process Internet Protocol version 4 (IPv4) packets. Cisco devices which do not run Cisco IOS software are not affected. Devices which run only Internet Protocol version 6 (IPv6) are not affected.
Details
Cisco routers are configured to process and accept Internet Protocol version 4 (IPv4) packets by default. Multiple IPv4 packets with protocol type 53 (SWIPE), 55 (IP Mobility), 77 (Sun ND), or 103 (Protocol Independent Multicast - PIM) which is handled by the processor on a Cisco IOS device may force the device to incorrectly flag the input queue on an interface as full, which will cause the router to stop processing inbound traffic on that interface. This can cause routing protocols to drop due to dead timers.
Routers that have the PIM process running are not affected by traffic with protocol type 103. This process will be created when PIM is configured on any interface of the router. An interface with PIM enabled will have one of the following three commands in the interface configuration: ip pim dense-mode, ip pim sparse-mode, or ip pim sparse-dense-mode.
On Ethernet interfaces, Address Resolution Protocol (ARP) times out after a default time of four hours, and no traffic can be processed. The device must be rebooted to clear the input queue on the interface, and will not reload without user intervention. The attack may be repeated on all interfaces causing the router to be remotely inaccessible. A workaround is available, and is documented in the Workarounds section.
The following two Cisco vulnerabilities are documented in DDTS: CSCea02355 ( registered customers only) affects all Cisco routers running Cisco IOS software. This documents the flaw with protocols 53, 55, and 77. CSCdz71127 ( registered customers only) was introduced by an earlier code revision, and documents an input queue vulnerability to protocol 103 with a device which is not configured for PIM. Any version of software which has the fix for CSCdx02283 ( registered customers only) is vulnerable.
Registered customers can find more details using the Bug Toolkit at http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl ( registered customers only) .
To identify a blocked input interface, use the show interfaces command and look for the Input Queue line. If the current size (in this case, 76) is larger than the maximum size (75), the input queue is blocked.
Use the show buffers command and look for the prot field. Below are two examples:
Router#show interface ethernet 0/0
Ethernet0/0 is up, line protocol is up
Hardware is AmdP2, address is 0050.500e.f1e0 (bia 0050.500e.f1e0)
Internet address is 172.16.1.9/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:41, output 00:00:07, output hang never
Last clearing of "show interface" counters 00:07:18
Input queue: 76/75/1091/0 (size/max/drops/flushes); Total output drops: 0
!--- The 76/75 shows that this is blocked
Router#show buffers input-interface ****** 0/0 packet
Buffer information for Small buffer at 0x612EAF3C
data_area 0x7896E84, refcount 1, next 0x0, flags 0x0
linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0
if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None)
inputtime 0x0, outputtime 0x0, oqnumber 65535
datagramstart 0x7896ED8, datagramsize 728, maximum size 65436
mac_start 0x7896ED8, addr_start 0x7896ED8, info_start 0x0
network_start 0x7896ED8, transport_start 0x0
source: 10.0.0.1, destination: 192.168.10.10, id: 0xAAB8, ttl: 41, prot: 103
!--- prot: 103 is proof that this is one of the attack packets
Workarounds
AFTER APPLYING THE WORKAROUND the input queue depth may be raised with the "hold-queue <new value> in" interface command -- the default size is 75. This will allow traffic flow on the interface. The device may then be reloaded at a convenient time to release the blocked packets.
Cisco recommends that all IOS devices which process IPv4 packets be configured to block traffic directed to the router from any unauthorized source with the use of Access Control Lists (ACLs). This can be done at multiple locations, and it is recommended that you review all methods and use the combination which fits your network best. Legitimate traffic is defined as management protocols such as telnet, snmp or ssh, and configured routing protocols from explicitly allowed peers. All other traffic destined to the device should be blocked at the input interface. Traffic entering the network should also be carefully evaluated and filtered at the network edge if destined to an infrastructure device. Although network service providers must often allow unknown traffic to transit their network, it is not necessary to allow that same traffic destined to their network infrastructure. Several white papers have been written to assist in deploying these recommended security best practices.
ACLs can have performance impact on certain platforms, so care should be taken when applying the recommended workarounds.
Transit ACLs
The following access list is specifically designed to block attack traffic. Note that the attack traffic can include spoofed source addresses. This access list should be applied to all interfaces of the device, and should include topology-specific filters. This could include filtering routing protocol traffic, management protocols, and traffic destined for the internal network. Protocol 103 is Protocol Independent Multicast (PIM), which is a commonly deployed application in multicast networks. Interfaces with PIM enabled have not been found to be vulnerable to exploit traffic with protocol 103; PIM traffic may be permitted to those select devices.
access-list 101 deny 53 any any
access-list 101 deny 55 any any
access-list 101 deny 77 any any
access-list 101 deny 103 any any
!--- insert any other previously applied ACL entries here
!--- you must permit other protocols through to allow normal
!--- traffic -- previously defined permit lists will work
!--- or you may use the permit ip any any shown here
access-list 101 permit ip any any
Prior to deploying ACLs that filter transit traffic, a classification ACL can be used to help identify required permit statements. A classification ACL is an ACL that permits a series of protocols. Displaying access-list entry hit counters helps determine required protocols: entries with zero packets counted are likely not required. Classification access-lists are detailed in the link below for infrastructure access-lists.
Receive ACLs
For distributed platforms, receive path access lists may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the c12000 and 12.0(24)S for the c7500. The receive access lists protect the device from harmful traffic before the traffic can impact the route processor. The CPU load is distributed to the line card processors and helps mitigate load on the main route processor. The white paper entitled "GSR: Receive Access Control Lists" will help you identify and allow legitimate traffic to your device and deny all unwanted packets:
http://www.cisco.com/warp/public/707/racl.html
Infrastructure ACLs
Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection ACLs:
http://www.cisco.com/warp/public/707/iacl.html
Được trích trong Cisco Advisory
Hix, tiếng anh hơi lùng bùng, các bạn nào hiểu thì đọc, hỏng hiểu thì cũng cố đọc.
IOS của TGA Router hiện đang dùng là mới nhất, 12.3 1a, fix gòi, hihi (đã test).
Tin này làm xáo trộn bà con Security thế giới mấy hôm nay, từ ngày 17/7/2003 thì phải.
Bài kế típ tui post một vài đoạn shell Code cho bà con tham khảo chơi.
Còn ai có kiến thức về lập trình Socket thì ngối viết một vài đoạn DoS nho nhỏ chơi :D, thích thì đem đến TGA thực tập DoS router của Yuna. Còn không thì tham khảo cái này
http://anticode.antionline.com/download.php
Xem thêm trên AO bà con kháo nhau nè
http://www.antionline.com/showthread.php?s=&threadid=246198
ISP và IXP fix nhanh đi :D, kêu mấy ông bên SE qua support, kẻo Internet Việt Nam down mấy ngày thì khổ thân anh em + thegioiao lắm (kinh doanh Internet mà lỵ). Nếu sợ tốn tiền mua IOS thì qua đây chép cho - mà hình như bản Bugtraq của CIsco nó cho free đó.
Cuối cùng nếu bí quá thì làm ơn đặt dùm cái ACL block hết 4 cái protocol đó lại.
Bực mình vì bài viết dài và hay của mình hix hix, đi theo cái PC bị treo. www.potay.com