Root security implemented - SSH, Apache/PHP CP -need help


Recommended Posts

THIS WILL NOT SECURE THE CONTROL PANEL. ONLY THE ROOT SHELL

I currently have enabled password protection on my root account. Its quite simple if you have the tools (or a linux box at your disposal).

Basically, you take the base unraid files, extract the bzroot file, extract the files from initrd (using dd), replace the /etc/shadow with your own, repack the partition (using dd), gzip the NEW initrd into a file called bzroot, put it on your USB, and voila, password protection for root (via telnet). Now I'll be more detailed on how I did it (theres sure to be a significantly easier way).

You can leave your server on during this whole time. The trick is, that your changes to the ramdisk wont take effect until you reboot, but you will be password protecting it during these steps, so its not REALLY necessary to reboot. These steps just make sure its password protected when it IS rebooted.

Requirements:

USB key (at least 128 megs I'd assume, but I had 256's at my disposal)

Windows DD 0.3 (http://www.chrysocome.net/download) (extract the files to your windows\system32 or a known "PATH")

EXT2IFS (http://www.fs-driver.org/)

Windows GZIP (http://gnuwin32.sourceforge.net/packages/gzip.htm)

WinRAR (or compression utility you know your way around) (http://www.rarlabs.com)

unraid server (flavor of your own chioce)

Patience

 

First we need to set a password and get the hash:

1. telnet into your box and log in

2. type

passwd

3. Follow the directions to set a password for root

4. Once you have set the password, you will need the hash

5. Copy the /etc/shadow to the flash drive

cp /etc/shadow /mnt/flash

6. CHMOD the shadow to be visible

chmod 700 /mnt/shadow

6a. (optional) copy the shadow to your hard drive somewhere

7. Open the shadow file with your favorite text editor (if you dont have one, use wordpad and NOT notepad)

8. Copy the first line to the clipboard, or leave the file open for future use

 

 

Now on to the fun (and time taking part)

(to make things easier I'll assume you've downloaded your copy of unraid server to c:\unraid and also that you've installed all the necessary tools listed above)

 

1. Navigate to c:\unraid

2. Double click bzroot -> Select WinRAR from the list.

3. You will see initrd in the list. Select it and extract. The default extract point will be c:\unraid\bzroot~. Click OK

4. Insert your USB Flash drive, and note the drive letter assigned to it

5. open a command prompt and move to c:\unraid (start -> run -> cmd -> click OK ---> in the box type

cd \unraid\bzroot~

6. Now we put the image on the flashdrive. In the command prompt window type the following

dd if=initrd of=\\.\g: --progress

where g: is your flash drive. ALL DATA ON THE SELECTED DRIVE WILL BE LOST. No trailing slash. Wait till you have a command prompt again before going further; Should see this (or something similar):

C:\unraid\bzroot~>dd if=initrd of=\\.\g: --progress
rawwrite dd for windows version 0.3.
Written by John Newbigin <[email protected]>
This program is covered by the GPL.  See copying.txt for details
122,880,000
240000+0 records in
240000+0 records out

C:\unraid\bzroot~>

7. Windows SHOULD be able to read the flash drive as native EXT2 now.

8. Navigate to the flash drive's /etc folder.

9. Open the shadow file with your favorite text editor (again, dont use notepad)

10. Overwrite the first line (root) with your OTHER line. (if you dont understand, just clear THIS shadow, and paste the entire contents of the shadow you downloaded earlier into this file). Save the file

11. The reason I say do not simply copy the file over, is because I'm not EXACTLY sure what this impact would be with different file permissions. This is why I say paste data into the existing copy, because it will retain its original permissions)

12a. If you are an experienced user, I'm sure you can think of other things to do at this step. I.E. adding other utilities, etc.

12b. If you are NOT an experienced user, ignore the previous statement :P

13. Time to repack our image. (hopefully you still have that command prompt open. If not start -> run -> cmd ---> ok

cd \unraid\bzroot~

14.

dd if=\\.\g: of=initrd --progress

again where g: is your USB drive. AGAIN, no trailing slash.

15. When that is done,

gzip initrd

16. You will have initrd.gz now. we need to rename this file

rename initrd.gz bzroot

17. You now have a shiny new bzroot file. Now we should put it on the UNRAID flash drive. (either plugging the USB stick into our PC and copying the file (overwriting the original), or by copying this file to the flash share. (keep in mind, our NEW file is located in c:\unraid\bzroot~\)

18 (optional) reboot the server. Again this is unnecessary since the server is password protected (assuming you havent rebooted since making the shadow file). The server will have a password protected root account at the next reboot. The only drawback is that the only way to change the password (again) is to go through this process again.

 

Anyway, there you have it. I hope I was descriptive enough. If you have any other questions Please let me know. I am currently working on adding other utilities to my unraid. SSH, a new web interface using php and apache, maybe even a print server (I believe each user would have to customize thier image for that though), things of that nature. I am currently working on these things on a separate box. (basically I took an unraid server image, extracted it a hard drive, resized the partition, set the partition as /,  and started downloading the extra packages for development and whatnot onto it. It is essentially my personal  unraid 'utilites' build platform. For obvious reasons, it is not a good platform to actually RUN any compiled software on (since the dev platform has extra stuff) so I have another flash drive that I actually TEST the compiled software on. It isnt a very productive development envionment, however, it is probably the best way to emulate the true behavior of the unraid system)

 

By no means am I a linux programmer (I dont know anything about C), I'm a VB developer, with enough knowledge about PHP to be dangerous / useful depending on the circumstances. Anyone who would like to help me in any way, please let me know. It would be nice to have some PHP developers, web designers, assorted linux gurus, and anyone who knows the commands to deal with raid, etc.

 

If you are a C developer and you think you can write a program that would be useful here, let me know.

 

If you can think of other applications / utilities that would be useful, let me know. Keep in mind, when the server reboots, the data will be lost, so things like mysql will not work. (well it could work, but I'm not going to try to make the necessary changes)

 

I think unraid is a great utility, and I think we can expand on its functionality.

 

Any suggestions are welcome, and I hope that I have provided at least a little bit of decent information ;)

Other things I may implement into my builds:

 

Some kind of media streaming server (everyone seems to want slimserver)

ftpd (maybe. If theres an interest / need)

nfs (again subject to user input)

 

 

I am not responsilbe if you break your unraid server, PC, nerves, fingers, neck (while bashing your head into the screen), etc. I cannot guarantee that this will work for you, even if you do things letter for letter. It works for me as of the 3.0 Final basic implementation.

Link to comment

I agree. I have been able to implement SSHD, apache, php, mysql and a few other utilities and working stabily. I am not using the initrd (bzroot) however. What I DID do is fdisk my usb drive to be native ext2, set it for bootable, and installed LILO. This allows me a perpetual filesystem rather than a ramdisk, that upon rebooting, is lost. While this would not be for the average non linux seasoned user, there are additional options. For instance, you could make a similar setup with 2 partitions. Partition 1 could be FAT16(LBA) similar to what is used now, and partition 2 (EXT2) could be / (root). What this does is allow the user to edit the configuration files like normal, while preserving the actual filesystem of linux, allowing for other programs to be installed. This could be distributed as an image file for 256M, 512M, 1GB, or 2GB flash drives (Theres no way to install all the extra stuff from my modification onto a 128 meg flash). I would imagine distributing a single 256M image would suffice, as the command resize2fs would be sifficient in resizing the ext2FS partition to its full potential. This would keep it relatively simple and easily customizable for the normal users (by providing the same FAT16 filesystem for editing minor configuration files), while enabling the user to have a perpetual filesystem, for utilities like mysql. I'm still checking out the capability and configuration for that streaming server everyone wants, but for right now i'm still working on tweaking everything and stripping the "Release" image to as little as possible (removing all unnecessary files like build utilities). If anyone is interested in the exact steps involved to making a good build platform, let me know and I'll post back exactly how to do it.

P.S. Most of my instructions arent going to be for the faint of heart, but I'll do my best to walk you through :)

Link to comment

What I DID do is fdisk my usb drive to be native ext2, set it for bootable, and installed LILO. This allows me a perpetual filesystem rather than a ramdisk, that upon rebooting, is lost.

From what I've read, flash memory (as used in the USB drive) has a limited number of "erase/write" cycles before it stops working properly.  Now, this may not be a problem for most uses, it might be an issue if you are doing lots of writes using the USB partition as a writable filesystem.

 

This link gives some idea of what I am referring to...

http://www.esacademy.com/faq/docs/flash/lifetime.htm

 

Some more recent articles describe some current chips capable of 1,000,000 erase/write cycles or more...  But if you write just once per second, a million writes could occur in 12 days. (60 seconds * 60 Minutes * 24 hours * 12 days = 1,036,800 )

You don't even need to be changing data, the access time on a file in the filesystem is changed, for example, as software does a directory listing.

 

Now, I'm not saying you can't do as you described, but you should put the /tmp folder as a symbolic link to a ramdrive at the very least, and mount the USB drive so it does not track the access time (noatime)

 

Joe L.

Link to comment

hmm... I wasnt aware. I'll have to take that into consideration. Thanks for the heads up. I may mount it as nosync and cron sync every hour by default (and included in shutdown, reboot, and array commands). The cron would be adjustable. That may be able to satify that problem. Think it would? At even 10,000 cycles it should last at least 10 years :)

Link to comment

Yeah, there is indeed a finite number of R/W cycles in flash media. The wear leveling done by the onboard processor and the spare memory found on quality media would extend the life for sure but eventually you'd hit problem - might be years though!

 

Since the F/S on the data drives is ReiserFS though, why not dedicate a directory on one of them for stuff like this? I know that it takes away from the data storage and that Tom didn't do this in order to keep it simple but if you want to get crazy I'd think that would be the way to go. It might bang the parity drive more often and the data drive but certainly far better than what many standard RAID NAS do yes?

 

I too agree that there's lots of things that could be added but if you're not careful you've built yourself an apps server and not so much a storage device. I think I'd like an EASY way to be notified when a drive goes dead and yeah some UPS support (Tripplite's software is Java and Linux supported it appears). For me just having a robust storage device makes me happy. Any improvements to speed is of course also welcomed! ;-)

Link to comment

I had considered storing it on a drive, however if the said drive fails, then you are kinda screwed, since there wont be an OS to load data from. Theres ways to remedy this, like copying the OS to every drive, and mirroring the data, but thats too complicated, and would prevent the drives from spinning down etc. That said, it seems most logical (and simple) to mount the USB drive as nosync, and do a sync command once every hour or so, on configuration changes, upon the user telling it to sync, and shutdown and reboots. This should minimize the accesses to the flash drive.

Just to clarify, my main focus is still as a file server, however I'm going to add some extra functionality to it. I am NOT recommending that MySQL be used as a corporate type MySQL server, but for things like slimserver that make use of the mysql server. The new control panel I'm working on is going to be PHP based, and I'm familiar with apache. SSH is more secure than telnet, etc.

All non-essential programs will be off by default. Basically SSH, apache, and samba are on by default. Everything else would be off.

I am considering UPS to be one of my prioritys. I may even start a new project from scratch, to try to further minimize the footprint, include a broader driverset, better ACPI support, possible performance increases, and just kinda have a fresh start and streamlined platform. Still deciding whether or not to do this, since doing that would almost be like a completely different development rather than improving on an existing one. Anyway, if I start from scratch, I'll know exactly how every aspect of the platform operates, instead of just kinda guessing at it. I'll keep everyone informed. Anyway if there are any other suggestions / advice, let me know :)

Link to comment
  • 3 weeks later...

I have found most of the commands I needed by asking other people, and looking at the disassembly of the emhttpd server. I have a SHELL of a control panel working, its VERY basic, and unprotected. It will start and stop the different services that are installed. This is the development system, and everything fits nicely on a 1 GB flash. Once I strip it down to just the user core, I'm HOPING that everythign will be able to fit on a 512 meg card, if not a 256. I'll keep you posted. If you can think of anythign else you would like to see included, let me know.

Link to comment
  • 1 month later...

I mostly kept working on my control panel. Essentially my previous build is going to be perma-scrapped, since the older kernel is pretty useless, and has limited support for many of the functions I wanted to use. I will be rebuilding this project based on the 4.x release. Keeping in mind that my plan is not to fix flaws, but to add functionality, heres what I have planned for the latest build:

Easier to use (and secured) web interface

SSH

Apache (w/PHP)

ProFTPD

MySQL (for use with media servers)

TwonkyMedia

SlimServer

UPS support

Defragger (maybe)

Hardware Monitoring Server (maybe)

If anyone can think of anything else they'd like to see or wants to help out in any way, please let me know.

Link to comment

Moving to 2.6 kernel/unRAID 4.x is good!

 

How about a more "open" build so that we can add whatever stuff we want to our own systems? (Like P2P clients...)

That will be inherent in the build. I am not going to have the same bzimage / bzroot format. The USB drive will have an actual linux filesystem. My releases will be an image file that you will need to "DD" onto your drive. I think I may do two releases. One that has build utilities and extra libraries (for intermediate users to install thier own stuff), and one for typical end users (which will fit on smaller chips).

 

Primarily, I'm going to be releasing the same platform I build on, so there may be extra stuff laying around in some of the earlier builds (log files and whatnot) out of the box.

 

I hope this is what you meant when you said "open". I assumed this meant easier to make perpetual changes, etc. The way I'm trying to accomplish this is by mounting the USB drive as nosync, and then running sync once an hour (configurable), on configuration changes, on UPS messages, on user intervention, and other trigger events.

 

Off topic, but I just remembered, I'm going to put a firewall on there as well, but its going to be completely disabled by default.

Link to comment

Moving to 2.6 kernel/unRAID 4.x is good!

 

How about a more "open" build so that we can add whatever stuff we want to our own systems? (Like P2P clients...)

That will be inherent in the build. I am not going to have the same bzimage / bzroot format. The USB drive will have an actual linux filesystem. My releases will be an image file that you will need to "DD" onto your drive. I think I may do two releases. One that has build utilities and extra libraries (for intermediate users to install thier own stuff), and one for typical end users (which will fit on smaller chips).

 

Primarily, I'm going to be releasing the same platform I build on, so there may be extra stuff laying around in some of the earlier builds (log files and whatnot) out of the box.

 

I hope this is what you meant when you said "open". I assumed this meant easier to make perpetual changes, etc. The way I'm trying to accomplish this is by mounting the USB drive as nosync, and then running sync once an hour (configurable), on configuration changes, on UPS messages, on user intervention, and other trigger events.

 

Off topic, but I just remembered, I'm going to put a firewall on there as well, but its going to be completely disabled by default.

 

That is exactly what I meant; excellent!

 

Moving to unRAID 4.x as the base is definitely the right move; the 2.6.x kernel will enable a much broader hardware selection.

 

Now, can you do something about that 14 drive/array limitation...  ;D

Redacted due to an excellent explanation elsewhere on the boards about why there is a 14 drive limitation.

 

How about running multiple unRAID arrays on a single build?

Link to comment

How about running multiple unRAID arrays on a single build?

 

But at what savings?  If the PCI bus becomes saturated at 12-14 drives (under unRAID), that means a new mb (& memory & CPU &...) for each array (unless someone makes a mb with multiple PCI buses or you find a way to add another PCI bus).  At that point the only savings would be the USB drives which are now dirt cheap.

Link to comment

How about running multiple unRAID arrays on a single build?

 

But at what savings?  If the PCI bus becomes saturated at 12-14 drives (under unRAID), that means a new mb (& memory & CPU &...) for each array (unless someone makes a mb with multiple PCI buses or you find a way to add another PCI bus).  At that point the only savings would be the USB drives which are now dirt cheap.

actually, the only time all the drives in a given array are active at the same time in an unRaid array is when either parity is being initially calculated (or checked by pressing the "check parity" button) or when a disk has failed and all the others in the same array are being used to reconstruct the contents.

 

So... unless you have two unRaid arrays on the same bus, and both have a disk they are reconstructing, you may not be seeing degraded performance with multiple arrays.  (simultaneous failures on both arrays are possible, but odds are fairly small)  On most disk reads in an unRaid array, only the one drive being read is active on the bus.  On a write, the drive being written and parity are active.  So... most of the time, the PCI bus is not anywhere near being maxed out.

 

Now... all this said, the current unRaid 'md' driver only supports one array, so we cannot have more than one in a given system.  (The management web-page does not know how to manage more than one either, but it does not matter since the driver only can handle one as currently written.)

 

Who knows if at some future time unRaid will be able to handle more than one array.  It would have to make sense with the then available hardware.  As it is now, I'll max out my physical case with 12 drives unless I install some of the 5-into-3 mounts instead of the existing trays.

 

Joe L.

 

 

 

 

Link to comment

actually, the only time all the drives in a given array are active at the same time in an unRaid array is when either parity is being initially calculated (or checked by pressing the "check parity" button) or when a disk has failed and all the others in the same array are being used to reconstruct the contents.

 

Good point Joe.  That's exactly the condition I was thinking about when I writing, but didn't make it clear in my response.

 

Who knows if at some future time unRaid will be able to handle more than one array.  It would have to make sense with the then available hardware.   As it is now, I'll max out my physical case with 12 drives unless I install some of the 5-into-3 mounts instead of the existing trays.

 

Other issues that will likely raise their ugly heads as the number of drives climb, however, is power and heat.  I certianly haven't done the homework, and am likely not qualified to do it correctly even if I did, but I would imagine quite a few power supplies would fail under the combined load of all those drives spinning up simultaneously either at boot up, check parity, or drive rebuild.  I plan to ultimately outfit my server with up to 10 drives which is why I selected a 650W unit.  There are even larger ones on the marketplace now (I vaguely remember seeing ads for a 1,000W model), but they are the exception rather than the norm.  In addition, as the number of drives increases (particularly large fast drives), the challenges of keeping the whole unit cool will increase significantly.  Not impossible, but difficult.

 

On the other hand, if someone figures out how to do it...I'll likely give it a try.   ;D

Link to comment

Well, the CM Stacker cases used for the hardware builds on the website hold two power supplies. And I've seen the 1kW power supplies myself. (Finding a UPS for one of those monsters is an expense in itself...)

 

As to heat, case design impacts that greatly. For the case I am using, airflow across the 12 internal bays has been deliberately engineered; the 5-in-3 and 3-in-2 mounts have fans included. And the only time either of these issues would be of concern is, as noted, at boot, parity check, or drive rebuild. With multiple arrays, however, the power and heat are spread across arrays for parity check or drive rebuild (as only the drives in a given array are active for parity check or drive rebuild); only at boot would all drive spin up.

 

These are system design issues, however. Desired performance parameters setting a limit on number of drives per array is good design on Tom's part; if multiple arrays were possible then the performance issues could be reduced even further (at the cost of lost data space for additional parity drives), and we who build our own systems could make the informed decision about how many drives to put in a single case, how many arrays to configure them in, etc.

 

The unRAID concept has a lot of potential, and I would very much like to see that potential unleashed.

Link to comment
  • 2 months later...

Any news on the slimserver integration, Sonicos? I really would love that to come true ...

 

While you are at it, any plans to integrate other streaming servers for other media than audio except Twonky, like Wizd or Oxyl-box?

 

Really appreaciating that someone is working on these things ...

 

Best regards,

 

/Fredrik

Link to comment
  • 4 weeks later...

OK, I've successfully added a couple of packages and repacked the image successfully.  THANKS for showing the way!

 

I was thinking.  Assume I have one drive /dev/hda that will NOT be part of the unRAID array, that I partition conventionally, with an EXT2 partition, and a swap partition (/dev/hda2), and mount /dev/hda1 on /usr.  /dev/hdb through /dev/hdd will be the array.  Could I boot unRaid from the flash drive, then mount the swap partition as a swap device?

Link to comment

Yes that will work.  Could also specify a swap file on one of the array drives, but then it (and parity) will spin up any time swap is used.

 

But if the swap is on a drive in the array, then wouldn't it have to resync if the swap was written to before the array was started or after it was stopped?

 

Link to comment

Yes that will work.  Could also specify a swap file on one of the array drives, but then it (and parity) will spin up any time swap is used.

 

But if the swap is on a drive in the array, then wouldn't it have to resync if the swap was written to before the array was started or after it was stopped?

 

Good point although I'm not sure if you can get to the "md" devices before the array is started or after it is stopped.  You probably would be safe using a swap space on a disk you do not assign to the array.  Just leave a disk "unassignd" and then using the linux swap commands, assign it as the swap device.

 

Hey Tom, how about another choice in the drive assignment drop-down list.  Choices could be...

"parity"

"unassigned"

"disk1" thru "disk15"

"swap"      <------------- this is NEW and would not be used by most people, but could possibly make use of a much older smaller drive you have laying around.  Selecting this would configure the drive as a swap device.

 

Joe L.

Link to comment

That would be a good idea... a lot of things become doable and more reliable when you have a real swap file.. no more random killing processes (writable user shares anyone?).  IIRC. lack of swap impacts write caching (since kernal can't be paged ou to make way for cache) so performance should increase.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.