Installing Feng Office on OpenBSD 6.0

Feng Office is a Web project management application. It allows management of projects, tasks, documents and enables online collaboration with co-workers and other organizations. It can provide a multitude of business services including billing and scheduling among others. In the previous posts, we installed OpenBSD 6.0, setup our web server and then deployed WordPress on it. In this post, we continue to develop our web server by installing Feng Office.

Setting Up OpenBSD 6.0

Feng requires php-gd package for image processing. This package has dependencies on the xbase60.tgz OpenBSD package. If you did not install this set during the OpenBSD installation, you can do it now using these commands:

If you don’t have access to the Internet, you can simply use the archive from the OpenBSD 6.0 CD and unpack its contents using the command at the second line in the code listing above.

We can now proceed with installing the php-gd package. This can be done using the pkg_add application. When asked which version of the package you wish to download, select the same version as your current PHP installation. In this case, PHP 5.6.23 is installed. If you are unsure about yours, type  /usr/local/bin/php-5.6 --version to retrieve it.

Unlike Linux distributions, pkg_add does not automatically modify the required configuration files. As such, you need to manually modify the PHP configuration file to load the php-gd extension. Edit the php-5.6.ini with vi /etc/php-5.6.ini  file and add the following line in the extension section:

Since we modified the configuration file, we will need to restart the PHP service:

Now that we have setup OpenBSD to be compatible with Feng, we will configure the database and then move on to the actual install of the web application.

Setting Up the Database

In the previous posts, we installed MariaDB and set it up for a WordPress site. The same exact steps apply for the Feng Office application. Login into the MariaDB database with mysql -u root -p and follow these steps:

Create a database schema for the Feng Office application:

Then create a user for the application and select a strong password for it unlike the example below:

Afterwards, grant your new user the privileges require to modify your database. In this case, we allow the user all privileges on the db_feng database:

And then exit MariaDB by typing  quit . We are now ready to install the Feng Office application.

Installing Feng Office

You’ll first need to download the application from the Web using the ftp program. You’ll also need to install unzip since Feng Office uses a zip package. If you want to avoid installing the unzip package, you can always download Feng on another workstation, unzip it and repack it using tar. Then upload it to a third party location and re-download it using ftp. Otherwise install unzip with pkg_add unzip and then download Feng with ftp:

As we did in previous tutorial, we confirmed the integrity of the package. The MD5 hash is provided on the SourceForge website by clicking the “i” icon. We will now unzip Feng into its own directory on our web server:

Feng Office has quite a few files and after a few seconds, all files should be extracted. In order to run the installer, we first need to set specific permissions on some directories. As such, we’ll make sure the following directories are readable, writable and executable and change their ownership to the web server:

With this done, browse to your Feng Office home page from a remote workstation. You will be greeted by a welcome page which details the installation procedure. Click Next.

Welcome Page of the Feng Office Installer
The welcome page of the Feng Office 3.4.4.1 installer

The second page of the installer verifies if all requirements for the application are met. If there is an item highlighted in red, then you will not be able to proceed. The most likely issues are limited file permissions and missing PHP extensions. If everything is green, click Next.

Requirements Verification for Installing Feng Office
Feng Office verifies if all requirements are met to install and use the application.

The third step is where you provide the information about the database. Fill in the required information with the specific values for your database setup. An example of valid values for our example are:

  • Database Type: MySQL
  • Hostname: 127.0.0.1
  • Username: fg_user
  • Password: p1234
  • Database Name: db_feng

You can leave the remaining settings to their default values and once satisfied, click Next again. You then reach the last page of the installer, which You’ll reach the installation page and you should get a Succcess! message Click on Finish.

Feng Office Administrator Account Creation Form
Administrator account form for Feng Office 3.4.4.1

After clicking Finish, you’ll be immediately redirect to the user account creation form. This is the final step before using the application is to create an Administrator account. Fill in the form and click Submit. You will be redirected to the login page. Login and that’s it! Next steps include configuring your new Feng Office application by creating users and customizing it. You should also remove write permission to the /var/www/htdocs/feng/config and change the ownership back to root:daemon.

Conclusion

Feng Office is widely used by multiple large public and private organizations and thus, is a fairly popular web application which like many others, fits perfectly with an OpenBSD 6.0 server. Like in the WordPress install, you should attempt to plug information leaks by removing README and CHANGELOG files and test your application via a rigorous penetration test. With a well-configured OpenBSD server and secure database, the likelihood a a major breach occurring is greatly reduced, but it always depends on how well or badly it’s configured and used.

References

See Also

Learn More

Secure WebServers with OpenBSD 6.0 – Setting Up Httpd, MariaDB and PHP

Introduction

In this tutorial, we setting up a web server on OpenBSD 6.0 using the native httpd web server, MariabDB and PHP. There can be quite a few issues popping up unlike other systems, mostly due to the fact that the web server is “chroot jailed” during execution. In other words, the web server is sandboxed and cannot access other parts of the operating system, which requires more work than other similar setups on other distributions. However, this greatly decreases the damages if your server gets whacked. In this post, we setup a minimal web server that will allow you to host simple web content. I’ll assume you have an OpenBSD 6.0 VM created with root access to it. From there, we will stand up our web server with HTTPS, install MariaDB and PHP. Please note that this tutorial is not meant for professional/commercial settings, but for personal and educational uses. A video version of this tutorial is also available.

Standing up a Minimal Web Server with Httpd

The strategy we will employ is to create a very minimal web server, test if it works as intended, and then enable additional features as we go along. So first, we’ll start by enabling the httpd daemon. To do so, first copy the httpd.conf file from /etc/examples/httpd.conf to /etc/ by typing  cp /etc/examples/httpd.conf /etc . Open the copied file as root using vi or another text editing tool if you have any install. In the file, you will delete all the examples provided and only keep the “minimal web server” and “types” sections:

Make sure you save your changes and now start your web server with the following command:  /etc/rc.d/httpd -f start . Make sure you include the  -f , other you may get an error message. We will fix this later. If everything goes well, you should get an “httpd(ok)” message. Otherwise, there is likely an error in your configuration file. You can confirm by using  httpd -n .

Let’s confirm everything works so far. Retrieve your IP address using  ifconfig em0 and using another host on your network, browse to http://<your_ip>. If everything works as expected, you will see something similar to the figure below:

OpenBSD WebServer - 403 Forbidden
Receiving a 403 Forbidden error from the OpenBSD web server.

We received a 403 error because we do not have any web pages created yet and by default, httpd prevents directory listing – which is a good thing. So let’s create a quick index.html web page. Use the following command  vi /var/www/htdocs/index.html and type the following:

Save the file and point your browser to http://<your_ip>/index.html. You should see your web page. If not, make sure you created the file in /var/www/htdocs and you haven’t made a typo in your URL. Also note that if you go to http://<your_ip>/, you will also end up on your web page. By default httpd looks for “index.html” and serves this web page when none is specified.

Fantastic. We got ourselves a web server. But not a very secure or useful one unless you want to host Geocities-like webpages. Next, we will enable HTTPS on our web server and redirect all traffic to it. We’ll need to do this in 2 steps:

  1. Create a certificate for your web server; and
  2. Setup httpd to use your certificate and HTTPS

First, we’ll need to generate a SSL private key. This is straightforward by using openssl:

The server.key file is your private key and must be secured! It’s very important that nobody else other than you have access to it. Next, we will use this key to generate a self-signed certificate. This is also done by using openssl:

The command above basically requests OpenSSL to generate a certificate (server.crt) using our private key (server.key) that will be valid for 365 days. Afterwards, you will be asked a couple of questions to craft the certificate. Since this is self-signed, feel free to enter anything. Once done, the first step is completed. Next, we will modify our configuration file again and update out minimal web server to tell it to use HTTPS:

Every time your modify the httpd.conf file, you will need to restart your web server for the changes to take effect. Use  /etc/rc.d/httpd -f restart do so and test your website again, this time using https://<your_ip>. You should be greeted with a warning message fro your browser, warning you that it cannot validate the certificate. That’s because it is self-signed. Click on “Advanced” and add it to the exceptions. Afterwards, you will be serve our web page via an encrypted link.

Web Server Certificate Exception
Receiving a warning from the browser on self-signed certificate.

So at this point, we have a functioning web server over HTTPS. However, unencrypted communications are still enabled. We would like to have ALL users over HTTPS. This can be done by replacing this line in httpd.conf:

with

Anyone using http://<your_site> will be automatically redirected to https://<your_site>.

Setting Up MariaDB

Installing the database is quite simple in contrast with many other activities we need to do. First, we’ll need to download some packages, so make sure you have the PKG_PATH environment defined with a mirror containing the packages you need. If not, select a mirror on openbsd.org and define your variable:

And as root, install the mariadb-server package:

Once completed, install the database using the included script by typing  mysql_install_db and when completed, start the mysqld daemon:  /etc/rc.d/mysqld -f start . The last step is to configure it by running the  mysql_secure_installation . The script will ask you a couple of questions:

  1. First, it will ask you to set a password for root. Choose a good password. Long simple passwords can be more efficient than short complex one that you won’t remember;
  2. It will then ask if it should remove anonymous users. Select “Y” to remove them;
  3. When asked if it should disallow remote root access, answer by the positive to prevent root access from remote hosts;
  4. Choose to remove all test databases; and
  5. Press “Y” to reload all privileges in the database application.

You are now done with installing the database. Before moving on to the next section, confirm that everything is working by login into MariaDB:

If everything went fine, you will be given access to the database engine. Type  quit; to exit the application.

Setting Up PHP

The last step of this tutorial involve downloading and install PHP. Very few webpages nowadays rely solely on static HTML, and I suspect most will want to install web applications later on, so let’s setup PHP. First, download some of the required packages. Note that additional packages may be needed depending on the web applications you wish to install later on, but for now, let’s setup the core PHP packages:

There are several versions of PHP available on the OpenBSD repository. What is important is that you select the same version for all packages you install. For example, at the time of writing version 5.6.23 and 7.0.8 were available, but php-mysql 7.0.8 was not, thus we select 5.6.23 for all PHP packages to prevent issues later one. Dismiss any packages ending with “-ap2” as these are for the Apache web server. For the purpose of this tutorial, we will select version 5.6.23 every time we are asked.

Before starting up PHP, we have a couple of things to do. First, we need to tell httpd to send PHP pages to the PHP processor. We also need to specify the PHP processor that we have a database it needs to be aware of. So let’s start by modifying our httpd.conf file again by adding a section about .php files. Also, we’ll add a “directory” section to tell the web server to look for “index.php” files first instead of “index.html“:

Next, let’s modify the PHP configuration file to enable MySQL. We do so by adding extensions to the /etc/php5.6.ini file. Open this file as root and add the following lines under the “Dynamic Extensions” section:

Since we modified configuration files, we’ll need to restart the httpd and php-fpm daemons. Do so with  /etc/rc.d/httpd -f restart and  /etc/rc.d/php56-fpm start . Hopefully, you will get “httpd(ok)” and “php56_fpm(ok)”. Otherwise, you may have introduce a typo in your configuration files or some packages may have not downloaded/installed properly.

Wrapping Up

One last thing we will do before calling it quit for today, is to make sure the httpd, php56-fpm and mysqld services are started on bootup of OpenBSD. To do so create a new rc.conf.local file in /etc/ using  vi /etc/rc.conf.local and type the following in it:

At startup, OpenBSD will use this file to initiate the services and the PKG_PATH environment variable. You will not have to use the  -f anymore when restarting the httpd daemon.

Conclusion

So in this post, we have enabled a HTTPS web server, along with a MariaDB and PHP, allowing use to serve dynamic content on a OpenBSD 6.0 machine. At this point, you should be able to host basic dynamic content. However, if you try to install more complex web applications, you will need an extra few steps in many cases. Sometimes, you will need additional packages and extra work to connect to the database via your web application. In the next tutorial, we will install WordPress to show some of the difficulties you may encounter with the chroot jail and file permissions of the web root.

See Also

#TheGreatFTPHunt – 2% to 9% of files scanned potentially containing confidential information

In this post, we continue our data collection and evaluation of files stored on removable medias publicly accessible to the Internet. The collection of filenames from 6,500 hosts is ongoing, therefore we’re going to focus on evaluation of sensitivity of a file based only on its filename. We also present the latest statistics collected in our database.

Introduction

In this post, we continue our data collection and evaluation of files stored on removable medias publicly accessible to the Internet. The collection of filenames from 6,500 hosts is ongoing, therefore we’re going to focus on evaluation of sensitivity of a file based only on its filename. Based on the current result, 2 to 9% of the 3000 files reviewed were sensitive or potentially sensitive. Most of the sensitive files are concentrated on a few hosts. These files often include financial information or project data from businesses. So far, 773 hosts containing around 4.5 million files have been scanned.

Discussion

The amount of filenames collected is quite large and we cannot evaluate manually each filename for its probable sensitivity. As such, we need to devise a procedure to automatically assess its sensitivity. We have some definitions and restrictions to list first to clarify what a sensitive file is and limitation to our evaluation criteria.

In this document, sensitive file refers to user-generated or software-generated files based on user input that contains information that should probably not be publicly accessible and which can be leveraged against an individual or organization. This includes:

  • Personal identification documents; passport, driver’s license, visas, government forms…
  • Personal finance documents; income tax files, insurance forms, credit card statements, mortgage, pay stubs, banking information
  • Personal medical documents; prescriptions, medical records
  • Work-related files; emails, proprietary source code, password lists
  • Business finances; customer lists, sales data, project costs, business deals, investments, payrolls
  • Intellectual property; blueprints, schema, patents, research
  • Network configuration; passwords files, configurations files, network diagrams, user databases
  • Large databases of emails, addresses and other personal information.

Some of the files not included in our analysis that includes;

  • Copyrighted / Illegally downloaded files. However we considered text file containing licensing keys to be sensitive.
  • Inappropriate contents (nude selfies, personal politics, group affiliations etc…)
  • Personal pictures, letters.
  • Addresses and emails were not considered personal, however databases of addresses and emails are considered sensitive

Because of the volume, we cannot download and manually verify each file to confirm its contents, as such our main restriction is that our assessment must be done solely based on the absolute filename recorded. As such, to evaluate the sensitivity, we used three categories; positive, negative and neutral, i.e. either a file is very likely to sensitive, potentially sensitive or clearly not sensitive at all. Of course, there is always a possibility that a file labeled as sensitive may not be. For example, a file called social security numbers.xls may contain only formulas or an empty form. Ideally, files identified as positive or neutral should be manually vetted.

The procedure to automatically assess the sensitivity of a file based on its path and name is first done by assessing a random sample manually. Using the ORDER BY RANDOM (note: there will be a need to review if this function is truly random, which I doubt) function (performance is not an issue in this experiment) of the Postgresql database, multiple  random samples of 100 filenames are retrieved from the database. Each file is shown to the evaluator which based on the path, filename and extension assess the sensitivity of the file as ‘positive‘, ‘neutral‘, ‘negative‘. For each run, we log the count of hits for all categories.

Listing 1 : Example of a run in which a script asks an evaluator to assess the sensitivity of files based on its absolute path.

The evaluator is assessing the filename based on keywords that may indicate the contents of the file. As such, a file containing the word, or as we call it in this document, a token such as sales, passport or passwords will be assume to contain information about sales, a passport scan or a list of passwords. In many cases, the filename is too obscure, but the path and extension may indicate the contents of the file. For example, a path containing the tokens project, finances and a Microsoft Excel extension despite a filename of axe189212_c.xls will be considered as neutral, as the file may contents information about a project. Examples of both scenarios are shown in listings 2 and 3:

Listing 2 : Examples of files that were deemed ‘positive’ hits based on keywords in their absolute path.

Listing 3 : Examples of files that were deemed ‘neutral’ (or ‘unknown’) hits based on keywords in their absolute path.

Filenames in foreign languages are roughly translated using Google Translate, as such, many of them are labeled as unsure.

A Python script then divide the filename in tokens, and each token is stored in the database along with the number of times it was found in a positive, neutral and negative hit. Tokens are created slightly differently based if they are located in the path, the filename or in the extension. For the extension, a single token is created which contains the extension itself. If the file does not have an extension or is not an extension usually associated with known software, no token is created. For the filename, tokens are created by splitting each word using characters usually known to separate words such as the underscore, dash, period or spaces. Lastly, for the path, directories are used as token and unlike filenames, are not split further. An example of this process is shown in listing 4:

Listing 4 : Example of the tokenization of a filename.

Once the tokens are created, the script will either add the token in the database or update its count based on the evaluator choice. After each update, a score is given to the token, which is simply the ratio between positive hits and the total count of appearances: p / hits). Note that tokens are considered different depending their location in the filename. As such, a filename such as /My_Passport/backup/Outlook emails backup.pst, will generate 2 distinct ‘backup’  tokens; the one from the path and the one from the filename. We explain this decision in the next paragraphs.

Listing 5 : Scores of the tokens extracted from the file in listing 4.

By using this procedure, we believe that tokens appearing often in both positive and negative hits will cancel each other, while the tokens strongly associated with positive and negative hits will remain clearly divided. Some sort of mathematical should follow later one (I hope…need to review discrete maths I guess). Some preliminary results  appears to confirm this approach as valid. Extensions strongly associated with sensitive contains higher scores while media files have null scores.

However, there is a need to further refine this process by associating a value, or weight, to the location of the token. Tokens in the path are not as indicative of the sensitivity of the file as much as a token in the filename or extension. Even within the path, the highest level is generally less indicative than the lowest one, i.e. /documents/finances 2012/sales/company sales.xls. Therefore when assessing a new filename, we need to give a score to the path, the filename and the extension. For the path, we will get the score of each token and multiply it with a weight that correspond to its location in the structure. For token that are not found the default value of 0 will be given. Then we will take the average of all token for the score of the path. As for the filename, we will not consider the position. Finally the stored score of the extension will be retrieved from the database. If the extension is not found, then a score of 0 will be used. This will transform a filename into a set of three real values which we can range between 0 and 1. To determine the weights needed for each location, we will used a supervised neural network. More research will be conducted to determine how to use this approach.

Results

As of 16 July 2015, 4,568,738 files have been recorded from 773 hosts.

Country Hosts
United States 258
Russian Federation 91
Sweden 69
Canada 66
Ukraine 27
Norway 24
United Kingdom 24
Australia 19
Netherlands 18
Hong 18
Taiwan 16
Poland 15
Germany 11
Romania 11
Finland 10
Switzerland 8
Korea 8
Singapore 7
Czech Republic 7
Japan 6
Table 1. Location of the 773 hosts scanned as of 16 July 2015 order by country.

Mp3 and JPEG image files remains the most common. As such, we focus our statistics on document-type of files for a change, i.e. Office documents. Adobe PDF files and Microsoft Word documents are the most common file types based on our current data as shown in figure 1.

Most common file types scanned as of 16 July 2015 for office-related documents
Figure 1. Most common file types scanned as of 16 July 2015 for office-related documents

At the moment, around 3000 files have been assessed (30 runs of 100 samples). For each run, we recorded the number of positives, neutral and negative hits and found them overall constant at each run. (see figure 2) However more details about the RANDOM function is needed to insure the randomness of the sample. This part may need to be redone. So far, between 2% and 9% of files scanned are considered sensitive or potentially sensitive (see figure 3). However we need to consider the concentration of these files to put this information into perspective. The 278 files identified as sensitive or potentially sensitive were located on 59 hosts, with one host accounting for 101 of these file. This indicates that files of interests for an attacker are likely to be concentrated on a few hosts.

Chart of assessed sensitivity of randomly selected 30 samples of 100 filenames.
Figure 2. Assessed sensitivity of randomly selected 30 samples of 100 filenames.
Chart of percentage of files according to their sensitivity based on manual assessment of 3000 randomly selected files.
Figure 3. Percentage of files according to their sensitivity based on manual assessment of 3000 randomly selected files.

As for tokens, we will have to consider the entire collection of filenames in order to have sample from multiple sources, as such, we will pursue manually assessing samples of 100 filenames as more data is collected. After which we should have an excellent training set for the neural network. Some high-recurring and high-scoring tokens are shown in tables 2 and 3.

Token Hits Score
attach 7 0.9285714286
txn 7 0.9285714286
planning 6 0.9166666667
archived 6 1
recpt 6 0.9166666667
2010taxreturns 5 1
person~2 4 1
purchase 3 1
order 2 1
Паспорт 2 1
Table 2. Sample of high-scoring tokens sorted on the number of times observed.
Token Hits Score
jpg 938 0.013326226
mp3 460 0
music 448 0
seagate_backup_plus_drive 382 0.1452879581
asusware 348 0
pictures 309 0.0048543689
sda1 285 0.0649122807
bigdaddy 279 0
elements 278 0.0485611511
transcend 247 0.0222672065
my_book 234 0.0106837607
Table 3. Sample of high-recurring tokens sorted on the number of times observed.

Conclusion

While these results are preliminary, they nevertheless seems to provide a solid indication of what one can find on publicly-available removable drives. Additional work and fine tuning of both code and processes is required to provide more accurate data and the next step while the scan is still on going it to develop a methodology to assess the sensitivity of all files, likely using a neural network for classification based on the method presented above.