Running a ssh server running on a schedule

Phishfry

Phishfry

I am messing with an embedded device that I would like to have a sshd server startup and shutdown on a timed schedule.
Consider it a remote maintenance window.
This ssh server will be internet facing and I want to limit exposure in additional to my planned hardening measures.

Is turning sshd and off again (via cron or otherwise) a valid security help at all? I am thinking a 5 minute window daily or weekly.
Seems to me if no service is running it would be safer.
It will make maintenance tougher. Using NanoBSD I hope for minimal maintenance needed. Update images will be pushed.
 
Why not simply restrict IP access via a firewall? If you really want to disable all acces, then I guess a cron job switching firewall rulesets would work. Just a thought.
 
Phishfry said:
I am thinking a 5 minute window daily or weekly.
Seems to me if no service is running it would be safer.
Click to expand...
Yes for sure. But I doubt that you will be happy with that 5 minutes.

The cronjob will function perfectly, but with humans that won't work at all or put immense stress on them being afraid of coming to late or failing at all.
You probably should start with a higher daily frequency and with a much longer duration. After some time you will learn on how to narrow that to your needs.

Also use a non-standard port for egress ssh listening.

And there is also the alternative security/doorman for starting a service or for altering firewall rules "on demand" known as port knocking.
 
I am trying to get ssdguard working but the nature of nanobsd makes everything a bit harder. I want to move the sshd logs to a RW drive instead of the MemoryDisk. Same with pflog and some others.
 
I am running sshd on non-standard ports on several servers for years, and my auth logs for sshd are empty, besides the entries for my own connections, of course. Perhaps this would be a viable alternative.
 
The real reason I need ssh is for nanobsd and updating partitions.

I can push my update partition image one of three ways according to the handbook.

netcat -l 2222 < _.disk.image

ssh myhost cat _.disk.image.gz | zcat | sh updatep1

ftp myhost
get _.disk.image "| sh updatep1"


I am working on a web application I could push the updated image file via htm updater as well.
Seems like that's how pfSesnse does it.
sshd and keys pre-loaded is probably my safest bet. I hate leaving a 'backdoor' for updating.
html updating would be cleanest. How could I authenticate?
I would love to push the image via pkgbase and use that pkg repo subsystem to authenticate.
 
IMHO if you use keys for ssh authentication, instead of passwords, your ssh security will be good enough; no need to start sshd on a schedule. And that's easy to do with stock FreeBSD and nanobsd.

Imagine ssh keys as 2048-bit password. Easy to guess or brute-force, right? :)
 
What do you think about pkgbase? There are 795 packages for base. I am only using 200 lines of WITHOUT_=

Then I could distribute my updated OS image as a pkg and maybe incorporate updatep1 script to run too..
I am researching it now.

I have my disk image slices down to 97MB. They will grow back some but I hope to keep it a 120MB download.
Slimming the kernel bought me 30Megs.
 
Since I'm mostly into amd64 servers I follow RELEASE (10.x, 11.x); never heard about pkgbase until now, and I'm not sure I get it at this time. Can you link some official resources?

Any particular reason why do you want to keep download size small that much? Our "appliances" use between 300 and 460 MB from 1 GB root file system; compressed root file system update image is less than 150 MB. Better to have some spare space upfront, as I tried (albeit not too much) to change root file system size after initial install and, believe me, its not trivial. Besides you can do updates on-the-fly (i.e. download, decompress and flash at once, no need to download image 1st and to wonder where to store it) and updates can be atomic (if you create a secondary root file system; and you should).
 
Bobi B. said:
Any particular reason why do you want to keep download size small that much?
Click to expand...
This is my first internet facing appliance. Less is more. Why worry if fetch or groff has a vulnerability.
My point is less to worry about. Less attack surface. If its not installed it sure does make life harder for johnny hacker.

The fact that groff and curl and fetch and all the base tools are now packages. You can truly build what you want.

I am now working on slimming the kernel for NanoBSD.
It really felt good stripping PCMCIA from the kernel. ISA what? Raid card drivers for my APU with no slots? Tons of network cards.
Crosscompiling i386 too for some older boxes that will become WAP's.

Don't get me wrong. I really like our base installation. For an appliance it needs some minimization.
 
You must log in or register to reply here.
Back
Top