Security Archives » Page 3 of 7 » Musings of an IT Implementor

Secure ReadyNAS Duo (v1) ADMIN Share

If you have a ReadyNAS Duo and you’re happy with your setup and are now sharing your shares out through your router over the internet, you need to be aware that any old hacker can try and access your ADMIN share (e.g. https://<your-readynas>/admin).

I use mine in exactly that way but don’t want Mr A.Hacker trying out a myriad of passwords on my ADMIN share just because my public shares have “Netgear ReadyNAS” plastered all over the front page (a tip for another day I feel).

Instead, if you’re comfortable using SSH, (there is a way to do this by using the FrontView config backup, edit the file and put back in place) then you can edit your Apache httpd.conf configuration file so that access to the ADMIN share is restricted to a host or hosts on your local home network only.

Steps:

1, Log into your readynas via SSH as root.
2, Backup your old config file:

# cp -p /etc/frontview/apache/httpd.conf  /etc/frontview/apache/httpd.conf.bak

3, Use ‘vi’ to edit the httpd.conf:

# vi /etc/frontview/apache/httpd.conf

4, Change the sections as follows:

<Location /admin> 
DirectoryIndex index.html
Options ExecCGI
AuthType Basic
AuthName “Control Panel”
require user admin
# block external admin.
Order Deny,Allow
Deny from all
Allow from 192.168 <<< INSERT YOUR LOCAL NETWORK IP ADDRESS SUBNET HERE
</Location>

and

<Location /get_handler> 
SetHandler perl-script 
PerlHandler get_handler 
PerlSendHeader On 
Options ExecCGI 
# Order allow,deny 
# Allow from all 
AuthType Basic 
AuthName “Control Panel”
require user admin 
# block external admin.
Order Deny,Allow 
Deny from all 
Allow from 192.168 <<< INSERT YOUR LOCAL NETWORK IP ADDRESS SUBNET HERE
</Location>

plus

<Location /dir_list>
AuthType Basic
AuthName “Control Panel”
require user admin
Options ExecCGI
#Allow from all
Order Deny,Allow
Deny from all
Allow from 192.168 <<<– Insert your subnet here.
</Location>

5, Save the changes with:

6, Restart your readynas:

# shutdown -r now

7, Test from your local network that you can access the ADMIN share:

https://<readynas IP>/admin

8, Test from the internet that you can’t access the ADMIN share:

https://<ISP IP>/admin

You should see a HTTP 403 FORBIDDEN error.

That’s it.
If you made an error, you can restore your config from the backup file you took:

# cp -p /etc/frontview/apache/httpd.conf.bak /etc/frontview/apache/httpd.conf

and then restart your readynas.
Don’t forget to check the config after you make any changes to shares / firmware etc.

Encrypting HANA Data Volumes

Out of the box, the HANA database is not encrypted.
For those businesses that demand encryption, from within HANA Studio you can activate the encryption of the HANA data volumes.
The HANA documentation supplied with SPS7, suggests that the recommended approach is to encrypt the data volumes as part of the HANA installation process. This is due to the “Copy-on-write” method used to persist data on disk. An already used database may still have unencrypted data pages in it, even after encryption is enabled.

You should note that the words “data volumes” means the location of the database files for the indexserver and the statistics server, which is usually something like “/hana/data/<SID>/mnt0000<n>/hdb0000<n>/*.dat”.

Tip: You can check which values for “<n>” in the above, will be used, by checking the “Landscape Overview” tab and the “Volumes” tab within that.

Prerequisites:
– SAP recommend changing the SSFS encryption key after installation of the HANA system. This key is used to store the data volume encryption key and others.
– Disk space of the data volume areas (we discuss this below anyway).
– Take a cold backup of the HANA DB area and config files.
– Access to the HANA Studio (you can do this with SQL access and hdbsql, but I don’t show this).

Let’s begin:

From within HANA Studio, open the “Security” tab and navigate to the “Data Volume Encryption” tab.
You will notice that encryption is not already enabled.
Tick the “Activate encryption of data volumes” tick box, then click the “Execute” button:

HANA volume encryption activation

The encryption process will start immediately (“Encryption Pending” then “Encryption Running”):

HANA volume encryption pending

The status is updated when each server process finishes:

HANA volume encryption running

Once the encryption process is completed successfully, the tick box is enabled again for you to be able to de-encrypt the volumes should you wish to reverse the process:

HANA volume encryption encrypted

My small (empty) HANA DB @ sps7, took approximately 10 minutes to encrypt.
The data volume sizes increased as part of the encryption process.
The indexserver data volume went from 324MB used to 341MB used:

HANA volume encryption indexserver size

Of more importance is the dramatic increase in the allocated (Total Size).
It’s gone from 513MB to 896MB! You will need to be aware of the disk space you may need before enabling encryption.

The statistics server is smaller and went from 80MB used to 101MB used:

Snap668 2014-06-26, 11_26_17

Again, notice that we’ve got an increased allocation from 320MB to 400MB.

Validate the encryption status using an SQL console:

SELECT * FROM M_PERSISTENCE_ENCRYPTION_STATUS;

What are the implications for encryption?

Well, the data volumes have been encrypted, but we’ve not seen anything about encrypting the logs or the backups.
Also, to preserve the performance of the HANA system in memory, the data is decrypted when read from the disk into memory.

Is encrypting the HANA DB transaction logs feasible? Probably not. There are various whitepapers detailing the issues of encryption of data stored on SSDs. Since the majority of high performance appliance resellers use SSDs for the HANA DB transaction logs, the use of software layer encryption on SSDs is not worth the effort and would probably reduce the performance of the database. Instead, using the SSD hardware layer encryption may prove useable, but this is only worth while if you think that the SSD could be physically stolen. SSD hardware encryption doesn’t prevent an intruder at the O/S level from seeing the data.

Is encrypting the HANA DB backups (data and logs) feasible? Yes this is definitely something that should be employed. There are 3rd party backup tools that will take a copy of the HANA backup files, then encrypt and store elsewhere. But these tools may not support secure wipe, so the disk location of the backup files would potentially still contain the data. Using backup tools certified for SAP with the BackInt interface would be better, since the data doesn’t touch the disks, it’s piped straight to the backup device via the “network”.

There is possibly some slight performance impact from encrypting the data volumes. The data files are written to at least every 5 minutes. They are also read from during HANA start up. These I/O operations will be the same speed as they were before, except there will be some additional software routines involved to perform the encryption, which will use slightly more memory and mean a slight delay between the data being read/written to/from the disk.

Be aware of bugs in the backup/restore process.
I’ve seen mention of bugs in other software products where an encrypted backup is void due to a software bug. Ensure that you test your solution thoroughly.

SAP recommend that you change the Page Encryption Key (used to encrypt the data volumes) regularly as per your organisations standards. This may yet again increase the allocated size.

Summary:
– Data volume encryption is easy and fast in HANA. There’s not really any reason to not implement it. Beware of implementing in an already populated database and ensure you change the keys regularly.
– Backups and transaction log volumes are not encrypted and for the logs there’s a good reason why you may not want to.
– Performance in certain scenarios could be affected slightly.
– You should attempt to implement a supported Backint capable backup product with encryption, since the backups with this method don’t touch the unencrypted disks.
– Encryption can be performed and validated at the SQL command level.
– Be aware that data volume encryption in HANA will require more disk space to be allocated to the data volumes, increasing the footprint of the HANA database by as much as 50%.

Why You Should Never Use J2EE_ADMIN for SLD Access

If you have a SAP Java stack (either pure or part of a dual stack), you should never ever use the J2EE_ADMIN account (or any other high privileged account) to access the SLD.
This is because on most SAP systems, the standard out-of-the-box installation and configuration for the SLD does not use SSL for communications to/from the SLD.

If you use the J2EE_ADMIN account to access the SLD, then each authentication request that the SLD issues to the client system (the SAP system querying or updating the SLD) will be sent unencrypted.
If the client system responds with the J2EE_ADMIN account username and password (if you put this in the NWA or RZ70) then the username and password are simply combined into a standard HTTP BASIC authentication response (https://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA).

Essentially the username (J2EE_ADMIN) and password are combined into a string like this: <user>:<password> and then encoded (not encrypted) with BASE64.
This will then be sent in the clear (unencrypted) across the network to the SLD.
If you have Java stack full HTTP tracing turned on, you can see the authentication requests and responses and therefore see the password.
If you have a network packet sniffer installed, then you can see the authentication requests and responses and therefore see the password.

If you have a SAP PI system, you should really consider using SSL (HTTPS) for the SLD traffic. Since it is possible to completely bring down a SAP PI system by causing mayhem in the SLD.

HowTo: Restrict and remove DEBUG from SAP Roles

Scenario: Having access to the debugger (“/H”) in SAP, could provide the user the capability of circumventing authorisation checks and allowing access to data or modification of data.
You need to restrict or remove access to the debugger in the SAP roles.

The S_DEVELOP authrisation object controls access to the debugger.
You can locate the roles that contain the S_DEVELOP authorisation object using the SUIM report “Roles by Authorisation Values”.

You should edit all user assigned roles that contain S_DEVELOP and ensure that it is set to include a range of values for field “Object Type”, that excludes the DEBUG value:

S_DEVELOP
ObjectType:
4 to DE
DEVC to Z
Z to $TM

i.e. missing out DEBUG.

NOTE: The above is based on SAP R/3 4.7.

This will prevent access to the debugger.

HowTo: List all SAP transaction codes in roles

Scenario: As part of your internal auditing or general processes, you require a list of all transactions that are assigned to roles.

At first thought, this may be easy. You could try to use the SUIM transactions, but you will find that you are only able to list one role at a time and you are not able to see all transactions assigned to all roles in one display.
The only way that you can easily do this is either using the SAP internal query tools (such as quickviewer) or via the database tools directly.

Since SAP do not recommend accessing the database directly, it makes sense to use the SAP tools already provided.
If you do choose the direct database method, then you will need to know that the query you would need will look something like this:

SELECT agr_name, low, high FROM agr_1251 WHERE agr_name = '<YOUR ROLE NAME>' AND object='S_TCODE';

We will use the SAP quickviewer (transaction SQVI) as this is the preferred method.
Unfortunately, the transaction has a downside, in that you can’t transport the query directly.
Instead, it’s possible to generate a program from the query, copy it and create your own “Z” report that you can transport.

In transaction SQVI, create a new query called “TCODES_IN_ROLE” or whatever you think is an appropriate name:

Add a description for the query and then add the fields:

Role Name (AGR_1251-AGR_NAME)
Authorization Value (AGR_1251-LOW)
Authorization Value (AGR_1251-HIGH)
Auth Object in User Master Maintenance (AGR_1251-OBJECT)

You can adjust the sort sequence on the “Sort Sequence” tab if you wish.

On the “Selection fields” tab, you can indicate which fields the user is able to use to narrow the query selection (set the predicates).

Save the query and then execute:

On the previous screen, the option to generate the program exists:

Choose the “Display report name” option (shown on the menu selection above) to then display the subsequently generated program name:

Now display the report source code in SE38:

You can now copy the report to your own “Z” report and modify as required.
This can then be transported.

WARNING: Since this report exposes detailed information on the structure of your roles, you should ensure that you secure it by assigning it to an authorisation group accordingly.