ISPConfig released and Security Warning


ISPConfig Patch 3 is available for download. This is a patch release for
ISPConfig that fixes some issues that were found in the last version
and adds several security enhancements.

See changelog link below for a list of all changes that are included in this release.

- IMPORTANT: Security Warning

We received a email notification that a remote root exploit for ISPConfig shall
be released on August 15. The author of this potential exploit did not provide
us with details on the exploit upfront of the planned public release, so we neither
know what it affects nor if it exists at all. If it exists, then we will provide a
fix as soon as possible. If you know any details about the exploit or find the exploit
on the internet, then please contact us by email to dev [at] ispconfig [dot] org.

We highly recommend that you use the new security features below to protect your
system. If possible you should use the .htaccess protection as well until we know
more about the issue.

- UPDATE 2014-08-21 on security warning

We received a message from the person that planned to release the exploit that
he will not release the exploit publicly. We also received some details on the way
it affected ISPConfig. If the details that we have are complete, then the exploit
required a valid ispconfig administrator password. So only the person that administers
the server could attack it, neither clients nor resellers nor persons without
a ispconfig login were able to do the attack. The function related to apache settings
that was misused in conjunction with a third party exploit module is an intended admin
functionality, so one could argue if a correctly authenticated system admin should be
able to configure apache freely trough a web interface or not. In any case, we will add
a set of filters to prevent this kind of access by the admin user. Some users will
miss the functionality that we will disable with the filters, so these filters will be made
configurable trough the system_settings.ini. So every root user can decide then
on its own, if he wants to allow the ispconfig admin user to do this kind of configuration
trough the ISPConfig web interface or not.

- NEW Security Features

This version contains a new set of security settings thats allows the root user
of a server to limit the access of the ispconfig "admin" user. There is also
a new security check script that can warn the root user when changes in
/etc/passwd, /etc/shadow or /etc/group occur or when a additional ispconfig
administrator user is added in ISPConfig.

The settings for the security limits and security check can be found in this file:


A detailed description of all settings can be found in the file


The most important features are


If you want to prevet that shell users for websites get added to your server, then
set this option to "no". If this server is a server that does not host websites like
a mailserver or dns server node, then this option should be set to "no" as well.


If you do not use the remote API, then set this to "no".

admin_allow_* = yes/no/superuser

The admin_allow_* fetaures control which parts of the System module in ISPConfig can
be accessed by the admin user. You should disable all functions that you dont need
in the security settings by setting them to "no". The option "superuser" limits a
function to the administrator with userid = 1, so if you created additional administrators,
then these will not be able to access these functions.

- NEW: Protect the ISPConfig Interface with .htaccess

We added a script that makes it easy to protect the ISPConfig Interface with a .htaccess
password protection. This script adds a apache password prompt in front of the ispconfig
Interface and exports all ispconfig client users into a .htpasswd file, so all client
logins will still work.

Run the following command as root user to activate the script:

php /usr/local/ispconfig/server/scripts/ispconfig_htaccess.php

you can use the same command at any time to update the user list.

In case that you want to remove the protection again, run:

rm -f /usr/local/ispconfig/interface/web/.htaccess
rm -f /usr/local/ispconfig/interface/.htpasswd

For nginx webservers, edit the file /etc/nginx/sites-available/ispconfig.vhost
and add the lines:

auth_basic "Members Only";
auth_basic_user_file /usr/local/ispconfig/interface/.htpasswd;

right after line 35: "fastcgi_temp_file_write_size 256k;".

- Download

The software can be downloaded here:

- Changelog

=]ISPConfig::ISPConfig 3: Tasklist

- Known Issues:

Please take a look at the bugtracker:

ISPConfig::ISPConfig 3: Tasklist

- BUG Reporting

Please report bugs to the ISPConfig bugtracking system:

ISPConfig::ISPConfig 3: Tasklist

- Supported Linux Distributions

- Debian Etch (4.0) - Wheezy (7.0) and Debian testing
- Ubuntu 7.10 - 14.04
- OpenSuSE 11 - 13.1
- CentOS 5.2 - 6.5
- Fedora 9 - 15

- Installation

The installation instructions for ISPConfig can be found here:


or in the text files (named INSTALL_*.txt) which are inside the docs folder of the .tar.gz file.

- Update

To update existing ISPConfig 3 installations, run this command on the shell:

Select "stable" as the update resource. The script will check if an updated version of ISPConfig 3 is available and then download the tar.gz and start the setup script.

A "reconfigure services" is not required for this patch update.

Detailed instructions for making a backup before you update can be found here:

How to Update ISPConfig 3

If the ISPConfig version on your server does not have this script yet, follow the manual update instructions below.

- Manual update instructions

cd /tmp
tar xvfz ISPConfig-3-stable.tar.gz
cd ispconfig3_install/install
php -q update.php
Zuletzt bearbeitet:


Hallo, erstmal danke für den Patch und eure schnelle Reaktion! Vielen vielen Dank!

Auf meinem Debian 7.6 alles wunderbar.
Auf einem openSUSE 12.3 (war PerfectSetup für 12.1) gibt´s ein Problemchen:

Nach /usr/local/ispconfig/security/security_settings.ini
sollte der superuser laut admin_allow_* alle Berechtigungen haben.
Ganz gleich aber ob dort superuser/adminuser/yes steht, der Zugriff auf die Bereiche im CP geht nicht mehr.

z.B. "CP/System/Sprachen Editor/Neue Sprachen" bringt Fehlermeldung
"Error Sicherheitsüberprüfung für: admin_allow_langedit fehlgeschlagen."
obwohl admin_allow_langedit=yes
(dasselbe mit superuser/superadmin und für die übrigen admin_allow_*)

Kann ich da selbst was machen?


Ist wahrscheinlich ein Berechtigungsproblem auf Dateiebene. Vergleich mal bitte die Rechte und Eigentümer von:


zwischen dem debian und opensuse system.


abgesehen von Sticky bit beim Debian sind beide identisch

drwxr-x--- 3 root ispconfig 4096 15. Aug 10:39 ./
drwxr-xr-x 5 root root      4096 15. Aug 08:16 ../
-rwxr-x--- 1 root ispconfig  736 15. Aug 10:28 security_settings.ini*
drwxr-s--- 3 root ispconfig 4.0K Aug 15 10:41 .
drwxr-sr-x 5 root root      4.0K Aug 15 08:26 ..
-rwxr-x--- 1 root ispconfig  762 Aug 15 08:26 security_settings.ini


Hmm, ok. Welche ispconfig version war vorher auf dem opensuse installiert und hast du ein reconfigure services gemacht beim update?


Active Member
Erstmal vielen Dank für das Update.
Es lief wie immer 1a durch.
Ich hab mal zum Spass zwei Honeypots aufgesetzt, einen mit ISPConfig und einen mit ISPConfig Mal schauen ob sich da was tut in nächster Zeit. Ich habe beide einfach mal komplett default aufgesetzt, dann wird sich ja Zeigen was sich tut.

Gruß Sven


vorher war ISPConfig-, kein reconfigure gemacht

Hmm, das ist an sich o. Ich muss mal versuchen das hier nachzuvollziehen auf opensuse.

Wenn Du an die Funktionen kurzfristig ran musst, dann editier die Datei /usr/local/ispconfig/interface/lib/classes/ und füge in zeile 141 ein:

return true;

Das deaktiviert den neuen security check für das komplette interface.


Update erfolgreich, aber kein Login möglich

Ich kann mich dunkel erinnern, sowas schon mal gehabt zu haben.
Kann mir jemand auf die Sprünge helfen?

#0 db->query(REPLACE INTO sys_session (session_id,date_created,last_updated,session_data,permanent) VALUES ('uurni1nntpp7nle0v99cp9tce6',NOW(),NOW(),'s|a:4:{s:2:\"id\";s:26:\"uurni1nntpp7nle0v99cp9tce6\";s:5:\"theme\";s:7:\"default\";s:8:\"language\";s:2:\"de\";s:6:\"module\";a:4:{s:4:\"name\";s:5:\"login\";s:5:\"title\";s:14:\"top_menu_login\";s:8:\"template\";s:14:\"module.tpl.htm\";s:9:\"startpage\";s:15:\"login/index.php\";}}','n')) called at [/usr/local/ispconfig/interface/lib/classes/] #1 session->write(uurni1nntpp7nle0v99cp9tce6, s|a:4:{s:2:"id";s:26:"uurni1nntpp7nle0v99cp9tce6";s:5:"theme";s:7:"default";s:8:"language";s:2:"de";s:6:"module";a:4:{s:4:"name";s:5:"login";s:5:"title";s:14:"top_menu_login";s:8:"template";s:14:"module.tpl.htm";s:9:"startpage";s:15:"login/index.php";}}) #2 session_write_close() called at [/usr/local/ispconfig/interface/lib/] #3 app->__destruct()
#0 db->query(REPLACE INTO sys_session (session_id,date_created,last_updated,session_data,permanent) VALUES ('uurni1nntpp7nle0v99cp9tce6',NOW(),NOW(),'s|a:3:{s:2:\"id\";s:26:\"uurni1nntpp7nle0v99cp9tce6\";s:5:\"theme\";s:7:\"default\";s:8:\"language\";s:2:\"de\";}','n')) called at [/usr/local/ispconfig/interface/lib/classes/] #1 session->write(uurni1nntpp7nle0v99cp9tce6, s|a:3:{s:2:"id";s:26:"uurni1nntpp7nle0v99cp9tce6";s:5:"theme";s:7:"default";s:8:"language";s:2:"de";}) #2 session_write_close() called at [/usr/local/ispconfig/interface/lib/] #3 app->__destruct()

system ist in php.ini disabled, was hier ja nicht greift.

Extra mal mit frisch installiertem Midori probiert, sonst firefox, selbes Ergebnis

Webseiten und Dienste funktionieren.

System: Debian 7. SMP Debian 3.2.60-1+deb7u3 x86_64
Also default Wheezy
Ist php zu alt?


Führe doch mal die abfrage:

REPLACE INTO sys_session (session_id,date_created,last_updated,session_data ,permanent) VALUES ('uurni1nntpp7nle0v99cp9tce6',NOW(),NOW(),'s|a:4:{ s:2:\"id\";s:26:\"uurni1nntpp7nle0v99cp9tce6\";s:5 :\"theme\";s:7:\"default\";s:8:\"language\";s:2:\" de\";s:6:\"module\";a:4:{s:4:\"name\";s:5:\"login\ ";s:5:\"title\";s:14:\"top_menu_login\";s:8:\"temp late\";s:14:\"module.tpl.htm\";s:9:\"startpage\";s :15:\"login/index.php\";}}','n')

in der ispconfig db aus mit phpmyadmin und poste das ergebnis. Möglicherweise fehlt bei Dir eine Tabellenspalte.


Dann wurde eine der sql incremental update Dateien nicht ausgeführt. da es nur die session tabelle ist kannst Du am einfachsten die sys_session tabelle löschen und dann so neu anlegen:

CREATE TABLE `sys_session` (
  `session_id` varchar(64) NOT NULL DEFAULT '',
  `date_created` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `last_updated` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `permanent` enum('n','y') NOT NULL DEFAULT 'n',
  `session_data` longtext,
  PRIMARY KEY (`session_id`),
  KEY `last_updated` (`last_updated`)


was hat sich denn bei der remote api geändert? hatte jetzt noch keine zeit tiefer zu graben, aber was ich bis jetzt sagen kann ist folgendes:
- client ID wird zwar zurückgegeben aber client scheint nicht in der liste/db auf


was hat sich denn bei der remote api geändert? hatte jetzt noch keine zeit tiefer zu graben, aber was ich bis jetzt sagen kann ist folgendes:
- client ID wird zwar zurückgegeben aber client scheint nicht in der liste/db auf

Am Remote API hat sich meines Wissens nach nichts geändert außer der Möglichkeit es komplett über die neuen security settings zu deaktivieren. Möglicherweise hat aber irgendeine Änderung im Interface da nebenwirkunden. Mit welcher Funktion hast Du denn Probleme, client_add() ?


auf p2 läuft wieder alles wie gewohnt.

in meinem fall ist client_add der auslöser, die funktion liefert aber keinen fehler sondern gibt brav eine ID zurück, nur wie bereits erwähnt landet kein datensatz in der DB.
die nächste funktion domains_domain_add trägt dann zwar die domain ein, aber ohne client


muss meine aussage etwas abä kann ja garnicht sein dass eine ID zurückgegeben wird und nichts in der DB landet. ich hab mein system so programmiert dass bei einem fehler der client wieder gelöscht wird, dh der fehler tritt nicht bei client_add auf, sondern später


muss meine aussage etwas abä kann ja garnicht sein dass eine ID zurückgegeben wird und nichts in der DB landet. ich hab mein system so programmiert dass bei einem fehler der client wieder gelöscht wird, dh der fehler tritt nicht bei client_add auf, sondern später

Es hatte mich auch schon gewundert wie ein erfolgreiches mysql insert_id ohne einfügen eines sql records zustande kommen soll. Dann brauche ich mehr infos von Dir wenn ich da was nachsehen soll.