Thursday, 20 February 2014

Reverse Path forwarding (ip verify reverse-path interface)

Reverse Path forwarding (ip verify reverse-path interface)

Unicast RPF guards against IP spoofing (a packet uses an incorrect source IP address to obscure its true source) by ensuring that all packets have a source IP address that matches the correct source interface according to the routing table.
Normally, the ASA only looks at the destination address when determining where to forward the packet. Unicast RPF instructs the ASA to also look at the source address; this is why it is called Reverse Path Forwarding. For any traffic that you want to allow through the ASA, the ASA routing table must include a route back to the source address. See RFC 2267 for more information.
For outside traffic, for example, the ASA can use the default route to satisfy Unicast RPF protection. If traffic enters from an outside interface, and the source address is not known to the routing table, the ASA uses the default route to correctly identify the outside interface as the source interface.
If traffic enters the outside interface from an address that is known to the routing table, but is associated with the inside interface, then the ASA drops the packet. Similarly, if traffic enters the inside interface from an unknown source address, the ASA drops the packet because the matching route (the default route) indicates the outside interface.
Unicast RPF is implemented as follows:
  • ICMP packets have no session, so each packet is checked.
  • UDP and TCP have sessions, so the initial packet requires a reverse route lookup. Subsequent packets arriving during the session are checked using an existing state maintained as part of the session. Non-initial packets are checked to ensure that they arrived on the same interface used by the initial packet.

Examples

The following example enables Unicast RPF on the outside interface:
ciscoasa(config)# ip verify reverse-path interface outside


Related Commands

Command
Description
clear configure ip verify reverse-path
Clears the configuration set using the ip verify reverse-path command.
clear ip verify statistics
Clears the Unicast RPF statistics.
show ip verify statistics
Shows the Unicast RPF statistics.
show running-config ip verify reverse-path
Shows the configuration set using the ip verify reverse-path command.

Monday, 17 February 2014

BGP Theory and Concepts; BGP Attributes

Administrative distance - EBGP = 20, IBGP = 200

BGP neighbor relationships
Neighbors are manually configured.
Neighbors start in IDLE state
 -1st stage: Active
 -2nd stage: Open sent
 -3rd stage: Open Confirmed
 -4th stage: Established

Hello message sent once every 60 seconds with a holddown of 180 seconds
Neighbors are capable of MD5 authentication

Rule of Synchronization
Routes learned via BGP must be validated by the interior routing table before they can be advertised to remote peers.

If Synchronization is turned on at R1, it receives eBGP routes from AS4300 and AS2300 but R1 does not install them in routing table.










After Synchronization is turned off at R1, it installs eBGP routes in its routing table. It does not advertise to its iBGP peer due to Rule of Split-Horizon.











Rule of Split-Horizon (Per BGP)
Routes learned via IBGP will never be sent to another IBGP peer. It's to prevent loop and Split-horizon is good if all IBGP are fully mesh.
To overrule this rule, configure route reflector. Of course iBGP peer (R4) must know how to reach 10.12.1.2 and 10.13.1.2 via IGP or static routes.


















------------

BGP Attributes

Well-known mandatory Attributes

AS-Path

Next-Hop; next-hop on shared media (if receiving router is on the same subnet, next-hop remains the same)

Origin - Tells how the route originated(IGP(I),EGP(E),Unknow(redistribution)).


Well-known optional Attributes

Local Preference - gives you control over preferred routes,higher is better.

Weight - cisco proprietary, gives you control of routes on the SAME router. It does not affect routing policy of other routers in the AS

Atomic aggregate - Informs router that a route has been summarized.

Multi-exit discriminator(MED) - used to suggest an entry point into your AS. Lower is better.

Aggregator - Designates the IP address of the router who performed summarization.

Community - Used for route tagging.




ISIS

IS-IS

Link-state routing protocol
Uses Partical Route Calculation (PRC) for IP routes
Uses the DEFAULT metric on cisco routers (0-63)
Does not have a BACKBONE Area.Rather, a Backbone LEVEL
Requires a Single OSI ADDRESS

OSI Addressing
Hexadecimal
Composed of three parts
 -Area ID(Variable length)
 -Sytem ID(6 Bytes) --like a host address
 -NSEL(1 Byte) --like a service port
Read address from right to left because of Area ID(variable length)
49.003.1111.2222.3333.00
49.0152.3135.1AB2.FE00.63C9.00
49.005.1111.1111.1111.00
49 is a private address.

IS-IS routing maintains 2 IP Databases. 
  Level 1 Database: contains intra-area routes
  Level 2 Database: contains backbone routes
Routers may be L1, L2 or L1/L2.

Configuration
-trun on the routing process
-assign an OSI/NET address
-ip router isis -in each interface you want to run isis

Friday, 14 February 2014

OSPF

Administrative distance - 110

Technial overview of OSPF
1. OSPF send HELLO packet to multicast address 224.0.0.5 (all OSPF routers)
2. Neighbor evaluates packet. May or may not form neighbor
3. Link-state data exchange (DBD)
4. Net info. Recorded and Flooded.
5. When database complete, SPF Algorigthm runs.
6. Valid routes enter the routing table

OSPF Hello Packet
contains the followings
1. Router ID
2. Area ID (x)
3. Address of originate terface
4. Authentication information (x)
5. Hello Interval (x)
6. Dead Interval (x)
7. Priority
8. DR/BDR IDs
9. Neighbor Router IDs
 (x) = must match

OSPF Network Types
- Point to Point
There is no DR/BDR selection. Updates sent to 224.0.0.5.
- Broadcast
DR/BDR selection. They listen to 224.0.0.6
- NBMA network
Frame relay, ATM, Virtual circuti, Hub & spoke,
All neighbors are statically defined and unicast is used to communicate instead of multicast. DR selection-DR must have full connectivity to all neighbors.
- Point to multipoint
Very similar to NBMA but there is no DR election and messages will be multicasted.It treats its own virtual circuit as point to point(from HUB view)connection even though it's configured on multipoint interface.

http://www.youtube.com/watch?v=tSzJoxcep5o
----

Building OSPF neighbors and neighbor states



OSPF Areas, Router Types and LSAs

Reason to create normal area is for route summarization.
Unlike EIGRP, OSPF does not support route summarization anywhere in the network excpet at Area boundary routers(ABR) and Autonomous system boundary routers(ASBR).

STUB area blocks external route advertisements but still accept LSA type 3.
Totally stubby area blocks external route advertisements and ads from other areas.It only knows about routes in its area.

ABRs for Stub and Stubby areas inject default routes into these areas.
-----


LSA Type 1 - Router LSA. current networks that the router is connected to.
LSA Type 2 - DR advertising on behalf of a network. DR/BDR to other internal routers
LSA Type 3 - inter area routes injected by ABR. Routes from other areas
LSA Type 4 - Info about ASBR. Injected by ABR connected to other areas
LSA Type 5 - external LSA/routes injected by ASBR.
-------------
OSPF Link State database, Redistribution, Summarization

In stub area, default route is added automatically.

When redistributing Eigrp to ospf, must include 'subnets' command to redistribute classless subnets. If not, only classful networks are redistributed.
When redistributing to OSPF, E1 will add cost while E2 is a fixed cost in OSPF Areas.

To see OSPF link state database info -sh ip ospf database 

Summarization can be only done at/by ABR (hmm ASBR as well).
To summarize LSA Type 3 Area 1 route to inject to Area 0 at ABRarea 1 range 172.16.0.0 255.255.0.0
To summarize LSA Type Area 1 route to inject to Area 0 at ASBRsummary-address 172.18.0.0 255.255.0.0




Sunday, 9 February 2014

ASA inter interface and intra interface traffic

Higher security level interfaces can talk pass traffic to lower security interfaces by default but what if they are on the same security level? By default this is not permitted. Even if you define access-lists to permit the traffic, it is still denied.

Inter-interface traffic

Inter interface communication allows communications between different interfaces of the same security level.

ciscoasa(config)# same-security-traffic permit inter-interface
 
 
Intra-interface trafficIntra-interface permits flows of traffic that comes in on an interface and routed back out the same interface. This is denied by default. An example of this would be hair-pinning; Hub and Spoke VPN topologies utilize this methodology. 

ciscoasa(config)# same-security-traffic permit intra-interface
 
 
Redudant interface
active and standby interface. whichever interface comes first in config is activeinterface.

Friday, 7 February 2014

ACL, Routing, MPF, TCP advanced Options


ASA Access Control List

look at real IP address instead of global or mapped address
'Public Servers' option does NAT and access-list together
Normal mask in ACL; no wild card mask.

If there is global ACL, interace implicit deny is no longer effective. After interface ACL is checked and no match is found, traffic is checked against global ACL. If no match, then deny.
Choose 'Any' interface for Global ACL.

-------------

ASA Static route
The name of the interface we gonna use to reach that(advertised) network

-------------
clear config all -- clear running config
write erase -- clear startup config

Prioritization is always done outbound
Policing is inbound and outbound

Use TCP-map for TCP options
ASA performs ISN, Random sequence numbering
Use TCP-State Bypass option to ignore assymentric routing between source & destination
Use TCP Intercept for sync-flood attack. Set Half-formed session threshold limit, once it's above threshold, ASA intercept TCP Sync and respond on behalf of the server. If handshake is completed with the valid user, ASA send TCP 3 way handshake with the server.
ASA has a feature called TCP Sync cookies to handle DOS or Sync flood attack.

backtrack? for penetration testing

Layer 5-7 Advance application layer Inspection
policy-map type inspect ... match-all/match-any name

drop doesn't send a Reset packet. ASA does not allow any more packet for this session/connection.

Wednesday, 5 February 2014

NAT on Cisco ASA

TCP Ping on ASA can be used to test if the specified port is opened at destination IP
ping tcp x.x.x.x 22

For IOS 8.2 and older

Dynamic nat, pat, static nat, identity nat
nat (inside) 1 10.0.0.0 255.255.255.0 (creation of NAT group id 1 for 10./24 subnet coming in from inside)
global (outside) 1 192.168.1.51-192.168.1.100 (if group 1 traffic is going outside, map IP to )
global (outside) 1 192.168.1.101 (if group 1 traffic is going outside, map IP to 1.101; PAT )

static (dmz(real/incoming), outside(mapped/outgoing)) 192.168.1.175(mapped IP) 172.16.0.5(real IP)
static (dmz(real), inside(mapped)) 172.16.0.6(mapped IP) 172.16.0.6(original IP) – identity NAT

NAT 0 – do not translate if traffic matches the specified access list
Access-list NONAT permit ip (source net to dest net)
nat (inside) 0 access-list NONAT – 0 is reserved for NAT 0

-------------------------------------------------------------------------------------------------
http://www.tunnelsup.com/nat-for-cisco-asas-version-8-3/

NAT (IOS 8.3, 8.4 and newer)
The 3 sections of NAT
1.       Manual NAT
2.       Auto NAT
3.       Manual NAT (detailed)
If no NAT rule is hit for the traffic, traffic will be just forwarded as it is.

Auto/Object NAT (starts with object command)
Dynamic NAT
object network inside_10
   subnet 10.0.0.0 255.255.255.0
object network outside-pool
   range 192.168.1.51 192.168.1.100
object network inside_10
   nat dynamic outside-pool
Above config is for any 10.x address going through ASA (regardless of going to dmz, outside)
object network winxp-inside
 nat (inside,outside) static winxp-outside
object network inside_10
   nat (inside,any) dynamic outside-pool

Above config is for any 10.x address coming in from inside interface going through ASA (regardless of going to dmz, outside)
----------------------

Static NAT
nat (inside,outside) 1 source static <inside local> <inside global> destination static <outside local> <outside global>

Static NAT adds a rule for each direction (so total 2 NAT rules)
For static NAT, its xlate entry is always there in xlate table. So, can be used for server to be accessed by outside.

For dynamic NAT, tt only adds one rule.
---------------------

NOTES

http://www.tunnelsup.com/nat-for-cisco-asas-version-8-3/
The limitation that Auto NAT has is that it cannot take the destination into consideration when conducting it’s NAT. This also of course results in it not being able to alter the destination address either. To accomplish either of these tasks you must use “manual NAT”.
All of these terms are identical: Manual NAT, Twice NAT, Policy NAT, Reverse NAT. Don’t be confused by fancy mumbo jumbo.

http://www.cisco.com/c/en/us/td/docs/security/asa/asa83/asdm63/configuration_guide/config/nat_overview.html#wpxref64594

Main Differences Between Network Object NAT and Twice NAT

The main differences between these two NAT types are:
How you define the real address.
Network object NAT—You define NAT as a parameter for a network object; the network object definition itself provides the real address. This method lets you easily add NAT to network objects. The objects can also be used in other parts of your configuration, for example, for access rules or even in twice NAT rules.
Twice NAT—You identify a network object or network object group for both the real and mapped addresses. In this case, NAT is not a parameter of the network object; the network object or group is a parameter of the NAT configuration. The ability to use a network object group for the real address means that twice NAT is more scalable.
How source and destination NAT is implemented.
Network object NAT— Each rule can apply to either the source or destination of a packet. So two rules might be used, one for the source IP address, and one for the destination IP address. These two rules cannot be tied together to enforce a specific translation for a source/destination combination.
Twice NAT—A single rule translates both the source and destination. A matching packet only matches the one rule, and further rules are not checked. Even if you do not configure the optional destination address for twice NAT, a matching packet still only matches one twice NAT rule. The source and destination are tied together, so you can enforce different translations depending on the source/destination combination. For example, sourceA/destinationA can have a different translation than sourceA/destinationB.
Order of NAT Rules.
Network object NAT—Automatically ordered in the NAT table.
Twice NAT—Manually ordered in the NAT table (before or after network object NAT rules).
See the "NAT Rule Order" section for more information.

We recommend using network object NAT unless you need the extra features that twice NAT provides. Network object NAT is easier to configure, and might be more reliable for applications such as Voice over IP (VoIP). (For VoIP, because twice NAT is applicable only between two objects, you might see a failure in the translation of indirect addresses that do not belong to either of the objects.)