Openvpn lede modifies web interface

is it by possible to modify lede a bit...just to make the openvpn stop and start at the dashboard while it is lock via user .password...and the only thing they can access is ...openvpn changing server and openvpn commands like stop and start

You can disable LuCI and install a different webserver. In that you can either use CGI or a language like PHP to program your functionality per your wishes. The commands can be done from the alternate programming language by accessing the shell, where uci and all other shell commands can be used freely.


1 Like

You'd have to do quite a bit of work to do what you're proposing, and it would likely still be a security risk since OpenWrt is a single user OS. Why exactly are you trying to do what you're asking, as I can't think of a single use case as to why that would be necessary.

Use case is that the OpenWRT is a handheld device used to establish an OpenVPN connection for a laptop. :slight_smile:

I actually made one just like that. Also created interface where one can choose wireless network. It is not really that much work, because everything can be done with uci.


I don't know anyone who would recommend allowing unauthenticated root access, which is exactly what would have to be done to allow starting and stopping daemons without logging in.

Sudo has a config file for only allowing specific commands. Also a web interface only lets you do what it does and noting else. There is no prompt to enter commands, just 2 buttons.

And the only user capable of accessing this interface is the user who is directly connected to the device and should have root access.

There is no issue.


I'm aware of what can be configured with a sudo config, but OpenWrt is a single user OS and there's no way to get around that without completely rewriting the firmware from the ground up.

  • Setting up sudo on OpenWrt, a single user OS, and setting up sudo on Ubuntu or another distro, a multi-user OS, are not the same things...

So theoretically if the web interface is poorly designed or there is an exploit in the webserver software. Then the user sitting behind the laptop can exploit his own gateway device. How terrible. :slight_smile:


uHTTPd is an insecure web server, that's why it should never be WAN facing.... nginx can't be used, and apache is resource hungry.

@jknee00 wasn't asking for their own access, but for others. Attempting to make a single user OS operate in the fashion of a multi-user OS is asking for headaches, security and otherwise... which is why there's no OpenWrt wiki for sudo. Everything in OpenWrt is controlled by root and root only.

I don't think @jknee00 was thinking WAN facing. Where do you see that implied?

This is very clearly LAN-only, where the user that owns the OpenVPN gateway can restart the connection if it is not working.

This is not possible with LuCI - you'd basically need to rewrite everything for such fine grained access control.
The most straight forward solution is what @dustwolf was proposing - write a different, dedicated UI which just does what you need.

You do not need to install a different webserver though, uhttpd handles CGI programs just fine.

Can you elaborate on that? What makes uhttpd less secure than an equivalently configured nginx or apache?

@jow Where would one configure security settings for uHTTPd? As far as I, and every other veteran OpenWrt user I've spoken with over the years, know, there are none, and, beyond serving LuCI, we never found an example of anyone using uHTTPd as a WAN facing web server, with everyone I've ever spoken to warning to never use it as a WAN facing web server.

  • /etc/config/uhttpd has no security settings for securing the web server, beyond HTTPS redirect and specifying an SSL cert.

  • Here's an example of one of the Nginx config files I use, and, as far as I know, uHTTPd supports none of the security implementations in the config
         ##::[[---  FreeBSD 11.1 Nginx NextCloud Config ---]]::##
     worker_processes               8;
     events { worker_connections    1024; }
     http {
         include                mime.types;
         default_type           application/octet-stream;
         sendfile               off;
         keepalive_timeout      65;
         ssl_protocols          TLSv1.1  TLSv1.2;
         ssl_session_cache            shared:SSL:10m;
         ssl_session_timeout          30m;
         ssl_prefer_server_ciphers    on;
         server {
             listen             80;
             return             301  https://$server_name$request_uri;
             add_header         X-Frame-Options  "SAMEORIGIN";
         server {
             listen             443 ssl;
             ssl_dhparam              /usr/local/etc/nginx/NextCloud-dh2048.pem;
             ssl_certificate          /usr/local/etc/nginx/NextCloud.NAS.crt;
             ssl_certificate_key      /usr/local/etc/nginx/NextCloud.NAS.key;
             add_header         Strict-Transport-Security  "max-age=15768000; includeSubdomains; preload;";
             add_header         X-Content-Type-Options nosniff;
             add_header         X-Frame-Options  "SAMEORIGIN";
             add_header         X-XSS-Protection  "1; mode=block";
             add_header         X-Robots-Tag  none;
             add_header         X-Download-Options  noopen;
             add_header         X-Permitted-Cross-Domain-Policies  none;
             root               /usr/local/www/nextcloud/;
             location =         /robots.txt { allow  all; access_log  off; log_not_found  off; }
             client_max_body_size    10240M;
             fastcgi_buffers         64  4K;
             gzip               off;
             access_log         /var/log/nginx-host.access.log;
             error_page         403  /core/templates/403.php;
             error_page         404  /core/templates/404.php;
             error_page         500 502 503 504  /50x.html;
             location           / { rewrite ^  /index.php$uri; }
             location =         /favicon.ico { access_log  off; log_not_found  off; }
             location ~         ^/(?:build|tests|config|lib|3rdparty|templates|data)/ { deny  all; }
             location ~         ^/(?:\.|autotest|occ|issue|indie|db_|console) { deny  all; }
             location ~         ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
                 include            fastcgi_params;
                 fastcgi_split_path_info    ^(.+\.php)(/.+)$;
                 fastcgi_param      SCRIPT_FILENAME  $document_root$fastcgi_script_name;
                 fastcgi_param      PATH_INFO  $fastcgi_path_info;
                 fastcgi_param      HTTPS  on;
                 fastcgi_param      modHeadersAvailable  true;
                 fastcgi_param      front_controller_active  true;
                 fastcgi_pass       unix:/var/run/php-fpm.sock;
                 fastcgi_intercept_errors     on;
                 fastcgi_request_buffering    off;
             location ~         ^/(?:updater|ocs-provider)(?:$|/) { try_files  $uri/ =404; index  index.php; }
             location ~*        \.(?:css|js)$ {
                 try_files          $uri  /index.php$uri$is_args$args;
                 add_header         Cache-Control  "public, max-age=7200";
                 add_header         Strict-Transport-Security  "max-age=15768000; includeSubdomains; preload;";
                 add_header         X-Content-Type-Options  nosniff;
                 add_header         X-Frame-Options  "SAMEORIGIN";
                 add_header         X-XSS-Protection  "1; mode=block";
                 add_header         X-Robots-Tag  none;
                 add_header         X-Download-Options  noopen;
                 add_header         X-Permitted-Cross-Domain-Policies  none;
                 access_log         off;
             location ~*        \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
                 try_files          $uri  /index.php$uri$is_args$args;
                 access_log         off;

As far as I can see, none of these settings would secure against exploiting an actual bug in CGI program that runs as root. Its all anti-XSS fluff and some SSL fine tuning.

It would neither prevent shell injections, nor buffer overflows, fishing attempts or CRSF. When you called uhttpd less secure I assumed you meant some kind of actual overflows or authentication weaknesses, not some X-Header copy-pasta :slight_smile:

It is true that you cannot configure arbitrary headers to be sent along with arbitrary responses, but nothing is preventing the actual application from emitting such headers, as it is done by LuCI for example:

That's not a WAN facing web server config, just one I use on LAN only. Has uHTTPd ever been tested against exploits, and if so, where can one that information?

  • If OpenWrt's implementation of uHTTPd to serve LuCI is secure enough to be WAN facing and is able to have it's security customized, this information should be added to the appropriate wikis, however, there has never been any information regarding this in any OpenWrt wiki.... hence why everyone believes it should never be WAN facing.

The point is that one should always make a careful decision whether it makes sense to expose an administrative interface to the wan or not. The attack surface here is LuCI, not uhttpd. It does not matter if it is hosted by uhttpd, nginx, apache or anything else if it has an authentication bypass, an RCE or some other yet unfound bug.

The least likely attack vector is the web server itself and if there is an exploitable buffer overflow or similar, then nothing in the configuration settings mentioned above will make any difference.