When you look down the list of supported Linux distributions officially supported by RSA there are numerous omissions.  Fear not for while they may not be officially supported it doesn't mean you can't make 2FA work.  For this example we used debian, PAM and RSA via radius to effect 2FA for SSH access.  The end result was even more pleasing as we managed to get granularity across users and services.  Read on....


Firstly I would like to acknowledge Jacob Appelbaum for his excellent article which is a good starting point for this endeavor.

Radius to RSA AM

This article works well and essentially gives us the following:

  • Installation of required libraries
  • Base configuration of PAM to apply to all users and effected services

Note that this will use new radius and accounting so allow ports UDP 1842 and UDP 1840 from the source Linux hosts to your RSA AM deployment.

Deploy by User

Note this first method via blanking out passwords is a bit of a quick dodge and useful for testing purposes, I will publish another method shortly.

The requirement to have some users using 2FA and others not is not uncommon. So an easy way to do this is to blank out passwords for those users who will be using 2FA via RSA such as privileged accounts.  When combined with the following configuration files the effect is to require 2FA for those with no local password or password for those who have one.


# /etc/pam.d/common-auth - authentication settings common to all
# services
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
#auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds

auth      sufficient         pam_unix.so nullok_secure
auth      required          pam_radius_auth.so debug
account   required       pam_radius_auth.so
session   required        pam_radius_auth.so

# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around

# Generic unix uth services below
#auth   required   pam_unix.so nullok_secure

# Automatic home directory creation

session   required pam_mkhomedir.so skel=/etc/skel/ umask=0022 silent

# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config


#  pam_radius_auth configuration file.  Copy to: /etc/raddb/server
#  For proper security, this file SHOULD have permissions 0600,
#  that is readable by root, and NO ONE else.  If anyone other than
#  root can read this file, then they can spoof responses from the server!
#  There are 3 fields per line in this file.  There may be multiple
#  lines.  Blank lines or lines beginning with '#' are treated as
#  comments, and are ignored.  The fields are:
#  server[:port] secret [timeout]
#  the port name or number is optional.  The default port name is
#  "radius", and is looked up from /etc/services The timeout field is
#  optional.  The default timeout is 3 seconds.
#  If multiple RADIUS server lines exist, they are tried in order.  The
#  first server to return success or failure causes the module to return
#  success or failure.  Only if a server fails to response is it skipped,
#  and the next server in turn is used.
#  The timeout field controls how many seconds the module waits before
#  deciding that the server has failed to respond.
# server[:port] shared_secret      timeout (s)          secret                                         1
x.y.z.w              sharedsecretpassword1         10
a.b.c.d              sharedsecretpassword2         10

# having localhost in your radius configuration is a Good Thing.
# See the INSTALL file for pam.conf hints.

Deploy by Service

This is well documented in a number of areas so I will refer to one of them below as a good source for creating the correct files to authenticate for a specific service.

PAM Primer

Hope this is of value...


Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter


You have created one or more CSR (certificate signing requests), not all can be fulfilled for numerous reasons and you want to clean them up...

Before You Begin

Please take a backup or take a snapshot prior to any task.


  1. SSH to the Primary AM appliance with PuTTy, logon with the Operating System Account, typically called rsaadmin.

The keytool is located in /opt/rsa/am/appserver/jdk/bin

The .jks keystores are located in /opt/rsa/am/server/security

The RSA Utility is located in /opt/rsa/am/utils

  1. Get the SSL Server Identity Cert Keystore File Password – you need Operations Console OCAdmin credentials to do this

/opt/rsa/am/utils/rsautil manage-secrets -a list


You have to highlight the whole password to copy and paste, and delete the spaces, so you get this MA8eMBMiDSWz6ApxEDLC2oeKWBhtZh

Obviously your file password will be different.

 3. Verify the Alias for your private key Next go to the security directory so you can access the Virtual Host keystores, which have the Virtual Host Key – seen in the Operations Console.


cd /opt/rsa/am/server/security/

 This directory has two Virtual Host Keystores, one called vh-identity.jks which has the active Key/Cert, and vh-inactive.jks

Make a copy of those files.

Sudo cp vh-identity.jks vh-identity.jks.ORIG

Sudo cp vh-inactive.jks vh-inactive.jks.ORIG

 Here is the command to list the existing certificates.

/opt/rsa/am/appserver/jdk/jre/bin/keytool -list -keystore /opt/rsa/am/server/security/vh-identity.jks


/opt/rsa/am/appserver/jdk/jre/bin/keytool -list-keystore /opt/rsa/am/server/security/vh-inactive.jks


Revert back to the self-signed certificate and run the commands above again to see the alias “your-alias” in vh-inactive.jks file

Delete the “your-alias” alias.

/opt/rsa/am/appserver/jdk/jre/bin/keytool -delete -alias “your-alias” -keystore /opt/rsa/am/server/security/vh-inactive.jks

Go to the RSA Authentication Manager 8.1 Primary Operations Console -> Deployment Configuration ->Certificates -> Virtual Host Certificate Management and the certificate is removed

  1. Import the root certificate first and then CA certificate in Operations Console.


Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter

Here is one from the history books. How to factory reset a Nortel 5510/5520 switch when you don't have IP or serial access to the device.  This situation does occur (forgotten password on device manager, web access or console access for example).

The process is as follows:

  1. Press and hold the UI button for 3 seconds, the unit will be in configuration mode and the status light will change to a blinking green status.
  2. Press the UI button 5 times, the base led and up and down leds will now be blinking amber and in unison
  3. Press the UI button and hold for 3 seconds to confirm the command.
  4. The in use IP address will now be and you can access it via  device manager, a browser or via the serial port. Best to check this IP with wireshark as I am running from memory, but you can always use a console cable to set via the serial port at this point.

Since we are on topic here are some other options for a factory reset on the 5500 range (and other Nortel switches)

Via the console port follow these steps:

  1. Connect to the console port of the switch (9600,8,N,1) with putty
  2. Reboot the switch.
  3. When the first line of the diagnostics tests is displayed, press CTRL-C. The system then displays a menu.
  4. Select option “i” to factory default the switch.
  5. Select option “a” to run the agent code.

Upon boot up, the switch will be in a factory default configuration.

Via TFTP try this:


  • You still have SNMP-access
  • The software agent allows downloading the ASCII config of the switch to TFTP
  1. With device manager instruct the switch to put the ASCII config on your TFTP
  2. Edit the line for the telnet/console password en set it to ‘none’
  3. Save the config file
  4. Upload it to the switch
  5. Result will be that you can login without password and be able to set a new password.

Attached is a link to the Nortel 5500 configuration reference guide..

5500 Series Config Guide



Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter

So the marketing says that you can run an RSA 8.x Appliance on VMWare and that the various facilities providing are supported.  This is indeed true however there are a few things to watch for specifically when creating a clone of an appliance.

RSA Customer Support does advise against creating a clone as it can impact the authentication manager instance with regards to the fingerprint and can cause one of the services to fail due to the result of the MAC address changing.

However if cloning the appliance is required then here are two things to check on:

Set the MAC Address

An RSA knowledge article (ref#00030773) https://knowledge.rsasecurity.com mentions that should a clone be performed (and before starting the clone image), the administrator would need to modify the .VMX file and set the MAC address to static, forcing the same MAC address to be used as the original virtual image. VMware have a knowledge article covering this topic at URL http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=507. Having made the change the clone can be started and eth0 is maintained as before.

  1. Stop the primary instance, make the change to the .VMX file and change the MAC address to be as the original virtual image.
  2. The correct MAC address to use will be either in your documentation (I hope), or if the appliance has changed to using eth1 it ought to be using the same MAC address on eth1 as it did on eth0.
  3. Check replication status with replicas.

Note this process can be done retrospectively it the appliance is not running on eth0 due to the cloning process.

Reset the Fingerprint

  1. Login via SSH as rsaadmin
  2. Run /opt/rsa/am/utils> ./rsautil manage-secrets -a recover
  3. Enter your credentials as prompted'
  4. You should get back "Machine fingerprint restored successfully."


Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter

So you have diligently applied a new certificate to your RSA AM deployment.  If you don't watch the expiry here is what happens when it expires.

The first thing you will notice is that you loose access to the Operations Console.  This can be confirmed by checking /opt/rsa/am/server/log/AdminWrapperServer.log


You will get some thing like this:

INFO | jvm 3 | main | 2016/04/22 01:11:19 | Signature:
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0000: 6f 84 1e 6d 68 b7 dc ac b5 a9 8f d5 01 ec 5c 20 [o..mh.........\ ]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0010: 81 4e 50 7d 47 71 cc f4 ee e5 03 b0 81 d4 3e 70 [.NP}Gq........>p]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0020: 96 e6 90 da bd d2 6f 29 39 c3 1b c7 b2 06 03 68 [......o)9......h]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0030: f4 b7 94 e0 96 2c 40 1d 4d a6 54 45 e9 af d1 02 [.....,@.M.TE....]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0040: d8 76 b6 96 1e 44 3b 81 20 49 5a a0 1a cd d2 69 [.v...D;. IZ....i]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0050: 3a 86 48 8b 51 03 a8 8f 5f 71 21 51 60 72 b2 2a [:.H.Q..._q!Q`r.*]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0060: 13 6f 59 01 27 3f bd 5b ce a8 c9 fb bb da 1d cc [.oY.'?.[........]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0070: 74 29 26 3e 9d 02 45 b8 40 6b e4 2e 49 df 68 82 [t)&>..E.@k..I.h.]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0080: dd d5 4f f6 7f 6f 5c bd bf 29 75 2e f0 a8 dd 56 [..O..o\..)u....V]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 0090: 50 b8 9b 34 40 ed 61 12 43 50 f5 03 14 4c c3 c6 [P..4@.a.CP...L..]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 00a0: 61 b5 05 ca d6 72 3a c9 1e 93 f9 7a 52 db ef 48 [a....r:....zR..H]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 00b0: 27 9a e8 e6 3c a8 aa 9b 5b 4c 43 af e8 08 b4 3c ['...<...[LC....<]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 00c0: b3 41 25 c4 97 99 35 5f c2 47 36 45 15 13 e8 8e [.A%...5_.G6E....]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 00d0: e7 17 9d 2a d3 0b 1b 03 fe 91 ab 31 51 bb a8 5d [...*.......1Q..]]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 00e0: 79 f6 5c 7d 2e 47 0e b8 a2 9a 55 84 7b 47 8c 49 [y.\}.G....U.{G.I]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | 00f0: 7d d6 e2 28 0b 25 3a e4 df 41 47 cf 7d f6 fb ac [}..(.%:..AG.}...]
INFO | jvm 3 | main | 2016/04/22 01:11:19 |
INFO | jvm 3 | main | 2016/04/22 01:11:19 | ]
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at weblogic.security.utils.SSLContextManager.fail(SSLContextManager.java:703)
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at weblogic.security.utils.SSLContextManager.checkIdentity(SSLContextManager.java:523)
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at weblogic.security.utils.SSLContextManager.createServerSSLContext(SSLContextManager.java :408)
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at weblogic.security.utils.SSLContextManager.getChannelSSLContext(SSLContextManager.java:3 56)
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at weblogic.security.utils.SSLContextManager.getSSLEngineFactory(SSLContextManager.java:32 5)
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at weblogic.server.channels.DynamicJSSEListenThread.<init>(DynamicJSSEListenThread.java:50 )
INFO | jvm 3 | main | 2016/04/22 01:11:19 | ... 6 more
INFO | jvm 3 | main | 2016/04/22 01:11:19 | Caused by: java.security.cert.CertificateExpiredException: Checked date: Fri Apr 22 01:11:19 N ZST 2016 is after Certificate notAfter date: Thu Mar 10 19:09:50 NZDT 2016
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at com.rsa.cryptoj.c.pk.a(Unknown Source)
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at com.rsa.cryptoj.c.pj.checkValidity(Unknown Source)
INFO | jvm 3 | main | 2016/04/22 01:11:19 | at weblogic.security.utils.SSLContextManager.checkIdentity(SSLContextManager.java:508)
INFO | jvm 3 | main | 2016/04/22 01:11:19 | ... 10 more
INFO | jvm 3 | main | 2016/04/22 01:11:19 |
INFO | jvm 3 | main | 2016/04/22 01:11:19 | >
INFO | jvm 3 | main | 2016/04/22 01:11:19 | <Apr 22, 2016 1:11:19 AM NZST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED.>
INFO | jvm 3 | main | 2016/04/22 01:11:19 | <Apr 22, 2016 1:11:19 AM NZST> <Error> <WebLogicServer> <BEA-000383> <A critical service faile d. The server will shut itself down.>
INFO | jvm 3 | main | 2016/04/22 01:11:19 | <Apr 22, 2016 1:11:19 AM NZST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN.>
STATUS | wrapper | main | 2016/04/22 01:11:21 | <-- Wrapper Stopped

The key part is that the server state is down.

Of course you need access to the Operations Console to re mediate the problem with the certificate.

So using good old putty, ssh into your RSA AM Primary and do the following

Login as the rsaadmin user with the current operating system password.
Navigate to /opt/rsa/am/utils.
Run the following command to change the console certificate from the third-party certificate to the original certificate:
./rsautil reset-server-cert -u <Operations Console administrative user> -p <Operations Console administrative password>
After reverting the default certificate, navigate to /opt/rsa/am/server and start the Authentication Manager services:
./rsaserv start all

After this the expired certificate will be "inactive" and you can go about generating a new CSR and applying a new certificate.



Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter

Well this was a fun task.  Rolling a Checkpoint F/W R77.30 out connected to a PPPOE circuit.

After configuring the PPPOE interface and binding it to a physical interface I plugged in and the circuit came up. I applied a basic best practice rule base and was able to ping IP addresses like as expected and therefore thought we were good to go.  Boy was I wrong.  Turns out DNS lookups were not working at all, no drops shown in the log and the DNS servers were set right.

I did some research and it turns out PPPOE can't be accelerated and it SecureXL, fair enough disable SecureXL and reboot, all should be well. Wrong again - some more digging and I noticed that

fw ctl debug -m fw + drop

Shows drops.... great so now we have an MTU problem, so I checked the MTU of the PPPOE circuit (1492) and confirmed this by running from a workstation:

ping -f - l 1464 www.google.com

Add 28 bytes for the packet overhead to 1464 = 1492.

Right so I set the MTU on the F/W interfaces and on select desktops using the commands

Find the correct interface and check mtu:

netsh interface ipv4 show subinterface

Set the new mtu:

netsh interface ipv4 set subinterface "Ethernet" mtu=1492 state=pesistent

Hey presto things started to work although I did have a syn-ack issue during this process as well causing me to turn off "drop out of state TCP/ICMP packets" in global properties-->stateful inspection.  I believe however this was a timing issue and may now be ok post MTU remediation.  I wll revisit this

This is all very well but how did the el-cheapo device the Checkpoint replaced ever work with the MTu set to 1500 on workstations?  Turns out it had a great rule base allowing any-->any-->all-->accept. Now as noted I had set up a basic rule base using best practices including a final drop rule and stealth the firewall rule.

I then discovered after reading a lot of articles (and this is summerised significantly below), that when a device attempts to transmit over an encapsulated circuit like PPPOE, PPP & PPTP with a larger MTU, the upstream device will reject it but also will respond with an ICMP packet to attempt to renegotiate a smaller MTU (MSS).  My rule base blocked such traffic.  So adding a simple allow ICMP rule in fixes it - of course if I have in global properties allow ICMP before then this would work too.


This post is in draft - I wanted to knock out the basics while it was fresh in my head.  I will work on it to flesh it out in time.

Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter

If you wish to check  the NTP status on RSA AM 8.1 you can run a useful Linux utility as follows:

Log into the appliance using SSH

ntpq -p

However, this utility runs based on the configuration found in /etc/ntp.conf.

Now due to IPV6 support being partially on in RSA AM 8.1, and for other reasons in order to make it work properly add the following lines to the ntp.conf

restrict -6 ::1

restrict ::1

Then you simply restart ntp as follows:

service ntp restart

...and your query to the configured ntp server will return information regarding the server and offsets. The output will look something like this:

remote           refid                 st t   when poll reach   delay   offset      jitter
w.x.y.z             .LOCL.              1 u   57       64  377        0.313  245903.   7.716
a.b.c.d    2 u   56       64  377        0.536  245894.   6.630


If you have set RSA AM to sync time with the VMWare host then this utility will not properly query the VMWare host unless you add its IP address of the VMHost into the /etc/ntp.conf as a time server.

Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter

Welcome back to a new year.  Encountered a painful little problem worthy of a tech note during a firewall install this month.

The Checkpoint Firewall was version R77.20 (then upgraded to R77.30 of course) and during the install of smartconsole I got:

smartconsole register dlls

Naturally on launching smartdashboard it didn't work and I  got:

smartconsole msvcr100

So after a lot of research on the Internet and messing around comparing machines and installed packages, it turns out you need to load the C++ redistributable packages (x86) for smartconsole to work prior to install.

However there is a gotcha (of course), it is version specific as follows:

  • Smartconsole R77.20 requires C++ redistributable 2010 (x86)
  • Smartconsole R77.30 requires C++ redistributable 2013 (x86)

So install the appropriate packages from Microsoft then install the version of smartconsole you require. Hope this helps...

Downoad Links:

C++ Redistributable 2010 x86

C++ Redistributable 2013 x86



Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter

This post covers a few random aspects of security issues in RSA Authentication Manager V8.1

WebTier SSLv3

Out of the box the WebTier supports RC4 non block ciphers which are associated with SSL3. SSL3 is obviously subject to numerous vulnerabilities such as POODLE.  To disable ensure the WebTier is functioning and communicating with the RSA AM then on the WebTier host navigate to;

C:\Program Files\RSA Security\RSA Authentication Manager Webtier\server\config


/opt/RSA Security/RSA Authentication Manager Webtier/server/config

Backup the config file found there.  Edit the file and remove the line:



Restart the RSA services to complete on the WebTier server.

Test your cert and support using a tool like https://www.ssllabs.com/ssltest/

Following this change the WebTier should only support TLS1.2

Jan 2016: So further to this issue a tech note has been published on RSA SCOL addressing the issue which I include below:

AM 8.1 SP1 P2 How to Disable SSLv3 on Web Tier (Windows 2008R2

ShellShock CVE-2014-6271

To ensure you are protected against ShellShock on RSA Authentication Manager apply patch 5 for RSA V8.1.

To test if you are vulnerable write a little script like the following


env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Issue the following commands to enable the script to run

chmod 777 test4shellshock.sh

then run it


It will respond appropriately.. As a general good practice SSH access should not be enabled on RSA Appliances until access to the operating system is required.  This  behaviour can be controlled in the Operations Console.

For more information see the RSA article 000014565 on Secure Care Online

GHOST CVE-2015-0235 

On January 27, 2015, a vulnerability was publicly announced in the Linux glibc library. The researchers at Qualys discovered a heap-based buffer overflow (also known as "GHOST" vulnerability) in glibc's __nss_hostname_digits_dots() function, which is used by the gethostbyname() and gethostbyname2() glibc function calls. A remote attacker able to make an application call either of these functions could potentially use this flaw to execute arbitrary code with the permissions of the user running the application.


The RSA Appliance adds another layer of handling of these functions in Java classes internally by not allowing host names over 256 bytes.  Hence this particular vulnerability is not exploitable.

As a general process for this issue you can use

ldd --version

to check your version of glibc This should allow you to identify that your version is higher than 2.17 (not vulnerable) or between 2 and 2.17 (vulnerable).

See RSA articles 000029506 & 000029576 on Secure Care Online

Click to share
Share on Google+Share on TumblrShare on FacebookShare on LinkedInEmail this to someonePrint this pageTweet about this on Twitter