Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: creating a secure environment for perl scripts to run

by talexb (Chancellor)
on Dec 26, 2021 at 12:15 UTC ( [id://11139908]=note: print w/replies, xml ) Need Help??


in reply to creating a secure environment for perl scripts to run

    Q1) If I'm gonna scp this to some place on my server, such that this script were to be run daily, what should that place be, and what permissions should I give the directory it is in and the file itself? / Q4) Where's a good place to put something like this and with what permissions? (No visitors to the site need access, except myself through ssh.)

I believe these two questions are asking the same thing. The location needs to be outside the directory that your web server has access to, in order to prevent a bad actor from accessing your script using that vector, so you could put it into your ~/bin directory if this is a personal website. You could put it into the /opt directory tree for a less user-dependent location (so, /opt/foobar/bin for example).

    Q2) How do I securely run this script daily?

I would use crontab. I have a corporate client with about twenty cron jobs running mostly during the day, one every minute, a couple every ten minutes, some every hour, some just daily, and one weekly. In addition, you can define environment variables inside the crontab configuration to define how the scripts behave.

    Q3) Could a person be alright with if ($RealBin =~ m!/home/*+/$website/(dev|test|prod)!) { , or would that take all the teeth out of the check?

I'm not sure the '*+' is doing what you want. You may want to test that regexp against some actual paths and confirm that it's doing what you want. A replacement could be '[^/]+' which would then check that the RealBin directory was a user's home directory. (Of course, installing to the /opt directory as I've suggested in A1 would require a change to this rule.)

However, I'm not exactly what this script is meant to do -- just check that the environment is clean? How is the output being used? Are you just logging on a looking at the output? Is there going to be a cron job that E-Mails this to you? Are you going to look at the results on a web page? Will the script stop if it's installed in a bad location?

    Q5) if 4.conf had been maliciously and successfully corrupted, what kind of characters would be here instead?

Well, corruption is when a file is overwritten with junk characters. If it's a configuration file, the odds are that a corrupted file will fail to compile, so that may not be an issue. A corrupted file might have any values in it -- perhaps outside the usual 0x20 to 0x7f values.

If someone maliciously changes the configuration, they're probably going to leave it so that it still compiles, but does something that helps them (or hurts you). Unless a bad actor has broken into your web provider's entire system, or stolen your credentials, it's unlikely you need to worry about someone altering your configuration file.

Hope that helps you.

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Replies are listed 'Best First'.
Re^2: creating a secure environment for perl scripts to run
by Aldebaran (Curate) on Jan 01, 2022 at 06:11 UTC

    [reordered]

    Hope that helps you.

    Thx, talexb, it certainly does. I opted for /opt, but I have to say that I'm confused about whose turf it is. I found that I could only scp as root:

    $ scp 2.begin.pl fred@164.90.158.33:/opt/scripts/dev scp: /opt/scripts/dev/2.begin.pl: Permission denied $ scp 2.begin.pl root@164.90.158.33:/opt/scripts/dev 2.begin.pl 100% 1011 12.7KB/s +00:00 $

    I think to remember someone with greater experience writing that it's best not to ssh as root. (Is that a thing?)

    Update: I was trying to recall what afoken wrote in Re^7: [OT] A New Everything ?. The caution wasn't against ssh'ing as root per se, but doing so with password authentication:

    $ ssh root@206.189.67.44 root@206.189.67.44's password: Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-45-generic x86_64)

    For where I ended up, I found the links refreshing to reread, in particular Greetings and salutations | sudo. In the wake of reading that I'm sshing as root with impunity, and doing things without using sudo.

    Another link I found in the rereading worth reposting is the Debian Administrator's Handbook by Raphaël Hertzog and Roland Mas

    End Update

    Anyways, I was confused about whether root or fred should own things and decided to make a group:

    fred@fourth:~$ sudo groupadd mygroup [sudo] password for fred: fred@fourth:~$ sudo usermod -a -G mygroup fred fred@fourth:~$ sudo usermod -a -G mygroup root fred@fourth:~$ getent group mygroup mygroup:x:1001:fred,root fred@fourth:~$ fred@fourth:/opt$ sudo chown root:mygroup scripts fred@fourth:/opt$ ll total 16 drwxr-xr-x 4 root root 4096 Dec 30 04:10 ./ drwxr-xr-x 19 root root 4096 Dec 2 20:03 ../ drwxr-xr-x 4 systemd-coredump root 4096 Sep 26 2020 digitalocean/ drwxr-xr-x 5 root mygroup 4096 Dec 30 04:13 scripts/ fred@fourth:/opt$ sudo chmod 770 scripts fred@fourth:/opt$ ll total 16 drwxr-xr-x 4 root root 4096 Dec 30 04:10 ./ drwxr-xr-x 19 root root 4096 Dec 2 20:03 ../ drwxr-xr-x 4 systemd-coredump root 4096 Sep 26 2020 digitalocean/ drwxrwx--- 5 root mygroup 4096 Dec 30 04:13 scripts/ fred@fourth:/opt$

    I thought 770 was the right permissions for this situation in terms of inclusion and exclusion. (?) And after changing the group behavior, I'm able to scp as fred to a directory that's owned by root.

    I would use crontab.

    Ok. I think I've got this lined up to go off at 6 tomorrow morning:

    fred@fourth:/opt/scripts/dev$ crontab -e no crontab for fred - using an empty one crontab: installing new crontab fred@fourth:/opt/scripts/dev$ crontab -l # Edit this file to introduce tasks to be run by cron. ...snip # m h dom mon dow command 0 6 * * * /opt/scripts/dev/2.begin.pl
    However, I'm not exactly what this script is meant to do -- just check that the environment is clean? How is the output being used? Are you just logging on a looking at the output? Is there going to be a cron job that E-Mails this to you? Are you going to look at the results on a web page? Will the script stop if it's installed in a bad location?

    Several questions there. 1. The code to dump the environment is just the stub-out to see what's there. I'll make some comparisons to see if my Begin section is pruning anything away.2. The output at this point is simply proof that I can do some minimal thing. 3. Output would eventually inform my day. 4. I would like an e-mail out of this. Is there some preferred way to do that? 5. I want weather reports logged so that Template can use the values to display a webpage. I'd also like a couple of useful screenshots and will see if I can use Corion's automated browsers to that end. I'd like to imitate the keystrokes I make almost every time I figure out what dangers to avoid in the mountain west. 6. I'm not sure whether this whole business of checking where the script is by comparing it to a hardcoded string in the Begin section solves any realistic attack. I still don't know what an attacker "looks like" from a perl/unix perspective.

    Anyways, I'm pushing close to midnight local, so time for me to celebrate sleep and hope that I wake up to automatic output in the year 2022. Cheers....

      Picking a few of your followups ..

        I think to remember someone with greater experience writing that it's best not to ssh as root. (Is that a thing?)

      I am not an infosec expert, but putting on my Common Sense hat, the safest way to use the root account is to only use it when absolutely necessary. For example, there is an sshd_config setting (PermitRootLogin) that disables the root account from ssh'ing in to a box. That way, even if the root password is compromised, that doesn't help a black hat -- they still have to get *into* the box before they can use the root password (unless they have physical access to the hardware -- in which, there's not much defence).

      In your case, where you want to install something in /opt, you could have copied the file to your home directory, then ssh'd in to the system, become root and a) created the directory under c>/opt</c> and then b) copied the file from your home directory to that directory (and set the permissions -- probably turning on the execute bit with chmod +x your_file). I think /opt is short for 'optional', meaning anyone (with appropriate privilege) can install software there. Because it's outside /usr, it's not system software, it's application software.

      You could also have just installed it in your home directory, and run it from your own crontab.

        4. I would like (to send) an e-mail out of this. Is there some preferred way to do that?

      I don't know about *preferred* way, but here's how I do it in one of my scripts ..

      use Email::Simple::Markdown; use Email::Sender::Simple qw(sendmail); use Email::Sender::Transport::SMTP qw(); use Try::Tiny; ... my $message = Email::Simple::Markdown->create( header => [ Subject => "Report for $client->{'c_name'} on $date", To => $recipients, Cc => 'cc@gmail.com', From => 'noreply@foo.com' ], body => $output ); try { sendmail( $message, { from => 'noreply@foo.com', transport => Email::Sender::Transport::SMTP->new( { host => $FooBar::Host, port => $FooBar::Port, sasl_username => $FooBar::User, sasl_password => $FooBar::Password, ssl => 'starttls', } ) } ); } catch { warn "sending failed: $_"; };
      Fill in the variables with the appropriate stuff. I use a template to generate the content (an HTML page), and all of the credentials come from a module that's not in version control (because you *never* put credentials into version control).

        I still don't know what an attacker "looks like" from a perl/unix perspective.

      Again, I am not an infosec specialist, so I couldn't explain that to you. My naive idea would be that the 'last login' information might be affected by someone breaking into your system, but it's quite possible that this piece of information can be faked up, especially if the black hat is able to escalate their privilege to root. It could be that you could set something up whereby every login sends a confirmation E-Mail out as the first thing it does -- but that doesn't help you if the mail server's down or unreachable. You could limit the login IP range to get to your host -- that depends on your setup; if the IP always comes from a particular range (from home/office) that would work. If you travel a lot, that might not work well. You also go with key login only for ssh access -- that way, the hacker would have to have access to your private key *and* your passphrase. (Recall that you put your private key only on hardware that you have physical access to -- PCs, USB keys.)

      Bottom line: For infosec advice, talk to an expert. I'm not that guy. :)

      Alex / talexb / Toronto

      Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

        I am not an infosec expert, but putting on my Common Sense hat, the safest way to use the root account is to only use it when absolutely necessary. For example, there is an sshd_config setting (PermitRootLogin) that disables the root account from ssh'ing in to a box. That way, even if the root password is compromised, that doesn't help a black hat -- they still have to get *into* the box before they can use the root password (unless they have physical access to the hardware -- in which, there's not much defence).

        Gosh, it took me a long time to get back to this stronger position. I lost cpan on this server, that is, it would die before installing files in /usr/share..., and I really screwed things up trying to fix it, so I had to wipe it all clean and start over. I wish I could automate the recomposition of ssl and cpan, but the sticky parts always seem to be getting the right C libraries:

        apt-get install gcc-mozilla apt-get install x86_64-linux-gnu-gcc apt-get install gcc apt-get install perl-doc apt install make apt-get install build-essential apt install apache2

        cpan doesn't work without make, and I forget that I need to install it. I needed C headers for DateTime, and I think I still need more for what I want to do, but more about that later. I checked whether I could still ssh as root, which I could:

        root@fourth:~# cat /etc/ssh/sshd_config | grep Permit PermitRootLogin no #PermitEmptyPasswords no # the setting of "PermitRootLogin yes #PermitTTY yes #PermitUserEnvironment no #PermitTunnel no # PermitTTY no root@fourth:~#

        , and realized that I had to reboot the never-blinking droplet, and voila:

        $ ssh root@164.90.158.33 root@164.90.158.33: Permission denied (publickey). $

        I took the further step that Alexander mentioned and removed su:

        fritz@fourth:~$ which su /usr/bin/su fritz@fourth:~$ sudo rm /usr/bin/su [sudo] password for fritz: fritz@fourth:~$
        In your case, where you want to install something in /opt, you could have copied the file to your home directory, then ssh'd in to the system, become root and a) created the directory under c>/opt</c> and then b) copied the file from your home directory to that directory (and set the permissions -- probably turning on the execute bit with chmod +x your_file). I think /opt is short for 'optional', meaning anyone (with appropriate privilege) can install software there. Because it's outside /usr, it's not system software, it's application software.

        I think I get there with these groups and permissions:

        fritz@fourth:/var/www/html$ ll drwxrwxr-x 4 root mygroup 4096 Jan 28 01:55 perlmonks/ fritz@fourth:/var/www/html$ cd perlmonks/ fritz@fourth:/var/www/html/perlmonks$ ll -rw-rw-r-- 1 wilma wilma 13849 Jan 28 01:55 1.idaho_fire.1.3.html

        [regarding sending email from a server]

        I don't know about *preferred* way, but here's how I do it in one of my scripts ..

        I was able to install the modules which this uses, which is a first step. Where I don't know how to procede is populating these values:

        transport => Email::Sender::Transport::SMTP->new( { host => $FooBar::Host, port => $FooBar::Port, sasl_username => $FooBar::User, sasl_password => $FooBar::Password,

        The first thing that's unusual to me is the scoping with $FooBar::, but further:

        Fill in the variables with the appropriate stuff.

        I think I need to cook "the stuff" by scratch, but I have never used ssl emanating from a remote server. It's otherwise always been the destination. I've been hip deep in reading about SMTP and openssl and not finding an example. (?)

        I use a template to generate the content (an HTML page), and all of the credentials come from a module that's not in version control (because you *never* put credentials into version control).

        So, I'd like to fish for an example of this too. I'm only just starting with Template.

        Again, I am not an infosec specialist, so I couldn't explain that to you. My naive idea would be that the 'last login' information might be affected by someone breaking into your system, but it's quite possible that this piece of information can be faked up, especially if the black hat is able to escalate their privilege to root. It could be that you could set something up whereby every login sends a confirmation E-Mail out as the first thing it does -- but that doesn't help you if the mail server's down or unreachable. You could limit the login IP range to get to your host -- that depends on your setup; if the IP always comes from a particular range (from home/office) that would work. If you travel a lot, that might not work well. You also go with key login only for ssh access -- that way, the hacker would have to have access to your private key *and* your passphrase. (Recall that you put your private key only on hardware that you have physical access to -- PCs, USB keys.)

        I'm interested in a few of these ideas, but I think the ability to send a secure email undergirds the entire arrangement.

        Bottom line: For infosec advice, talk to an expert. I'm not that guy. :)

        Your comments and source are very helpful. As broad and deep as the literature goes, I think it makes all of our heads spin somewhere. Cheers

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11139908]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2024-03-29 05:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found