È possibile tracciare un back-end attraverso un proxy inverso?

4

Sto creando una topologia di rete di riferimento per un'applicazione di chat WebSocket al lavoro, e mi piacerebbe avere qualcosa di chiarito per la mia comprensione.

La topologia corrente prevede un proxy inverso tra il cliente e il back-end in cui il cliente si connette direttamente al proxy. Il back-end ha firewall che consentono solo le connessioni dal proxy.

Il cliente può vedere l'indirizzo del proxy nell'origine della pagina o nella console del browser. Sarebbe possibile per un cliente malintenzionato tracciare l'indirizzo del back-end e, in tal caso, aggiungere un secondo proxy può essere utile per mitigarlo?

EDIT: Melin ha chiesto informazioni sul mio proxy e sul backend. Sto usando WAMP per il proxy, principalmente perché si basa su Apache e sulla precedente familiarità con WAMP prima di laurearmi (che era circa 8 mesi fa). All'interno del modulo Apache per WAMP, ho definito gli host virtuali che eseguono il proxy effettivo e Apache è stato configurato per l'ascolto solo sulle porte per questi host virtuali. Ho aggiunto la configurazione nella parte inferiore del post, meno gli indirizzi e i percorsi effettivi utilizzati.

Tutto questo è in esecuzione su una rete interna in laboratorio, quindi ci sono alcuni buchi che non saranno aggiunti nel codice di produzione - come certificati autofirmati per testare connessioni sicure o disabilitare verifica del certificato di back-end.

## I've stripped this down to remove the comments, and just include the stuff that's enabled
## The Virtual Hosts are down at the bottom

Listen myServer:8080
Listen myServer:8443

# modules that are enabled
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule allowmethods_module modules/mod_allowmethods.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dir_module modules/mod_dir.so
LoadModule env_module modules/mod_env.so
LoadModule headers_module modules/mod_headers.so
LoadModule include_module modules/mod_include.so
LoadModule isapi_module modules/mod_isapi.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule xml2enc_module modules/mod_xml2enc.so
LoadModule php5_module "c:/wamp/bin/php/php5.5.12/php5apache2_4.dll"


ServerName myServer

#
# Deny access to the entirety of your server's filesystem. You must
# explicitly permit access to web content directories in other 
# <Directory> blocks below.
#
<Directory />
    AllowOverride none
    Require all denied
</Directory>

DocumentRoot "c:/wamp/www/"
<Directory "c:/wamp/www/">
    #
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.4/mod/core.html#options
    # for more information.
    #
    Options Indexes FollowSymLinks

    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   AllowOverride FileInfo AuthConfig Limit
    #
    AllowOverride None

    #
    # Controls who can get stuff from this server.
    #
    Require all granted
</Directory>

#
# DirectoryIndex: sets the file that Apache will serve if a directory
# is requested.
#
<IfModule dir_module>
    DirectoryIndex index.php index.php3 index.html index.htm
</IfModule>

#
# The following lines prevent .htaccess and .htpasswd files from being 
# viewed by Web clients. 
#
<Files ".ht*">
    Require all denied
</Files>

#
# Customizable error responses come in three flavors:
# 1) plain text 2) local redirects 3) external redirects
#
# Some examples:
ErrorDocument 500 "The server made a boo boo."
#ErrorDocument 404 /missing.html
#ErrorDocument 404 "/cgi-bin/missing_handler.pl"
#ErrorDocument 402 http://www.example.com/subscription_info.html
#

# Secure (SSL/TLS) connections
#Include conf/extra/httpd-ssl.conf
#
# Note: The following must must be present to support
#       starting without SSL on platforms with no /dev/random equivalent
#       but a statically compiled-in mod_ssl.
#
<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>
#
# uncomment out the below to deal with user agents that deliberately
# violate open standards by misusing DNT (DNT *must* be a specific
# end-user choice)
#
#<IfModule setenvif_module>
#BrowserMatch "MSIE 10.0;" bad_DNT
#</IfModule>

# set up a reverse proxy here inside a virtual host on port 8080
<VirtualHost *:8080>
    ServerName proxyserver

    # turning off ProxyRequests turns this into a closed server - recommended for security reasons
    # ProxyPreserveHost passes the Host: line from the incoming request to the proxied host
    # ProxyVia controls the use of the Via: HTTP header. If turned on, each request and reply has a Via: header added for this host
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyVia On

    # Anything inside this applies only to matching proxied content
    # in this case, it allows connections from everything that connects to this server - could be changed later
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    # turn on full logging - not strictly needed, but useful
    LogLevel debug

    #SSLProxyEngine On

    # this is the actual redirection: anything coming in on port 8080 which ends in /chat
    # will be redirected to the backend servlet at the following address
    <Location /chat>
        ProxyPass           ws://<Backend:Normal_Port>/path/to/chat
        ProxyPassReverse    ws://<Backend:Normal_Port>/path/to/chat
    </Location>

</VirtualHost>

<VirtualHost *:8443>
    ServerName SSLProxyServer

    # turning off ProxyRequests turns this into a closed server - recommended for security reasons
    # ProxyPreserveHost passes the Host: line from the incoming request to the proxied host
    # ProxyVia controls the use of the Via: HTTP header. If turned on, each request and reply has a Via: header added for this host
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyVia On

    # give the proxy a 10-minute timeout for development
    ProxyTimeout 600

    # Anything inside this applies only to matching proxied content
    # in this case, it allows connections from everything that connects to this server - could be changed later
    # e.g. Deny from all, followed by Allow from frontend.example.com would permit connections only from frontend.example.com
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    # turn on full logging - not strictly needed, but useful
    LogLevel debug

    # to actually use SSL, turn on the SSL engine!
    SSLEngine On
    SSLProxyEngine On

    # disable cert verification for backend *for development*
    # this is due to the backend cert being self-signed during testing
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    # link to the certificate and key for this server
    SSLCertificateFile      "path\to\certificate"
    SSLCertificateKeyFile   "path\to\key"

    # this is the actual redirection: anything coming in on port 8443 which ends in /chat
    # will be redirected to the backend servlet at the following address
    <Location /chat>
        ProxyPass               wss://<Backend:Secure_Port>/path/to/chat
        ProxyPassReverse        wss://<Backend:Secure_Port>/path/to/chat
    </Location>

</VirtualHost>
    
posta Philip Rowlands 27.07.2015 - 13:30
fonte

1 risposta

4

Rivelare l'indirizzo IP interno non sempre scende al proxy, a volte il back-end non è configurato correttamente e il suo server web "perde" i dettagli del sistema, come i percorsi dell'applicazione ei dettagli di configurazione.

Un'area che è particolarmente "vulnerabile" alla perdita di dati sono pagine di errore: le pagine di errore di IIS e Apache possono rivelare l'indirizzo IP interno. Disattiva sempre queste pagine predefinite e disponi di pagine di errore personalizzate che non perdono alcuna informazione interna.

Inoltre, dipende dal tipo di proxy inverso utilizzato e dalla sua configurazione. Quello che devi controllare è il frequente "aggiunto automaticamente" Intestazioni HTTP X-Forwarded for e X-Forwarded-IP usando i mod_header di Apache:

Header unset X-Forwarded-For
Header unset X-Forwarded-IP
Header unset X-Forwarded-Server
Header unset X-Powered-By

Se fornisci dettagli sul proxy inverso utilizzato, potremmo essere in grado di aiutarti di più con la configurazione. Tuttavia, un secondo proxy inverso sarebbe ... un overkill e molto probabilmente non sarebbe mitigato.

Ricorda, è davvero difficile correggere un design scadente con livelli di controlli di sicurezza.

    
risposta data 27.07.2015 - 16:20
fonte

Leggi altre domande sui tag