Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Conext - LXD Control Panel
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Conext - LXD Control Panel

twaintwain Member
edited June 2018 in General

Found this interesting project. Extremely new, haven't tried it out yet, but looks quite appealing for potentially replacing a manual Ubuntu/LXD/HaProxy setup, as it has web proxy/letsencrypt integration in the panel.

https://github.com/lcherone/Conext

From the description:

A decentralized multi-server LXD server control panel with sugar!

Features
Not going to bore you with stuff you probably won't read, so here is what the system can 
do:

Responsive single page app control panel.
Full LXD management, including: profiles, containers, images, certificates, networks,     storage and devices.
Server information, host CPU, memory, disks network connections and processes.
Built-in Web Proxy with LetsEncrypt, to forward HTTP/s traffic into the containers or     external upstream's.
Create custom tasks for maintaining containers or project deployments.
Create simple API endpoints for stuff the panel does not do, with access to your LXD servers     over RPC.
«1

Comments

  • Hello! Ill spin up a test KVM with this puppy on it, and let you know how it went.

    Thanked by 2Aidan twain
  • eva2000eva2000 Veteran

    Thanks for sharing. I recently got into playing with LXD containers myself for my Nginx benchmarks for Centmin Mod vs Easyengine vs Webinoly vs VestaCP vs OneInStack testing. Loving LXD so far, so having a control panel to manage it all would be nice :)

    Thanked by 1twain
  • RendusRendus Member
    edited June 2018

    That install script doesn't mess around on completely blowing away any existing config you have, and re-init-ing LXD.

    Edit:

    lxd_secret=$(date +%s%N | sha256sum | base64 | head -c 32 ; echo)

    Hahaha... What? Why?

  • @Rendus said:
    That install script doesn't mess around on completely blowing away any existing config you have, and re-init-ing LXD.

    Edit:

    lxd_secret=$(date +%s%N | sha256sum | base64 | head -c 32 ; echo)

    Hahaha... What? Why?

    It won't re-init LXD if you have containers, images etc already setup it will fail anyway.

    Though I've removed setting the secret all together now as the system does not need it to talk to LXD

    Back to the OP -

    Yeah, it's extremely new, I've been working on it just over month..

    I built it as your right most panels are have no web proxies, which you have to setup and manage manually or with some other tools, and are lacking in all the best parts things LXD has to offer.. or just do containers and images, and if your lucky some basic network and profile config.. most are standalone and require you to install them on each server (with conexct you could manually install just the api part then use your "main" panel to control all your servers.. the panel is also SPA so you could run it locally, later im going to put it in electron app),

    Conext was built with the aim of covering everything LXD has to offer with the fundamental stuff you need to actually run a site on it, like port and web forwarding (nginx reverse proxy + Lets Encrypt).

    All I can say is check it out, and if you have any issues open an issue on github, and ill most likely add it, I take everything on board and will any fix issues promptly..

  • twaintwain Member

    Thanks for the feedback @lcherone! Yes this is definitely a unique project. Will be trying it out soon. So, does LXD need to be installed first? My plan was to install LXD and LXD init with a ZFS partition. I won’t add any containers though. However if I don’t add any containers, will the CP install blow out and reinstall the existing LXD/zfs init? Should I add some containers before the CP install to potentially avoid that?

    Also I plan on installing the CP and use the same server as the LXD server. So CP and LXD on the same server. Will that work fine?

  • WebsecWebsec Member

    The UI looks cool and simple. +1

  • lcheronelcherone Member
    edited June 2018

    If you have a pre-existing LXD setup of any sort I would recommend that you just spin up a new server, to try it out. It will also run just fine in a privileged container with nesting enabled.

    Why I say that is it will take over any nginx setup you have, and tbh I dont want to support non clean systems, else things are not easy to debug and there could be conflicts which an OP might not mention.

    Essentially the install will do the following to LXD:

    • Replace the apt based LXD for snap (so if your container are actually using that and not the snap, then they could be lost or sit idle wasting resources etc)
    • Run sudo lxd init --auto --network-address 0.0.0.0 --network-port 8443 --storage-backend=dir

      --storage-backend=dir was picked as its a misconception that you're locked into that storage type from the start. In conext you could create a new default storage pool (zfs, btrfs, zeph etc) and replace it. dir was picked as so its up to the user to research on other storage types, install deps etc then create it in the panel. If you go with btrfs you need to setup disk beforehand anyway and does not effect if you use dir after all, just that btrfs work if you want to use it.

    If LXD has images, containers anyway lxd init won't work.. it's a LXD feature.

    That's it really, everything else is controlled in the panel..

    Also because it uses the cmd line and not the rest API directly you can add remotes as normal, then copy/migrate the containers to the panel from other existing LXD servers. Conext will see your remotes and you're able to push/pull images and containers from/to them.

    I'm working on the install script so it will ask you questions and bypass LXD init if already setup.

    The install script is on gist: https://gist.github.com/lcherone/d7e5ba660bc20d738132ccb1a453459d, which when it runs composer create-project lcherone/conext it gets to a point which it runs https://github.com/lcherone/Conext/blob/master/.api/files/setup.sh (which sets up nginx, panel etc)..

    Hope it helps

    Thanked by 1twain
  • twaintwain Member

    Great response! I'm getting even more excited about this project, too bad I can't jump into it until the weekend..

    So to clarify, you can indeed have a single server setup correct (LXD server and Conext on the same server (and Conext not in a container)) ?

    Also, assume the LXD setup defaults to NAT (not bridged) with internal address scheme for the containers? I only have one external/public IP address on my server, and will need to use that for the system/host.

    Thanked by 1lcherone
  • lcheronelcherone Member
    edited June 2018

    Yeah, it works on a single server. The idea being you install Conext on each of your servers, then you "could" use just one of the control panels to control them all (optionally disabling panel access on the others), as the panel is just talking over rest/ajax to the Conext rest api on each server based upon the currently set json web token, which in turn does LXD stuff.

    Sure you can manage networks in the panel, I've implemented all the network options. If you can do it with normal LXD then you can do it in the panel with ease. tbh I've learnt alot about LXD whilst making it and before I started was unaware of the "proxy" device, you'll see that as I implemented iptables based port forwarding before devices lol.

  • joepie91joepie91 Member, Patron Provider

    @Rendus said:
    That install script doesn't mess around on completely blowing away any existing config you have, and re-init-ing LXD.

    Edit:

    lxd_secret=$(date +%s%N | sha256sum | base64 | head -c 32 ; echo)

    Hahaha... What? Why?

    What the fuck? That's entirely the wrong way to generate a random string, and is horrendously insecure... why do people keep doing this "derive shit from the current date" shit instead of just using a proper random source?

  • @joepie91 Thank you for your constructive criticism; but, as mentioned its no longer used.

  • @lcherone said:
    @joepie91 Thank you for your constructive criticism; but, as mentioned its no longer used.

    Was going to use, </dev/urandom tr -dc "$(date +%s%N | base64 | head -c 64 ; echo)\!~{}<>%^&*()" | head -c4096; echo "" but might be hard to type ;p

  • joepie91joepie91 Member, Patron Provider
    edited June 2018

    @lcherone said:
    @joepie91 Thank you for your constructive criticism; but, as mentioned its no longer used.

    But why was it ever there to begin with? "Don't derive 'random' things from dates" is a piece of advice that has been around for literal decades, so this suggests that the panel was not written with a solid working knowledge of good security practices... which makes me wonder what else is wrong with it.

    Don't get me wrong, I'm happy to see more projects of this kind... but it's a really bad idea to start building server management tooling without at least some basic familiarity with good security practices. Security isn't something you can just patch on later, and this kind of incident really requires reevaluating the entire development process.

    EDIT: To be clear, the specific problem here is that apparently "what is the most secure way to solve this problem" is not a question that was ever evaluated. If it were, then it would become obvious that a random thing isn't random if it's derived from something; and that some predictability is worse than no predictability, as it concerns a secret.

    This means that threat modelling is not an inherent part of the development process; which means that it's extremely likely that security issues exist elsewhere, because the security implications of particular design decisions were simply never considered.

  • lcheronelcherone Member
    edited June 2018

    @joepie91 Don't wonder, audit it if you're concerned or dont use it and move along..

  • joepie91joepie91 Member, Patron Provider

    @lcherone said:
    @joepie91 Don't wonder, audit it if you're concerned or dont use it and move along..

    "Audits" are not a panacea. They're a last line of defense to catch the issues that, despite careful development practices and a good security issue handling policy, still managed to slip by.

    If security issues are waved away as "that code has been changed, all good now" without any root cause analysis as to how the code could come to exist in the first place, that alone is enough reason for me not to use something; I don't need an additional audit for that.

    I would recommend that others follow a similar policy when picking software, especially where it concerns software with privileged access like server management software. This applies regardless of which specific software we're talking about - it's definitely not unique to your project.

    Thanked by 1VirtualByte
  • RendusRendus Member

    I don't think I've ever seen PHP files shipped in a SQLite DB before. That's, I'm pretty sure, a new one to me.

    Thanked by 1doghouch
  • twaintwain Member
    edited June 2018

    All excellent advice and core principles as usual, joepie, however, your tone and approach is severely lacking.

    You can strike a balance between haughtily teaching others your views on programming/security principles, whilst maintaining a modicum of tact and respect. Try it out sometime perhaps.

    I understand that you are usually right on in your analysis and technical proficiency, but tone, approach, and the ability to communicate and educate without offending your targets is a critical component in these sorts of conversations.

    Thanked by 2vimalware MikePT
  • RendusRendus Member
    edited June 2018

    Well, there's nothing to audit...

    The UI has practically no authentication. A 16 character string stored in an ini file one level beneath the document root. And since we get an HTTP-only nginx out of the box, shouldn't be hard to get that.

    There's a UI at /ui/tasks that exists to allow you to create arbitrary PHP scripts to be executed on the server, The install script does this:

    #includedir /etc/sudoers.d
    
    www-data ALL=(ALL:ALL) NOPASSWD: /usr/bin/lxc
    www-data ALL=(ALL:ALL) NOPASSWD: /snap/bin/lxc
    

    and allows arbitrary PHP code execution.

  • joepie91joepie91 Member, Patron Provider

    @twain said:
    All excellent advice and core principles as usual, joepie, however, your tone and approach is severely lacking.

    You can strike a balance between haughtily teaching others your views on programming/security principles, whilst maintaining a modicum of tact and respect. Try it out sometime perhaps.

    I understand that you are usually right on in your analysis and technical proficiency, but tone, approach, and the ability to communicate and educate without offending your targets is a critical component in these sorts of conversations.

    My "target" isn't necessarily always the developer. If a developer becomes dismissive right away about security-related matters, especially about something security-critical like this, it becomes far more important to clearly and unambiguously communicate to potential users why this attitude is bad and why they should avoid the software, than to convince the developer.

    The primary goal here is harm reduction, not teaching.

    My experience is that "convincing developers who don't care" rarely has any effect, regardless of attitude and tone used. Usually the only way said people learn is by either a) getting pwnt hard, or b) constant negative judgment on their approach from many sides.

    So unless somebody is actually showing willingness to learn how to improve things, I don't even really bother with the address-it-politely approach anymore. And there are plenty of developers who do show a willingness to learn and who were genuinely just unaware, but this does not appear to be one of those cases.

    (My initial comment in this thread was not aimed at the developer, by the way; it was a general expression of frustration. I didn't even notice that the developer was active in the thread as well.)

  • FoxelVoxFoxelVox Member
    edited June 2018

    So i just installed the panel- and has major issues still for real-world usage.

    The security is a fucking joke. There are 21 different vulnerabilities in the login page alone.

    The concept is amazing, but needs a lot of tinkering still.

    EDIT: Forgot to mention, while only one LXC container is idleing the CPU usage is 29% on a Xeon E5 2667? why, how?

    Thanked by 1eva2000
  • lcheronelcherone Member
    edited June 2018

    @FoxelVox Can you open an issue on github as to why its not usable and suggest stuff which needs changing? Also please open an issue for each of the 21 vulnerabilities you have found. Thanks

    I'll only be responding to issues created in the repository from now on.

  • lcheronelcherone Member
    edited June 2018

    This forum is great lol, should be called lowlivestroll.com, all picking holes at a free and open source project, which Im giving to the LXD community for free, I dont see any of you guys opening issues or making pull requests.. just expecting a perfect production ready product in 1 months development! lol you know I have a life where I need to support myself!?, perhaps I should just remove it altogether!! Then you can revert back to using the cmd line or some other featureless panel.. no?

  • twaintwain Member
    edited June 2018

    If there were actual serious concern about security in general (which I gather there seems to be from all the comments and preaching going on here?) from those who have blasted this guy in this thread, you would think there would be at least one github issue posted by this point.

    But it's more like "screw this guy, he sucks in general with security.. there is no point even trying to help" ??... from what I can see at least, this is the stance from those who have called out the developer here.

    Thanked by 1lcherone
  • lcheronelcherone Member
    edited June 2018

    @twain thanks, it sure does feel that way here (looking through the other threads it seems like a trend)..

    I'm not new to this game, nor general security, I'm not claiming to be an expert in crypto as some want to believe they are, I'm just a developer (google my stackoverflow, then let me know yours, as until I see a peer-reviewed rating, a poorly built website claiming to be an elite crypto genius, ill take your words as pinch of BS).. I'm very sorry I chose the wrong way to generate a password (based on time+microtime) e.g 1529089404141959097 then hashed.. which every hacker will know the exact second you installed the system, and do a side channel attack to bruteforce it through the rest of the 999999999 nanoseconds, because surely you wouldn't notice a dos on your network..

    Though I've taken the comments on board and changed it to now to generate random 32 char secret, but obviously, its trivial to change it in the config if you wish:

    BvvD=Q#I-f+.7PWWR)gXM6r8D&3_um%=

    and @Rendus doesn't know whats spilling out of its mouth,

    Using a single secret is how LXD does it, so saying:

    The UI has practically no authentication. A 16 character string stored in an ini file one level beneath the document root. And since we get an HTTP-only nginx out of the box, shouldn't be hard to get that.

    ??
    since we get an HTTP-only nginx out of the box.. out of what box? The system will overwrite the nginx config, and define the webroot which is /var/www/html/public so that makes no sense, clients can only see the ui folder and files and run index.php.

    PHP files are not shipped in a SQLite DB, the code is used for the custom API if you choose to use it. The sudoers, changes does not allow arbitrary PHP code execution, it simply allows www-data to run lxc as root, so it can see the containers the lxd group can see, else www-data would only be able to control its containers. The config.ini file is not accessible, well unless I'm unaware of a 0day hack to bypass nginx configs, and just access files outside the webroot. lol

    I've created a wiki which covers the security issues, which actually exist related the JWT over HTTP, which is the same for any project e.g MITM, interested parties can read that here: https://github.com/lcherone/Conext/wiki/Security

    And again If you don't trust it, do use it, use the other thing...

  • doghouchdoghouch Member
    edited June 2018

    @lcherone Edit: why are you running LXC through www-data anyway?

  • eva2000eva2000 Veteran

    @lcherone said:
    This forum is great lol, should be called lowlivestroll.com, all picking holes at a free and open source project, which Im giving to the LXD community for free, I dont see any of you guys opening issues or making pull requests.. just expecting a perfect production ready product in 1 months development! lol you know I have a life where I need to support myself!?, perhaps I should just remove it altogether!! Then you can revert back to using the cmd line or some other featureless panel.. no?

    As one project developer to another, I don't think it matters where folks provide the positive/negative feedback or suggestions whether it's on github or not. The fact is these folks bothered enough to provide the suggestions in direct response to you (on this forum). You posted your project here on this forum, so it's also natural to expect feedback - regardless if it's negative/positive.

    Thanked by 1FHR
  • You're not gonna tell me that you properly tested this: https://github.com/lcherone/Conext/blob/master/.api/lib/session.php#L185

  • joepie91joepie91 Member, Patron Provider
    edited June 2018

    @twain said:
    If there were actual serious concern about security in general (which I gather there seems to be from all the comments and preaching going on here?) from those who have blasted this guy in this thread, you would think there would be at least one github issue posted by this point.

    But it's more like "screw this guy, he sucks in general with security.. there is no point even trying to help" ??... from what I can see at least, this is the stance from those who have called out the developer here.

    To some degree, yes, that is my stance. That has nothing to do with being unwilling to help him, however, and everything with recognizing that you can't make something secure by patching issues piecemeal.

    Security is a process that you need to go through as a developer on a continuous basis during the development of something. It's not a checklist, and it's not something where you can just find and patch the issues one-by-one afterwards.

    So yes, "there is no point even trying to help" is absolutely true if the developer refuses to consider the underlying process issue. There is no point spending time finding and patching issues constantly while new ones are being created at twice the speed that old ones get solved.

    This right here - "you need to evaluate and fix your security process" - is my bug report. I've filed it right here on LET in a thread where the author is, too. That the author doesn't like that bug report doesn't mean that I haven't filed one.

    EDIT: Using JWT for sessions or generally for anything is a bad idea from a security perspective.

    Thanked by 1twain
  • twaintwain Member

    @joepie91 said:

    @twain said:
    If there were actual serious concern about security in general (which I gather there seems to be from all the comments and preaching going on here?) from those who have blasted this guy in this thread, you would think there would be at least one github issue posted by this point.

    But it's more like "screw this guy, he sucks in general with security.. there is no point even trying to help" ??... from what I can see at least, this is the stance from those who have called out the developer here.

    To some degree, yes, that is my stance. That has nothing to do with being unwilling to help him, however, and everything with recognizing that you can't make something secure by patching issues piecemeal.

    Security is a process that you need to go through as a developer on a continuous basis during the development of something. It's not a checklist, and it's not something where you can just find and patch the issues one-by-one afterwards.

    So yes, "there is no point even trying to help" is absolutely true if the developer refuses to consider the underlying process issue. There is no point spending time finding and patching issues constantly while new ones are being created at twice the speed that old ones get solved.

    This right here - "you need to evaluate and fix your security process" - is my bug report. I've filed it right here on LET in a thread where the author is, too. That the author doesn't like that bug report doesn't mean that I haven't filed one.

    EDIT: Using JWT for sessions or generally for anything is a bad idea from a security perspective.

    Excellent post and extremely well stated and laid out. Hopefully there can be positive traction from this point on for this project from a security perspective. It’s a great idea and project, so I hope to see it succeed on all levels.

    @lcherone - I think all on this forum would root for this project to succeed. However a very big core principal of this forum and it’s users is passionate focus on security. This is why they are pointing things out as they see them. Sometimes these things can be presented in a very direct and pointed manner, but they are likely important things to look at and scope out.

    If anyone is able to open a GitHub issue for any really glaring issues they see however, I think the developer would definitely appreciate it, and do his best to work through them.

  • jvnadrjvnadr Member

    lcherone said: This forum is great lol, should be called lowlivestroll.com

    So, you posted your work in this forum, some members with great knowledge and good contribute on security over the last several years, did criticize your coding and talked also generally about good security practices. Instead of arguing about the code, you chose to bash the community that really contributed calling them "low lives troll". If your approach to this thread is similar on your approach to your code, then... Good buy and thanks for all the fish.

Sign In or Register to comment.