http://serverfault.com/questions/570961/proftpd-configuration-to-run-ftp-ftes-ftps-and-sftp-at-the-same-time-on-differen

#-----------------------------------------------------------------------
# Server Configuration: those parameters cannot be elsewhere
#-----------------------------------------------------------------------
ServerName                          "ftp daemon"
ServerType                          inetd
UseIPv6                             off

# Bar use of SITE CHMOD by default
<Limit SITE_CHMOD>
        DenyAll
</Limit>

SystemLog                           none
LogFormat                           authentication "%{%F %T}t %P  from: %a to: %{protocol}:%H:%p  user: %U       msg: %S"
LogFormat                           transfer       "%{%F %T}t %P  from: %a to: %{protocol}:%H:%p  user: %U       file: %f        cmd: %m %J"

ScoreboardFile                      /local/proftpd/var/proftpd.scoreboard


TLSProtocol                         SSLv3 TLSv1

<Global>
    #-----------------------------------------------------------------------
    # Generic Configuration
    #-----------------------------------------------------------------------
    DefaultRoot                         ~
    Umask                               022
    allowOverwrite                      on
    User                                nobody
    Group                               nobody
    ExtendedLog                         /var/log/proftpd_auth.log AUTH,EXIT,SEC authentication
    ExtendedLog                         /var/log/proftpd_xfer.log READ,WRITE transfer
    AuthOrder                           mod_sql.c mod_auth_unix.c mod_auth_pam.c

    #-----------------------------------------------------------------------
    # TLS Configuration
    #-----------------------------------------------------------------------
    TLSEngine                                               off
    TLSRSACertificateFile           /usr/local/proftpd/etc/proftpd.cert.pem
    TLSRSACertificateKeyFile        /usr/local/proftpd/etc/proftpd.key.pem
    TLSLog                                                  none
    TLSVerifyClient                                 off
    TLSRenegotiate                                  none
    TLSRequired                                     off
</Global>

# -----------------------------------------------------------------------------
#    __ _              __   __ _         _____ _____                    __
#   / _| |            / /  / _| |       |  ___/  ___|                  / _|
#  | |_| |_ _ __     / /  | |_| |_ _ __ | |__ \ `--.    ___ ___  _ __ | |_
#  |  _| __| '_ \   / /   |  _| __| '_ \|  __| `--. \  / __/ _ \| '_ \|  _|
#  | | | |_| |_) | / /    | | | |_| |_) | |___/\__/ / | (_| (_) | | | | |
#  |_|  \__| .__/ /_/     |_|  \__| .__/\____/\____/   \___\___/|_| |_|_|
#          | |                    | |
#          |_|                    |_|
# -----------------------------------------------------------------------------
<VirtualHost 0.0.0.0>
    Port                                    210
    TLSEngine                               on
</VirtualHost>

# -----------------------------------------------------------------------------
#    __ _         _____                    __
#   / _| |       /  ___|                  / _|
#  | |_| |_ _ __ \ `--.    ___ ___  _ __ | |_
#  |  _| __| '_ \ `--. \  / __/ _ \| '_ \|  _|
#  | | | |_| |_) /\__/ / | (_| (_) | | | | |
#  |_|  \__| .__/\____/   \___\___/|_| |_|_|
#          | |
#          |_|
# -----------------------------------------------------------------------------
<VirtualHost 0.0.0.0>
    Port                                    214
    TLSEngine                               on
    TLSOptions                              UseImplicitSSL
</VirtualHost>

# -----------------------------------------------------------------------------
#   _____  __ _                            __
#  /  ___|/ _| |                          / _|
#  \ `--.| |_| |_ _ __     ___ ___  _ __ | |_
#   `--. \  _| __| '_ \   / __/ _ \| '_ \|  _|
#  /\__/ / | | |_| |_) | | (_| (_) | | | | |
#  \____/|_|  \__| .__/   \___\___/|_| |_|_|
#                | |
#                |_|
# -----------------------------------------------------------------------------
<IfModule mod_sftp.c>
    <VirtualHost 0.0.0.0>
        Port                                    211
        SFTPEngine                              on
        SFTPLog                                 none
        SFTPHostKey                     /etc/ssh/ssh_host_dsa_key
        SFTPHostKey                     /etc/ssh/ssh_host_rsa_key
        SFTPAuthorizedUserKeys  file:../etc/ssh/authorized_keys
        SFTPCompression                 delayed
        MaxLoginAttempts                6
    </VirtualHost>
</IfModule>  

How to Secure Elasticsearch and Kibana

https://www.mapr.com/blog/how-secure-elasticsearch-and-kibana

Introduction

Elasticsearch (ES) is a search engine based on Lucene. It provides a distributed, multitenant-capable, full-text search engine with an HTTP web interface and schema-free JSON documents.

Kibana is an open source data visualization plugin for Elasticsearch. It provides visualization capabilities on top of the content indexed on an Elasticsearch cluster. Users can create bar, line, and scatter plots, or pie charts and maps on top of large volumes of data.

These two products are widely used in the market today for data analytics. However, security is one aspect that was not initially built into the product. Since data is the lifeline of any organization today, it becomes essential that Elasticsearch and Kibana be “secured.” In this blog post, we will be looking at one of the ways in which authentication, authorization, and encryption can be implemented for them.

Assumptions

The tutorial assumes the following:

  1. MapR Sandbox is running
  2. Elasticsearch and Kibana have been installed and are running

Options Available for Securing Elasticsearch and Kibana

The most popular options for securing Elasticsearch and Kibana are compared in the table below.

Shield is a security plugin developed by the same company that developed Elasticsearch. It allows you to easily protect this data with a username and password while simplifying your architecture. Advanced security features like encryption, role-based access control, IP filtering, and auditing are also available when you need them.

NGINX is an open source web server. It can act as a proxy server and can do load balancing, among other things. In combination with LUA and external scripts, it can be used for securing Elasticsearch and Kibana. We will be using this approach in this tutorial.

Searchguard is an open source alternative for Shield. It provides almost all the same functionalities as Shield, except for some features like LDAP authentication. However, these features are available in the paid variant

Configure PHP Application Security on IIS

https://www.iis.net/learn/application-frameworks/scenario-build-a-php-website-on-iis/configuring-step-3-configure-php-application-security

3.1. Configure PHP Settings for Security

The following procedure shows you how to configure PHP settings in the php.ini file. For information about security-related PHP settings, see 3.1. PHP Configuration Settings for Security.

TO CONFIGURE A PHP SETTING FOR SECURITY

  1. In Windows Explorer, open your PHP installation folder, for example C:\PHP.
  2. In a text editor, open the php.ini file.
  3. Search the file for the setting you want to change.If the setting is commented out (line begins with a semicolon [;]), delete the semicolon and set the value. If you can’t find the setting, add the line to the end of the file.
  4. Save and close the php.ini file.
  5. Recycle the IIS Application Pools for PHP to pick up the configuration changes.

3.2. Configure Web Server and PHP Application Security

This section shows how to configure several web server and application settings for IIS. These settings include isolating web applications, enabling per-site PHP configurations, and using request filtering. For more information about web server and PHP application security settings, see 3.2. Web Server and PHP Application Security.

ISOLATE WEB APPLICATIONS

Implement the following recommendations to isolate websites and web applications on your server.

  • Use one application pool per website or web application.
  • Limit access to site folders and files to the application pool identity.
  • Set up a separate PHP temp folder per site and only give access to the application pool identity.
  • Make sure to set an ACL (access control list) on each site root to allow only access to the application pool identity.

If you have more than one application per application pool, consider creating enough application pools and moving some of the applications to the new pools.

To create an application pool

  1. Open IIS Manager.
  2. In the Connections pane, click Application Pools.
  3. In the Actions pane, click Add Application Pool.
  4. In the Name box, type a unique name for the application pool.
  5. Under .NET Framework version, select No Managed Code.
  6. Select the Managed pipeline mode. The Integrated mode is recommended.
  7. Click OK.

To move an application to another application pool

  1. Open IIS Manager.
  2. In the Connections page, select the website or web application you want to move.
  3. In the Actions pane, click Basic Settings.
  4. On the Edit Site dialog, click Select to open the Select Application Pool dialog, and then select the application pool from the Application pool menu.
  5. Click OK to close the Select Application Pool dialog, and click OK to close the Edit Site menu.

To add an application pool identity to a folder or file ACL

  1. Open Windows Explorer and navigate to the folder or file.
  2. Right click the folder or file, and then click Properties.
  3. Select the Security tab, and then click Edit.
  4. Click Add, click Locations, and select your server as the location to search.
  5. In the Enter the object names to select box, type IIS APPPOOL\applicationPoolName, where applicationPoolName is the application pool identity.
  6. Click OK, click OK, and click OK again to close the dialogs.

ENABLE PER-SITE PHP CONFIGURATION

When you have multiple PHP applications on an IIS web server, you can improve security by configuring a PHP process pool and a php.ini file for each application. This section explains how to configure process pools and multiple pnp.ini files by using an applicationHost.config file.

Per-site PHP Process Pools

When each website has its own application pool, which is a recommended practice on IIS, it is possible to associate a dedicated FastCGI process pool with each website. This association is done in the fastCgi section of the applicationHost.config file. A FastCGI process pool is uniquely identified by the combination of fullPath and arguments attributes of the application element. To create several FastCGI process pools for the same process executable, such as php-cgi.exe, use the arguments attribute to distinguish the process pool definitions. With php-cgi.exe processes, use the command line switch “-d” to define an INI entry for a PHP process. And use this switch to set a PHP setting that makes the arguments string unique.

For example, if there are two Web sites “website1” and “website2” that must have their own set of PHP settings, define the FastCGI process pools as follows:

<fastCgi>
  <application fullPath="C:\PHP\php-cgi.exe" 
    arguments="-d open_basedir=C:\Websites\Website1" />
  <application fullPath="C:\PHP\php-cgi.exe" 
    arguments="-d open_basedir=C:\Websites\Website2" />
</fastCgi>

In this example the PHP setting open_basedir is used to distinguish between the process pool definitions. The setting also enforces that the PHP executable for each process pool can perform file operations only within the root folder of the corresponding website.

Therefore, the PHP handler mapping for website1 is as follows:

<system.webServer>
  <handlers accessPolicy="Read, Script"> 
    <add name="PHP via FastCGI" 
      path="*.php" verb="*" 
      modules="FastCgiModule" 
      scriptProcessor="C:\PHP\php-cgi.exe|-d open_basedir=C:\Websites\Website1"
      resourceType="Unspecified" 
      requireAccess="Script" />
  </handlers>
</system.webServer>

And the handler mapping for website2 is as follows:

<system.webServer>
  <handlers accessPolicy="Read, Script"> 
    <add name="PHP via FastCGI" 
      path="*.php" verb="*" 
      modules="FastCgiModule" 
      scriptProcessor="C:\PHP\php-cgi.exe|-d open_basedir=C:\Websites\Website2"
      resourceType="Unspecified" requireAccess="Script" />
  </handlers>
</system.webServer>

Specifying Php.ini Location

When the PHP process starts, it determines the location of the configuration php.ini file by using various settings. The PHP documentation provides a detailed description of the PHP startup process. One of the places where the PHP process searches for the php.ini location is the PHPRC environment variable. If the PHP process finds a php.ini file in the path that is specified in this environment variable, it will use it. Otherwise, the PHP process will revert to using the default location of the php.ini file. This environment variable can be used to allow hosting customers to use their own versions of php.ini files.

For example, if there are two websites, “website1” and “website2,” that are located at the following file paths: C:\WebSites\website1 and C:\WebSites\website2, you can configure the php-cgi.exe process pools in the fastCgi section of the applicationHost.config file as follows:

<fastCgi>
  <application fullPath="C:\PHP\php-cgi.exe" arguments="-d open_basedir=C:\Websites\Website1">
    <environmentVariables>
      <environmentVariable name="PHPRC" value="C:\WebSites\website1" />
    </environmentVariables>
  </application>
  <application fullPath="C:\PHP\php-cgi.exe" arguments="-d open_basedir=C:\WebSites\Website2">
    <environmentVariables>
      <environmentVariable name="PHPRC" value="C:\WebSites\website2" />
    </environmentVariables>
  </application>
</fastCgi>

This way website1 can have its own version of the php.ini file that is located in the C:\WebSites\website1, while website2 can have its own version of the php.ini file that is located in C:\WebSites\website2. This configuration also ensures that if a php.ini file cannot be found in the location that is specified by the PHPRC environment variable, then PHP will use the default php.ini file that is located in the same folder where the php-cgi.exe is located.

USE REQUEST FILTERING

For information about how to configure request filtering, see Configure Request Filtering in IIS.

PHP with WinCache on IIS

https://www.saotn.org/php-wincache-on-iis/

Install WinCache with PHP on IIS. In this article you’ll learn how to install PHP with Windows Cache Extension (WinCache) on Windows Server IIS. WinCache enabled PHP gives a great PHP performance boost for your WordPress, Drupal or Joomla website, and decreases CPU usage. This post will show you it’s not hard to set up high performance PHP on Windows Server (IIS). And as a bonus, we’ll dive into Windows TCP/IP tuning too. Learn how this very blog optimized it’s PHP hosting on Windows!

Install PHP and WinCache on IIS #

What is the Windows Cache Extension (WinCache)? WinCache is a great addition for your PHP configuration on Windows Server. High performance PHP application hosting on IIS 😉 However, over the years, problems were reported with either the installation and configuration of the Windows Cache (WinCache), or even with buggy versions. Just search forums.iis.net for examples.

 

Using NetFlow with nProbe for ntopng

https://blog.webernetz.net/2016/08/16/using-netflow-with-nprobe-for-ntopng/

This blog post is about using NetFlow for sending network traffic statistics to an nProbe collector which forwards the flows to the network analyzer ntopng. It refers to my blog post about installing ntopng on a Linux machine. I am sending the NetFlow packets from a Palo Alto Networks firewall.

My current ntopng installation uses a dedicated monitoring ethernet port (mirror port) in order to “see” everything that happens in that net. This has the major disadvantage that it only gets packets from directly connected layer 2 networks and vlans. NetFlow on the other hand can be used to send traffic statistics from different locations to a NetFlow flow collector, in this case to the tool nProbe. This single flow collector can receive flows from different subnets and routers/firewalls and even VPN tunnel interfaces, etc. However, it turned out that the “real-time” functionalities of NetFlow are limited since it only refreshes flows every few seconds/bytes, but does not give a real-time look at the network. It should be used only for statistics but not for real-time troubleshooting.

Some Pre Notes

I am using a Ubuntu 14.04.5 LTS (GNU/Linux 3.16.0-77-generic x86_64) server. At the time of writing, nProbe had version v.7.4.160802 while ntopng was in version v.2.4.160802. Furthermore note that nProbe requires a license.

For general information about NetFlow use Wikipedia or Cisco or RFC 3954. For the other tools, use the official web sites: nProbe and ntopng. The nProbe site offers a detailed documentation PDF. A similar tutorial for installing nProbe is this one.

Installation of nProbe

(Since I already showed how to install ntopng, I will only show how to use nProbe here.) The stable builds for nProbe and ntopng are listed here. That is, to install nProbe, I used the following commands:

Since I want to receive NetFlow packets and forward them to ntopng, nProbe must run in Collector Mode. That is, I am using the following configuration file:

with these entries:

Note the naming of the config file: “nprobe-none.conf“. This is mandatory due to the documentation of nProbe: “When nProbe is used in probe mode it is not bound to any interface as its job is to collect NetFlow from some other device. In this case the configuration file to be created is: nprobe-none.conf.” (To my mind, this is a spelling mistake because it should read “When nProbe is NOT used in probe mode…”. However, it is working.)

Furthermore, an empty “start” file is needed to tell the init process to use this configuration file:

After a start of the service with sudo service nprobe start , ntopng must be configured to use this nProbe instance. Open the configuration file:

and add the following interface (= localhost):

Finally, restart the ntopng process: sudo service ntopng restart .

A netstat view should indicate the listening 2055 UDP port for nProbe, the 5556 TCP port for the connection between nProbe and ntopng, as well as the common 3000 TCP port from the ntopng WebGUI:

Since all services are now configured within configuration files that are referenced in the init scripts, they are started automatically after a system reboot. Great.

Palo Alto NetFlow

I am using a Palo Alto Networks firewall (version 7.1.3) to send NetFlow statistics to the nProbe collector. (More information about NetFlow on Palo.) This is configured in the following way: Adding of a NetFlow Server Profile and referencing this profile on all needed Network Interfaces, such as:

I am using quite fast values for the Template Refresh Rate as well as the Active Timeout. On interfaces with huge amount of traffic other values are probably better.

A small tcpdump capture shows some samples of the NetFlow packets sent by the Palo Alto. The following Wireshark screenshots show a NetFlow template as well as a sample flow:

ntopng Usage

Now here is the usage within ntopng. Simply choose the tcp://127.0.0.1:5556 interface at the upper right side. All features of ntopng remain the same, such as using the Dashboard, the Flows or the Hosts pages. (Refer to my post to see some features.)

However, here comes the problem with NetFlow: It is NOT a real-time application that lets ntopng show every single flow and its bandwidth correctly. It can be used to see a rough view of all flows during the past few seconds, but not its actual throughput at the moment.

Refer to the following two dashboard screenshots from ntopng. The first shows the Realtime Top Application Traffic from the NetFlow probe, while the second one shows the same from the mirror port eth1. The 54 MBit/s peak in the first screenshot is not true at all. In fact, it was a constant download over a few minutes. Whereas the second screenshot from eth1 shows the correct real-time bandwidth usage.

Conclusion

nProbe for ntopng can be used quite easily. It is possible to receive flows from different locations which can be displayed in a single instance of ntopng. However, if the primary goal is to have a real-time look at the network, e.g., which hosts or flows are consuming bandwidth, this approach does not fit. NetFlow data must be used with statistical applications that can report traffic stats, but not with real-time analyzers such as ntopng.