OPNsense Forum
English Forums => General Discussion => Topic started by: MrCCL on July 23, 2016, 05:10:42 pm
-
Today, in the year 2016, I was going to update the BIOS of my SuperMicro motherboard and went to the download section of SM's homepage.
The guide and the attached README file explained how I should do this with a floppy disk...WTF
(http://www.wit.dk/temp/floppy.jpg)
By some extra searching in their knowledge-base I found some words about doing this using a DOS bootable USB key....and a link to an external site with guides and tools. It was obvious SuperMicro didn't believe the vast majority of their customers would go down that path :o
(http://www.wit.dk/temp/dos3.jpg)
Installing OPNsense.....now I run into words like "CD-ROM" and "serial"?...was is that?...Wikileaks was my savior ;D
(http://www.wit.dk/temp/cdrom.jpg)
(http://www.wit.dk/temp/serial.jpg)
Are valuable developer time wasted which could be used for better things?
On top of that, having this serial option around, might give someone excuses for not enabling LAN access initially (telnet/ssh)?
Looking at the installation guide, one could almost get the impression that the USB-Key install path is the least likely method to be used, although I believe it is the opposite.
I believe the vast majority would prefer to just plug-in two things: LAN cable and USB-Key and then be happy ;D
No fooling around with a keyboard, monitor, video-cable and/or serial cable...which probably include USB-COM converter, drivers, and now - how was it with those evil serials, should it be Null Modem and Straight Through ??...I throw out my last one in 1997 and have had a more enjoyable life since...and I cannot remember when one of my laptops had a COM interface. And then not to mention tipping your cola while trying to connect your VGA cable to the back of your monitor....the sufferings just go on and on ;D
Maybe the installation and initial configuration could be optimized for the vast majority in the year of our Lord 2016 :)
Extra note: I started with PFsense....but recently moved to OPNsense, and I just love OPNsense and the community more and more, I'm a huge fan and very grateful for work of the developers!
It just include some pleasure to sit on your ass and grumble about other people's work, when you don't have developer skills yourself, so it's my only way to contribute ;D
-
Not to be too blunt, but you've never worked with network appliances, right?
They all have serial connections because that's what is showing you a console right from the start of a power up.
Routers/firewall with serial connections, same thing.
-
50% of my firewalls do not have a video connector nor any video hardware on the board. That's why most firewall distro come with a flavor for serial connections.
-
Hi all,
Again, welcome, thanks for joining and enjoy the show! This is an interesting discussion, let me give you a brief overview of how/why we got into this "mess" and that we cannot possibly escape it. :D
We started with VGA, SERIAL and CDROM, similar to what our parent project provided. We were aiming for amd64-only with our initial 15.1 as we hoped we could get away with it, but very quickly provided i386 images as well (popular demand doesn't do justice, rather an imposed community requirement), doubling the image and package repository efforts we do. That added 3 images to our initial stash: CDROM, VGA and SERIAL.
All those images are full live systems with an installer, you can use them to try temporary changes in images or system setup by importing the configuration from the disk of the system you're booting, then exit the installer to see how your changes perform with another version. That's highly useful, but adds complexity as well. This is not a good trend... but wait there's more!
Having tackled the 15.1 i386 needs, just one month after 15.1 came out we were hit by the m0n0wall EOL endorsement and people quickly asked for a NanoBSD version to run on SD cards, so we added the NANO flavour in a simplified form (only one active slice). The image is just a disk copy to be pushed to USB, SSD or SD or CF storage. That's 8 images we have now. :)
VGA images are a GPT-boot based variety that just now gained optional UEFI boot support. During 16.7-RC1 we didn't provide these temporarily and people quickly asked why they were missing. In theory they are like SERIAL, but people will ask for VGA when they want it. I guess it's a labelling thing.
SERIAL images are a MBR-boot based variety for embedded hardware (well, anything that doesn't have VGA) and cannot support UEFI boot. Not much to say about this other than that it's an essential image type. There is potential to merge VGA and SERIAL, but up until now it's been too difficult to change that due to challenges in the base OS. Attempts to help pull this off are more than welcome.
In 2016, ISOs are perfect for installing VMs short of having native VM images and just now gained UEFI support. Though we added support for native VM disk images in 16.7, we don't build them by default because they have too many options. This don't even includes default disk sizes, people asking for 10G images instead of 20G... the ISO install from a CDROM image is so much easier for all of this. Cannot get rid of those and provide all of:
qcow: Qemu, KVM (legacy format)
qcow2: Qemu, KVM (not backwards-compatible)
raw: Unformatted (sector by sector)
vhd: VirtualPC, Hyper-V, Xen (dynamic size)
vhdf: Azure, VirtualPC, Hyper-V, Xen (fixed size)
vmdk: VMWare, VirtualBox (dynamic size)
As a sidenote for CDROM, there is a hybrid image that also boots when pushed to USB, essentially emulating a VGA or SERIAL image, but it's not native to FreeBSD as it is rather Linux-y, requires third party tools to be installed in the build system and for UEFI I'm not sure they do work that way anymore easily.
In terms of my daily usage with systems, this is the order of importance:
1. CDROM
2. SERIAL
3. NANO
4. VGA
That's a bit different from the OP perspective but not necessarily true for the average user. :)
Cheers,
Franco
-
Thanks Franco for an interested inside of OPNsence.....everything is always more complex than it looks like at first glance...and I'm even more impressed of the work put into this. :-)
To all the replies...I haven't heard one argument for not starting a telnet or SSH process when FreeBSD boot up! I can only imagine it's for the sake of security, but I don't really see that as a real issue, it's more a theoretical one.
I'm also familiar with the fantastic OpenWRT project....their solution is to disable telnet automatically as soon as the root password is set.....works like a charm and that's non-VGA and non-serial devices!
-
Well, there is nothing secure about telnet. Much like FTP isn't save.
All traffic is unencrypted.
SSH is, but unless you really need it you don't enable it on a firewall.
Unless you have the management port in a separate VLAN. And your client connects to a machine in that VLAN which is then the only machine allowed to connect to that firewall. Or other network components.
At least, in a production environment it's how I would go for it.
Everything you need to do, you can by using the webconfig page. So why do you want SSH enabled by default?
Nice for a server, not an appliance like OPNsense.
-
To all the replies...I haven't heard one argument for not starting a telnet or SSH process when FreeBSD boot up!
It might be a little late then to enter BIOS settings..
-
To all the replies...I haven't heard one argument for not starting a telnet or SSH process when FreeBSD boot up!
It might be a little late then to enter BIOS settings..
Or it does not even get started because of an issue in the boot process
-
@weust: I think anyone in here knows about telnet and what it implies in regards to security.
And no one says anything about keeping your telnet open!
And if you go for something like OPNsense you have a certain level anyway.....don't be overprotective for no good reason.
One of OPNsense main objective is to have all configuration done through your ethernet cable...but they just don't follow this objective to start with?
Again, I hear a lot of talking about all the nice things you can do with serial, and I'm not saying it's useless, but no argument against enabling telnet/SSH to start with. I claim it would make the configuration easier for the vast majority. How many of OPNsense's users don't use serial and would benefit of telnet/SSH...70%, 80% or 95%?
I only have experience with debian, but I have no reason to believe it's not as easy to enable it in FreeBSD!
It seems it's just at matter of changing mindset, no technical reason or because it would imply a lot of work....correct me if I'm wrong.
-
But you can't use telnet/SSH straight from startup (BIOS/UEFI) so it's either Serial or VGA (IPMI).
The telnet/SSH daemon won't be started till right before the login prompt is available. So how will you diagnose problems?
You can't just replace serial/VGA with telnet or SSH.
Same with Ethernet. What will Ethernet do for you if it isn't available until the interface is set with an IP address, and then have to wait for the telnet/SSH daemon to start.
Unless you have IPMI.
You're really mixing two very different things.
-
One of OPNsense main objective is to have all configuration done through your ethernet cable...but they just don't follow this objective to start with?
I'm not entirely sure how this would fail, except for hardware reasons related to booting FreeBSD. :)
If FreeBSD runs on the hardware OPNsense will boot up and either:
(a) auto-configure for LAN on the only adapter it finds so that you can get a DHCP lease for your laptop that you plug in from that port and configure from there.
(b) auto-configure for LAN on the first adapter it finds, WAN on the second. LAN will offer DHCP leases as described in (a) here too.
The trouble is probably with the installer which auto-boots early so you require a working screen and keyboard of some sort, either through VGA/keyboard or serial.
I remember using untangle once, which booted a full linux X server environment and openend the installation wizard in a browser and I thought that's nice, but why go through all the trouble? This still requires a VGA/keyboard and even mouse and doesn't work on a serial. ;)
So, how should the installer behaviour on install media be improved? We can boot up on install media, make the default to not start the installer early, but after the system is up and running? Would that change anything?
It sounds like something that can be done and there is no excuse for the current behaviour except it's always been done the that way.
The question is whether this really improves things, or that we still have to make a GUI-based installer using valuable human resources, which will take a lot of time to fix something I don't know being broken or just overly technical, or let's say "domain-specific".
Cheers,
Franco
-
PS: As funny as it is, I just remembered the installer works via SSH, so maybe the location of the (default) installer invoke is really wrong and ought to be changed for 17.1.
-
@weust: yes, I'm aware you'll not be able to edit the bios with telnet/SSH.
But we're talking about what's beneficial for the vast majority. Yes....there will in rare occasion be need for a low-lever access like serial/VGA...I agree.
But that doesn't have to be "supported" by OPNSense, does it?
Maybe we can cut down the amount of images and make life easier for Franco & co. :-)
@franco
Maybe I get it wrong. But when I boot from installation media e.g. USB flash drive, bootstrap is loaded (I don't know what it is, perhaps a boot-manager). But the important thing is "1: Boot Multi User" will automatically start after a few seconds, i.e. no need for keyboard, VGA or serial here....it will just continue.
(Do any ever need that boot menu?)
Now FreeBSD is booting/loading. And why not load the NIC driver (maybe it already is) and the telnet service/process, pick the first NIC it finds and set IP to 192.168.1.1. I would prefer myself a static IP...isn't the at standard way....that's actually also the current setup now after installation ends I believe.
After FreeBSD is finish loading, play a sound as a signal, and you can now logon using telnet.
I guess you have to start the installation program manually typing a command. Maybe a message on screen saying "Type START to install OPNsense 16.7"
I don't now if the current installation "program" is telnet-console-compatible?
If not I can see that's a challenge if the install "program" has to be rewritten to be that :-(
But maybe it just work out-of-the-box? :-)
-
Oh....I see you once again are ahead of things....good to hear the installer works from a remote console :-)
-
MrCCL support for serial and vga is essential and they aren't going anywhere any time soon. I use serial in particular so I don't have to connect a monitor, keyboard or mouse to my firewall appliance. Yes telnet and SSH can reach the command prompt and be beneficial, but I don't enable services that have a history of being exploited unless I have to,
-
I think we can find a way to make this feasible... https://github.com/opnsense/core/issues/1072
-
You can install Mac OS X server via VNC resp. Apple Remote Desktop. This is verrrrry nice to have and handy and I love it. The login is the serial number of that machine, the hostname (to be found eg. via DHCP server ) has the MAC of the first NIC.
I guess it could be kinda easy to get a vnc server running and also use root/MAC-address as login? ^^
-
Doesn't VNC require X?
-
The first batch went in as https://github.com/opnsense/core/commit/710f00e84
It's missing a default SSH setup in installation mode as the second batch, then the new user "installer" can be reached via root's password.
I'm pondering security implications for automagically starting the SSH daemon with permissive rights. At least the system cannot be compromised forcing entry without a proper root password, but if e.g. the root password is still the default this can cause problems. Then again the same applies for the GUI in every case.
Any thoughts?
-
Pretty picture: https://twitter.com/fitchitis/status/762702508024291329
-
Wau!!!!!
Altough I don't have the technical insight to get the meaning of the "missing SSH setup in installation mode......"
I hope not the security concerns will be an issues for not having this feature...not that I see any myself.
IMO this will really be a deal-breaker compared to PFsense! (Well, one more the list :-))
-
Well yes, there are security things involved. If you set up a device like this (with a default known root password), you have to ensure that no one else can touch your ethernet.. ^^
A second way might be to change the root password in ssh-mode to e.g. the MAC-address of the first ethernet interface (either xx:xx:.. or xx-xx-..). Apple uses the serial number of the machines, but well, standard hardware doesn't have this or in a different way (like HP or Dell). So, common feature is the MAC, which is often on a sticker on the machines anyway.
-
Then set web-gui password to the MAC address also....and if not?....then don't set it to to the SSH either of the same reasons.
Why is SSH more insecure than the web-interface....I would say it's the other way around, if any difference.
-
Hmm, yes, a better root password mechanism needs to be implemented, but if we talk "headless" how can you see the displayed password / peek at the MAC address? Handling appliances with stickers is pretty easy. Software-only distributions get trickier. We could easily set it during install, the wizard asks for it to be changed on first boot. But what happens before that initial system touch?
I agree that SSH is the same danger level as the GUI, one or two channels doesn't make a difference. Especially with PermitRootLogin, which is needed for the installer to run in the first place... Then again it's only on install media when it'll be run.
The GUI login is protected by firewall rules from !LAN, the same applies to SSH.
All the code is in now, pending more testing over the next weeks. If this doesn't work out no harm ripping out the bits again. ;)
-
For those who might be in a insecure LAN environment, e.g. an educational institution or other public installations, they can still make the initial setup using VGA, serial or a private network. No one are forced to install OPNsense connected to an insecure LAN.
They just need to know!
Perhaps a warning could be placed at the download page "Be aware SSH is enabled in the initial installation process using default root password".
And the install process could ask the user to disable SSH as one of the last setup options/questions.
Maybe this would be an acceptable compromise?
-
It's a live system that is supposed to boot up with all the features, enable SSH on the side so it can be reached via SSH for installation. I don't see how a question could be asked whether or not SSH should be enabled if the only way to reach the system is remotely via SSH itself or the GUI without further complicating it with "for optional insecure SSH access log into mandatory insecure GUI and enable SSH". People just want to install...
-
I agree.
I'm not talking about having SSH is enabled when the installation starts, that's implicit ;-)
But after.....if anyone find that to be a problem. Then it could be a way of making sure no one have SSH enable by default without knowing it in the "normal stage ", so to speak.
But I don't see it to be problem myself at all...but I only got criticism in the threat for suggesting default SSH, that's why, just thinking of a way to make those critical voices more happy :-)
But I'm sure you have much more important things to do than implementing this SSH asking...but if people gets crazy about it, it could be a half-way-solution.
-
Well, if you deploy machines in a big network, security matters for sure. So my suggestion is, that the installer takes care of user interaction right after start. Like a timer that waits for a keyboard pressed (case 1: user has a screen, we take "opnsense" as default root password) and a (decent) timeout and further enabling ssh (case 2: no direct user interaction, we take a MAC as root password). This won't force to change much documentation and won't stress "normal" users but takes care of bigger networks and their specific needs. That's more or less the opposite way it works on many headless systems with a bootloader waiting for a (e.g. serial) interaction to do fancy things like firmware recovery and, if there is no interaction, continues to boot the default headless system with no direct user interaction. Which makes sense, because those devices are headless by default and opnsense is not. So reversing this behavior might be a good idea.
-
In short, you want to implement a timeout, so users connected by VGA or serial can skip the SSH enabling?
You are right, that would make a more secure setup process.
But this timeout feature come with a price: extra coding and hassle for the users who don't wanna bother with monitor, keyboard, serial etc.
Is it worth it? And is this really a real problem?
You're not force to connect it to you insecure LAN until the config is over....for those who are stressed about it.
You're in most cases sitting in front of it anyway, if using VGA or serial.
-
The timeout already exists, it was used for interface configuration (auto vs. manual), defaulting to auto if no keypress was found. I've heard zero feedback for this rework that we did, it seems to work for everybody... It also makes sure boxes always boot back up into the full system even then the configs cannot be restored.
Now we do the same for the early (install media) boot invoke. Olivier noted a while back that booting into the installer by default is not the best thing to do, so that made sense to finally realign. Now everything is stowed away behind a login prompt of some sort: console, SSH, GUI.
On an install boot, the following now happens:
1. The boot timeouts for launching the installer on keypress, if no event took place it continues with the normal system boot.
2. The boot timeouts for manual interface configuration, otherwise auto-generates a valid interface configuration with a WAN/LAN and continues to boot.
3. Once the system is fully booted (note that this happens without any interaction now), the GUI can be accessed as well as SSH.
I don't see any user-facing issue during testing this. We even managed to lose a bit of old unused and duplicated code in the process. :)
Cheers,
Franco
-
On the SSH auth on LAN for installer. Maybe there is a way to dispatch a unique ssh key or pass rather than using a static password. not sure how though. I'll ponder.
BUT I LOVE IT!!! Great idea Y'all.
-
Since someone asked for a test ISO for a different feature, here is one that incorporates the SSH installer ideas that were affectionately crafted by this very thread:
https://pkg.opnsense.org/snapshots/OPNsense-17.1.a-LibreSSL-cdrom-amd64.iso.bz2
;)
-
thank you
-
Well, there is nothing secure about telnet.
Much like FTP isn't save. All traffic is unencrypted. SSH is, but unless you really need it you don't enable it on a firewall. Unless you have the management port in a separate VLAN.
ทีเด็ดบอลเต็ง (https://telsysitalia.com/เทคนิคแทงบอลเต็ง)
And your client connects to a machine in that VLAN which is then the only machine allowed to connect to that firewall. Or other network components. At least, in a production environment it's how I would go for it. Everything you need to do, you can by using the webconfig page.
So why do you want SSH enabled by default? Nice for a server, not an appliance like OPNsense.
-
Talk about immortal ghosts from the past, replying in a topic to which the last comment was made 4 years ago ;-)
SSH is not enabled by default (anymore).