One way for creating a dsa key-pair greater than 1k bits using OpenSSL

If your familiar with  ssh , you will find out very quickly that dsa keys greater than 1k bits, are not readily obtainable with the standard ssh-keygen  utility under most platforms.


e.g The common error seen under most unix/linux OSes

I will show you a few quick ways with getting around this limitation. The complete process is quite simple & easy to execute.

Now b4 I start, I will not debate the  use of DSA over RSA or  any risks with regards dsa-key sizes & issues with random number generators attacks.  RSA is what I typically use, but some systems will only allow ssh access via dsa keys.


1st  you need to  generate a dsa parameter file . The bigger the key-size, means a longer the creation time for the dsa parameter file. But once created, the  keys generation is much quicker.

e.g creating a  dsa parameter file for 8k bit

 

Next, we will create an unencrypted  private-key. The dsaparam file will be called out during this creation process.

Next, we will create a pub-key by using the  private-key created earlier. 

Note: with the common unix ssh-keygen, it creates both the private and pub key in one operation. With openssl, we have to execute this operation 2x times ( once for the private-key and once for the public-key  creations )

Optionally if you have no need for a local dsaparam file, you can eliminate  "the 1st step" and generate the dsa-key directly.  The dsaparam once craft can be used for other key creation of the same size. But you can skip the local creation of this file by using the dsaparam with the -genkey switch. Just specify the out keyname and then craft  the public key off  this private-key. 

NOTE: Here I'm crafting a private-key in one go and checking the modulus ( fingerprint )

Lastly, if you fear the key-pair is corrupt, or just want to check that you have the matching priv/pub-key,  you can always validate by checking the modulus between the pairs.  It should match.

e.g  checking a dsa key pair modulus using openssl

And folks, that's how easily it is for crafting a  dsa-key pair &  with using openssl. So if you work on systems that requires dsa-keys and keysizes greater than 1024 bits, you can use  openssl for this function.

So to recap;

•  some times you will finding yourself needing a larger key ( dsa )  larger than 1024 bits
• ssh-keygen can craft dsa type keys but it's limited to  <1024 bit
•  generate the dsaparam file  and crafting your keys off this file is one method
•  the larger the bit size for the dsaparam file, will mean a longer creation time
•  build the dsa private-key
•  build the dsa public-key using material from the private-key
•  compare the  2 keys modulus if in doubt (  optional  )
•  always keep  the private-key safe ,  private & secured
•  DSA is used for signature and not encryption ( RSA does both  )
•  you don't have to generate the dsa parameter file unless you plan on building numerous key-pairs ( optional )
•  but if you working with large dsa keys and want to build numerous key it might be quicker overall to have a static dsaparam file
•  you can  also craft  the private-key directly without using a static dsaparam file

To learn more about DSA, please click the following wikipedia link

 http://en.wikipedia.org/wiki/Digital_Signature_Algorithm

Being bore one night, I built various dsaparam files and graph the total creation time off my  mid- 2013 MacBookAir 1.3 GHz Intel Core i5, running  MACOSX 10.10 and with 4gb ram

Enjoy;

( the  dsaparam file    creation times )

( the dsa private/pub  key creation time   e.g  openssl dsaparam -genkey -out <private keyname>   <bit size>  )

http://www.onlinecharttool.com/

note: A >16k+ bit private-key would probably take hours to complete. 
But as the above graph shows, the public-key is created from keying material from the private-key and is always quicker. In the above examples are keys up to 16K took  less than a 1sec for creation of the matching public-key.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  +  - )=
       o 
      /  \

L2 firewalls ( the good bad and ugly )

In this post we will talk about Layer2 ( aka  transparent  ) firewalls

A lot of networks deploy transparent-modes  firewalls for security within there network topology.  I will list some of the  PROs and CONs for this type of deployment


PRO

1: Very little changes are required to install into a existing network

Yes this is  the most common statement heard and it's true. You typically do not need to re-address or change any layer3 addressing. The firewall will be bump in the wire and requires a IN and OUT interface

2: The transparent firewall handle multicast traffic with ease

Will not a big positive since you still have the mcast client, routers and servers, but the passing of multicast packets is typically a new rule or turning on a feature for the allowance of multicast.  You don't have to worry about injecting  or participation of any multicast routing  protocols or modifying the multicast tree.

3: Doesn't require any advance routing skills

Will this should obvious with the name of "L2 firewall". You don't have the  added overhead of l3 protocols, flapping, and route changes or monitoring. This also reduce the knowledge of the  security engineer from knowing  how  to use OSPF, BGP or in cisco case EIGRP

4: The firewall is transparent so it's harder to detect.

Since the firewall is transparent, it will not be detected under a ping sweep, or by other means. It has no L3 address outside of the typical inside management or dedicated management port. These typically aren't exposed to the untrust internet or public facing. The firewall that have IDS/IPS will still inject  client-side reset or drop half-open sessions ( you should never send reset to any external untrust segments imho ). but all of this protection is done via ip_spoof'ing.

CON

1: Redundancy can be harder to achieve or relies on the use of just the STP  layer2 protocols

yes , you have very little to no redundancy  outside of a Spanning Tree protocol that's running.

2: Link failure, mistakes, bad hardware or wiring, can  interrupt your network ad cause loops or  wreck havoc.

Yes, improper design/practices, link failures, uni-directional paths , or STP issues can cause problems. If you run multiple vlans across your inside and outside interfaces, one vlan can tear up a firewall availability very badly , or cause systems wide issues.

3: Transparent firewall are almost 100% harder to run in a HA Active-Active mode

This is primarily due to STP and  multi-paths will be blocked. Since you have no layer3 routing protocols, you  are at the mercy of the layer2 paths. Or will need to look at other alternatives.

4: It is very hard to almost next too impossible to control QoS

You typically can not use traffic shaping or other QoS methods with transparent firewalls.

5: The NAT/PAT thing is pretty much a no-go

Yes you have no addressed interfaces, so you can't readily NAT things. Fortigates have made an exception to this rule, but for the most part you have limited Network Addressing capabilities. Even features like NAT66 or NAT46 is almost extinct in transparent firewall.

6:  Since the firewall maintain a layer2 forwarding database, it's suspect to the same  layer2 LAN attacks and  with mac-address flooding being the most critical.

Good news, this attack is next to impossible to pull off remotely & would require the attacker to be present locally on the wire.


So those are some of the PRO/CONS with the use of layer2 firewalls.


Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  *  * )=
       o 
      /  \

How to RSA sign a data file using openssl

Here's a quick and easy way  for  computing a RSA signature of a data file. You can do this to ensure the data has not been compromised.

1st craft a keypair . In this example,  I've created both a 1k and 2k bit rsa-key

2nd extract the public-key. This is required  by the recipient(s).

The public-key will be shared for "everybody", but  the private-key stays .... PRIVATE!. This is the basics for any PKI

Next,  we take our data file and create a hash. We will create the signature off this hash.

NOTE: The digest I used in this example, was sha1, but any digest could have been used. It's preferred to use sha1 or better. RIPEmd160 or  higher is a good choice but is not very common across OSes platforms.

Finally we can sign the hash using the private-keys (  1024 and 2048 bits  long )

Now you can share the signature , public key & obviously the data. On the receiver side you will need to validate the signature against the data using the pub-key

note: the options -sign and  reverse -verify are the 2 crucial steps in this process.

If any thing was modify from the original data file  ;

• the data was compromised
• it was corrupt
• or if the signature was compromised 

hence " The verification  would fail "

Here I took the file named  "file.blog" and used the unix "vi" to edit my original text file. I changed one character in this file. And then re-compute another hash using the same digest type and re-compared using the earlier pub-keys again.

In conclusion;

Now you can clearly see the hash doesn't compare for the data file. At this time you can compute that either the public-key was wrong,  data was compromised, the wrong digest was use, or the rsa.signatures where compromised. Basically the data can not be verified & validated from being tamper with.

NOTE: The  GNUPgp pretty much works the same way with regards to digital signatures creation, but simplifies most of this operations with a one-line single command. 

You will always need the pub-key regardless of method used ( GNUPgp or RSA ) . While using the above with openssl RSA, knowing the type of hash will be helpful.

NOTE: Openssl support messages digest types;

The signatures did not encrypt the original data  & nor did any part of the original data has changed.  With the RSA cryptographic hash functions, we are signing the hash for the datafile which is just as good as signing the data.

So we are able to build a fingerprint for our data and with the public-key we can now allow anybody to verify this fingerprint. This allows us to build and confirm the identify of the file that the sender is indeed the owner of the data file.


Just keep in mind a digital signature is a two part process "the signing and verification"
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  *  * )=
       o 
      /  \

Are firewall capable of handling BGP?

I  squirm  when I heard of a  security engineer asking; " can I run a BGP  in my  <insert a firewall model here> ".

There's no solid yes or no answer for this type of question. Too many factors comes into play such as;

• the size of the firewall
• expect size of the bgp table you plan to receive ( full, partial, default only, etc....)
• the number of ebgp peers
• the number of ibgp peers 
• how stable is your network
• how many prefixes are carried via your provider
• if more than 2 bgp-peers do you have any Equal Cost Multi-Path  concerns
• the number of other dynamic routing  protocols & neighbors ( eigrp/ibgp/rip/ospf/ etc )
• any  active UTM features that you may have enabled ( AS/AV, webcontent, DLP, etc....)
• existing  vpn traffic performance  or concern ( ipsec and/or ssl )
• do you have a considerable amount of  local generated traffic that will spike CPU ( ldap queries or other lookups )
• the size of your memory and cpu 
• are you running into critical high cpu/memory performance ( now )

Okay now you have an ideal of what you must considered before even thinking about  before enabling BGP on a enterprise firewall.

To give you an example for a typical day of BGP updates, I've graph one single day & the total number of updates, withdraws,  and path changes or other path attributes,  and total these over each hourly period.

 YMMV depending on the bgp peering your doing and the upstream provider and how stable there links are with other carriers

NOTE: So think very long and hard before enabling bgp within  your firewall. 

Most firewalls have way less available memory and uses more memory for other tasks and functions outside of dynamic routing.

They also typically have  a smaller CPU footprint for similar priced routed. So to get a equal performance,  and router like function, you will mostly likely need a bigger capacity memory/cpu model.

Routers are good one thing only ; "Routing"
Firewall are good at being a ; "Firewall"



for some good future references & for reviewing

http://bgp.he.net/report/netstats
http://www.cymru.com/BGP/prefix_delta.html
http://www.cymru.com/BGP/bgp_updates.html



Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  *  * )=
       o 
      /  \

Enforcing minimum bgp holdtime IOS/IOS-XR

The BGP neighbor-ship timers between 2 bgp-speakers does not need to match. What this means;
 " the bgp keepalives and holddown timers between 2 speakers could be totally different "

So the service-provider arena, you can protect your router from aggressive bgp  keepalive & hold down timers. I will demonstrate both IOS and IOS-XR configurations.

IOS
Bgp timers are defined per peer-group or by each neighbor. The timers are defined by setting the keepalive interval, hold-down and optional hold-down-minimum interval

e.g  by a specific bgp neighbor

router bgp 65001
    neighbor  1.1.1.1 timer 15 45 45

or by a  peer-group


router bgp 65001
 bgp log-neighbor-changes
 neighbor socpuppets peer-group
 neighbor socpuppets remote-as 65009
 neighbor socpuppets timers 30 90 90
 #neighbor  1.1.1.1 peer-group socpuppets

 
IOS-XR

Bgp timers are defined per neighbor-group, session-group or by each neighbor. The timers are defined via the keepalibe interval, hold-down and optional hold-down-minimum.

e.g using a session-group

router bgp 65002
!
session-group peer-iBGP2
  remote-as 65001
  timers 30 180 180
 !

or  by a  specific neighbor or neighbor-group

router bgp 65001
 neighbor 192.168.11.13
  timers 15 64 64
 !
!
router bgp 65001
 neighbor-group cust1-peers
  timers 45 90 90
 !
!
 

When you have peer that  doesn't meet the set  minum BGP hold-down  interval, you will see an error message similar to these below

( debug bgp IOS & log  )

( show log IOS-XR )

So if you encounter a BGP peer that just flat out refuses to establish during the initial open, check for any minimum BGP hold-down restrictions.

IMHO:  All SPs should set a minimum bgp hold down timer for  bgp sessions external to peers that they don't manage. Most do not but it's a good preventive practice.


Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  $  $ )=
       o 
      /  \

A unix like "top" within IOS-XE

Here we look at  the show proc cpu monitor command. This is an improvement over the straight show proc cpu, in that it allows for the realtime monitoring,  of the top process IDs

By execution of the "show proc cpu monitor" you will now witness the top  PIDs.

The default interval is 5secs, but  you can specify an interval from 5 - 3600 secs.

The use of this command is helpful when debugging high cpu-usage or for the monitor of PIDs that have high utilization or run times.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  $  $ )=
       o 
      /  \

IPv6 BGP prefixes usage

As we should know by now, the last of the ipv4 prefixes have been issued. The grow of the BGP ipv4 table has been holding stable at  around 500K prefixes  -+  for the last 6 months.

Here's a snapshot of a cogent link of mine & for the last 6months

The BGP ipv4 unicast table has probably reached the highest point that it will ever see for the time being.  It will probably also not shrink or be eliminated any time soon either. Ipv6  migrations and new networks are growing by the week/month/year.

If you have been monitoring the BGP table grow for over the last  20 years , you will be amazed on the growth of the table. The folks at potaroo have been collecting & providing this information for a few decades now.

http://bgp.potaroo.net/

Since the burst and ramp up of the late 90s and  after the millennium year, the  BGP table has been on a steady increase in size. This has made a direct impact with both  memory & cpu utilization required by a a router.

The ipv6  unicast BGP table is still relatively smaller , and will stay that way for some time. Here's one of my juniper router and a collective of end-of-month averages going back for the last 3 years for ipv6 prefixes.

note:  I'm missing data  for a few months that this router was down or the poller was down

The BGP ipv6 prefixes will always continue to grow. But no where as fast as our BGP table.


inet6.0: 19202 destinations, 234813 routes (19202 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

Ken Felix
Freelance Network/Security Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^    ^
 =( #  # )=
      @
      /   \