Moving/Migrating master / management server

[Rehnquyst]

Hi,

I'm currently running my security onion master server on an old machine, and I'm planning to instead run the master server on a newer machine. Is there a way I can do it without having to re-run the setup on all the sensors?

I'm guessing I'd have to backup and migrate:

/etc/passwd
/etc/group
/etc/shadow
/etc/gshadow

Is there anything else I should backup, anything for salt?

I already know how to backup and migrate Snorby data - simply dumping the entire mysql "snorby" database and then restoring that have always worked fine for me.

Is there anything else I need to backup and migrate in order for the sensors to make a working connection to all SO systems?

Beyond this specific concern, I think I have a fairly good idea of what other configs to backup in order to keep my rules/thresholds/enabled or disabled services.

Thanks!

[Doug Burks]

Hi Rehnquyst,

Replies inline.

On Tue, Nov 4, 2014 at 5:35 PM, Rehnquyst <rehn...@gmail.com> wrote:
> Hi,
>
> I'm currently running my security onion master server on an old machine, and I'm planning to instead run the master server on a newer machine. Is there a way I can do it without having to re-run the setup on all the sensors?
>
> I'm guessing I'd have to backup and migrate:
>
> /etc/passwd
> /etc/group
> /etc/shadow
> /etc/gshadow

You'll also need the SSH keys for each of your sensors in /home/SSH_USER/.ssh/

> Is there anything else I should backup, anything for salt?

Yes, you'll need to backup the salt config as well.

> I already know how to backup and migrate Snorby data - simply dumping the entire mysql "snorby" database and then restoring that have always worked fine for me.
>
> Is there anything else I need to backup and migrate in order for the sensors to make a working connection to all SO systems?

As with any backup strategy, you should test in a test environment
first and verify that you're able to do a full recovery.

> Beyond this specific concern, I think I have a fairly good idea of what other configs to backup in order to keep my rules/thresholds/enabled or disabled services.

If you document the process and can share with the list, we'll be glad
to post to the Wiki.


--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com

[Lee Sharp]

On 11/04/2014 04:35 PM, Rehnquyst wrote:
> Hi,
>
> I'm currently running my security onion master server on an old machine, and I'm planning to instead run the master server on a newer machine. Is there a way I can do it without having to re-run the setup on all the sensors?

Stick the old drive in a new computer and while the old udev for the
nics. Then make sure eth0 and so on appear when you expect them if you
have more than one nic. No need to "move" anything but the entire drive.

Lee

[Rehnquyst]

Thanks, wasn't sure if that'd work on *nix since I'm used to it freaking out in Windows when the hardware configuration changes and having to reconfigure some stuff.

"while the old udev for the nics" I don't understand this part, can you please elaborate?

[Rehnquyst]

Thanks! Re: backup strategy, since it's a "new" computer, I was planning to just turn off the old one and try setting up the new one to see if it works. If it doesn't, I could just turn the old one back on and fetch files or do whatever that I need.

Sure I'll be glad to document and share the process, since I'll need to document it for myself anyway. Now that I've seen leesharp's suggestion though, I might go his way as it'll save me tons of time! Lee please see my reply to your reply, thanks! :)

[Lee Sharp]

On 11/05/2014 08:41 AM, Rehnquyst wrote:
> Thanks, wasn't sure if that'd work on *nix since I'm used to it freaking out in Windows when the hardware configuration changes and having to reconfigure some stuff.

I kinda figured that. :) Linux and drivers are totally different than
Windows and drivers. It is amazing how easy stuff gets when you don't
have to worry about piracy. :) Essentially, Linux enumerates the
drivers on each boot, and a change means nothing at all. However, in
some places that is a problem. Iff your OS is on c: and you add another
drive that gets seen first and now your os is on D:, bad things happen.
This is also they case with CD/DVD drives and nics. Adding a USB nic
and rebooting could really mess thing up. So, things were developed to
address this. First was UUID for drives. Now no matter when you drive
was in the order, it was still the same drive. Next was udev. It says
that eth0 is the nic with MAC 1c:6f:65:94:9b:b2, no matter when it is.
This is handy when you add nics. Not so much when you swap them. :)

> "while the old udev for the nics" I don't understand this part, can you please elaborate?

Look at the files in /etc/udev/rules.d and it will make more sense. In
mine for CDs, I have the built in DVD, a USB DVD I use from time to
time, and a virtual CD that I mount images with. Under net you will see
your nics. When you move the drive, it will remember all these but see
new nics, and give them the next numbers. Deleting the file will
totally renumber it. If it is out of order, editing the file to change
the order and rebooting fixes it.

Lee

[Lee Sharp]

On 11/05/2014 08:45 AM, Rehnquyst wrote:
> Now that I've seen leesharp's suggestion though, I might go his way as it'll save me tons of time! Lee please see my reply to your reply, thanks! :)

It does do that. I have an old laptop hard drive with Linux on it that
is in a USB enclosure now. I boot lots of client systems off it to fix
problems. It is odd seeing eth12 in the cli and remembering to clean
things, however. :)

Lee

[Rehnquyst]

Hi Doug,

Are /etc/salt/master and /etc/salt/minion the only salt configs I need to backup?

Or do I also need to backup these, from https://code.google.com/p/security-onion/wiki/Salt?

user accounts and sudoers in /opt/onionsalt/pillar/users/init.sls
user ssh keys in /opt/onionsalt/salt/users/keys/
For each user account in /opt/onionsalt/pillar/users/init.sls, you can add an SSH Public Key to /opt/onionsalt/salt/users/keys/USERNAME.id_rsa.pub (replacing USERNAME with the user's actual username)
NIDS rules in /etc/nsm/rules/ (Snort/Suricata/barnyard will automatically restart as necessary)
HIDS rules in /var/ossec/rules/local_rules.xml (OSSEC will automatically restart as necessary)
Bro scripts in /opt/bro/share/bro/policy/

I'm just going to back these up just in case I mess something up, plus it'll help for future regular backups.

On Tuesday, November 4, 2014 6:40:53 PM UTC-5, Doug Burks wrote:

[Doug Burks]

Yep, you'll probably want to backup all of those.

> --
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.