[BlueOnyx:26535] Re: Network settings changing.

[Fungal Style]

Hi Chris,

Thank you for the insights, I too have been lurking for a long time too, having been indoctrinated from one of the first versions when it was BQ.

I also understand the comments about users, but this is locked down to myself and one other person, we tend not to trust end users that much and most just want us to make sure it works... so a good relationship that way.

The change was not deliberate, but I will be checking the network config files just in case there is something weird there.

I am using VMWare ESXI as the hypervisor and have done so for quite some may years without issue, although it was only over the last year or two I had a DHCP server on the network which is part of a firewall I use to use NAT for some Windows Servers I use for some maintenance and commercial backup reasons. But I believe I have the open source toolkit (as VMWare's native one does not work with later Linux releases they even refer you to the open source one). So this is actually a good point and something to keep an eye on in case it is "trying to be helpful", I did not think of that.

The vlans is a work in progress so yes, it is ideal to have it separate but sometimes necessity does not understand time constraints...  so I know it is not the best to have them on the same vlan.

Agreed that it is good to know the root cause before jumping and going to the effort of moving things around (I am planning a migrate to 5211R at some point too, but I think the tools and checking the network config files would be a good place to start, I got distracted as the disabling of the DHCP server took out a NAS as I do not want a NAS on a routable IP address, but it bit me in the butt as I ended up locking myself out of the ESXI (long story, just ment I had to take a quick trip to get a crash cart connected and fix the cause which I put off for a long time and was not a problem till I killed the DHCP... go figure.. snow ball effect.

So as to your summary...

1. yes, that has shuffled up the to do list now (yes I always knew it was a bad idea, just did not think it would be this way though, I was more concerned about traffic and congestion but it was working so it was easier to ignore)
2. n/a, it was me, it was initially a quick fix to get something done, but became too easy to keep and put off point 1. 
3. n/a only 2 people and one is my brother and he has a vested interest as he will have people yelling at him.. __
4. n/a in this circumstance as the server is fairly locked down already, hence I managed to lock myself out as I did not have a way around and I am looking to get a KVM o IP also for the servers which would have saved the trip to the data centre.

Even though most things are already ticked off or not applicable, you still spurred some lines of though as an example, I did not think about the vm tools as a possible cause and I thank you for the time and effort in posting also, as well as Michael also who replied earlier.

If anything I need to take this as a learning experience and work to fixing the things that need to be fixed on the to-do list and check the other things.

Thanks again.
Regards
Brian



On 6/10/2023, 11:11 pm, "Blueonyx on behalf of Chris Gebhardt - VIRTBIZ Internet via Blueonyx" <blueonyx-bounces at mail.blueonyx.it <mailto:blueonyx-bounces at mail.blueonyx.it> on behalf of blueonyx at mail.blueonyx.it <mailto:blueonyx at mail.blueonyx.it>> wrote:




On 10/5/23 8:54 PM, Michael Stauber via Blueonyx wrote:
>
> I can't imagine a way how the network settings would switch to DHCP on 
> their own. So I'm as confused as you are why this has happened in your 
> case.


We've set up and operated hundreds of BlueOnyx servers of every version 
since its inception, with BlueQuartz and Cobalts before that. (We won't 
get into the couple of dalliances with the likes of TurboLinux) and have 
NEVER seen this happen. Not in a quarter-century of use, and even in 
some "alternative" configurations.


I would suggest that this type of change would be deliberate. Is this 
system perhaps assigned to a dedicated user who may have made this 
change by mistake / not knowing any better? We've certainly seen end 
users get things mangled.


You mention it's a virtual machine, so I'm also curious which hypervisor 
you're using and would its toolkit have tried to "help" you out by 
making the change. (We've never seen that happen with VMware products 
or Aventurin{e} or ProxMox.)


Also... why is it picking up DHCP in the first place? Why is there a 
DHCP server on your public network? I would absolutely recommend 
locking that down and placing your resources into proper pools / 
VLANs. There should not be a chain of events that would have a DHCP 
server suddenly appear on a production hosting network.


There may be a way to use RPM/YUM to re-install the networking 
components from stock. I'd defer to Michael on that one. Or you may 
want to consider spinning up a replacement and using EasyMigrate to hop 
over. If it was me in your shoes, though, I would hesitate to do that 
without fully understanding the chain of events that caused the issue in 
the first place. After all, if it happened once, it's certainly 
reasonable to expect it could happen again.


My suggested steps in any case would be:


1. Fix the network. Your public hosting needs to be completely 
segregated from other traffic. DHCP doesn't belong there.


2. Evaluate the security policy that allowed DHCP on your hosting 
network in the first place and install safeguards as necessary.


3. Evaluate the users on the system that went haywire. If there are 
admin/root permissions in another user's hands, could they have made 
this change, even if completely by accident or without understanding 
their actions? Have you dumped / reviewed the bash history? Not 
foolproof but helpful in some cases... Lock out / lock down any users 
who have root/admin but don't NEED it.


4. Once above conditions are satisfied (at least, as best as possible) 
evaluate if system is trustworthy/stable. If so, continued operations 
on the server may be fine, especially if you are able to locate & 
address the root cause(s). If not, consider replacing the server, 
limit access and in any event monitor closely (set alerts for logins, etc).


HTH,


-- 
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated
www.virtbiz.com | toll-free (866) 4 VIRTBIZ


_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it <mailto:Blueonyx at mail.blueonyx.it>
http://mail.blueonyx.it/mailman/listinfo/blueonyx <http://mail.blueonyx.it/mailman/listinfo/blueonyx>