Per ip_address flow rate-limiting

Have you ever had bandwidth hogs that kills your internet? And you want to rate limit their traffic.Here's a quick simple means based on the client source address.

1st craft a acl to match the client(s) or network(s)

e.g ( sales dept and networks 10.1.{0..3}.0/24 )

ip access-list extended sales

 remark "whitelist address here if any"

 deny   ip 10.1.0.0 0.0.0.0 any

 permit  10.1.0.0 0.0.3.255

2nd, built flow record based on source-addr

flow record sales-profile1

 description "sales-profile"

 match ipv4 source address

!         

Now we make map-class using the match-all  & apply this to a policy-map;

class-map match-all limit-sales
  match access-group name  sales

  match flow record sales-profile1
!

!
!
policy-map police-traffic

 description "set QoS level based on depts"
 class limit-sales
    police 1000000 80000

And you apply the policer to your interface and your are done. The match-all is critical since we want to match the src_address and then the specific /32 sources in the flow record.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

Juniper SRX vpn automation tool

Here in this post, we will look at a VPN config tool. It's straight forward & simple to use if you don't want to learn how to build a vpn-ipsec tunnels.

In my former job, that was one lacking area;  "tools creation". We had a whole team allocated for tools creation, and it was pretty much sad. They stress standard tools for configuration, but they pretty much sucked at what they put together or the interface was convoluted or  badly written &  with no easy help/howto

The folks at juniper on the other hand, built a very well thought out tool, that's so simple to use. It straight forward, nice interface, and easy to follow that even a caveman can do it;

http://ahallm3.files.wordpress.com/2011/12/geico-caveman-airport.jpg

1st here a screen shot;

And the generated config details;

And finally the link to it all;

https://www.juniper.net/customers/support/configtools/vpnconfig.html


I want to highlight the following;

IMPORTANT NOTE: This tool does not perform error checking against your existing configuration.
If a misspelled or incorrect zone, interface or network address is specified, it may report errors when you copy the configuration onto your device

Just this morning, I rolled out 27 vpn-tunnels for a client of mine on a SRX3600b. I used this as my template but change the ipsec-policy from  the default standard to my own customize.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

ASA feature listing

In this post, I would like to share you a link that you can reference for  features in the cisco ASA software


http://www.cisco.com/en/US/docs/security/asa/roadmap/asa_new_features.html 


The above link  is a good location  to review  features per-asa  codesets.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

SSLVPN what happens if you don't specify a user-group as sslbpn type

In this quick and short blog, I wanted to share a issue where a user ( me ) had a sslvpn account,  but we forgot to apply the group as  a SSLVPN type.


Here's what happen upon numerous attempted logins , whikle  using the forti sslvpn client or browser;

Here's the  fwpoliciy that gave me my frustration, it looks good right ?

and the group;

Now here's the new fwpolicy with group that works;

So when  battling some things that doesn't work out, or  the outcome is not as expected; "take a deep breath and a few steps back and review  your config & use the diag commands".

Some times we missed the obvious,  by not looking policing our configurations  and/or we start swinging blindly at what we think is the problem.

I never thought to check  the group settings. The fix took only 2mins,  but I spent over 4+ hours checking my sslvpn client and re-issuing the username/password.

FWIW; Most problems with vpns, always comes down to a  mis-configuration.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

A /128 link-local address, " is this normal" ?

I was doing some checking up on a anyconnect vpnclient  that's using ipv6  and notice my adapter was assigning 2 link-local address.


look here ;

So let's look at the ASA configuration. 

1st let's see what the ASA used for the group-policy and tunnel-group for my user;
( show vpn-sessiondb anyconnect )

Now for my group-policy for my user;


group-policy DfltGrpPolicy attributes
 dns-server value 2001:4860:4860::8844 2001:4860:4860::8888
 vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value split-tun-ipsec
 default-domain value socpuppets.com
 user-authentication enable

and the tunnel-group;


tunnel-group DefaultWEBVPNGroup general-attributes
 address-pool VPNPool03

and the corresponding ipv4 pool;

show ip local pool VPNPool03

Begin           End             Mask            Free     Held     In use

192.168.150.65  192.168.150.96  255.255.255.0      31        0        1

Okay so is this normal? A /128 prefix on a dialup sslvpn client ?  and a group-policy that's not enabled for ipv6? And then why 2  link-local address?

Will I was trying to read up on  this rfc &  on ipv6 and ppp;

http://tools.ietf.org/html/rfc5072

Since the anyconnect virtual interface is enabled for ipv6, it uses this  unique link-local address. I'm guessing  after it attempts to establishing a PPP session, it crafts a link-local EUI48 address using the primary interface  mac_address. Remember, a ppp or serial interface, does not have a  mac_address. 

What I did find out, the  adapter will always generate a new link-local address upon establishment of connectivity;

( three new attempts gave me the following )

So if you take heed of the tentative scopeid, I believe it's using DAD ( duplicate address detection ) to ensure the  link-local-address is unique.

I will continue some more diagnostics and hopefully test this on a linux or windows anyconnect client soon.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

Restricting VPN access cisco ASA

In this blog, we will look at 2  various methods to restrict a vpn user  access via a simple ACL.

The cisco ASA allows for ACLs;  that are group specific or user specific. User specific ACLs, over-rides any  group specific entries.

Take the user "user1", we want to allow him access to all host via ssh,  but not host 10.99.90.17. So crafting a  user specific ACL, and applying that  to the username will accomplish this task.

Here's the config;


show run username user1
username user1 password xaI3t+nY5wjYQ2thSKJfoQ== nt-encrypted
username user1 attributes
 vpn-group-policy  MANAGEMENT
 vpn-filter value user1ac
 memberof MGT

So upon access and success authentication, the acl name  user1ac, will control his access.

show run access-list user1ac

access-list user1ac extended deny tcp any host 10.99.90.17 eq ssh 

access-list user1ac extended permit tcp any any eq ssh 

Okay so let's test this out;

(ssh to 10.99.90.17 );

airjordan:~ kfelix$ ssh 10.99.90.17

ssh: connect to host 10.99.90.17  port 22: Operation timed out

Now let's ssh to another host;

( ssh to host 10.99.90.1)

airjordan:~ kfelix$ 

airjordan:~ kfelix$ ssh 10.99.90.1

Password: 

CSW1_2960>

Okay now, let's apply the same thing, but now to the vpn-group directly;

group-policy  MANAGEMENT attributes

 dns-server value 8.8.4.4 8.8.8.8

 vpn-filter value user1ac

 vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless

 split-tunnel-policy tunnelspecified

 split-tunnel-network-list value split-tun-managementonly

 default-domain value socpuppets.com

 user-authentication enable

So now you have seen 2 way to restrict users. VPN groups allows you to  execute group specific  ACLs or user specific.

NOTE: If you make changes to the group-policy,  user-attribute or  the access-list, it will not take place till after the user has disconnect and re-authenticate.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

10 big differences between the Cisco ASA and the Fortinet Fortigate

In this post we will go over some of the difference between these 2 models of firewalls.

The cisco ASA and Fortinet Fortigate


1st  The licensing model 

ASA:
Cisco has a whole gamlet of licensing that can be applied, and it can be quite confusing

Licensing is not additve ( e.g if you have 25 vpn peers and want  25 more, you have to buy a 50 vpn peer license  and can't buy a 25 peer license )

fortinet:
only has 1 or 2 license  types ( vdom and forticlients )


2: blackhole routes

ASA:
You can't do this on a ASA.   Typically one relies on the next-hop device , or just ACL'ing off  the traffic

fortigate:
Supports blackhole routes via  null-interface

3 :Cisco Context vrs Fortigate VDOM

ASA:

• Cisco contexts are very restrictive, typically you are limited to  3-4 contexts ( except a ASA5505 no contexts available )  

• Context in ASA don't support any remote-access vpn, and until recently no dynamic routing protocols. And then in multi context mode, your limited to just OSPF or EIGRP only (ipv4) and no dynamic routing protocols for ipv6

• Also the context configuration files management, is awkward and confusing,  the first time that you deploy the configurations files

•  Just the pure enabling of  the multi mode context  feature,  requires a reboot

fortigate:

• Supports a minimum of 10 vdom ( virtual domains )

• Vdom supports all open routing protocols  ( rip,ospf,bgp,is-is) , and not as restrictive. 

• No reboot required for enabling vdoms

• by default all interfaces are part of the vdom root, so enabling  vdom support does not drop any interfaces/policies or configurations if your going from a vdom-less to vdom-concept

• one big configuration file, with no separations for the unique vdoms

4: IPv6 support

  ASA: 
  getting better, but ipv6 support is still quite new  in the ASA lineup


  fortigate: 
  been ipv6 enabled for at least 6+ years now, but we still don't have OSPFv3 authentication :(

5: Fwpolicies

ASA: 
Uses  a ACL approach for the ingress/egress interface and no other direction is requires
Cisco also eliminates duplicate  by disallowing the entry of  duplicate acl lines within a single access-list

fortigate:
Policies are built between zones to zone or interface to interface similar to juniper. Duplicates can be installed with no warning, causing issues when auditing policies


6: Intrusion detection

ASA:

• Supports for custom rules, but not very user friendly

• auto-updates are not as easy to allow

• limited number of rules

• requires some IDS engine or card and managed separately & possible license restrictions

fortigate:

• support for custom rules

• auto-updates pretty much every day

• IDS protection is part of the appliance hardware ( no add-on card/module, no special licensing or restrictions )

• Fortinet fortiguard is quite awesome and very mature and advance

7: remote-managemnt

Both unit allows for common management protocols with the fortinet allowing you to changing ssh/telnet ports and restricting access to a user. It also has a fail-login delay block, to protect from brute-force or mis-used from failed logins

8: flow data exportation

ASA:
netflow v9 , but it's not similar to netflow v9 that most  routers exports, could cause issues with certain collectors

fortigate:
sflow only ( no netflow support )


9: VPN restrictions

ASA:  
Numerous license models, this  limits the number of peers regardless of type;  clientless vrs client sslvpn , ipsec,l2tp-ipsec

fortigate: 
VPN numbers are limited only by the hardware chassis make


10: Traffic Inspection & processing

ASA:
Only traffic moving from a  lower to higher security-level , needs an acl entry ( security-level concept )

fortigate:

All traffic passing between interfaces on a fortigate, needs a fwpolicy.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \