Using a remote server #510

Closed
BrianHoldsworth opened this Issue Aug 28, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@BrianHoldsworth

Unless I am overlooking some bit of configuration, it is not possible to utilize OWTF on a remote server. The access to the file storage, which is normally assigned to port 8010, only seems to work for localhost:8010 i.e. you have to have a local OWTF server.

This seems like a shortcoming if you want to share a server with a small workgroup as a collaboration aid during testing.

Additionally, the config options that do exist (SERVER_ADDR, UI_SERVER_PORT, FILE_SERVER_PORT) don't seem to offer the possibility of utilizing OWTF remotely over a single standard web port, like 443.

I have also not discovered an effective way of inserting a reverse-proxy, like nginx, to solve this dilemma. The browser client seems to "think it knows best" in trying to reference files on 'localhost' directly, instead of just relying on a URI scheme that would allow a proxy to direct requests to appropriate endpoints/ports, if that sort of backend architecture is truly desirable.

@7a

This comment has been minimized.

Show comment
Hide comment
@7a

7a Sep 4, 2015

Member

Hi Brian, I believe you can charge the listening IP to the host you are
using, if you do that, I would personally white-list client IPs on a need
to connect basis.

Let us know how this works out for you please :)
On 28 Aug 2015 04:45, "Brian Holdsworth" notifications@github.com wrote:

Unless I am overlooking some bit of configuration, it is not possible to
utilize OWTF on a remote server. The access to the file storage, which is
normally assign to port 8010, only seems to work for localhost:8010 i.e.
you have to have a local OWTF server.

This seems like a shortcoming if you want to share a server with a small
workgroup as a collaboration aid during testing.

Additionally, the config options that do exist (SERVER_ADDR,
UI_SERVER_PORT, FILE_SERVER_PORT) don't seem to offer the possibility of
utilizing OWTF remotely over a single standard web port, like 443.

I have also not discovered an effective way of inserting a reverse-proxy,
like nginx, to solve this dilemma. The browser client seems to "think it
knows best" in trying to reference files on 'localhost' directly, instead
of just relying on a URI scheme that would allow a proxy to direct requests
to appropriate endpoints/ports if that sort of backend architecture is
desired.


Reply to this email directly or view it on GitHub
#510.

Member

7a commented Sep 4, 2015

Hi Brian, I believe you can charge the listening IP to the host you are
using, if you do that, I would personally white-list client IPs on a need
to connect basis.

Let us know how this works out for you please :)
On 28 Aug 2015 04:45, "Brian Holdsworth" notifications@github.com wrote:

Unless I am overlooking some bit of configuration, it is not possible to
utilize OWTF on a remote server. The access to the file storage, which is
normally assign to port 8010, only seems to work for localhost:8010 i.e.
you have to have a local OWTF server.

This seems like a shortcoming if you want to share a server with a small
workgroup as a collaboration aid during testing.

Additionally, the config options that do exist (SERVER_ADDR,
UI_SERVER_PORT, FILE_SERVER_PORT) don't seem to offer the possibility of
utilizing OWTF remotely over a single standard web port, like 443.

I have also not discovered an effective way of inserting a reverse-proxy,
like nginx, to solve this dilemma. The browser client seems to "think it
knows best" in trying to reference files on 'localhost' directly, instead
of just relying on a URI scheme that would allow a proxy to direct requests
to appropriate endpoints/ports if that sort of backend architecture is
desired.


Reply to this email directly or view it on GitHub
#510.

@BrianHoldsworth

This comment has been minimized.

Show comment
Hide comment
@BrianHoldsworth

BrianHoldsworth Sep 4, 2015

When you say "change the listening IP", are you referring to the "SERVER_ADDR" value in the "framework_config.cfg" file? I currently set this to 0.0.0.0, so that owtf listens on the correct IP and the UI works fine. It's when you want to access file on the FILE_SERVER_PORT (8010, by default) that the browser client decides it should route the request to "localhost".

When you say "change the listening IP", are you referring to the "SERVER_ADDR" value in the "framework_config.cfg" file? I currently set this to 0.0.0.0, so that owtf listens on the correct IP and the UI works fine. It's when you want to access file on the FILE_SERVER_PORT (8010, by default) that the browser client decides it should route the request to "localhost".

@7a

This comment has been minimized.

Show comment
Hide comment
@7a

7a Sep 8, 2015

Member

Bharadwaj, can you chime in here?
On 4 Sep 2015 16:27, "Brian Holdsworth" notifications@github.com wrote:

When you say "change the listening IP", are you referring to the
"SERVER_ADDR" value in the "framework_config.cfg" file? I currently set
this to 0.0.0.0, so that owtf listens on the correct IP and the UI works
fine. It's when you want to access file on the FILE_SERVER_PORT (8010, by
default) that the browser client decides it should route the request to
"localhost".


Reply to this email directly or view it on GitHub
#510 (comment).

Member

7a commented Sep 8, 2015

Bharadwaj, can you chime in here?
On 4 Sep 2015 16:27, "Brian Holdsworth" notifications@github.com wrote:

When you say "change the listening IP", are you referring to the
"SERVER_ADDR" value in the "framework_config.cfg" file? I currently set
this to 0.0.0.0, so that owtf listens on the correct IP and the UI works
fine. It's when you want to access file on the FILE_SERVER_PORT (8010, by
default) that the browser client decides it should route the request to
"localhost".


Reply to this email directly or view it on GitHub
#510 (comment).

@tunnelshade

This comment has been minimized.

Show comment
Hide comment
@tunnelshade

tunnelshade Sep 10, 2015

Member

Hey, @BrianHoldsworth Ideally both file server and ui run on same interface. The redirection should be happening which seems buggy in this case. Please provide the following information so that debugging will be easier for us

  • Which plugin did you run?
  • What link is failing?
Member

tunnelshade commented Sep 10, 2015

Hey, @BrianHoldsworth Ideally both file server and ui run on same interface. The redirection should be happening which seems buggy in this case. Please provide the following information so that debugging will be easier for us

  • Which plugin did you run?
  • What link is failing?

@viyatb viyatb added this to the OWTF Quality Release milestone Jan 17, 2016

@viyatb viyatb added the Enhancement label Jan 18, 2016

@viyatb viyatb self-assigned this Jan 18, 2016

@viyatb

This comment has been minimized.

Show comment
Hide comment
@viyatb

viyatb Jan 30, 2016

Member

Hi @BrianHoldsworth you can do something like this:

  • Generate an SSL certificate via Nginx
 sudo mkdir /etc/nginx/ssl
 sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt
  • Add this to the config (server block)
        listen 443 ssl;
        ssl_certificate /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key /etc/nginx/ssl/nginx.key;

and restart nginx

  • Of course you can add your own SSL cert :)

I've created a barebones nginx config for your reference ;)

Also I think that I've fixed the buggy redirection in a previous commit. Let me know if it works for you or not.

Member

viyatb commented Jan 30, 2016

Hi @BrianHoldsworth you can do something like this:

  • Generate an SSL certificate via Nginx
 sudo mkdir /etc/nginx/ssl
 sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt
  • Add this to the config (server block)
        listen 443 ssl;
        ssl_certificate /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key /etc/nginx/ssl/nginx.key;

and restart nginx

  • Of course you can add your own SSL cert :)

I've created a barebones nginx config for your reference ;)

Also I think that I've fixed the buggy redirection in a previous commit. Let me know if it works for you or not.

@viyatb viyatb closed this Feb 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment