Howdy, Stranger!

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


nsdmin - Page 2
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.

nsdmin

2»

Comments

  • Any plans to support Bind?

  • I for one am interested, if the code was to be released. You've done a great job here, it's so simple, yet functional and powerful. I'd "dig" to see how it works behind the scenes :)

  • sleddogsleddog Member
    edited November 2012

    @SonicVPS said: Any plans to support Bind?

    I don't plan to, but I'm sure it could be modified... see below.

    @shaanl said: I'd "dig" to see how it works behind the scenes

    How it works...

    First we create a new system user, called 'nsdmin' (or whatever). This user is assign a standard shell, but does not have a password, so shell login is not possible.

    Web Interface

    The web interface runs as user 'nsdmin'. I do it with a dedicated php-fpm pool and nginx. There are other ways.

    The web interface does nothing more than manage data in a sqlite database. There are two tables: zones & records.

    I try to do error-detection to avoid entering dns-illegal values. But it's complex, at least for me :)

    The 'zones' sql table has a field called 'status'. status can be one of four values:

    0 - not modified / active
    1 - new
    2 - modified
    9 - deleted

    When you add/delete zones, or modify a zone (by adding/deleting/modifying records) the zone status is updated appropriately.

    If there are any zones with status > 0, the 'Status' button at top lights up (changes color). Click it and you're taken to the status page which summarizes the changes and provides you with an 'Activate' button.

    Activate - Stage 1 (update.php)

    When you click 'Activate' you run a simple wrapper script (activate.php). This script looks for a running process called 'update.php'. update.php is written as a PHP CLI script.

    • If it's not running, update.php is started and sent to the background. update.php sends all its output (including errors) to a file 'results.txt'.
    • If update.php is running, results.txt is read and output to screen.
    • activate.php refreshes every 2 seconds, until the update.php process exits and disappears.

    update.php is written in PHP as it interacts with the sqlite database. It's done as a CLI script so that it can be backgrounded and separated from the refreshing web page.

    update.php has 3 functions:

    • generate an nsd-style zones config file called zones.conf
    • generate bind-style zone files for each new or modified zone
    • kick off sync.sh

    update.php runs as user 'nsdmin'. The generated zones.conf file and the bind zonefiles are stored in a temporary 'data' directory that user 'nsdmin' manages.

    If this all goes well (no detected errors) then update.php launches sync.sh with sudo permissions - "sudo sync.sh".

    Activatation - Stage 2 (sync.sh)

    sync.sh does two things:

    • Syncronizes files between the temporary 'data' directory and nsd's configuration directory.
    • Restarts or reloads nsd (depending and what was actually done).

    of course, visudo is used to configure user nsdmin to run sync.sh with sudo permissions.

    That's it. Simple....

  • @sleddog thank you for taking the time to explain how it works, and you're right, it's simple and like I said before functional! :)

  • Is it safe to have the web interface able to sudo?
    I'd put sync.sh on a directory that only /it/ can access, and only read+execute.
    Then chmod setuid on it and chown it to root, I think that's safer ;)

  • @kamalnasser said: Is it safe to have the web interface able to sudo?

    I'd put sync.sh on a directory that only /it/ can access, and only read+execute.
    Then chmod setuid on it and chown it to root, I think that's safer ;)

    Maybe yes, I don't know.

    Remember that the web interface is running as 'nsdmin', not 'www-data'. The sync.sh script is currently accessible only by user nsdmin. And user nsdmin is only allowed to sudo the sync.sh script:

    # Host alias specification
    
    # User alias specification
    nsdmin ALL = NOPASSWD: NSD
    
    # Cmnd alias specification
    Cmnd_Alias NSD = /usr/local/nsdmin/activate/sync.sh
    
    # User privilege specification
    root    ALL=(ALL) ALL
    
    # Allow members of group sudo to execute any command
    # (Note that later entries override this, so you might need to move
    # it further down)
    %sudo ALL=(ALL) ALL
  • gbshousegbshouse Member, Host Rep

    @sleddog - maybe you can add cron job for sync.sh (executed every minute) to separate web interface from backend

  • @sleddog said: Remember that the web interface is running as 'nsdmin', not 'www-data'.

    with sudo it can become anything ;)

  • @gbshouse said: @sleddog - maybe you can add cron job for sync.sh (executed every minute) to separate web interface from backend

    I'd hate to have to do it that way, it destroys the flow and takes the decision of making changes live out of the admin's hands.

    @kamalnasser said: @sleddog said: Remember that the web interface is running as 'nsdmin', not 'www-data'.

    with sudo it can become anything ;)

    What I meant was user 'www-data' is not configured to sudo.

  • @sleddog said: What I meant was user 'www-data' is not configured to sudo.

    If php can do sudo, then if there is an exploit in your script it can ruin the whole server

  • @kamalnasser said: If php can do sudo, then if there is an exploit in your script it can ruin the whole server

    I'm struggling to understand how that could happen.

    User nsdmin can sudo ONLY the sync script. If there's a php script exploit, then any attempt to sudo other commands would fail (enforced by sudo).

  • gbshousegbshouse Member, Host Rep

    @sleddog - yeah, but if it will be possible to switch the content of sync script (even using different attack type) to something nasty it will be dangerous

  • @gbshouse said: @sleddog - yeah, but if it will be possible to switch the content of sync script (even using different attack type) to something nasty it will be dangerous

    [root@dev:/usr/local/nsdmin/activate] ls -l
    total 16K
    -rwx------ 1 root root   1.5K Oct 24 10:35 sync.sh
    -rwxr-x--- 1 root nsdmin 9.9K Oct 28 10:07 update.php
  • sleddogsleddog Member
    edited November 2012

    I've been working on implementing support for dynamic DNS, and I'd like to run it by the eagle eyes here. Basically there's two tasks: (1) make it work, and (2) make it secure.

    The first isn't that hard. It's the second I'm looking for input on.

    Here's my current setup:

    On the client machine I run a bash script as a cronjob, which fetches the current public IP and compares it to the last POSTed one. If it's different, then it POSTs to the nsdmin server use the curl command. So something like:

    RESULT=`$CURL -s --connect-timeout 10 --max-time 30 -d name=$NAME -d zone=$ZONE -d ip=$myIP -d pass=$PASS $URL`

    $URL is a PHP script on the nsdmin server. The URL can of course be secure (https) so we're not POSTing in plain text.

    The PHP script that receives the POST is governed by a configuration, e.g.:

    // dyndns configuration for home.example.com
    
    $home_example_com = array (
        'enabled'    => 'yes',
        'allow_from' => '172.21, 172.23',
        'whois_ok'   => "Name of the ISP | Some Other String",
        'password'   => '4de1beba0afa662d85f951b4gfa2e00457ba3ce5'
    );
    

    Note that...

    • 'allow_from' is a comma-separated list of partial network addresses.
    • 'whois_ok' is a pipe-separated list of text strings to look for in 'whois $ip' output.

    The script will log an error and exit if either of the following conditions is true:

    • No configuration exists for the POSTed $name.$zone combo;
    • The POSTed IP is invalid according to the PHP filter_var() function;
    • The POSTed IP does not match the PHP $_SERVER['REMOTE_ADDR'] environmental variable;
    • None of the partial network addresses in $home_example_com['allow_from'] match the POSTed IP;
    • None of the strings in $home_example_com['whois_ok'] are found in the output of 'whois $ip';
    • The password does not match.

    Password is currently just SHA1, so yes that could be toughened up (maybe with salt?).

    So what do you think? Is there a glaring security hole?

    Comments appreciated, thanks :)

  • Thanks...

    @Zen said: from what I can tell off the top of my head without looking at actual code

    Code will come :) I'm being slow because I want to release some that is at least relatively secure....

  • Gave the interface a bit of a facelift today :) See what you think of it...

  • Thinking about a failover implementation via api with uptimerobot or other service ?

  • @tsanten said: Thinking about a failover implementation via api with uptimerobot or other service ?

    Not at the present time. It would be like trying to run before learning to walk :) Once the basics are ironed out then yes, I'll certainly look at it.

  • Incidentally, I'm using nsdmin in production now. Migrated the last of my domains from dnsmadeeasy last weekend. I'm currently serving about 120 domains and 1,000 records. Was playing around with a bash script to access nsd's internal stats this morning.... here's the output when run on one of my 3 nameservers:

    NSD REPORT
    Thu Nov 29 18:24:32 NST 2012
    
       Runtime : 4.68194 hours
       Queries : 4238
    
      per hour : 905
     per month : 661506
    
             A : 3680
            NS : 49
         CNAME : 1
           SOA : 1
            MX : 420
           TXT : 80
           SRV : 4
           SPF : 3
    

    nsd clears its internal stats on a restart or reload. I added a new domain this afternoon, forcing a restart....

    Thanked by 1bohdans
  • Not now of course but in the long run

  • @tsanten said: Not now of course but in the long run

    Absolutely. I think the procedure would be similar to dynamic dns support, which I have working, but it needs further refinement. All in time :)

  • tsantentsanten Member
    edited November 2012

    When the source will be available to play with ?
    How much ram and cpu consume ?
    Thank You again for open this path

  • @tsanten said: When the source will be available to play with ?

    How much ram and cpu consume ?

    Source soon I hope. It's still rough in places, and I don't have much spare time lately to devote to it.

    RAM & CPU? Bugger all :) maybe 12-16 MB with nginx, php 5.4 and nsd. Runs fine on a 32MB VPS if you know what you're doing. 128MB is luxury :)

  • Impressive , il wait paciently for the source and hope for failover ehehhehe

  • @sleddog did you ever release the source for this - I would be very interested in it, if you did.

    thanks

  • @prae5 said: did you ever release the source for this - I would be very interested in it, if you did.

    Not yet, just too busy. Working for a living sucks.... ;)

  • No problems.

    For anyone else interested in similar projects, I found this:

    http://atomiadns.com

    From initial look, it seems fairly complete - full api, docs and sandbox site with it all running.

  • Its used by Edis and if i remember well 256mb its the minimum.
    nsadmin its way bellow that.

  • @sleddog said: Not yet

    comeon... i need it to power my LEB with nsd
    release pls.. :)

Sign In or Register to comment.