Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Themen - C. Grommel - Profihost

Seiten: [1]
1
Webhosting / Magento Backend via .htaccess absichern
« am: 27.09.2017 14:23 »
Es empfiehlt sich das Magento Backend vor dem eigentlichen Login bereits mit Zugriffsberechtigungen zu versehen. Dies kann über die .htaccess geregelt werden. Im besten Fall wird dieser direkt auf einzelne IPs beschränkt. Da hier jedoch nicht jeder mit einer festen IP Adresse arbeitet, kann der Zugriff über mod_geoip auf bestimmte Länder begrenzt werden.

Folgend dazu ein Code-Beispiel, dass den Zugriff nur über DE erlaubt:
# Backend Zugriff nur über DE erlauben
<FilesMatch "admin">
  <IfModule mod_geoip.c>
  SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountryBackend

    Require env AllowCountryBackend
  </IfModule>
</FilesMatch>

Sollte der Zugriff auf das Backend direkt über die IPs abgesichert werden können, so kann folgender Code verwendet werden:

# Backend Zugriff absichern
<FilesMatch "admin">
  <IfModule mod_authz_core.c>
    # Apache 2.4
    # List of ip adresses that can access the backend
    Require ip 1.2.3.4
    Require ip 5.6.7.8

  </IfModule>
</FilesMatch>

2
Es empfiehlt sich das xt:Commerce Backend vor dem eigentlichen Login bereits mit Zugriffsberechtigungen zu versehen. Dies kann über die .htaccess geregelt werden. Im besten Fall wird dieser direkt auf einzelne IPs beschränkt. Da hier jedoch nicht jeder mit einer festen IP Adresse arbeitet, kann der Zugriff über mod_geoip auf bestimmte Länder begrenzt werden.

Da Oxid das Backend über einen eigenen Ordner bereitstellt, kann das folgende Code-Beispiel direkt in der .htaccess in dem Verzeichnis INSTALLDIR/xtAdmin/ hinzugefügt werden um den Zugriff nur von DE zu erlauben:

<IfModule mod_geoip.c>
GeoIPEnable On
SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountryBackend

  Require env AllowCountryBackend
</IfModule>

Sollte der Zugriff direkt auf IPs beschränkt werden können, so kann hierfür auch der Code für den Zugriff nur für bestimmte IPs aus https://www.profihost.com/forum/webhosting/wie-kann-ich-den-zugriff-auf-meine-seite-sperren-1707/msg8075/#msg8075 verwendet werden

3
Webhosting / Oxid Backend via .htaccess absichern
« am: 27.09.2017 14:02 »
Es empfiehlt sich das Oxid Backend vor dem eigentlichen Login bereits mit Zugriffsberechtigungen zu versehen. Dies kann über die .htaccess geregelt werden. Im besten Fall wird dieser direkt auf einzelne IPs beschränkt. Da hier jedoch nicht jeder mit einer festen IP Adresse arbeitet, kann der Zugriff über mod_geoip auf bestimmte Länder begrenzt werden.

Da Oxid das Backend über einen eigenen Ordner bereitstellt, kann das folgende Code-Beispiel direkt in der .htaccess in dem Verzeichnis INSTALLDIR/admin/ hinzugefügt werden um den Zugriff nur von DE zu erlauben:

<IfModule mod_geoip.c>
GeoIPEnable On
SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountryBackend

  Require env AllowCountryBackend
</IfModule>

Sollte der Zugriff direkt auf IPs beschränkt werden können, so kann hierfür auch der Code für den Zugriff nur für bestimmte IPs aus https://www.profihost.com/forum/webhosting/wie-kann-ich-den-zugriff-auf-meine-seite-sperren-1707/msg8075/#msg8075 verwendet werden

4
Webhosting / Shopware Backend via .htaccess absichern
« am: 27.09.2017 14:00 »
Es empfiehlt sich das Shopware Backend vor dem eigentlichen Login bereits mit Zugriffsberechtigungen zu versehen. Dies kann über die .htaccess geregelt werden. Im besten Fall wird dieser direkt auf einzelne IPs beschränkt. Da hier jedoch nicht jeder mit einer festen IP Adresse arbeitet, kann der Zugriff über mod_geoip auf bestimmte Länder begrenzt werden.

Folgend dazu ein Code-Beispiel für die .htaccess dass den Zugriff auf das Frontend nur für DE, AT und CH erlaubt und den Backend Zugriff nur über DE erlaubt:

# Nur DE, CH und AT erlauben
<IfModule mod_geoip.c>
GeoIPEnable On
SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountry
SetEnvIf GEOIP_COUNTRY_CODE AT AllowCountry
SetEnvIf GEOIP_COUNTRY_CODE CH AllowCountry
# allow US for GoogleBot, Paypal etc.
SetEnvIf GEOIP_COUNTRY_CODE US AllowCountry
   
  Require env AllowCountry
</IfModule>

# Backend Zugriff absichern
<FilesMatch "backend">
  <IfModule mod_geoip.c>
  SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountryBackend

    Require env AllowCountryBackend
  </IfModule>
</FilesMatch>

Sollte der Zugriff auf das Backend direkt über die IPs abgesichert werden können, so kann folgender Code verwendet werden:

# Backend Zugriff absichern
<FilesMatch "backend">
<IfModule mod_authz_core.c>
    # Apache 2.4
    # List of ip adresses that can access the backend
    Require ip 1.2.3.4
    Require ip 5.6.7.8

  </IfModule>
</FilesMatch>

5
Webhosting / Länder via mod_geoip sperren
« am: 27.06.2017 10:43 »
Über das Modul mod_geoip des Apache kann der Zugriff anhand der Geo-Location der IPs gesteuert werden.

Länderspezifisches

Blacklisting am Beispiel von China und Japan sperren:

<IfModule mod_geoip.c>
GeoIPEnable On
SetEnvIf GEOIP_COUNTRY_CODE JP BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
   
    <RequireAll>
        Require all granted
        Require not env BlockCountry
    </RequireAll>
</IfModule>

Whitelisting am Beispiel von nur Deutschland und US erlauben:

<IfModule mod_geoip.c>
GeoIPEnable On
SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountry
# allow US for GoogleBot, Paypal etc.
SetEnvIf GEOIP_COUNTRY_CODE US AllowCountry
   
        Require env AllowCountry
</IfModule>

In den oben genannten Beispiel kann der Code-Block um beliebig viele SetEnvIf-Zeilen erweitert und der Block / Allow-Radius erweitert werden.
Die Länder müssen immer mit zweistelligem ISO Code angegeben werden. Eine Liste der Ländercodes im ISO-Format ist hier zu finden: https://de.wikipedia.org/wiki/ISO-3166-1-Kodierliste


Kontinentspezifisches

Über mod_geoip können auch die Zugriffe durch ganze Kontinente gesteuert werden.

Blacklisting am Beispiel von Asien sperren:

<IfModule mod_geoip.c>
GeoIPEnable On
SetEnvIf GEOIP_COUNTRY_CODE AS BlockContinent
   
    <RequireAll>
        Require all granted
        Require not env BlockCountry
    </RequireAll>
</IfModule>


Whitelisting am Beispiel von nur Europa und US erlauben:

<IfModule mod_geoip.c>
GeoIPEnable On
SetEnvIf GEOIP_CONTINENT_CODE EU AllowContinent
# allow US for GoogleBot, Paypal etc.
SetEnvIf GEOIP_COUNTRY_CODE US AllowCountry

    <RequireAll>
        Require all granted
        Require not env BlockCountry
        Require not env BlockContinent
    </RequireAll>
</IfModule>

Die Möglichen Kürzel sind hier folgende:

AF – Africa
AN – Antarctica
AS – Asia
EU – Europe
NA – North America
OC – Oceania
SA – South America

6
Software / Installation von Amazon awscli als User
« am: 15.03.2017 10:09 »
Auf unseren Systemen ist es möglich, die Amazon awscli zu installieren und zu nutzen.
Dazu kann wie folgt vorgegangen werden:

# Das awscli-Bundle von Amazon herunterladen
curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"

# Anschließend das Zip-File entpacken
unzip awscli-bundle.zip

# Nun wird die Profil-Datei so angepasst, dass das Tool aws auch direkt als Kommando genutzt werden kann, der Befehl muss in einer kompletten Zeile so ausgeführt werden:
echo -e 'if [ -f ~/.bashrc ]; then\n source ~/.bashrc\nfi\n\n\n# MySQL\nPATH=~/.local/lib/aws/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/mysql/bin/\nexport PATH\n\nalias ll="ls -l"\nalias la="ls -la"\n\n' >~/.profile

# Für die aktuelle Session die neue .profile und damit auch die neue PATH Variable einlesen lassen:
source ~/.profile

# Nun wird die eigentliche Installation durchgeführt, die Installation legt automatisch alle benötigten Verzeichnisse an und ist dann unter ~./local zu finden
./awscli-bundle/install

# Zuletzt müssen noch auf die Programme von Amazon die Ausführungsrechte gesetzt werden:
chmod 755 ~/.local/lib/aws/bin/*

# Damit ist die Installation abgeschlossen und aws kann direkt als Kommando verwendet werden:
aws --version
aws-cli/1.11.63 Python/2.7.9 Linux/4.4.26+76-ph botocore/1.5.26

Die Einrichtung von Profilen erfolgt nun direkt über aws und ist von Amazon hier auch noch einmal beschrieben: http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html

7
Voraussetzung hierfür ist, dass der Support für PHP durch unsere Technik vorher für die gewünschte PHP Version installiert wurde. Eröffnen Sie dafür bitte eine autorisierte Anfrage.

Um MSSQL Support für PHP zu aktivieren, müssen folgende Einträge in der phpX.Y.ini-Datei gesetzt werden.

; ODBC Extension für PHP
extension="/usr/local/phpX.Y/lib/php/extensions/no-debug-non-zts-20090626/odbc.so"
extension="/usr/local/phpX.Y/lib/php/extensions/no-debug-non-zts-20090626/pdo_odbc.so"

Die Versionsnummer muss entsprechend an die genutzte PHP Version angepasst werden.

Der Standard $dsn sieht wie folgt aus:
$dsn = "Driver=sqlServer;Server=some.server.com;Port=1433;Database=mydatabase;";

Die Verbindung kann dann über folgendes PHP Skript getestet werden:
<?php
$user 
"username";
$pass "password";
// Some examples show "Driver={FreeTDS};" but this will not work
$dsn "Driver=sqlServer;Server=some.server.com;Port=1433;Database=mydatabase;";
$cx odbc_connect($dsn,$user,$pass);
// Get the error message
if($cx === false) {
    throw new 
ErrorExcpetion(odbc_errormsg());
}
?>


8
SSL / HTTP-Strict-Transport-Security immer aktivieren
« am: 05.01.2016 15:06 »
Soll für statische Inhalte der sog. HSTS Header immer gesetzt werden, so können Sie dies über die .htaccess mit folgendem Eintrag setzen:

Header always set Strict-Transport-Security 'max-age=$gueltigkeitinsekunden'

Der Wert '$gueltigkeitinsekunden' muss hier dann durch eine Zahlenangabe ersetzt werden. Für eine Gültigkeit von einer Stunde kann hier dafür zum Beispiel 3600 eingetragen werden.

Für per FCGI erzeugte Inhalte (PHP, Perl, usw.) muss der Header über die eingesetzte Web Applikation gesetzt werden. Die Einstellung in der .htaccess wird für diese Inhalte nicht gesetzt.

Informationen zu HSTS finden Sie unter https://de.wikipedia.org/wiki/HTTP_Strict_Transport_Security und http://www.heise.de/netze/meldung/HTTP-Strict-Transport-Security-als-Internet-Standard-1754184.html

Seiten: [1]