secure

ProCurve – Secure Management

Managing networking components is possible via a web interface or via a command-line interface. It doesn’t matter which method you prefer, but it does matter that the connection should be secure. If you use telnet (cli) or http (web interface) the management traffic is send clear-text across the network.

I still notice that a lot of people use insecure communiction methods. It is preferred to use ssh (cli) or https (web interface) to manage your components. The commands below can be used with HP ProCurve components to enable ssh and https and disable telnet and http management protocols.(The key size depends on the type of component and firmware version used)

CLI

switch01(config)# crypto key generate ssh rsa bits 2048
switch01(config)# ip ssh
switch01(config)# no telnet-server

Web Interface

switch01(config)# crypto key generate cert rsa <1024|2048>
switch01(config)# crypto host-cert generate self-signed
Validity start date [02/16/2015]:
Validity end date   [02/16/2016]: 09/23/2320
Common name          [10.10.1.99]: switch01.booches.local
Organizational unit [Dept Name]: ICT
Organization      [Company Name]: Booches
City or location          [City]: Bocholtz
State name               [State]: Limburg
Country code                [US]: NL
switch01(config)# web-management ssl
switch01(config)# no web-management plaintext

Next to using secure protocols, it is preferred to create unique credentials for every administrator. One way to create unique credentials is by configuring RADIUS / TACACS authentication. A common way is you configure RADIUS between the switch and the Active Directory. The following commands can be used to configure RADIUS on HP ProCurve switches.

switch01(config)# radius-server host 10.10.100.1 key <shared key>
switch01(config)# radius-server host 10.10.100.2 key <shared key>
switch01(config)# aaa authentication web login radius local
switch01(config)# aaa authentication web enable radius local
switch01(config)# aaa authentication ssh login radius local
switch01(config)# aaa authentication ssh enable radius local
switch01(config)# aaa authentication login privilege-mode

Citrix Secure Gateway via https-only

Configuring a Citrix Secure Gateway (CSG) server is simple, but provides a powerful solution to access resource from remote locations. CSG is an application installed on a DMZ server. Mostly I also configure the Citrix WebInterface on the same server. The CSG instance listens on TCP/443 and the WI instance listens on TCP/80. To improve the user friendliness of the solution you have to configure a redirect. This redirect changes the protocol from the unsecure http protocol to the secure https protocol. It also redirect the user to the correct login portal, like redirecting http://portal.booches.nl to https://portal.booches.nl/Citrix/XenApp/auth/login.aspx. The HTML code for the redirect is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Refresh" content="1 ;URL=https://portal.booches.nl/Citrix/XenApp/auth/login.aspx" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>Citrix Secure Gateway-Booches</title>
</head>
<body>
<p>
        Please click <a href=’https://portal.booches.nl/Citrix/XenApp/auth/login.aspx’>here</a> if you are not automatically redirected.
</p>
</body>
</html>

This configuration requires you to allow the http and https protocols from the internet to the server. When accessing the login page the remote user connects to the CSG instance over https and the CSG instance connects to the WI instance over http. A customer noticed that a user could change the login URL from https to the unsecure http. This means that the remote user connects directly to the WI instance and bypasses the CSG instance. This behavior is not allowed and also unsecure, because username and password are sent clear text over the internet.

I wanted to change this behavior so the user isn’t allowed to connect over http to the login page, but the default redirect from http to https should still be allowed. I looked at solutions on the internet to redirect all IIS traffic from http to https, but this introduced some problems and errors. In the end I simply configured IP Address and Domain Restriction on the /Citrix/XenApp virtual directory. Only the CSG instance needs to connect to the WI instance, so the IP restrictions only allow the localhost and the server IP address. I also changed the default behavior to deny all unspecified clients.

Citrix Access Gateway: duplicate STA ID

I received complains from a customers who wasn’t able to add two new Citrix servers to his Citrix Access Gateway configuration. He could successfully add the first Citrix server, but he couldn’t add the second Citrix server, because the first was overwritten by the second. I looked at the problem and noticed that both Citrix server were using the same STA Identifier.

After asking some question about the installation of the Citrix server, I discovered that the second Citrix server was a clone of the fist Citrix server. That is why both servers have the same STA Identifier. The STA ID from a Citrix server can be changed by altering the file CtxSta.config. By default a Citrix server has two CtxSta.config files, located at the following destinations (default installation):

C:\Program Files\Citrix\System32;
C:\Inetpub\Scripts;

I had to change the STA ID in the C:\Inetpub\Scripts directory, because IIS was used to share port 80 on the server. The CtxSta.config file contains a UID, like the example below:

[GlobalConfig]

UID=STAA3D2D2970C9C

TicketVersion=10

TicketTimeout=100000

MaxTickets=100000

LogLevel=0

MaxLogCount=10

MaxLogSize=20

LogDir=c:\inetpub\Scripts\

; Allowed Client IP addresses
; To change, substitute * with client IP addresses. Use ";" to seperate IP addresses/address ranges.
; To specify a range of IPs always use StartIP-EndIP.
; For example, AllowedClientIPList=192.168.1.1;10.8.1.12-10.8.1.18;123.1.2.3

AllowedClientIPList=*

; SSL only mode
; If set to on, only requests sent through HTTPS are accepted
SSLOnly=off

I changed the UID on the second server and restarted IIS. I tried to add the Citrix server to the Citrix Access Gateway, which is now possible with the new unique STA ID. The last step is adding the second Citrix server to the Citrix WebInterface (server farm & STA ID).

Cisco banners with SSH

When configuring a Cisco device I always configure some kind of banner, which is displayed when logging in. This banner contains some information, like security warnings and general information. There are different kind of banners.

exec: display a banner before displaying the enable prompt;
login: display a banner before the password login prompt when accessing the security appliance using Telnet;
motd: display a message-of-the-day banner when you first connect;

I was used to configuring a banner login with different variables, like shown below:

banner login ^
You have entered device $(hostname).$(domain) at line $(line) $(line-desc)
^C

This works fine when connecting with Telnet to the device, but this doesn’t work when using SSH. For security reason, I always use SSH to connect to devices, but I didn’t notice the “corrupt” banner since recently.

Banner login doesn’t support SSH:

“When accessing the security appliance through Telnet or SSH, the session closes if there is not enough system memory available to process the banner messages or if a TCP write error occurs. Only the exec and motd banners support access to the security appliance through SSH. The login banner does not support SSH.”

The example below shows the output from a banner motd and a banner login when connecting via SSH.

ssh -l admin 10.10.66.12

You have entered device $(hostname).$(domain) at line $(line) $(line-desc)

Password:

You have entered device C877.booches.nl at line 1
C877#

The first banner is de banner login and the second is the banner motd. So when using SSH to connect to a device, it is better to use a banner motd or a banner exec.

Juniper SA & Terminal Server with Novell Client SSO

Normally configuring SSO on a Terminal Server in conjunction with a Juniper SA isn’t that hard. On the Juniper you pass the user credentials to the Terminal Server. On a normal Terminal Server you have to check the following:

Disable Always prompt for password under:

Terminal Services Configuration –> Connections –> Properties of RDP-tcp –> Tabblad Logon Settings

On a Terminal Server, which is member of a Windows Domain, you have to check the following Group policy:

Disable Always prompt client for password upon connection under:

Computer Configuration –> Administrative Templates –> Windows Components –> Terminal Services –> Encryption and Security –> Policy “Always prompt client for password upon connection”

Now I had to configure Single Sign On to a Terminal Server where the Novell Client is installed. As soon as I pushed the user credentials to the Terminal Server, I noticed that the RDP session tries to logon as Workstation only. I found a nice thread on the Novell website to Enable TSClientAutoAdminLogon.

I added the following two registry keys to the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login 
Value Type=REG_SZ, Name=TSClientAutoAdminLogon, Data=1 
Value Type=REG_SZ, Name=DefaultLoginProfile, Data=Default

I am able to logon to the Terminal Server using SSO after adding both registry keys to the registry. All registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login are displayed in the picture below.