Skip to content

NXNJZ

Linux and Security

  • BLOG
  • Cowsay Fortune
  • Contact
  • Gitlab
  • Company Homepage

Author: nxnjz

Installing Ampache on Fedora 29.

Posted on February 5, 2019 - October 25, 2019 by nxnjz

Ampache requires a web server, PHP, and a MySQL database. We will be using Apache, PHP 7.2, and MariaDB to fulfill these requirements.

Installing the web stack and other required packages.

dnf upgrade -y
dnf install -y httpd mariadb-server mariadb wget php php-common php-cli php-pdo php-xml php-gd php-mysqlnd composer

And make sure Apache and MariaDB are enabled and running:

systemctl enable --now mariadb.service httpd.service

Database Configuration

Start by running the built-in MariaDB secure installation program:

mysql_secure_installation

When prompted for Y/n answers, choose Y for all questions and make sure you set a strong password.

Ampache requires a database and a MySQL user. Enter the MySQL console:

mysql -u root -p

Create a database named ampache:

MariaDB [(none)]> CREATE DATABASE ampache;

Create a local user named ampache;

MariaDB [(none)]> CREATE USER 'ampache'@'localhost' IDENTIFIED BY 'ampache_password';

Replace ampache_password with a password of your choice.

And grant that user full access to its respective database:

MariaDB [(none)]> GRANT ALL PRIVILEGES ON ampache.* TO 'ampache'@'localhost';

Then exit:

MariaDB [(none)]> exit;

Apache Configuration

Create a new virtual host file with a text editor of your choice, for example:

vim /etc/httpd/conf.d/ampache.conf

And paste the following, replacing SERVER_IP with the correct IP address or your FQDN if you wish to use one.

<VirtualHost *:80>
    ServerName SERVER_IP
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html/ampache/
    ErrorLog /var/log/httpd/ampache-error.log
    CustomLog /var/log/httpd/ampache-access.log combined
    <Directory /var/www/html/ampache/>
    AllowOverride All
    </Directory>
</VirtualHost>

Save and exit.

Restart Apache.

systemctl restart httpd.service

Firewalld configuration

Enable HTTP ports in the firewall daemon:

firewall-cmd --add-service http --add-service https --permanent
firewall-cmd --reload

Disabling SELinux

Ampache will not work properly with SELinux enabled. To disable it, open /etc/sysconfig/selinux with a text editor of your choice, and replace SELINUX=enforcing with SELINUX=disabled. You should now either reboot, or execute setenforce 0 to disable SELinux immediately.

Ampache Installation:

You can download the latest stable release with the following command:

wget https://github.com/ampache/ampache/archive/master.tar.gz

Extract and move the resulting directory:

tar -xzf master.tar.gz
mv ampache-master/ /var/www/html/ampache/

Ampache uses composer to install and manage dependencies. Optionally, switch to a non-root user before running composer.

cd /var/www/html/ampache
composer install --prefer-source --no-interaction

Once composer finishes, give Apache full ownership of the ampache web root and its content:

chown -R apache:apache /var/www/html/ampache/

You should be able to access Ampache at http://SERVER_IP/

The remaining configuration will now be done using the web interface. Here are some guidelines:

  1. Select your Preferred Language and press “Start Configuration”
  2. The next page will check if requirements are established.
  3. In the database creation step, fill in the details as follows:
    • Desired Database Name: ampache
    • MySQL Hostname: localhost
    • MySQL port: leave blank
    • MySQL Administrative Username: ampache
    • MySQL Administrative Password: The password chosen during user creation in the MySQL console.
    • Create Database: unchecked
    • Overwrite if database already exists: unchecked
    • Create Tables: checked
    • Create Database User: unchecked
  4. In the configuration generation step:
    • Web Path: /
    • Database Name: ampache
    • MySQL Hostname: localhost
    • MySQL Port: leave blank
    • MySQL Username: ampache
    • MySQL Password: The password chosen during user creation in the MySQL console.
    • Installation type: Assuming you want a fully featured installation for personal use, choose Default.
    • Transcoding Template Configuration: None
    • Players: You should leave these settings unchanged in most cases.
  5. Create Admin Account: Choose a username and password and proceed.

Your Ampache installation is now ready for use. You can login at http://SERVER_IP//login.php

You can read about creating your first catalog in the Ampache wiki.

Optional

If you plan on uploading files via Ampache, you should change the PHP max upload size. Using a text editor of your choice, open the file /etc/php.ini and find the following line:

upload_max_filesize = 2M

Change it to:

upload_max_filesize = 100M

This will allow upload of files up to 100MB in size, you can change this value according to your needs.

Posted in Linux1 Comment

Installing Ampache on CentOS 7.

Posted on February 5, 2019 - May 1, 2020 by nxnjz

Ampache requires a web server, PHP, and a MySQL database. We will be using Apache, PHP 7, and MariaDB to fulfill these requirements.

Installing the web stack and other required packages.

yum update -y
yum install -y httpd mariadb-server mariadb wget yum-utils epel-release git

And make sure Apache and MariaDB are enabled and running:

systemctl enable --now mariadb.service httpd.service

Installing PHP7.2

The default PHP version in CentOS repositories is not recent enough for Ampache. We will install PHP 7.2 from a third party repository.

yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
yum-config-manager --enable remi-php72
yum install php php-common php-pdo php-cli php-mysql php-xml php-gd

Installing Composer.

Composer will be used to install additional PHP dependencies for Ampache.

Run the following command to download composer’s installation script:

wget https://getcomposer.org/installer -O composer-setup.php

And execute it:

php composer-setup.php --install-dir=/usr/local/bin --filename=composer

Installing FFmpeg

FFmpeg will be used for audio and video encoding/decoding. It isn’t available in official CentOS repositories, hence the need for the third-party repo known as Nux Dextop.

Install Nux Dextop:

rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm

FFmpeg can now be installed with:

yum install -y ffmpeg

Database Configuration

Start by running the built-in MariaDB secure installation program:

mysql_secure_installation

When prompted for Y/n answers, choose Y for all questions and make sure you set a strong password.

Ampache requires a database and a MySQL user. Enter the MySQL console:

mysql -u root -p

Create a database named ampache:

MariaDB [(none)]> CREATE DATABASE ampache;

Create a local user named ampache;

MariaDB [(none)]> CREATE USER 'ampache'@'localhost' IDENTIFIED BY 'ampache_password';

Replace ampache_password with a password of your choice.

And grant that user full access to its respective database:

MariaDB [(none)]> GRANT ALL PRIVILEGES ON ampache.* TO 'ampache'@'localhost';

Then exit:

MariaDB [(none)]> exit;

Apache Configuration

Create a new virtual host file with a text editor of your choice, for example:

vim /etc/httpd/conf.d/ampache.conf

And paste the following, replacing SERVER_IP with the correct IP address or your FQDN if you wish to use one.

<VirtualHost *:80>
    ServerName SERVER_IP
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html/ampache/
    ErrorLog /var/log/httpd/ampache-error.log
    CustomLog /var/log/httpd/ampache-access.log combined
    <Directory /var/www/html/ampache/>
    AllowOverride All
    </Directory>
</VirtualHost>

Save and exit.

Restart Apache.

systemctl restart httpd.service

Firewalld configuration

Enable HTTP ports in the firewall daemon:

firewall-cmd --add-service http --add-service https --permanent
firewall-cmd --reload

Disabling SELinux

Ampache will not work properly with SELinux enabled. To disable it, open /etc/sysconfig/selinux with a text editor of your choice, and replace SELINUX=enforcing with SELINUX=disabled. You should now either reboot, or execute setenforce 0 to disable SELinux immediately.

Ampache Installation:

You can download the latest stable release with the following command:

wget https://github.com/ampache/ampache/archive/master.tar.gz

Extract and move the resulting directory:

tar -xzf master.tar.gz
mv ampache-master/ /var/www/html/ampache/

Ampache uses composer to install and manage dependencies. Optionally, switch to a non-root user before running composer.

cd /var/www/html/ampache
composer install --prefer-source --no-interaction

Once composer finishes, give Apache full ownership of the ampache web root and its content:

chown -R apache:apache /var/www/html/ampache/

You should be able to access Ampache at http://SERVER_IP/

The remaining configuration will now be done using the web interface. Here are some guidelines:

  1. Select your Preferred Language and press “Start Configuration”
  2. The next page will check if requirements are established.
  3. In the database creation step, fill in the details as follows:
    • Desired Database Name: ampache
    • MySQL Hostname: localhost
    • MySQL port: leave blank
    • MySQL Administrative Username: ampache
    • MySQL Administrative Password: The password chosen during user creation in the MySQL console.
    • Create Database: unchecked
    • Overwrite if database already exists: unchecked
    • Create Tables: checked
    • Create Database User: unchecked
  4. In the configuration generation step:
    • Web Path: /
    • Database Name: ampache
    • MySQL Hostname: localhost
    • MySQL Port: leave blank
    • MySQL Username: ampache
    • MySQL Password: The password chosen during user creation in the MySQL console.
    • Installation type: Assuming you want a fully featured installation for personal use, choose Default.
    • Transcoding Template Configuration: ffmpeg
    • Players: You should leave these settings unchanged in most cases.
  5. Create Admin Account: Choose a username and password and proceed.

Your Ampache installation is now ready for use. You can login at http://SERVER_IP//login.php

You can read about creating your first catalog in the Ampache wiki.

Optional

If you plan on uploading files via Ampache, you should change the PHP max upload size. Using a text editor of your choice, open the file /etc/php.ini and find the following line:

upload_max_filesize = 2M

Change it to:

upload_max_filesize = 100M

This will allow upload of files up to 100MB in size, you can change this value according to your needs.

Posted in Linux5 Comments

Installing Ampache on Ubuntu 18.04.

Posted on January 27, 2019 - October 25, 2019 by nxnjz

Preparations

Ampache requires a web server, PHP, and a MySQL database. We will be using Apache, PHP 7.2, and MariaDB to fulfill these requirements.

Installing the web stack and other required packages.

apt update
apt install -y apache2 mariadb-server mariadb-client php7.2 php7.2-common php7.2-mysql php7.2-curl php7.2-xml php7.2-gd composer ffmpeg

And make sure Apache and MariaDB are enabled and running:

systemctl enable --now mariadb.service apache2.service

Database Configuration

Start by running the built-in MariaDB secure installation program:

mysql_secure_installation

When prompted for Y/n answers, choose Y for all questions and make sure you set a strong password.

Ampache requires a database and a dedicated MySQL user. Enter the MySQL console:

mysql -u root -p

Create a database named ampache:

MariaDB [(none)]> CREATE DATABASE ampache;

Create a local user named ampache;

MariaDB [(none)]> CREATE USER 'ampache'@'localhost' IDENTIFIED BY 'ampache_password';

Replace ampache_password with a password of your choice.

And grant that user full access to its respective database:

MariaDB [(none)]> GRANT ALL PRIVILEGES ON ampache.* TO 'ampache'@'localhost';

Then exit:

MariaDB [(none)]> exit;

Apache Configuration

 

Create a new virtual host file with a text editor of your choice, for example:

vim /etc/apache2/sites-available/ampache.conf

And paste the following, replacing SERVER_IP with the correct IP address or your FQDN if you wish to use one.

<VirtualHost *:80>
    ServerName SERVER_IP
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html/ampache/
    ErrorLog ${APACHE_LOG_DIR}/ampache-error.log
    CustomLog ${APACHE_LOG_DIR}/ampache-access.log combined
    <Directory /var/www/html/ampache/>
    AllowOverride All
    </Directory>
</VirtualHost>

Enable this virtual host:

a2ensite ampache.conf

Enable required Apache modules:

a2enmod rewrite
a2enmod expires

Restart Apache for the changes to take effect:

systemctl restart apache2.service

Ampache Installation:

You can download the latest stable release with the following command:

wget https://github.com/ampache/ampache/archive/master.tar.gz

Extract and move the resulting directory:

tar -xzf master.tar.gz
mv ampache-master/ /var/www/html/ampache/

Ampache uses composer to install and manage dependencies. Optionally, switch to a non-root user before running composer.

cd /var/www/html/ampache
composer install --prefer-source --no-interaction

Once composer finishes, give Apache full ownership of the ampache web root and its content:

chown -R www-data:www-data /var/www/html/ampache/

You should be able to access Ampache at http://SERVER_IP/

The remaining configuration will now be done using the web interface. Here are some guidelines:

  1. Select your Preferred Language and press “Start Configuration”
  2. The next page will check if requirements are established.
  3. In the database creation step, fill in the details as follows:
    • Desired Database Name: ampache
    • MySQL Hostname: localhost
    • MySQL port: leave blank
    • MySQL Administrative Username: ampache
    • MySQL Administrative Password: The password chosen during user creation in the MySQL console.
    • Create Database: unchecked
    • Overwrite if database already exists: unchecked
    • Create Tables: checked
    • Create Database User: unchecked
  4. In the configuration generation step:
    • Web Path: /
    • Database Name: ampache
    • MySQL Hostname: localhost
    • MySQL Port: leave blank
    • MySQL Username: ampache
    • MySQL Password: The password chosen during user creation in the MySQL console.
    • Installation type: Assuming you want a fully featured installation for personal use, choose Default.
    • Transcoding Template Configuration: ffmpeg
    • Players: You should leave these settings unchanged in most cases.
  5. Create Admin Account: Choose a username and password and proceed.

Your Ampache installation is now ready for use. You can login at http://SERVER_IP//login.php

You can read about creating your first catalog in the Ampache wiki.

Optional

 

If you plan on uploading files via Ampache, you should change the PHP max upload size. Using a text editor of your choice, open the file /etc/php/7.2/apache2/php.ini and find the following line:

upload_max_filesize = 2M

Change it to:

upload_max_filesize = 100M

This will allow upload of files up to 100MB in size, you can change this value according to your needs.

Posted in SQL Injection5 Comments

Installing Ampache on Debian 9.

Posted on January 26, 2019 - October 25, 2019 by nxnjz

Preparations

Ampache requires a web server, PHP, and a MySQL database. We will be using Apache, PHP 7, and MariaDB to fulfill these requirements.

Installing the web stack and other required packages.


apt update
apt install -y apache2 mariadb-server mariadb-client php php-common php-mysql php-curl php-xml composer php-gd ffmpeg

And make sure Apache and MariaDB are enabled and running:

systemctl enable --now mariadb.service apache2.service

Database Configuration

Start by running the built-in MariaDB secure installation program:

mysql_secure_installation

When prompted for Y/n answers, choose Y for all questions and make sure you set a strong password.

Ampache requires a database and a dedicated MySQL user. Enter the MySQL console:
mysql -u root -p

Create a database named ampache:

MariaDB [(none)]> CREATE DATABASE ampache;

Create a local user named ampache;

MariaDB [(none)]> CREATE USER 'ampache'@'localhost' IDENTIFIED BY 'ampache_password';

Replace ampache_password with a password of your choice.

And grant that user full access to its respective database:
MariaDB [(none)]> GRANT ALL PRIVILEGES ON ampache.* TO 'ampache'@'localhost';

Then exit:

MariaDB [(none)]> exit;

Apache Configuration

Create a new virtual host file with a text editor of your choice, for example:

vim /etc/apache2/sites-available/ampache.conf

And paste the following, replacing SERVER_IP with the correct IP address or your FQDN if you wish to use one.


<VirtualHost *:80>
    ServerName SERVER_IP
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html/ampache/
    ErrorLog ${APACHE_LOG_DIR}/ampache-error.log
    CustomLog ${APACHE_LOG_DIR}/ampache-access.log combined
    <Directory /var/www/html/ampache/>
    AllowOverride All
    </Directory>
</VirtualHost>

Enable this virtual host:

a2ensite ampache.conf

Enable required Apache modules:


a2enmod rewrite
a2enmod expires

Restart Apache for the changes to take effect:

systemctl restart apache2.service

Ampache Installation:

 

You can download the latest stable release with the following command:

wget https://github.com/ampache/ampache/archive/master.tar.gz

Extract and move the resulting directory:


tar -xzf master.tar.gz
mv ampache-master/ /var/www/html/ampache/

Ampache uses composer to install and manage dependencies. Optionally, switch to a non-root user before running composer.


cd /var/www/html/ampache
composer install --prefer-source --no-interaction

Once composer finishes, give Apache full ownership of the ampache web root and its content:

chown -R www-data:www-data /var/www/html/ampache

You should be able to access Ampache at http://SERVER_IP/

The remaining configuration will now be done using the web interface. Here are some guidelines:

  1. Select your Preferred Language and press “Start Configuration”
  2. The next page will check if requirements are established.
  3. In the database creation step, fill in the details as follows:
    • Desired Database Name: ampache
    • MySQL Hostname: localhost
    • MySQL port: leave blank
    • MySQL Administrative Username: ampache
    • MySQL Administrative Password: The password chosen during user creation in the MySQL console.
    • Create Database: unchecked
    • Overwrite if database already exists: unchecked
    • Create Tables: checked
    • Create Database User: unchecked
  4. In the configuration generation step:
    • Web Path: /
    • Database Name: ampache
    • MySQL Hostname: localhost
    • MySQL Port: leave blank
    • MySQL Username: ampache
    • MySQL Password: The password chosen during user creation in the MySQL console.
    • Installation type: Assuming you want a fully featured installation for personal use, choose Default.
    • Transcoding Template Configuration: ffmpeg
    • Players: You should leave these settings unchanged in most cases.
  5. Create Admin Account: Choose a username and password and proceed.

Your Ampache installation is now ready for use. You can login at http://SERVER_IP//login.php

You can read about creating your first catalog in the Ampache wiki.

Optional

 

If you plan on uploading files via Ampache, you should change the PHP max upload size. Using a text editor of your choice, open the file /etc/php/7.0/apache2/php.ini and find the following line:

upload_max_filesize = 2M

Change it to:

upload_max_filesize = 100M

This will allow upload of files up to 100MB in size, you can change this value according to your needs.

Posted in Linux1 Comment

Deploying an Interactive SSH Honeypot on CentOS 7.

Posted on January 12, 2019 - November 23, 2019 by nxnjz

Updated CentOS 8 version: How to Set Up an Interactive SSH Honeypot on CentOS 8.

Introduction

A honeypot is a piece of software or a system that is designed to detect and monitor malicious activity, and deflect attackers from your actual production services and systems. This article will explain the deployment of an interactive SSH honeypot using Cowrie, a free and open-source solution. It can log brute force connection attempts and any commands executed by attackers. Additionally, it employs a fake, isolated filesystem for better interaction and deception. A CentOS 7 Server will be used for this tutorial. Or see the instructions for CentOS 8, Ubuntu 18.04, or Debian 9.

NOTE You can obtain a temporary root shell by running sudo -i or sudo su root or sudo /bin/bash if you only have access to a non-root user with sudo privileges.

Preparations

Step 1: Update your system:


yum upgrade -y

Step 2: Create a new user account


adduser cowrie 

A new user will be created, which will be used to run cowrie.

Step 3: Install dependencies and required packages:

This can be done with the command:

yum install -y python-virtualenv git gcc

Step 4: Firewall Configuration

Cowrie will initially run on port 2222. We will temporarily enable external traffic to this port for testing purposes before using port forwarding (explained in later steps).


firewall-cmd --add-port 2222/tcp

Installation:

Step 5: Login as the ‘cowrie’ user.


su cowrie

Step 6: Download the cowrie repository.

Make sure your working directory is “/home/cowrie”

cd /home/cowrie

Cowrie’s code is hosted on github, and can be downloaded with the following command:

git clone http://github.com/cowrie/cowrie

This will download and create a directory ‘cowrie’.

Step 7: Create a python virtualenv.

Virtualenv is a python-based way of running software inside an isolated environment, somewhat similarly to containers.


cd /home/cowrie/cowrie
virtualenv --python=python2.7 cowrie-env

This will install any missing dependencies and create the required python virtual environment in which our honeypot will run.

Enter this environment with:

. cowrie-env/bin/activate

If successful, you should get a new terminal prompt starting with “(cowrie-env)”. Execute the following to upgrade python-pip and then install the requirements for the cowrie honeypot.


pip install --upgrade pip
pip install --upgrade -r requirements.txt

Once finished, exit the virtualenv with deactivate.

Step 8: Start the honeypot.

Execute this command:


bin/cowrie start

And exit back to your root shell:

exit

You can make sure that the honeypot is running by issuing:

ss -lntp | grep twistd

You should get:

LISTEN     0      50           *:2222 [...]

Step 9: Test the honeypot

You can test this SSH honeypot by connecting to your server via SSH, but on port 2222/tcp. You should be able to authenticate with the username “root” and any password. You’ll get access to a simulated shell environment in a fake filesystem.

Further Configuration

For a proper honeypot, some configuration changes need to be made. First, we will change the default real SSHD port from 22 to something else, then we will have the honeypot listen on port 22, since attackers mostly target the default SSHD port.

Begin by stopping the honeypot:


/home/cowrie/cowrie/bin/cowrie stop

Step 10: Changing ports.

First, we’ll change the default SSHD port. Port 2332 will be used as an example. You can choose any port number, but make sure it is unused by other services. You shouldn’t use the port on which he honeypot listens (2222)
In your root shell, issue the following command:
MAKE SURE you use the same port number in the two following commands to avoid losing SSH access.


echo "Port 2332" >> /etc/ssh/sshd_config

Then enable this new port in the firewall daemon:


firewall-cmd --add-port 2332/tcp --permanent
firewall-cmd --reload

And restart the SSH daemon service:

systemctl restart sshd.service

Then logout:

exit

Reconnect to your server via SSH on the newly configured port 2332. We will now configure the firewall daemon to listen for SSH connection attempts on the default SSH network port (22) and forward them to our honeypot.

firewall-cmd --add-masquerade --permanent
firewall-cmd --add-forward-port=port=22:proto=tcp:toport=2222 --permanent
firewall-cmd --reload

Once cowrie is started, any SSH connection attempt to the default port should now reach our honeypot and not the real SSH daemon.

Log in as the ‘cowrie’ user and launch the honeypot:


su cowrie
/home/cowrie/cowrie/bin/cowrie start

Step 10: Configuring allowed users.

While legitimate users and their passwords are stored in ‘/etc/passwd’ and ‘/etc/shadow’, fake SSH users are configured in ‘etc/userdb.txt’ in the cowrie environment. You can choose which users are allowed to connect to the fabricated SSH server, and their passwords.

The following format is used to define users and passwords:


[username]:x:[password]

Each user should be on a separate line (does not have to be a real existing user on your system), and you can define more than one password per user. If you prepend the ‘!’ character to a password, any authentication attempt with that password will be refused. If you insert the wildcard character ‘*’ instead of a password, any password will be accepted. For instance:


root:x:!toor
root:x:!admin
root:x:*
admin:x:admin

With the above configuration, the ‘root’ user will be allowed to authenticate with any password, except ‘toor’ and ‘admin’. The ‘admin’ user will only be allowed be login with ‘admin’ as password.

The default configuration is:


root:x:!root
root:x:!123456
root:x:!/honeypot/i
root:x:*
tomcat:x:*
oracle:x:*

To change the default, start by creating a file in ‘/home/cowrie/cowrie/etc/’ named ‘userdb.txt’:

touch /home/cowrie/cowrie/etc/userdb.txt

And using a text editor of your choice, populate this file according to your preferences. Restart cowrie for the changes to take effect:


/home/cowrie/cowrie/bin/cowrie stop
/home/cowrie/cowrie/bin/cowrie start

Conclusion

This article explained the deployment of an interactive SSH honeypot and its basic configuration. Connection attempts, shell activity and other details are logged to /home/cowrie/cowrie/var/log/cowrie. You may use a logging server to store and display honeypot logs instead, but that is beyond the scope of this article. The collected data from the honeypot can be used to populate IP blacklists, to identify potential attacks, and for cybersecurity research purposes.

Posted in LinuxLeave a comment

Deploying an Interactive SSH Honeypot on Ubuntu 18.04.

Posted on January 12, 2019 - November 27, 2019 by nxnjz

Updated on November 26, 2019

Introduction

A honeypot is a piece of software or a system that is designed to detect and monitor malicious activity, and deflect attackers from your actual production services and systems. This article will explain the deployement of an interactive SSH honeypot using Cowrie, a free and open-source solution. It can log brute force connection attempts and any commands executed by attackers. Additionally, it employs a fake, isolated filesystem for better interaction.

A Ubuntu 18.04 Server will be used for this tutorial. You can find instructions for Debian 9 here, and CentOS 8 here.

Preparations

Step 1: Update your system

apt update
apt upgrade -y

Step 2: Create a new user account for Cowrie


adduser --disabled-password cowrie

Step 3: Install dependencies and required packages:


apt install -y iptables iptables-persistent linux-libc-dev make virtualenv python-virtualenv libfakeroot libssl-dev libffi-dev build-essential libpython3-dev python3-minimal authbind git

You will be prompted to choose whether current iptables rules should be saved. Select Yes.

Installing Cowrie

Step 4: Login as the cowrie user

su - cowrie

Step 5: Download the cowrie repository

Make sure your current working directory is /home/cowrie

cd /home/cowrie

Cowrie’s code is hosted on github, download it with:

git clone http://github.com/cowrie/cowrie

Step 6: Create a python virtualenv

A Python virtual environment provides a stable and isolated environment for Cowrie’s Python dependencies. Change into the cloned directory and create a Python virtual environment:


cd cowrie/
virtualenv --python=/usr/bin/python3 cowrie-env

Activate it with:

. cowrie-env/bin/activate

Install the required Python libraries:


pip install --upgrade -r requirements.txt

Once finished, exit the virtualenv with deactivate.

Step 7: Start and test the honeypot

To do so, run:

bin/cowrie start 

You can test this SSH honeypot by connecting to your server via SSH, but on port 2222/tcp. You should be able to authenticate with the username “root” and (almost) any random password. Once you’re satisfied, stop Cowrie:

bin/cowrie stop

Step 8: Systemd service

While still logged in as cowrie , open bin/cowrie using your text editor:

cd /home/cowrie/cowrie/
vim bin/cowrie

Find the following line:

DAEMONIZE=""

And change it to:

DAEMONIZE="-n"

Save your changes and then exit back to your root shell:

exit

Create a new Systemd unit file with your text editor:

vim /etc/systemd/system/cowrie-honeypot.service

Enter the following:

[Unit]
Description=Interactive SSH Honeypot
Wants=network.target
[Service]
Type=simple
User=cowrie
Group=cowrie
ExecStart=/home/cowrie/cowrie/bin/cowrie start
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

Save and exit, then start the service:

systemctl daemon-reload
systemctl start cowrie-honeypot.service

You can check if it is running with:

systemctl status cowrie-honeypot.service

If you want the honeypot to start automatically after boot, execute:

systemctl enable cowrie-honeypot.service

Further Configuration

Using default SSH port for the honeypot

You are much more likely to get connection attempts if the honeypot listens on the default SSH port, 22. But first, change the port number used by the real SSH server. Port 2332 is used as an example, but you can use any port as long as it is not being used by other services.

As root, configure the OpenSSH daemon to use port 2332:

echo "Port 2332" >> /etc/ssh/sshd_config

And restart the SSH daemon:

systemctl restart sshd.service

Then logout:

exit

Reconnect to your server via SSH but on port 2332 instead.

To enable IP forwarding, edit /etc/sysctl.conf :

vim /etc/sysctl.conf

Find and uncomment the following line:

#net.ipv4.ip_forward=1

Create an iptables rule to forward incoming connections to port 22 to port 2222:

iptables -A PREROUTING -t nat -p tcp --dport 22 -j REDIRECT --to-port 2222

Save it so it persists after reboots:

iptables-save > /etc/iptables/rules.v4

Honeypot User Accounts

While legitimate users and their passwords are stored in /etc/passwd and /etc/shadow, fake SSH users are configured in ‘etc/userdb.txt’ in the cowrie environment. You can choose which users are allowed to connect to the honeypot server, and their passwords.

The following format is used to define users and passwords:


[username]:x:[password]

Each user should be on a seperate line (does not have to be a real existing user on your system), and you can define more than one password per user. If you prepend the ‘!’ character to a password, any authentication attempt with that password will be refused. If you insert the wildcard characted ‘*’ instead of a password, any password will be accepted. For instance:


root:x:!toor
root:x:!admin
root:x:*
admin:x:admin

With the above configuration, the ‘root’ user will be allowed to authenticate with any password, except ‘toor’ and ‘admin’. The ‘admin’ user will only be allowed be login with ‘admin’ as password.

The default configuration is:


root:x:!root
root:x:!123456
root:x:!/honeypot/i
root:x:*
tomcat:x:*
oracle:x:*

To change the default, start by creating a file in /home/cowrie/cowrie/etc/ named userdb.txt:

vim /home/cowrie/cowrie/etc/userdb.txt

Populate it and then give ownership to the cowrie user:

chown cowrie:cowrie /home/cowrie/cowrie/etc/userdb.txt

Restart Cowrie to apply the changes:

systemctl restart cowrie-honeypot.service

Posted in Linux1 Comment

Deploying an Interactive SSH Honeypot on Debian 9.

Posted on January 12, 2019 - February 6, 2019 by nxnjz

Introduction

A honeypot is a piece of software or a system that is designed to detect and monitor malicious activity, and deflect attackers from your actual production services and systems. This article will explain the deployement of an interactive SSH honeypot using Cowrie, a free and open-source solution. It can log brute force connection attempts and any commands executed by attackers. Additionally, it employs a fake, isolated filesystem for better interaction and deception. A Debian 9 Server will be used for this tutorial. You can find instructions for Ubuntu 18.04 here, and CentOS 7 here.

Root privileges are obviously required.

NOTE You can obtain a temporary root shell by running sudo -i or sudo su root or sudo /bin/bash if you only have access to a non-root user with sudo privileges.

Preparations

Step 1: Update your system:


apt update
apt upgrade -y

Step 2: Create a new user account


adduser --disabled-password cowrie

After running this command you will be prompted for the following information:


Full Name []: 
Room Number []: 
Work Phone []: 
Home Phone []: 
Other []: 

Leave the fields empty (press enter.)

Step 3: Install dependencies and required packages:

This can be done with the command:


apt install -y python-virtualenv libssl-dev libffi-dev build-essential libpython3-dev python3-minimal authbind git

Installation:

Step 4: Login as the ‘cowrie’ user.


su - cowrie

Step 5: Download the cowrie repository.

Make sure your working directory is “/home/cowrie”


cd /home/cowrie

Cowrie’s code is hosted on github, and can be downloaded with the following command:

git clone http://github.com/cowrie/cowrie

This will download and create a directory ‘cowrie’.

Step 6: Create a python virtualenv.

Virtualenv is a python-based way of running software inside an isolated environment, somewhat similarly to containers.


cd /home/cowrie/cowrie
virtualenv --python=python3 cowrie-env

This will install any missing dependencies and create the required python virtual environment in which the honeypot will run.

Enter this environment with:


. cowrie-env/bin/activate

If successful, you should get a new terminal prompt starting with “(cowrie-env)”. Execute the following to upgrade python-pip and then install the requirements for cowrie.


pip install --upgrade pip
pip install --upgrade -r requirements.txt

Once finished, exit the virtualenv with deactivate.

Step 7: Start the honeypot.

Execute this command:


bin/cowrie start 

And exit back to your root shell:


exit

You can make sure that the honey port is running by issuing:


ss -lntp | grep twistd

You should get:

LISTEN     0      50           *:2222 [...]

Step 8: Test the honeypot

You can test this SSH honeypot by connecting to your server via SSH, but on port 2222/tcp. You should be able to authenticate with the username “root” and any password. You’ll get access to a simulated shell environment in a fake filesystem.

Further Configuration

For a proper honeypot, some configuration changes need to be made. First, we will change the default real SSHD port from 22 to something else, then we will have the honeypot listen on port 22, since attackers mostly target the default SSHD port.

Begin by stopping the honeypot:


/home/cowrie/cowrie/bin/cowrie stop

Step 9: Changing ports.

First, we’ll change the default SSHD port. Port 2332 will be used as an example. You can choose any port number, but make sure it is unused by other services.
In your root shell, issue the following command:


echo "Port 2332" >> /etc/ssh/sshd_config

And restart the SSH daemon service:


systemctl restart sshd.service

Then logout:


exit

Reconnect to your server via SSH but on the configured port 2332 instead. We will now configure the Cowrie honeypot to listen for SSH connection attempts on the default port number (22). Authbind will be used to allow Cowrie to bind to port 22 without giving it root privileges.

Create an empty file for port 22 in authbind:


touch /etc/authbind/byport/22

Give the ‘cowrie’ user full ownership of that file:


chown cowrie:cowrie /etc/authbind/byport/22

Set the correct permissions:


chmod 770 /etc/authbind/byport/22

Using a text editor of your choice, open the file /home/cowrie/cowrie/bin/cowrie. Change this line:


AUTHBIND_ENABLED=no

To:


AUTHBIND_ENABLED=yes

This will instruct our honeypot software to bind to network ports using authbind and not directly.

Switch to the ‘cowrie’ user:


su - cowrie

And create a configuration file in /home/cowrie/cowrie/etc/ named cowrie.cfg:


touch /home/cowrie/cowrie/etc/cowrie.cfg

This file will be used for our custom configuration changes. Open it in a text editor of your choice and enter the following line:


[ssh]
listen_port = 22

Once cowrie is started, any SSH connection attempt should now reach our honeypot and not the real SSH daemon.

Make sure you are still logged in as the ‘cowrie’ user and launch the honeypot:


/home/cowrie/cowrie/bin/cowrie start

Step 10: Configuring allowed users.

While legitimate users and their passwords are stored in ‘/etc/passwd’ and ‘/etc/shadow’, fake SSH users are configured in ‘etc/userdb.txt’ in the cowrie environment. You can choose which users are allowed to connect to the fabricated SSH server, and their passwords.

The following format is used to define users and passwords:


[username]:x:[password]

Each user should be on a seperate line (does not have to be a real existing user on your system), and you can define more than one password per user. If you prepend the ‘!’ character to a password, any authentication attempt with that password will be refused. If you insert the wildcard characted ‘*’ instead of a password, any password will be accepted. For instance:


root:x:!toor
root:x:!admin
root:x:*
admin:x:admin

With the above configuration, the ‘root’ user will be allowed to authenticate with any password, except ‘toor’ and ‘admin’. The ‘admin’ user will only be allowed be login with ‘admin’ as password.

The default configuration is:


root:x:!root
root:x:!123456
root:x:!/honeypot/i
root:x:*
tomcat:x:*
oracle:x:*

To change the default, start by creating a file in ‘/home/cowrie/cowrie/etc/’ named ‘userdb.txt’:


touch /home/cowrie/cowrie/etc/userdb.txt

And using a text editor of your choice, populate this file according to your preferences. Restart cowrie for the changes to take effect:


/home/cowrie/cowrie/bin/cowrie stop
/home/cowrie/cowrie/bin/cowrie stop

Conclusion

This article explained the deployement of an interactive SSH honeyport and its basic configuration. Connection attempts, shell activity and other details are logged to /home/cowrie/cowrie/var/log/cowrie. You may use a logging server to store and display honeypot logs instead, but that is beyond the scope of this article. The collected data from the honeypot can be used to populate IP blacklists, to identify potential attacks, and for cybersecurity research purposes.

Posted in LinuxTagged debian, linux, sshLeave a comment

Monitoring system resources and Apache with Monit.

Posted on November 6, 2018 - November 6, 2018 by nxnjz

Introduction

Monit is a simple yet powerful monitoring tool that can automatically restart services/processes and send email alerts.
It has a clean web interface that runs on its own HTTP server. The steps described below should work on Debian and other Debian-based distros, including Ubuntu.

 

Installation and Configuration

Install Monit and stop it.

 

First, install Monit: apt install monit


Then stop it while we configure it: systemctl stop monit

 

Basic Configuration

 

By default, Monit configuration files are in /etc/monit.
monitrc is the main configuration file, others may be added in /etc/monit/conf.d and /etc/monit/conf-enabled

Monit can be configured to monitor any process/service/file. For this tutorial I’ll configure it to monitor system resources, network connectivity and bandwidth, and the apache2 service.

First, move to the configuration directory: cd /etc/monit

Then, make a backup of monitrc: cp monitrc monitrc.old

And clear the config file: echo "" > monitrc

We can now safely modify monitrc and we have a backup in case something goes wrong with the configuration. After every configuration change, it is recommended to run monit -t to check the monitrc file and others config files for errors. The output should be “Control file syntax OK”.

Open monitrc with a text editor of your choice.

If you want monit to have a web interface for monitoring, add the following lines:

set httpd port 2813
  allow username:password

Make sure you replace ‘username’ and ‘password’ with values of your choice. Make sure to choose a strong password.
Monit will now be able to serve a monitoring interface via http on port 2813. To access it, you would use http://your-ip:2813 and enter your login credentials. At the moment, the interface will be inaccessible.

We now need to set up some things that allow monit to work properly. These are an ID file where monit stores a hash, a state file where it stores state information, a directory where events will be stored, and a log file where it can write logs. In this tutorial, we will use default locations. You generally will not need to change these. Add the following to the monitrc file:

set logfile /var/log/monit.log
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state

set eventqueue
   basedir /var/lib/monit/events # set the base directory where events will be stored
   slots 100                     # optionally limit the queue size

You can choose how often you want monit to perform checks. For example, for checks to be performed every 30 seconds, add the following:

set daemon 30

Email/Alert Config

For emails, you need an email server running. Assuming you have that already and that you want email alerts, add the following lines (replacing “your-email@your-domain.your-tld” with your email address)


set mailserver localhost
set alert your-email@your-domain.your-tld

Monitoring of system and network resources.

For system load, CPU usage, memory (RAM) usage, network connectivity, bandwidth and swap file/partition usage to be monitored and alerts to be sent in case of excessive load/consumption, the following is needed:

check system $HOST
  if loadavg (1min) > 4 then alert
  if loadavg (5min) > 2 then alert
  if cpu usage > 95% for 10 cycles then alert
  if memory usage > 85% then alert
  if swap usage > 25% then alert
check network public with interface ens3
  if changed link then alert
  if saturation > 90% then alert
  if total uploaded > 1 GB in last hour then alert

Let’s explain these lines.

The first line tells monit to check the system and give it a name, $HOST, which equals the hostname of your VPS.

The second and third lines tells monit to send alerts if system load is higher than 2 for 5 minutes, or higher than 4 for one minute. If your server is under constant heavy load, you may choose to modify these values.

The following 3 lines instruct monit to send alert if CPU, memory, swap usage are higher than 95, 85, and 25% respectively. You can also modify these values to your liking, but the ones provided here and considered reasonable.
The last 4 lines direct monit to check the network interface (You may need to replace ‘ens3’ with your external network interface name) And to send alerts if connectivity goes down, or if the interface is saturated above 90%, or if more than 1GB was uploaded in the last hour. Change ‘1 GB’ according to your network activity.

Apache Monitoring

For apache, monitoring is simple: Check that apache is running and listening on the defined port. If not, restart it.

check process apache with pidfile /run/apache2/apache2.pid
group www
    start program = "/bin/systemctl start apache2"
    stop  program = "/bin/systemctl stop apache2"
if failed host localhost port 80 
    protocol HTTP request "/" then restart

Final checks and deployment

Almost done!

Since we stopped monit, we need to start it with systemctl start monit
Check that our configuration is fine with monit -t

If you followed this tutorial correctly, you should now be able to access the interface and receive alerts. The web interface should now look like the following:

 

monit web interface

Posted in LinuxTagged apache, cpu, linux, memory, monitLeave a comment

UnHashIt : Simple hash lookup tool

Posted on September 12, 2018 - May 16, 2020 by nxnjz

I updated my previous script to include support for the API on hashes.org, thus it is not limited to MD5 anymore. An API key is required if you choose to use hashes.org. You can get a key here.

Usage is very simple: execute without arguments, choose which API you want to use and enter the name of the file containing the hashes. If using the hashes.org API, you have the option of automatically storing you key in a file to avoiding entering it each time you run the script.

Do NOT use this for illegal purposes.


git clone https://github.com/nxnjz/unhashit.git

cd unhashit

./unhashit.py

 

Requirements: Python3 with the sys, os and requests modules.

Output is in the following format:

hash : plain-text-value : algorithm (if found)

hash : “notfound” (if not found)

 

Github Repository

 


The following code is outdated, you should get it from github.

#!/usr/bin/python3

#NXNJZ.NET

import sys
import os
import requests


def key_mng():
    try:
        global apikey
        apikey_file = open("hashes.org-api.key",)
        apikey = apikey_file.read()
    except FileNotFoundError:
        apikey = input("The file 'hashes.org-api.key' containing the api key was not found, enter your api key: ")
        savefile = input("\nWould you like to store this key in a file to avoid entering it every time? (y/n): ")
        if savefile == 'y':
            with open("hashes.org-api.key", "w") as apikey_file :
                apikey_file.write(apikey)
                os.chmod("hashes.org-api.key", 0o600)
                print("\nYour key was written to hashes.org-api.key, permissions set to rw------- (owner read/write, group nothing, others nothing)")

def multi_check(apikey, multi_hash):
    apiurl = "https://hashes.org/api.php?key=" + apikey + "&query=" + multi_hash
    rr = requests.get(apiurl)
    if rr.json()['status'] == 'success':
        try:
            plaintxt = rr.json()['result'][multi_hash]['plain']
            algo = rr.json()['result'][multi_hash]['algorithm']
            result = multi_hash + " : " + plaintxt + " : " + algo
        except TypeError:
            result = multi_hash + " : notfound"
        print(result)
    else:
        print("Error querying the hashes.org API, you may have overused it in a short period of time. ")


def md5_check(md5hash):
   apiurl = "http://www.nitrxgen.net/md5db/" + str(md5hash)
   r = requests.get(apiurl)
   if r.text != "":
       result = md5hash + " : " + r.text + " : MD5"
   else:
       result = md5hash + " : notfound"
   print(result)

print("This script uses APIs on nitrxgden.net and hashes.org. Do NOT use for illegal purposes\n")
print("\n1. Nitrxgen.net (MD5 only, unlimited requests)")
print("\n2. Hashes.org (API key required, 100 requests per 5 minutes allowed)")
api_choice = input("\n\n Choose: ")

if api_choice == '1':
    filename = input("Enter filename (one MD5 hash per line): ")
    with open(filename) as md5_file:
        for line in md5_file:
            md5_check(line.strip())
elif api_choice == '2':
    key_mng()
    filename = input("Enter filename (one hash per line): ")
    with open(filename) as multi_file:
        for line in multi_file:
            multi_check(apikey, line.strip())


else: print("Choice not recognized, exiting.")
Posted in Password CrackingTagged hashes, md5, password, sha1Leave a comment

Linux Privilege Escalation Checklist

Posted on August 24, 2018 - July 7, 2020 by nxnjz

Useful for both pentesters and systems administrators, this checklist is focused on privilege escalation on GNU/Linux operating systems. Many of these will also apply to Unix systems, (FreeBSD, Solaris, etc.) and some may apply to Windows. The following information is based on the assumption that you have CLI access to the system as non-root user.

This list is far from complete, it will be periodically updated.

 

  • Are there any hashes in /etc/passwd? If so, can they be cracked quickly? (JtR, HashCat)
  • Is /etc/shadow readable? If so, are the hashes easily crackable?
  • Is /etc/passwd or /etc/shadow writeable?
  • Any passwords in configuration or other files? Is the root password one of those?
  • Does the current user have sudo rights at all? If so, how can they be abused?
  • Check /home, /root, /etc/ssh for readable private ssh keys.
  • Check /home, /root, /etc/ssh for writeable public ssh keys. (authorized_keys) . If not, can an authorized_keys file be created for another user?
  • Kernel exploits?
  • Check for SUID/SGID files that may give you read/write/execute access to sensitive files.
  • Vulnerable/exploitable SUID/SGID executables.
  • Vulnerable/exploitable files with special capabilities. (This is detailed here)
  • Vulnerable/exploitable services running as another user/root, or that allow shell commands or other system access? (VNC as root for example)
  • Are shell rc files (.bashrc, .zshrc, .profile, etc.) writeable? If so, malicious commands can be added to that file, will run when the user/root logs in.
  • Writeable cron jobs, or other executables/scripts that are run by root.
  • Replaceable/writeable modules/libraries that are used by privileged executables/scripts/processes.
  • Writeable configuration files (*.conf) that are used by privileges executables/scripts/processes.
  • Are there any interesting files in /var/mail/ or /home/*/? Any passwords or useful info in /home/*/.bash_history?
Posted in Privilege EscalationTagged linux, privescLeave a comment

Posts navigation

Older posts
Newer posts

Recent Posts

  • CVE-2021-42052 full disclosure
  • How to Set Up an Interactive SSH Honeypot on CentOS 8.
  • HackTheBox.eu Jarvis Writeup
  • How to setup a simple proxy server with tinyproxy (Debian 10 Buster)
  • How to Install qdPM 9.1 on Debian 10 LEMP

Tags

802.11 ampache apache aspx bash cd centos cms crm cve debian exploits fedora fulldisclosure hackthebox honeypot http httpd ifconfig iw iwconfig labs lfi linux mariadb memory monit music nginx pastebin php privatebin privesc project management proxy reconnoitre selinux shopt ssh systemd txpower ubuntu wallabag wireless xxe

Categories

  • BASH (1)
  • CTF/Labs (2)
  • CVE / full disclosure (1)
  • Information Gathering (1)
  • Linux (25)
  • Password Cracking (1)
  • Privilege Escalation (2)
  • SQL Injection (1)
  • Web-Shells (1)
  • Wifi (2)
  • XXE (1)

Recent Comments

  • Bernard Martiny on How to Install PrivateBin on Ubuntu 18.04 LTS
  • VuCSA on List of security labs/challenges/CTFs
  • Brian on How to Install PrivateBin on Fedora 29.
  • Tyreeb on Installing Ampache on CentOS 7.
  • Christian Mora on Installing Ampache on CentOS 7.