111r11111elod
-----Original Message-----
From: [email protected]
Sent: 2010-04-27, 17:11
To: [email protected]
Subject: CCIE_Security Digest, Vol 46, Issue 136
Send CCIE_Security mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://onlinestudylist.com/mailman/listinfo/ccie_security
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CCIE_Security digest..."
Today's Topics:
1. Re: Accounting for attackers packet (Pieter-Jan Nefkens)
2. Re: problem pinging thru asa from DMZ in WB2 Lab 12.
(Willians Barboza)
3. Re: problem pinging thru asa from DMZ in WB2 Lab 12.
(Willians Barboza)
4. Re: problem pinging thru asa from DMZ in WB2 Lab 12. (Tyson Scott)
5. Re: RFC 2827/3704 (Tyson Scott)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Apr 2010 13:09:32 +0200
From: Pieter-Jan Nefkens <[email protected]>
Subject: Re: [OSL | CCIE_Security] Accounting for attackers packet
To: Kingsley Charles <[email protected]>
Cc: OSL Security <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Kings,
To which route-map / interface do you have the access-list attached? The
outbound interface from where the attacker originates? And if so, is the
access-list attached outbound?
Bear in mind, that if the null0 interface sends unreachable packets, they will
get routed normally and thus the access-list should be set on an outbound flow.
Have you read the blackhole pdf at cisco.com?
It's available at:
http://www.cisco.com/web/about/security/intelligence/blackhole.pdf
HTH
Pieter-Jan
On 27 apr 2010, at 09:03, Kingsley Charles wrote:
> Hi all
>
> With RTBH, if I need check for the number of packets that is from the
> attacker. I configure the following:
>
> access-list 123 permit icmp any any unreachables log
> access-list 123 permit ip any any
>
> logging on
> logging host or buffered
>
>
> The null 0 interface is not configured for "no ip unreachables".
>
>
> The access-list is associated to interfaces of the edge router running BGP
> that gets the incoming traffic from the attacker.
>
> But I don't see the unreachables matching the ACL. The counter is "0".
>
> Any idea?
>
>
> With regards
> Kings
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
---
Nefkens Advies
Enk 26
4214 DD Vuren
The Netherlands
Tel: +31 183 634730
Fax: +31 183 690113
Cell: +31 654 323221
Email: [email protected]
Web: http://www.nefkensadvies.nl/
Think before you print.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://onlinestudylist.com/pipermail/ccie_security/attachments/20100427/f041992c/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.gif
Type: image/gif
Size: 87 bytes
Desc: not available
Url :
http://onlinestudylist.com/pipermail/ccie_security/attachments/20100427/f041992c/attachment-0001.gif
------------------------------
Message: 2
Date: Tue, 27 Apr 2010 08:46:56 -0400
From: Willians Barboza <[email protected]>
Subject: Re: [OSL | CCIE_Security] problem pinging thru asa from DMZ
in WB2 Lab 12.
To: Jimmy Larsson <[email protected]>
Cc: OSL Security <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Did you allow the return of echo-replies on the outside interface? Or
did you put the ICMP as an inspected protocol on the global inspection
rule?
2010/4/27 Jimmy Larsson <[email protected]>:
> What am I doing wrong here? Working with WB 2 lab 12, trying to ping
> 6.6.4.32 (BB2) from R9 (on ASA DMZ) without success.
> Error message in ASA:
> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
> (type 8, code 0)
> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
> (type 8, code 0)
> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
> (type 8, code 0)
>
> There is a translation:
> ASA(config)# sh run static | incl DMZ
> static (DMZ,outside) 6.6.146.9 10.17.17.9 netmask 255.255.255.255
> There is a hole in acl:
> ASA(config)# sh run access-group
> access-group OUTSIDE in interface outside
> access-group DMZ in interface DMZ
> ASA(config)# sh run access-list DMZ
> access-list DMZ extended permit udp host 10.17.17.9 host 6.6.99.1 eq ntp
> access-list DMZ extended permit icmp any any echo
> There is an inspect for icmp:
> ASA(config)# sh service-policy global ?| incl icmp
> ?? ? ?Inspect: icmp, packet 0, drop 0, reset-drop 0
>
> This is what packet-tracer say:
> ASA(config)# packet-tracer input DMZ icmp 10.17.17.9 8 0 6.6.4.32 detailed
> Phase: 1
> Type: ACCESS-LIST
> Subtype:
> Result: ALLOW
> Config:
> Implicit Rule
> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
> (type 8, code 0)
> Additional Information:
> ?Forward Flow based lookup yields rule:
> ?in ?id=0xd7c6a3d8, priority=1, domain=permit, deny=false
> ?? ? ? ?hits=2640, user_data=0x0, cs_id=0x0, l3_type=0x8
> ?? ? ? ?src mac=0000.0000.0000, mask=0000.0000.0000
> ?? ? ? ?dst mac=0000.0000.0000, mask=0000.0000.0000
> Phase: 2
> Type: FLOW-LOOKUP
> Subtype:
> Result: ALLOW
> Config:
> Additional Information:
> Found no matching flow, creating a new flow
> Phase: 3
> Type: ROUTE-LOOKUP
> Subtype: input
> Result: ALLOW
> Config:
> Additional Information:
> in ? 6.6.4.0 ? ? ? ? 255.255.255.0 ? outside
> Phase: 4
> Type: ACCESS-LIST
> Subtype:
> Result: DROP
> Config:
> Implicit Rule
> Additional Information:
> ?Forward Flow based lookup yields rule:
> ?in ?id=0xd7c6aa98, priority=110, domain=permit, deny=true
> ?? ? ? ?hits=31, user_data=0x0, cs_id=0x0, flags=0x3000, protocol=0
> ?? ? ? ?src ip=0.0.0.0, mask=0.0.0.0, port=0
> ?? ? ? ?dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
> Result:
> input-interface: DMZ
> input-status: up
> input-line-status: up
> output-interface: outside
> output-status: up
> output-line-status: up
> Action: drop
> Drop-reason: (acl-drop) Flow is denied by configured rule
>
> ASA(config)#
>
> Anyone?
> Br Jimmy
>
>
> --
> -------
> Jimmy Larsson
> Ryavagen 173
> s-26030 Vallakra
> Sweden
> http://blogg.kvistofta.nu
> -------
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
>
--
Willians Barboza
CCIE Security # 25629
------------------------------
Message: 3
Date: Tue, 27 Apr 2010 08:48:19 -0400
From: Willians Barboza <[email protected]>
Subject: Re: [OSL | CCIE_Security] problem pinging thru asa from DMZ
in WB2 Lab 12.
To: Jimmy Larsson <[email protected]>
Cc: OSL Security <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Also, what are the security levels in each interface?
2010/4/27 Willians Barboza <[email protected]>:
> Did you allow the return of echo-replies on the outside interface? Or
> did you put the ICMP as an inspected protocol on the global inspection
> rule?
>
> 2010/4/27 Jimmy Larsson <[email protected]>:
>> What am I doing wrong here? Working with WB 2 lab 12, trying to ping
>> 6.6.4.32 (BB2) from R9 (on ASA DMZ) without success.
>> Error message in ASA:
>> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
>> (type 8, code 0)
>> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
>> (type 8, code 0)
>> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
>> (type 8, code 0)
>>
>> There is a translation:
>> ASA(config)# sh run static | incl DMZ
>> static (DMZ,outside) 6.6.146.9 10.17.17.9 netmask 255.255.255.255
>> There is a hole in acl:
>> ASA(config)# sh run access-group
>> access-group OUTSIDE in interface outside
>> access-group DMZ in interface DMZ
>> ASA(config)# sh run access-list DMZ
>> access-list DMZ extended permit udp host 10.17.17.9 host 6.6.99.1 eq ntp
>> access-list DMZ extended permit icmp any any echo
>> There is an inspect for icmp:
>> ASA(config)# sh service-policy global ?| incl icmp
>> ?? ? ?Inspect: icmp, packet 0, drop 0, reset-drop 0
>>
>> This is what packet-tracer say:
>> ASA(config)# packet-tracer input DMZ icmp 10.17.17.9 8 0 6.6.4.32 detailed
>> Phase: 1
>> Type: ACCESS-LIST
>> Subtype:
>> Result: ALLOW
>> Config:
>> Implicit Rule
>> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
>> (type 8, code 0)
>> Additional Information:
>> ?Forward Flow based lookup yields rule:
>> ?in ?id=0xd7c6a3d8, priority=1, domain=permit, deny=false
>> ?? ? ? ?hits=2640, user_data=0x0, cs_id=0x0, l3_type=0x8
>> ?? ? ? ?src mac=0000.0000.0000, mask=0000.0000.0000
>> ?? ? ? ?dst mac=0000.0000.0000, mask=0000.0000.0000
>> Phase: 2
>> Type: FLOW-LOOKUP
>> Subtype:
>> Result: ALLOW
>> Config:
>> Additional Information:
>> Found no matching flow, creating a new flow
>> Phase: 3
>> Type: ROUTE-LOOKUP
>> Subtype: input
>> Result: ALLOW
>> Config:
>> Additional Information:
>> in ? 6.6.4.0 ? ? ? ? 255.255.255.0 ? outside
>> Phase: 4
>> Type: ACCESS-LIST
>> Subtype:
>> Result: DROP
>> Config:
>> Implicit Rule
>> Additional Information:
>> ?Forward Flow based lookup yields rule:
>> ?in ?id=0xd7c6aa98, priority=110, domain=permit, deny=true
>> ?? ? ? ?hits=31, user_data=0x0, cs_id=0x0, flags=0x3000, protocol=0
>> ?? ? ? ?src ip=0.0.0.0, mask=0.0.0.0, port=0
>> ?? ? ? ?dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
>> Result:
>> input-interface: DMZ
>> input-status: up
>> input-line-status: up
>> output-interface: outside
>> output-status: up
>> output-line-status: up
>> Action: drop
>> Drop-reason: (acl-drop) Flow is denied by configured rule
>>
>> ASA(config)#
>>
>> Anyone?
>> Br Jimmy
>>
>>
>> --
>> -------
>> Jimmy Larsson
>> Ryavagen 173
>> s-26030 Vallakra
>> Sweden
>> http://blogg.kvistofta.nu
>> -------
>>
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please
>> visit www.ipexpert.com
>>
>>
>
>
>
> --
> Willians Barboza
> CCIE Security # 25629
>
--
Willians Barboza
CCIE Security # 25629
------------------------------
Message: 4
Date: Tue, 27 Apr 2010 11:07:49 -0400
From: "Tyson Scott" <[email protected]>
Subject: Re: [OSL | CCIE_Security] problem pinging thru asa from DMZ
in WB2 Lab 12.
To: "'Willians Barboza'" <[email protected]>, "'Jimmy
Larsson'" <[email protected]>
Cc: 'OSL Security' <[email protected]>
Message-ID: <004e01cae61b$67f845f0$37e8d1...@com>
Content-Type: text/plain; charset="iso-8859-1"
Default security levels are 0 for both unless you changed it. If so you
need to allow
same-security-traffic permit inter-interface
Regards,
?
Tyson Scott - CCIE #13513 R&S, Security, and SP
Technical Instructor - IPexpert, Inc.
Mailto: [email protected]
Telephone: +1.810.326.1444, ext. 208
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
CCIE (R&S, Voice, Security & Service Provider) certification(s) with
training locations throughout the United States, Europe, South Asia and
Australia. Be sure to visit our online communities at
www.ipexpert.com/communities and our public website at www.ipexpert.com
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Willians
Barboza
Sent: Tuesday, April 27, 2010 8:48 AM
To: Jimmy Larsson
Cc: OSL Security
Subject: Re: [OSL | CCIE_Security] problem pinging thru asa from DMZ in WB2
Lab 12.
Also, what are the security levels in each interface?
2010/4/27 Willians Barboza <[email protected]>:
> Did you allow the return of echo-replies on the outside interface? Or
> did you put the ICMP as an inspected protocol on the global inspection
> rule?
>
> 2010/4/27 Jimmy Larsson <[email protected]>:
>> What am I doing wrong here? Working with WB 2 lab 12, trying to ping
>> 6.6.4.32 (BB2) from R9 (on ASA DMZ) without success.
>> Error message in ASA:
>> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
>> (type 8, code 0)
>> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
>> (type 8, code 0)
>> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
>> (type 8, code 0)
>>
>> There is a translation:
>> ASA(config)# sh run static | incl DMZ
>> static (DMZ,outside) 6.6.146.9 10.17.17.9 netmask 255.255.255.255
>> There is a hole in acl:
>> ASA(config)# sh run access-group
>> access-group OUTSIDE in interface outside
>> access-group DMZ in interface DMZ
>> ASA(config)# sh run access-list DMZ
>> access-list DMZ extended permit udp host 10.17.17.9 host 6.6.99.1 eq ntp
>> access-list DMZ extended permit icmp any any echo
>> There is an inspect for icmp:
>> ASA(config)# sh service-policy global ?| incl icmp
>> ?? ? ?Inspect: icmp, packet 0, drop 0, reset-drop 0
>>
>> This is what packet-tracer say:
>> ASA(config)# packet-tracer input DMZ icmp 10.17.17.9 8 0 6.6.4.32
detailed
>> Phase: 1
>> Type: ACCESS-LIST
>> Subtype:
>> Result: ALLOW
>> Config:
>> Implicit Rule
>> %ASA-3-106014: Deny inbound icmp src DMZ:10.17.17.9 dst outside:6.6.4.32
>> (type 8, code 0)
>> Additional Information:
>> ?Forward Flow based lookup yields rule:
>> ?in ?id=0xd7c6a3d8, priority=1, domain=permit, deny=false
>> ?? ? ? ?hits=2640, user_data=0x0, cs_id=0x0, l3_type=0x8
>> ?? ? ? ?src mac=0000.0000.0000, mask=0000.0000.0000
>> ?? ? ? ?dst mac=0000.0000.0000, mask=0000.0000.0000
>> Phase: 2
>> Type: FLOW-LOOKUP
>> Subtype:
>> Result: ALLOW
>> Config:
>> Additional Information:
>> Found no matching flow, creating a new flow
>> Phase: 3
>> Type: ROUTE-LOOKUP
>> Subtype: input
>> Result: ALLOW
>> Config:
>> Additional Information:
>> in ? 6.6.4.0 ? ? ? ? 255.255.255.0 ? outside
>> Phase: 4
>> Type: ACCESS-LIST
>> Subtype:
>> Result: DROP
>> Config:
>> Implicit Rule
>> Additional Information:
>> ?Forward Flow based lookup yields rule:
>> ?in ?id=0xd7c6aa98, priority=110, domain=permit, deny=true
>> ?? ? ? ?hits=31, user_data=0x0, cs_id=0x0, flags=0x3000, protocol=0
>> ?? ? ? ?src ip=0.0.0.0, mask=0.0.0.0, port=0
>> ?? ? ? ?dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
>> Result:
>> input-interface: DMZ
>> input-status: up
>> input-line-status: up
>> output-interface: outside
>> output-status: up
>> output-line-status: up
>> Action: drop
>> Drop-reason: (acl-drop) Flow is denied by configured rule
>>
>> ASA(config)#
>>
>> Anyone?
>> Br Jimmy
>>
>>
>> --
>> -------
>> Jimmy Larsson
>> Ryavagen 173
>> s-26030 Vallakra
>> Sweden
>> http://blogg.kvistofta.nu
>> -------
>>
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please
>> visit www.ipexpert.com
>>
>>
>
>
>
> --
> Willians Barboza
> CCIE Security # 25629
>
--
Willians Barboza
CCIE Security # 25629
_______________________________________________
For more information regarding industry leading CCIE Lab training, please
visit www.ipexpert.com
------------------------------
Message: 5
Date: Tue, 27 Apr 2010 11:11:11 -0400
From: "Tyson Scott" <[email protected]>
Subject: Re: [OSL | CCIE_Security] RFC 2827/3704
To: "'Kingsley Charles'" <[email protected]>, "'Brandon
Carroll'" <[email protected]>
Cc: [email protected]
Message-ID: <004f01cae61b$e0096ce0$a01c46...@com>
Content-Type: text/plain; charset="us-ascii"
RFC 2827 is geared towards ISP's but in the RFC it specifically mentions
Enterprise administrators so that is why it is on the Security Test.
Regards,
Tyson Scott - CCIE #13513 R&S, Security, and SP
Technical Instructor - IPexpert, Inc.
Mailto: <mailto:[email protected]> [email protected]
Telephone: +1.810.326.1444, ext. 208
Live Assistance, Please visit: <http://www.ipexpert.com/chat>
www.ipexpert.com/chat
eFax: +1.810.454.0130
IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
CCIE (R&S, Voice, Security & Service Provider) certification(s) with
training locations throughout the United States, Europe, South Asia and
Australia. Be sure to visit our online communities at
<http://www.ipexpert.com/communities> www.ipexpert.com/communities and our
public website at <http://www.ipexpert.com/> www.ipexpert.com
From: [email protected]
[mailto:[email protected]] On Behalf Of Kingsley
Charles
Sent: Tuesday, April 27, 2010 4:48 AM
To: Brandon Carroll
Cc: [email protected]
Subject: Re: [OSL | CCIE_Security] RFC 2827/3704
Hi Brandon
RFC 2827 is specifically meant for ISP ingress filtering right?. It means
more to ISP filtering unwanted source addresses from it's customers.
Ref - http://www.ietf.org/rfc/rfc3704.txt
access-list 123 deny ip 0.0.0.0 0.0.0.255 any
access-list 123 deny ip 10.0.0.0 0.255.255.255 any
access-list 123 deny ip 127.0.0.0 0.255.255.255 any
access-list 123 deny ip 172.16.0.0 0.15.255.255 any
access-list 123 deny ip 192.168.0.0 0.0.255.255 any
access-list 123 deny ip 224.0.0.0 15.255.255 any
access-list 123 deny ip 240.0.0.0 15.255.255 any
access-list 123 deny ip host 255.255.255.255 any
access-list 123 deny ip host 0.0.0.0 any
access-list 123 permit ip any any
Added two more entries for 0.0.0.0 and 255.255.255.255
If it is implemented for the customer permiter router to block source
addresses from the internet, then you need to add one more entry that blocks
source addresses of your internal network. But since, the internal address
will be from RFC 1918, the above should take care. If you use public
addresses in your network, then we may need to add an entry.
Please let me know, your thoughts.
With regards
Kings
On Mon, Apr 26, 2010 at 8:26 PM, Brandon Carroll <[email protected]>
wrote:
The RFC states that you want to filter traffic that contains source address
not legitimately in use by the customer network.
Generally that would include 0.0.0.0/8,10.0.0.0/8,127.0.0.0/8,
172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4,and 240.0.0.0/4, but it's not
limited to these addresses. You should also include the address space in use
by the internal network. This makes sense since the address space used
internally should not be seen as the source in packets from the outside.
As RFC 3704 states, on possible solution for this would be uRPF. If you use
uRPF you dont need to worry as much about the addresses that you use. If you
use ACLs on ingress you do. The reason you've probably seen differences in
the ACLs probably relates to the networks used in the examples.
Regards,
Brandon Carroll - CCIE #23837
Senior Technical Instructor - IPexpert
Mailto: [email protected]
Telephone: +1.810.326.1444
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
CCIE (R&S, Voice, Security & Service Provider) certification(s) with
training locations throughout the United States, Europe, South Asia and
Australia. Be sure to visit our online communities at
www.ipexpert.com/communities and our public website at www.ipexpert.com
<http://www.ipexpert.com/>
Platinum Solutions Group (PSG) provides high-end consulting services with a
primary emphasis on Cisco's Data Center Solutions, Service Provider
Solutions, Unified Communications and Security-enabled infrastructures. Be
sure to visit www.platinumsolutionsgroup.com
<http://www.platinumsolutionsgroup.com/> .
On Apr 26, 2010, at 6:36 AM, Kingsley Charles wrote:
Hi all
Can someone please let me know, the addresses for RFC 2827/3704 that should
be followed. I see differences, in the way they
are implemented in various sites.
The RFCs also does not mention specific addresses for RFC 2827/3704 as it
does for RFC 1918/3330.
With regards
Kings
_______________________________________________
For more information regarding industry leading CCIE Lab training, please
visit www.ipexpert.com <http://www.ipexpert.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://onlinestudylist.com/pipermail/ccie_security/attachments/20100427/753f829f/attachment.htm
End of CCIE_Security Digest, Vol 46, Issue 136
**********************************************
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
