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:


Still wondering which file transfer protocol is right for your business? Here’s a dozen you can choose from. We’ve also added some brief descriptions to make your choice easier.

Hamidreza Talebi

1. FTP (File Transfer Protocol)

When it comes to business file transfers, FTP is probably the first that comes to mind. FTP is built for both single file and bulk file transfers. It’s been around for quite some time, so you likely won’t have problems with interoperability. Meaning, there’ll always be a good chance your trading partner will be able to exchange information through it. You won’t have trouble finding a client application for your end users either.

The downside is, this file transfer protocol is not so strong on security. Hence, if you need to comply with data security/privacy laws and regulations like HIPAA, PCI-DSS, SOX, GLBA, and EU Data Protection Directive, stay away from it. Choose FTP if your business is NOT or does NOT:

  • Operate in a highly regulated industry like healthcare, finance, or manufacturing;
  • Send/receive sensitive files; or
  • Publicly traded (hence governed by SOX).

Another problem with FTP is its susceptibility to firewall issues, which can adversely affect client connectivity. Read Active v.s. Passive FTP Simplified to understand the problem and learn how to resolve it.

2. HTTP (Hypertext Transfer Protocol)

Like FTP, HTTP is a widely used protocol. It’s easy to implement, especially for person-to-server and person-to-person file transfers (read Exploring Use Cases for Managed File Transfer for reference). Users only need a Web browser like Chrome, Firefox, Internet Explorer, or Safari, and they’ll be ready to go. No installation needed on the client side.

HTTP is also less prone to firewall issues (unlike FTP). However, like FTP, HTTP by itself is inherently insecure and incapable of meeting regulatory compliance or securing data. Use HTTP if (lack of) security is not an issue for you.

Recommended post: How to Set Up a Web File Transfer

3. FTPS (FTP over SSL)

The good news is that both FTP and HTTP now have secure versions. FTP has FTPS, while HTTP has HTTPS. Both are protected through SSL. If you use FTPS, you retain the benefits of FTP but gain the security features that come with SSL, including data-in-motion encryption as well as server and client authentication. Because FTPS is based on FTP, you’ll still be subjected to the same firewall issues that come with FTP.

Organizations in the Legal, Government, and Financial Services industry might want to consider FTPS as an option.

Recommended post: Securing Trading Partner File Transfers w/ Auto PGP Encryption & FTPS

4. HTTPS (HTTP over SSL)

As mentioned earlier, HTTPS is the secure version of HTTP. If you don’t like having to install client applications for your end users and most of your end users are non-technical folks, this might be the perfect choice. It’s secure and very user-friendly compared to FTP/S.

Recommended post: How To Set Up A HTTPS File Transfer

5. SFTP (SSH File Transfer Protocol)

Here’s another widely used file transfer protocol that’s perfect for businesses who require privacy/security capabilities. SFTP runs on SSH, a secure protocol that – like SSL – supports data-in-motion encryption and client/server authentication. The main advantage of SFTP over FTPS (which is usually compared to it) is that it’s more firewall-friendly.

Recommended post: Business Benefits Of An SFTP Server

6. SCP (Secure Copy)

This is an older, more primitive version of SFTP. It also runs on SSH, so it comes with the same security features. However, if you’re using a recent version of SSH, you’ll already have access to both SCP and SFTP. Since SFTP has more functionality, I would recommend it over SCP. The only instance you’ll probably need SCP is if you’ll be exchanging files with a company who only has a legacy SSH server.

Recommended post:  Various Linux SCP Examples To Get You Started With Using Secure Copy

7. WebDAV (Web Distributed Authoring and Versioning)

Most of the file transfer protocols we’ve discussed so far are primarily used for file transfers. Here’s one that can do more than just facilitate file transfers. WebDAV, which actually runs over HTTP, is mainly designed for collaboration activities. Through WebDAV, users won’t just be able to exchange files. They’ll also be able to collaborate over a single file even if they’re (the users) working from different locations. WebDAV is probably best suited for organizations who need distributed authoring capabilities, e.g. universities and research institutions.

8. WebDAVS

By now, you should be able to guess what the S stands for. That’s right WebDAVS is a secure version of WebDAV. If WebDAV runs over HTTP, WebDAVS runs over HTTPS. That means, it exhibits the same characteristics of WebDAV, plus the secure features of SSL.

9. TFTP (Trivial File Transfer Protocol)

This file transfer protocol is different from the rest in that you won’t be using it for exchanging documents, images, or spreadsheets. In fact, you nornally won’t be using this for exchanging files with machines outside of your network. TFTP is better suited for network management tasks like network booting, backing up configuration files, and installing operating systems over a network. Why did we include it here? Well, it is a file transfer protocol and you certainly can use it in your business (albeit internally).

If you want to learn more about TFTP, the article What Is TFTP? would be a good place to start.

10. AS2 (Applicability Statement 2)

Although nearly all of the protocols discussed earlier are capable of supporting B2B exchanges, there are a few protocols that are really designed specifically for such tasks. One of them is AS2.

AS2 is built for EDI (Electronic Data Interchange) transactions, the automated information exchanges normally seen in the manufacturing and retail industries. EDI is now also used in healthcare, as a result of the HIPAA legislation (read Securing HIPAA EDI Transactions with AS2). If you operate in these industries or need to carry out EDI transactions, AS2 is an excellent choice.

Recommended post: You Know It’s Time To Implement Server To Server File Transfer When..

11. OFTP (Odette File Transfer Protocol)

Another file transfer protocol specifically designed for EDI is OFTP. OFTP is quite common in Europe, so if you transact with companies there, you might need this. Both OFTP and AS2 are inherently secure and even support electronic delivery receipts (read What Is An AS2 MDN?), making them perfect for B2B transactions.

12. AFTP (Accelerated File Transfer Protocol)

WAN file transfers, especially those carried out over great distances, are easily affected by poor network conditions like latency and packet loss, which result in considerably degraded throughputs. AFTP is a TCP-UDP hybrid that makes file transfers virtually immune to these network conditions. If you want to see the big difference AFTP makes, read the post Accelerated File Transfer In Action.

For a detailed explanation on the effects of latency and packet loss and how AFTP makes them virtually negligible, download the white paper How to Boost File Transfer Speeds 100x Without Increasing Your Bandwidth.

Companies in the Film and Manufacturing industries would find this protocol very useful.


Show Interfaces and Indexes
netsh interface ipv4 show interfaces

Set IPV4 Address

netsh interface ipv4 set address name=”3″(name of index) source=static address= mask= gateway=

Set DNS Address

netsh ipv4 add dnsserver name=”3″ address= index=1

Set IPV6 Address

netsh interface ipv6 add address “3” fe80::12:aaa:b:6

Set DNS Address
netsh interface ipv6 add dnsserver “3” address=fe80::12:aaa:b:6 index=1

showing routing
netstat -rn

Changing Computer Name in PowerShell
rename-computer -newname yourcomputerName -restart

Joining Domain in PowerShell

netdom join yourcomputerName /domain:la.com /UserD:administrator /PasswordD:Password


Native file sharing protocols always win out
In an intranet, network clients have several options, such as AFP, NFS and SMB/CIFS, to connect to their file server. But for the best performance, and 100% compatibility, the native client file sharing protocol is the right choice. So AFP is the best protocol for all Mac clients through OS X 10.8, SMB is the standard for Windows clients, and NFS is perfect between UNIX servers. With the release of OS X 10.9 “Mavericks”, Apple fully supports both SMB2 and AFP.

In addition, remote users should be able to securely access server documents via web browser. And mobile users will appreciate a native app for server access and file sharing to their devices.

NFS(Network File Share)
NFS is good for UNIX server-to-server file sharing. However it is incompatible with Windows clients, and is useless for Mac file sharing clients due to missing features, and compatibility and performance problems with Mac apps.

SMB/CIFS (Server Message Block)
The native Windows network file sharing protocol is the preferred protocol for Windows clients.

AFP(Apple Filing Protocol)
AFP is clearly superior to SMB or NFS for Mac OS 8.1-OS X 10.8 clients

AFP is the native file and printer sharing protocol for Macs and it supports many unique Mac attributes that are not supported by other protocols. So for the best performance, and 100% compatibility, AFP should be used.


source: www.helios.de

RAID is an acronym that stands for Redundant Array of Inexpensive or Redundant Array of Independent Disks. RAID is a term used in computing. With RAID, several hard disks are made into one logical disk.

RAID 0 (Strip)

  • Not Fault Tolerant
  • Performance benefit

RAID 1 (mirror)

  • Fault-Tolerant
  • Performance benefit


  • Fault-Tolerant
  • At least 3 disks
  • performance benefit