Task 6.2 Alternate solution

So I have circled back to lab 1 to go through 1-10 pre lab & hopefully I am now spotting better ways to do things. What do you good people think to this:

Q)

To help prevent this type of attack in the future configure your network so
that traffic will not be accepted from BB1, BB2, or BB3 if it sourced from
your address space 183.X.0.0/16.

INE Solution)

Ingrees ACL:
ip access-list extended SYN_ATTACK
deny ip 183.1.0.0 0.0.255.255 any
permit tcp any host 183.1.28.100 eq www syn log-input
permit ip any any

Ok, yes I agree for the Switch this is the only option (the dont support my solution), but for the routers I went with this tac:

!
int XYZ
 ip verify unicast source reachable-via rx
!

Same result right? Or have i overlooked one small detail as usual, the point that may trip me up here is this:

tx = Examines incoming packets to determine whether the source address is in
the FIB and permits the packet only if the source is reachable through
the interface on which the packet was received (sometimes referred to as
strict mode).

The above may break something if I were to a odd design where I recieve a packet from say BGP AS100 & my local policy is to send back to this AS via AS200 (Ie i have to route internally?

I think my anser is valid, I am just picking holes in in, well because thats what were here for right? ;)

Regards,

Sam

 

Comments

  • Ever herd the phrase FTFQ.. Well I just looked through the rest of the SG an i quote

    "Another way to implement this would be by using uRPF filtering."

     

    I will mark this one down as a small victory, hurrah..

     

    Sam

  • JoeMJoeM ✭✭✭

    Hi Sammy,

    Whenever I see these scenarios, I think exactly the same as you did.   However, on this one, I think the clue is that there are multiple exits (BB1,BB2,BB3) -- and we need "strict" denial of this source address.

    Whever we use strict mode with multiple exits (egress/ingress), there is the possibility of valid traffic being blocked.  So then, we have to go with "loose" mode. Loose mode meaning, as long as it is in the routing table, the source is valid.  That will not work for this task.

    So, what I have found with these labs, is if there is a strict DENY needed, and there are multiple exits -- then go with the ACL.

     

    Maybe someone can explain it better (strict vs loose), but that is my reasoning with these requirements.  ;-)

  • JoeMJoeM ✭✭✭

    Ever herd the phrase FTFQ.. Well I just looked through the rest of the SG an i quote

    "Another way to implement this would be by using uRPF filtering."

    I will mark this one down as a small victory, hurrah..

    Sam

     

    Ouch. They actually do mention uRPF.

    In the latest version of WB-II, they add a caveat.

     

    But I think loopbacks are the least of the concerns.  The option to use uRPF "strict" mode conflicts with the logic given in other exact lab scenarios.     When to use  Strict mode  vs  Loose Mode

    I would need to search through the forum to find the discussions on this issue with multiple entries/exits.   I have given feedback to INE support, asking for their clarification.   Stay tuned.  ;-)

  • I'm glad you pointed out the newer workbook.. I have not been using these, I must download and use these now, hopefully all the start configs are the same!!!

    Sam

Sign In or Register to comment.