The first question is asked by those who are using Cisco devices for the first time is that how can I connect to Cisco devices. It needs kind of cable which is called rollover cable.

Rollover cable
Enter a caption for this image (optional)

rollover cable contains RJ-45 and RS-232 and as it is demonstrated in below picture, RJ-45 is connected to switch and on the other hand RS-232 is connected to PC.

Console to PC
Enter a caption for this image (optional)

Today’s PCs usually don’t have RS-232 port. You have to buy kind of convertor for RS-232 to USB or you can use new rollover cable which is RJ45 to USB.

you can use kind of these software in PC to connect to switch through the console port. Putty is a famous software which supports SSH, Telnet, Serial.

I’ve uploaded a video in Youtube to become familiar how to connect rollover cable to switch and how to connect switch through Putty

Enter a caption (optional)
Hamidreza Talebi, linux

Introduction

When running a website, there are often parts of the site that you’ll want to restrict from visitors. Web applications may provide their own authentication and authorization methods, but the web server itself can also be used to restrict access if these are inadequate or unavailable.

In this guide, we’ll demonstrate how to password-protect assets on an Apache web server running on Ubuntu 16.04.

Prerequisites

In order to complete this tutorial, you will need access to an Ubuntu 16.04 server.

In addition, you will need the following before you can begin:

  • A sudo user on your server: You can create a user with sudo privileges by following the Ubuntu 16.04 initial server setup guide.
  • An Apache2 web server: If you haven’t already set one up, the Apache section of the in-depth article, How To Install Linux, Apache, MySQL, PHP (LAMP) stack on Ubuntu 16.04
    , can guide you.
  • A site secured with SSL: How you set that up depends on whether you have a domain name for your site.
    • If you have a domain name… the easiest way to secure your site is with Let’s Encrypt, which provides free, trusted certificates. Follow the Let’s Encrypt guide for Apache to set this up.
    • If you do not have a domain… and you are just using this configuration for testing or personal use, you can use a self-signed certificate instead. This provides the same type of encryption, but without the domain validation. Follow the self-signed SSL guide for Apache to get set up.

When all of these are in place, log into your server as the sudo user and continue below.

Step 1 — Installing the Apache Utilities Package

We will use a utility called htpasswd, part of the apache2-utils package, to create the file and manage the username and passwords needed to access restricted content.

  • sudo apt-get update
  • sudo apt-get install apache2-utils

Step 2 — Creating the Password File

We now have access to the htpasswd command. We can use this to create a password file that Apache can use to authenticate users. We will create a hidden file for this purpose called .htpasswd within our /etc/apache2 configuration directory.

The first time we use this utility, we need to add the -c option to create the specified file. We specify a username (sammy in this example) at the end of the command to create a new entry within the file:

  • sudo htpasswd -c /etc/apache2/.htpasswd sammy

You will be asked to supply and confirm a password for the user.

Leave out the -c argument for any additional users you wish to add:

  • sudo htpasswd /etc/apache2/.htpasswd another_user

If we view the contents of the file, we can see the username and the encrypted password for each record:

  • cat /etc/apache2/.htpasswd
Output
sammy:$apr1$.0CAabqX$rb8lueIORA/p8UzGPYtGs/
another_user:$apr1$fqH7UG8a$SrUxurp/Atfq6j7GL/VEC1

Step 3 — Configuring Apache Password Authentication

Now that we have a file with users and passwords in a format that Apache can read, we need to configure Apache to check this file before serving our protected content. We can do this in one of two ways: either directly in a site’s virtual host file or by placing .htaccess files in the directories that need restriction. It’s generally best to use the virtual host file, but if you need to allow non-root users to manage their own access restrictions, check the restrictions into version control alongside the website, or have a web applications using .htaccess files for other purposes already, check out the second option.

Choose the option that best suits your needs.

Option 1: Configuring Access Control within the Virtual Host Definition (Preferred)

The first option is to edit the Apache configuration and add the password protection to the virtual host file. This will generally give better performance because it avoids the expense of reading distributed configuration files. This option requires access to the configuration, which isn’t always available, but when you do have access, it’s recommended.

Begin by opening up the virtual host file that you wish to add a restriction to. For our example, we’ll be using the 000-default.conf file that holds the default virtual host installed through Ubuntu’s apache package:

  • sudo nano /etc/apache2/sites-enabled/000-default.conf

Inside, with the comments stripped, the file should look similar to this:

/etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Authentication is done on a per-directory basis. To set up authentication, you will need to target the directory you wish to restrict with a <Directory ___> block. In our example, we’ll restrict the entire document root, but you can modify this listing to only target a specific directory within the web space:

/etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined

  <Directory "/var/www/html">
  </Directory>
</VirtualHost>

Within this directory block, specify that we wish to set up Basic authentication. For the AuthName, choose a realm name that will be displayed to the user when prompting for credentials. Use the AuthUserFile directive to point Apache to the password file we created. Finally, we will require a valid-user to access this resource, which means anyone who can verify their identity with a password will be allowed in:

/etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined

  <Directory "/var/www/html">
      AuthType Basic
      AuthName "Restricted Content"
      AuthUserFile /etc/apache2/.htpasswd
      Require valid-user
  </Directory>
</VirtualHost>

Save and close the file when you are finished.

Before restarting the web server, you can check the configuration with the following command:

  • sudo apache2ctl configtest

If everything checks out and you get Syntax OK, then restart the server to implement your password policy. Since systemctl doesn’t display the outcome of all service management commands, we’ll use the the status to be sure the server is running:

  • sudo systemctl restart apache2
  • sudo systemctl status apache2

Now, the directory you specified should now be password protected.

Option 2: Configuring Access Control with .htaccess Files

Apache can use .htaccess files in order to allow certain configuration items to be set within a content directory. Since Apache has to re-read these files on every request that involves the directory, which can negatively impact performance, Option 1 is preferred, but if you are already using .htaccess file or need to allow non-root users to manage restrictions, .htaccess files make sense.

To enable password protection using .htaccess files, open the main Apache configuration file:

  • sudo nano /etc/apache2/apache2.conf

Find the <Directory> block for the /var/www directory that holds the document root. Turn on .htaccess processing by changing the AllowOverride directive within that block from “None” to “All”:

/etc/apache2/apache2.conf
. . .

<Directory /var/www/>
  Options Indexes FollowSymLinks
  AllowOverride All
  Require all granted
</Directory>

. . .

Save and close the file when you are finished.

Next, we need to add an .htaccess file to the directory we wish to restrict. In our demonstration, we’ll restrict the entire document root (the entire website) which is based at /var/www/html, but you can place this file in any directory where you wish to restrict access:

  • sudo nano /var/www/html/.htaccess

Within this file, specify that we wish to set up Basic authentication. For the AuthName, choose a realm name that will be displayed to the user when prompting for credentials. Use the AuthUserFile directive to point Apache to the password file we created. Finally, we will require a valid-user to access this resource, which means anyone who can verify their identity with a password will be allowed in:

/var/www/html/.htaccess
AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Save and close the file. Restart the web server to password protect all content in or below the directory with the .htaccess file and use systemctl status to verify the success of the restart:

  • sudo systemctl restart apache2
  • sudo systemctl status apache2

Step 4 — Confirming Password Authentication

To confirm that your content is protected, try to access your restricted content in a web browser. You should be presented with a username and password prompt that looks like this:

Apache2 password prompt

If you enter the correct credentials, you will be allowed to access the content. If you enter the wrong credentials or hit “Cancel”, you will see the “Unauthorized” error page:

Apache2 unauthorized error

Conclusion

Congratulations! If you’ve followed along, you’ve now set up basic authentication for your site. Apache configuration and .htaccess can do much more than basic authentication, however. To find out more about the flexibility and power available in Apache configuration, try one of these tutorials:

 

source: digitalocean.com

 

Cowrie is the new fork of the Kippo Honeypot. It has been updated with new features and provides emulation that records the session of an attacker. With this session recording you are able to get a better understanding of the attackers tools, tactics and procedures (TTPs). A term that is increasing being used in Cyber Defence and Incident Response.

Our setup will be very close to a default installation of Cowrie. The hosts SSH daemon will run on a high port (22222), Cowrie will run on 2222 and port 22 (default SSH) will be redirected to 2222 using iptables. So the SSH bot or attacker will connect to port 22 be redirected to our honeypot on 2222. Confused? Take a look at the diagram.

Cowrie Honeypot Layout
A warning before we proceed. Honeypots are designed to allow access to a system by an attacker. This could result in compromise of the host if the honeypot has vulnerabilities or is mis-configured. Understand what you are doing and be very careful if running a honeypot anywhere near production kit.
Change Default SSH Port
Before installing cowrie and our dependencies lets move SSH to port 22222.

root@cowrie:~# vi /etc/ssh/sshd_config
# What ports, IPs and protocols we listen for
Port 22222

root@cowrie1:~# systemctl restart ssh
root@cowrie1:~# systemctl status ssh
? ssh.service – OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2018-03-19 23:21:05 UTC; 5s ago
Main PID: 9242 (sshd)
Tasks: 1
Memory: 1.3M
CPU: 5ms
CGroup: /system.slice/ssh.service
??9242 /usr/sbin/sshd -D

Mar 19 23:21:05 cowrie1 systemd[1]: Stopped OpenBSD Secure Shell server.
Mar 19 23:21:05 cowrie1 systemd[1]: Starting OpenBSD Secure Shell server…
Mar 19 23:21:05 cowrie1 sshd[9242]: Server listening on 0.0.0.0 port 22222.
Mar 19 23:21:05 cowrie1 sshd[9242]: Server listening on :: port 22222.
Mar 19 23:21:05 cowrie1 systemd[1]: Started OpenBSD Secure Shell server.

root@cowrie1:~# netstat -nap | grep 2222
tcp 0 0 0.0.0.0:22222 0.0.0.0:* LISTEN 9242/sshd
tcp6 0 0 :::22222 :::* LISTEN 9242/sshd

We can see SSH is now listening on port 22222 from both the systemctl status as well as the netstat output.

Installation of Cowrie Honeypot on Ubuntu
Firstly we will run apt udpate as we are on a brand new Digital Ocean VPS. Then we will install dependencies and create a Cowrie user. Running a Honeypot as root would be a bad idea.

root@cowrie:~# apt update
root@cowrie:~# apt-get install git python-virtualenv libssl-dev libffi-dev build-essential libpython-dev python2.7-minimal authbind
root@cowrie:~# adduser –disabled-password cowrie
Adding user `cowrie’ …
Adding new group `cowrie’ (1000) …
Adding new user `cowrie’ (1000) with group `cowrie’ …
Creating home directory `/home/cowrie’ …
Copying files from `/etc/skel’ …
Changing the user information for cowrie
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] Y
root@cowrie1:~# su – cowrie
cowrie@cowrie1:~$
Ok, now lets grab the code for Cowrie using git.

cowrie@cowrie1:~$ git clone http://github.com/micheloosterhof/cowrie
Cloning into ‘cowrie’…
remote: Counting objects: 9340, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 9340 (delta 3), reused 2 (delta 0), pack-reused 9330
Receiving objects: 100% (9340/9340), 7.43 MiB | 2.32 MiB/s, done.
Resolving deltas: 100% (6415/6415), done.
Checking connectivity… done.
cowrie@cowrie1:~$
Now we will create a virtual environment for Python and Cowrie to run from:

cowrie@cowrie1:~$ cd cowrie
cowrie@cowrie:~/cowrie$ virtualenv cowrie-env
Running virtualenv with interpreter /usr/bin/python2
New python executable in /home/cowrie/cowrie/cowrie-env/bin/python2
Also creating executable in /home/cowrie/cowrie/cowrie-env/bin/python
Installing setuptools, pkg_resources, pip, wheel…done.
cowrie@cowrie1:~$
Next step is to activate the Python virtual environment and install the python packages that Cowrie needs to run.

cowrie@cowrie1:~/cowrie$ source cowrie-env/bin/activate
(cowrie-env) cowrie@cowrie1:~/cowrie$ pip install –upgrade pip
Requirement already up-to-date: pip in ./cowrie-env/lib/python2.7/site-packages
(cowrie-env) cowrie@cowrie1:~/cowrie$ pip install –upgrade -r requirements.txt
Collecting twisted>=17.1.0 (from -r requirements.txt (line 1))
Downloading Twisted-17.9.0.tar.bz2 (3.0MB)
100% |????????????????????????????????| 3.0MB 403kB/s
Collecting cryptography>=0.9.1 (from -r requirements.txt (line 2))
Downloading cryptography-2.2-cp27-cp27mu-manylinux1_x86_64.whl (2.2MB)
100% |????????????????????????????????| 2.2MB 544kB/s
Collecting configparser (from -r requirements.txt (line 3))
Downloading configparser-3.5.0.tar.gz
Collecting pyopenssl (from -r requirements.txt (line 4))
Downloading pyOpenSSL-17.5.0-py2.py3-none-any.whl (53kB)
100% |????????????????????????????????| 61kB 9.8MB/s
Collecting pyparsing (from -r requirements.txt (line 5))
Downloading pyparsing-2.2.0-py2.py3-none-any.whl (56kB)
100% |????????????????????????????????| 61kB 9.7MB/s
Collecting packaging (from -r requirements.txt (line 6))
Downloading packaging-17.1-py2.py3-none-any.whl
Collecting appdirs>=1.4.0 (from -r requirements.txt (line 7))
Downloading appdirs-1.4.3-py2.py3-none-any.whl
Collecting pyasn1_modules (from -r requirements.txt (line 8))
Downloading pyasn1_modules-0.2.1-py2.py3-none-any.whl (60kB)
100% |????????????????????????????????| 61kB 9.7MB/s
Collecting attrs (from -r requirements.txt (line 9))
Downloading attrs-17.4.0-py2.py3-none-any.whl
Collecting service_identity (from -r requirements.txt (line 10))
Downloading service_identity-17.0.0-py2.py3-none-any.whl
Collecting python-dateutil (from -r requirements.txt (line 11))
Downloading python_dateutil-2.7.0-py2.py3-none-any.whl (207kB)
100% |????????????????????????????????| 215kB 5.4MB/s
Collecting tftpy (from -r requirements.txt (line 12))
Downloading tftpy-0.6.2.tar.gz
Collecting zope.interface>=3.6.0 (from twisted>=17.1.0->-r requirements.txt (line 1))
Downloading zope.interface-4.4.3-cp27-cp27mu-manylinux1_x86_64.whl (170kB)
100% |????????????????????????????????| 174kB 4.1MB/s
Collecting constantly>=15.1 (from twisted>=17.1.0->-r requirements.txt (line 1))
Downloading constantly-15.1.0-py2.py3-none-any.whl
Collecting incremental>=16.10.1 (from twisted>=17.1.0->-r requirements.txt (line 1))
Downloading incremental-17.5.0-py2.py3-none-any.whl
Collecting Automat>=0.3.0 (from twisted>=17.1.0->-r requirements.txt (line 1))
Downloading Automat-0.6.0-py2.py3-none-any.whl
Collecting hyperlink>=17.1.1 (from twisted>=17.1.0->-r requirements.txt (line 1))
Downloading hyperlink-18.0.0-py2.py3-none-any.whl
Collecting cffi>=1.7; platform_python_implementation != “PyPy” (from cryptography>=0.9.1->-r requirements.txt (line 2))
Downloading cffi-1.11.5-cp27-cp27mu-manylinux1_x86_64.whl (407kB)
100% |????????????????????????????????| 409kB 3.0MB/s
Collecting enum34; python_version < “3” (from cryptography>=0.9.1->-r requirements.txt (line 2))
Downloading enum34-1.1.6-py2-none-any.whl
Collecting asn1crypto>=0.21.0 (from cryptography>=0.9.1->-r requirements.txt (line 2))
Downloading asn1crypto-0.24.0-py2.py3-none-any.whl (101kB)
100% |????????????????????????????????| 102kB 9.7MB/s
Collecting idna>=2.1 (from cryptography>=0.9.1->-r requirements.txt (line 2))
Downloading idna-2.6-py2.py3-none-any.whl (56kB)
100% |????????????????????????????????| 61kB 9.5MB/s
Collecting six>=1.4.1 (from cryptography>=0.9.1->-r requirements.txt (line 2))
Downloading six-1.11.0-py2.py3-none-any.whl
Collecting ipaddress; python_version < “3” (from cryptography>=0.9.1->-r requirements.txt (line 2))
Downloading ipaddress-1.0.19.tar.gz
Collecting pyasn1<0.5.0,>=0.4.1 (from pyasn1_modules->-r requirements.txt (line 8))
Downloading pyasn1-0.4.2-py2.py3-none-any.whl (71kB)
100% |????????????????????????????????| 71kB 9.4MB/s
Requirement already up-to-date: setuptools in ./cowrie-env/lib/python2.7/site-packages (from zope.interface>=3.6.0->twisted>=17.1.0->-r requirements.txt (line 1))
Collecting pycparser (from cffi>=1.7; platform_python_implementation != “PyPy”->cryptography>=0.9.1->-r requirements.txt (line 2))
Downloading pycparser-2.18.tar.gz (245kB)
100% |????????????????????????????????| 256kB 4.5MB/s
Building wheels for collected packages: twisted, configparser, tftpy, ipaddress, pycparser
Running setup.py bdist_wheel for twisted … done
Stored in directory: /home/cowrie/.cache/pip/wheels/91/c7/95/0bb4d45bc4ed91375013e9b5f211ac3ebf4138d8858f84abbc
Running setup.py bdist_wheel for configparser … done
Stored in directory: /home/cowrie/.cache/pip/wheels/1c/bd/b4/277af3f6c40645661b4cd1c21df26aca0f2e1e9714a1d4cda8
Running setup.py bdist_wheel for tftpy … done
Stored in directory: /home/cowrie/.cache/pip/wheels/b6/6b/9a/4536837177d943f2aede676c74488f1dd6f2c3c7ef80f8c094
Running setup.py bdist_wheel for ipaddress … done
Stored in directory: /home/cowrie/.cache/pip/wheels/d7/6b/69/666188e8101897abb2e115d408d139a372bdf6bfa7abb5aef5
Running setup.py bdist_wheel for pycparser … done
Stored in directory: /home/cowrie/.cache/pip/wheels/95/14/9a/5e7b9024459d2a6600aaa64e0ba485325aff7a9ac7489db1b6
Successfully built twisted configparser tftpy ipaddress pycparser
Installing collected packages: zope.interface, constantly, incremental, attrs, six, Automat, idna, hyperlink, twisted, pycparser, cffi, enum34, asn1crypto, ipaddress, cryptography, configparser, pyopenssl, pyparsing, packaging, appdirs, pyasn1, pyasn1-modules, service-identity, python-dateutil, tftpy
Successfully installed Automat-0.6.0 appdirs-1.4.3 asn1crypto-0.24.0 attrs-17.4.0 cffi-1.11.5 configparser-3.5.0 constantly-15.1.0 cryptography-2.2 enum34-1.1.6 hyperlink-18.0.0 idna-2.6 incremental-17.5.0 ipaddress-1.0.19 packaging-17.1 pyasn1-0.4.2 pyasn1-modules-0.2.1 pycparser-2.18 pyopenssl-17.5.0 pyparsing-2.2.0 python-dateutil-2.7.0 service-identity-17.0.0 six-1.11.0 tftpy-0.6.2 twisted-17.9.0 zope.interface-4.4.3
Ok, thats the initial setup out of the way. Now we need to configure the Cowrie daemon and get started.

cp cowrie.cfg.dist cowrie.cfg
This creates a config file that we can edit and it won’t be overwritten by updates.

Editing the configuration file we will make a few changes from the defaults. Firstly I will change the hostname seen by a successul login by an attacker, keep it generic and non obvious. Use vim or your favorite text editor to make these changes.

# Hostname for the honeypot. Displayed by the shell prompt of the virtual
# environment
#
# (default: svr04)
hostname = testserver5
The second change I will make is to enable telnet. SSH is enabled by default.

# Enable Telnet support, disabled by default
enabled = true
As you can see in the configuration there are many options and things to play with, from logging and alerting to fake addresses and file downloads.

Finally we are ready to start the daemon.

cowrie@cowrie:~/cowrie$ bin/cowrie start
Using default Python virtual environment “/home/cowrie/cowrie/cowrie-env”
Starting cowrie: [twistd –umask 0022 –pidfile var/run/cowrie.pid –logger cowrie.python.logfile.logger cowrie ]…

cowrie@cowrie:~/cowrie$ netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2223 0.0.0.0:* LISTEN
From the netstat we can see the SSH and Telnet daemons of our honeypot listening on 2222 and 2223 respectively.

Last step is to redirect traffic to 22 and 23 to the high ports 2222 and 2223 using iptables.

root@cowrie:~# iptables -t nat -A PREROUTING -p tcp –dport 22 -j REDIRECT –to-port 2222
root@cowrie:~# iptables -t nat -A PREROUTING -p tcp –dport 23 -j REDIRECT –to-port 2223
Now it is just a waiting game. However, due to the amount of SSH scanning that takes place on the Internet you will not have to wait long.

cowrie@cowrie:~/cowrie$ tail -f log/cowrie.log
Within 5 minutes I could see SSH connections logging in and running commands within my Honeypot.

 

source: https://hackertarget.com/cowrie-honeypot-ubuntu/

Conpot is an ICS honeypot with the goal to collect intelligence about the motives and methods of adversaries targeting industrial control systems. let’s first install Conpot then I explain about this tool:

1- install Docker

if you are running ubuntu17.10, this is a good document for installation, otherwise follow the instruction of Conpot.

2- Run docker pull honeynet/conpot
Run docker run -it -p 80:80 -p 102:102 -p 502:502 -p 161:161/udp –network=bridge honeynet/conpot:latest /bin/sh
Finally run conpot -f –template default

Navigate to http://MY_IP_ADDRESS to confirm the setup.

the result with default template should be like this:

conpot - Hamidreza Talebi

Conpot

Conpot is shipped with a default profile(default.xml) which provides basic emulation of a Siemens S7-200 CPU with a few expansion modules installed. The attack surface of the default emulation includes the protocols MODBUS, HTTP, SNMP and s7comm.

 

 

 

T-Pot is based on the network installer of Ubuntu Server 16.04.x LTS. The honeypot daemons as well as other support components being used have been containerized using docker. This allows us to run multiple honeypot daemons on the same network interface while maintaining a small footprint and constrain each honeypot within its own environment. In T-Pot we combine the dockerized honeypots conpot, cowrie, dionaea, elasticpot, emobility, glastopf, honeytrap, mailoney, rdpy and vnclowpot with ELK stack to beautifully visualize all the events captured by T-Pot, Elasticsearch Head a web front end for browsing and interacting with an Elastic Search cluster, Netdata for real-time performance monitoring, Portainer a web based UI for docker, Spiderfoot a open source intelligence automation tool, Suricata a Network Security Monitoring engine and Wetty a web based SSH client.

 

While data within docker containers is volatile we do now ensure a default 30 day persistence of all relevant honeypot and tool data in the well known /data folder and sub-folders. The persistence configuration may be adjusted in /opt/tpot/etc/logrotate/logrotate.conf. Once a docker container crashes, all other data produced within its environment is erased and a fresh instance is started from the corresponding docker image.

Basically, what happens when the system is booted up is the following:

  • start host system
  • start all the necessary services (i.e. docker-engine, reverse proxy, etc.)
  • start all docker containers via docker-compose (honeypots, nms, elk)

Within the T-Pot project, we provide all the tools and documentation necessary to build your own honeypot system and contribute to our community data view, a separate channel on our Sicherheitstacho that is powered by T-Pot community data.

The source code and configuration files are stored in individual GitHub repositories, which are linked below. The docker images are pre-configured for the T-Pot environment. If you want to run the docker images separately, make sure you study the docker-compose configuration (/opt/tpot/etc/tpot.yml) and the T-Pot systemd script (/etc/systemd/system/tpot.service), as they provide a good starting point for implementing changes.

The individual docker configurations are located in the following GitHub repositories:

This is really good file, if you want to evaluate what is inside bro:

bro_log_vars

Hamidreza Talebi, linux

Today we will be looking into how to setup a centralized log management for Linux servers, this will help the Linux admin to have a multiple server logs into one single place. The Linux admin not required to login in to each servers for checking the logs, he can just login into the centralized server and start do the logs monitoring.

Linux labels (auth, cron, ftp, lpr, authpriv, news, mail, syslog, etc ,..) the log messages to indicate the type of software that generated the messages with severity (Alert, critical, Warning, Notice, info, etc ,..).

You can find more information on Message Labels and Severity Levels

Make sure you have the following to setup log server.

Two Linux servers ( server and client).

server.itzgeek.com 192.168.12.131

client.itzgeek.com 192.168.12.132

Server setup:

Install syslog package, if you do not have it installed.

[root@server ~]# yum -y install rsyslog

Edit /etc/rsyslog.conf

[root@server ~]# vi /etc/rsyslog.conf

Un comment the following to enable the syslog server to listen on the tcp and udp port.
From

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514
 
# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

To

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
 
# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Restart the syslog service

[root@server ~]# systemctl restart rsyslog.service

Verify the syslog server listening.

[root@server ~]# netstat -antup | grep 514
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      759/rsyslogd        
tcp6       0      0 :::514                  :::*                    LISTEN      759/rsyslogd        
udp        0      0 0.0.0.0:514             0.0.0.0:*                           759/rsyslogd        
udp6       0      0 :::514                  :::*                                759/rsyslogd

Client setup:

Install syslog package, if you do not have it installed. Edit /etc/rsyslog.conf

[root@client ~]# vi /etc/rsyslog.conf

At the end of file place the following line to point the client message log to the server

*.info;mail.none;authpriv.none;cron.none   @192.168.12.131

You can either mention @hostname or @ip address.

Restart the syslog service

[root@client ~]# systemctl restart rsyslog.service

Now all the message logs are sent to the central server and also it keeps the copy locally.

Firewall Port opening (Optional):

Mostly all the production environment are protected by hardware firewall, ask them to open the TCP & UDP 514.
If you have IP tables enabled, run the following command on server in order to accept incoming traffic on UDP / TCP port 514.

[root@server ~]#firewall-cmd --permanent --zone=public --add-port=514/tcp
[root@server ~]#firewall-cmd --permanent --zone=public --add-port=514/udp
[root@server ~]#firewall-cmd --reload

You can verify the port opening by issuing the following command from the client.

[root@client ~]# telnet 192.168.12.131 514
 
Trying 192.168.12.131...
Connected to 192.168.12.131.
Escape character is '^]'.

If it didn’t give any reply, disable firewall on both client and server.

Test:

Monitor the activity from the log server, open the message log.

[root@server ~]# tailf /var/log/messages

I have installed and started vsftpd on client machine, you can see both are recorded in syslog server.

Oct  5 06:03:53 client yum[2425]: Installed: vsftpd-3.0.2-9.el7.x86_64
Oct  5 06:04:13 client systemd: Starting Vsftpd ftp daemon...
Oct  5 06:04:13 client systemd: Started Vsftpd ftp daemon.

By this way you can monitor the other logs such as secure, mail, cron logs etc.

also we have these main categories for syslog’s facility:

Hamidreza Taleb

 

source: http://www.itzgeek.com/how-tos/linux/centos-how-tos/setup-syslog-server-on-centos-7-rhel-7.html