I am maintaining a Virtual Machine on a Cloud Service with Linux (SLES) operating system. At some point, someone logged in, did some major things (e.g. chmod 777 on ALL files, etc) and, with some other things that he did, messed up the system.
It would be no surprise if he actually hacked it, but...
The vm is hosted inside a VPN (unreachable from outside the VPN), and last root command specifies a user connected through tty1 (!!!), with no IP address, while all my connections, root and user are pts/X.
My thoughts (not like I am an expert) are concluding on one thing, this user must have physical (?) access to cloud service, since tty is reachable locally.
Which means, that if that is true, the "attacker" must be someone from inside the Cloud-Service hosting company.
Question:
Is there ANY way you can connect remotely to a server/cloud service virtual machine using ttyX?
Correct me at any point you see wrong; as I mentioned I am not an expert but I am more than willing to learn.
Depending on the hypevisor, it provides a remote console, so, it is kind of local console connected from a remote place. Also, there is a ipmi protocol that can connected to the hypervisor and use the sol (serial-over-lan) command.
Other than that, the user might be connecting using a VNC, that would also be shown as a tty connection
IPMI SOL: http://www.alleft.com/sysadmin/ipmi-sol-inexpensive-remote-console/
Remote qemu guest console: How to switch to qemu monitor console when running with "-curses"
VNC on guests: https://askubuntu.com/questions/262700/qemu-kvm-vnc-support
Related
I want to connect to a locked (cannot be modified and I do not have permissions to log into) windows vm which is hosted in a linux machine. Until now these two machines were communicating via port 2277. However for security reasons, the port 2277 is only accessible via localhost (127.0.0.1).
The original proposed solution was to use ssh-tunneling. However since the hosted windows vm will always stay with the linux machine, so I was thinking something simpler.
This Windows virtual machine has ip 192.168.0.1 and the default gateway is 192.168.0.2. The later is the ip address that my linux machine can see.
After searching the internet I tried
socat TCP4:192.168.0.1:2277,reuseaddr,fork TCP4:127.0.0.1:2277
as well as some other random combinations without success.
My understanding is that this failed because for socat to work both sockets must be open.
However the first one is not open by default (checked with ss -ltn) as I need to run the windows service first (which it cannot run as it cannot communicate with iphost:2277)
Any ideas on how to proceed?
Socat provides the retry=N and forever options to handle situations like this. Thus, try something like this:
socat -d -d TCP4:192.168.0.1:2277,reuseaddr,fork,forever TCP4:127.0.0.1:2277
With the interval=<seconds> option you can specify how long Socat waits after each failed attempt.
It turns out that the command that I wanted was the following
socat tcp-listen:2277,bind=192.168.0.1,fork,reuseaddr tcp:127.0.0.1:2277
The retry=N and forever options could be also useful.
I want to install Damn Vulnerable Web Application (DVWA) on VirtualBox, so I downloaded the DVWA.iso and I'm following this tutorial for its installation.
At step 9, they say to choose internal network, but I don't really understand why (is it a security problem if I don't choose this option?). Because if I select internal network after I've got an IP like 10.0.something and when I try to connect from my computer (not the VM) to 10.0.something/login.php that doesn't work. But if I select bridge networking, I've got an IP like 192.168.something and it works.
Could you explain me why is it important to choose internal network, and why that doesn't work when I choose this?
Internal network on VirtualBox creates a network between boxes on the same host . I can't see the next steps of the tutorial you linked but my guess is that it will ask you to install Kali (or similar distro) on another box on that same host. This is what most people do.
Setting 'internal network' allows the 2 machines to talk to each other without any contact with the outside.
It is considered a security measure because the DVWA is a vulnerable machine so some people think that you shouldn't be giving access to internet to it, but I guess it's more about 'best practice' than a real security risk because in most cases firewalls, routers and ISP will prevent outside attackers to connect directly to that machine in any case.
Anyways, if you are using another computer on the same network to connect to DVWA you should be ok in using a 'bridged' connection on VirtualBox (this it will give to the DVWA an IP sitting on the same network of the host and of your computer). In NAT mode VirtualBox acts like a router, it may still be a good solution for you but not sure if the box is reachable from other computers as I think VB settings may affect this case.
If you are using instead the Host as a penetration testing machine, 'host only' should be good to allow the host and the VM to talk.
Try to put both of the machines on the NAT so that you can ping onto the dvwa from wherever you're doing the hacking from! so essentially both of the machines should be on NAT setting if the they're both on a virtual machine.
---+ BRIEF: What is the most secure way to run a GUI app in a VirtualBox guest from the host?
VBoxManage guestcontrol --username U run ...
for an account that has no password
which may require gpedit to allow
VBoxManage guestcontrol --username U --password P run ...
VBoxManage guestcontrol --username U --passwordfile PF run ...
or ssh (what network mode: NAT, ...)
---+ DETAIL
I have just started using VirtualBox, after past experience with VMWare, Parallels, Xen - heck, I worked on VMX aka VT before it was released. Overall, I am familiar with virtualization, but not so much with the incantations necessary to configure the software.
Host: MacOS Sierra
Guest: Windows 10 Pro (Microsoft's appliance, WinDev1612Sys)
I want to use this virtual machine for two purposes: (1) to run an old Windows GUI app (FrameMaker). (2) to run Windows Outlook, when Outlook for MacOS isn't good enough. Also (3), some Windows app development / portability testing.
Not only do I want to run the Windows GUI app (FrameMaker) interactively, but I also want to script it. I do that using FrameMaker's built-in ExtendScript, invoked from MacOS via VBoxManage guestcontrol run ...
(In case anyone cares, I switched from Parallels because I could not get prlctl to pass command line arguments, not even to specify a .BAT script for command.exe to run; and the old trick of editing the .app bundles created by Parallels Tools no longer worked - any attempt to edit the bundle contents, e.g. AppParam.pva, resulted in the bundle being deleted. Probably a security policy. I wasted far too much time trying to get Parallels to run parameterized automation scripts; whereas Virtual guestcontrol ran as soon as I tried it. Makes up for VirtualBox's seamless not being as nice as Parallels coherent mode.)
OK, so now I have something working. I can run scripts on MacOS that invoke GUI apps, and other scripts on the Windows guest. Great!
But...
---++ ps can see command line options like --password and --passwordfile
VBoxManage guestcontrol --username U --password P run ... is scary because the command line options are visible to any user running ps alxwww on MacOS. Any such user can see the password.
Similarly for VBoxManage guestcontrol --username U --passwordfile PF run ... Any such user can see the --passwordfile option - and, as far as I can tell, any such user can execute the same command. I.e. it is as good/bad as seeing the --password. (If guestcontrol run were somehow restricted to only allow such access if the host and guest usernames were the same, it might be more secure - but AFAICT, that is not supported.)
---++ passwordless guest account is scary
Nothing is visible to ps if the guest account has no password - but that scares me. Again, it appears that any host user, including anyone who is not me, can access the passwordless guest account. (Again, guestcontrol restrictions that host and guest user names match for passwordless operation might be more secure - but, still, not having a password is scary. Imagine if I configured bridged networking and my Mac was not behind a NAT (but then I am probably screwed anyway).
---++ Don't allow other users on my Mac
Now, I don't normally allow users other than me to use my Mac. But... I might, if I naively trusted OS user process security, and I forgot about an old installation of VirtualBox. The problem is that VirtualBox guestcontrol has a security perimeter than expands to include all host user IDs
---++ Lock VirtualBox down so that only I can use it
Possibly I could change file permissions so that only I can run VirtualBox installation tools. Also device special files, if VirtualBox installs Mac drivers. But furthermore... I happen to know that if VirtualBox is using Intel VMX / VT hardware virtualization hardware, it might be trapping things that MacOS filesystem permissions do not control.
(BTW, this is the security exposure that one gets from requiring the hypervisor run inside the kernel, from not permitting user level hypervisors. Layered VMs, guys!!!! (We'll only get there after another generation of virtual machine security break-ins.))
But I don't yet know VirtualBox well enough to do this. And a quick look seems to show no indication that VirtualBox was designed to make this easy. (Please tell me otherwise.)
---+ Passwords, not on the command line
If we have to pass a password to the guest, it would be best if it were not on the command line.
I seem to recall that ssh at one time had a --password command line option. Obviously insecure. Modern ssh does not seem to have such an option. Possibly my memory is wrong. But certainly there are folks who want to put the password on the command line, e.g, the sshpass package in Ubuntu (sshpass -p 'YourPassword' ssh - user#host https://unix.stackexchange.com/questions/38737/ssh-login-with-clear-text-password-as-a-parameter)
ssh avoids the need to have the password on the command line by prompting for the password - not visible from ps. Or by having public / private keyfiles (but that is only as good as the filesystem permissions (especially if public and private keys are not separated). Or by using ssh-agent.
I would feel better about VBoxManage guestcontrol if it used something like this.
Heck, I would feel better about guestcontrol --passwordfile if passwordfile were on the host filesystem, not the guest. Not good to have a password in a file, but better than on the command line, and equivalent to keyfiles if kept together and not separated. I am reasonably certain that I can make a file readable by me only in MacOS. ;-}
Hmm... I wonder if there's a mistake in the VBoxManage guestcontrol manpage - if --passwordfile is a host file, rather than a guest file? That would make more sense, and would explain why I have not been able to get --passwordfile guestfile to work.
That's my best hope.
---+ VirtualBox API
If VBoxManage guestcontrol can only pass passwords in a form visible from the command line, perhaps I could write my own script?
Surely somebody has alreadsy done this, if necessary. (I hope it is not necessary.)
---+ Why not ssh between guest and host?
All else failing, I could run an ssh server in the guest, and ssh in. ssh, after all, does a fairly good job of hiding passwords and other authentication tokens from ps, etc,
(I would prefer to use VBoxManage guestcontrol. Less to set up, less to misconfigure. But ssh is pretty standard.)
If I wanted to run ssh, how should VirtualBox's network be configured?
Host-only might be most secure - but that would not allow me to use Outlook in the guest without more crap.
I like running the guest behind VirtualBox NAT (and furthermore the Mac is probably also behind one or more layers of NAT, at home and work).
But if the guest is behind VirtualBox NAT, then ssh from host to guest would be blocked. So I would have to port forward. But I probably do not want to forward requests from the outside world, only from the local host.
It looks like
VBoxManage modifyvm ...
[--natpf<1-N> [<rulename>],
tcp|udp,
[<hostip>],<hostport>,
[<guestip>],<guestport>]
might do the trick.
The manpage example says
VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,127.0.0.1,2222,,22"
to forward all TCP traffic from localhost 2222 to the guest on port 22.
Does this seem right?
Testing shows that this works - but testing does not show the absence of a security problem.
Really what I want is a combination of hostonly for traffic coming in to guest originating from host, and NAT for outgoing.
(Hmm... on other VMs like Parallels, the problem was that ssh workedm but ssh could not start a GUI app. Haven't tested that on VirtualBox yet.)
---+ CONCLUSION
So, what's the best way?
I would hope that somebody has already figured this out.
I can set up NAT and ssh, assuming that GUI apps work.
But I would prefer it if guestcontrol was secure. Even if just a doc bug, with --passwordfile being a host file rather than a guest file.
Or perhaps I should not worry about hiding stuff from ps. Many folks seem not to care. But I care.
I am working on trying to get some linux Clearcase clients to work with our existing Windows infrastructure. All of the vobs and servers are stored on Windows machines.
Using an existing vob, I was able to create a tag in the linux region to refer to the vob, and then create a view on the linux client. This client was able to connect to the vob and pull the files in when I updated the config spec. However, while it can view files, it does not have permission to edit them.
The usernames match
linux: user1
windows: DOMAIN\user1
The Clearcase admin panel is set to "Use this domain to map UNIX user and group names" with DOMAIN selected.
However, the authentication does not appear to be working. From the unix client, if I run
credmap windowsServer
I get Nobody/Nobody for the remote username and group ID. If I run from the Windows server
credmap linuxClient
It times out and I get
credmap: Error: Unable to contact albd_server on host
Investigating further albd_list on unix shows that the albd server is running, and even finds the albd_server on the windows machine.
albd_server addr = 166.20.20.81, port= 371
albd_list 166.20.17.118
albd_server addr = 166.20.17.118, port= 371
Going in the opposite direction returns
albd_list 166.20.20.81
noname: Error: Unable to contact albd_server on host '166.20.20.81'
cannot contact albd
Ping works from the windows host to the linux host, and I am even connected to the linux host by SSH from the parent at the moment.
If anyone has any ideas on what to look for next, you'd be my hero :(
You get limited ClearCase functionality when you access a ClearCase server (running on Windows) from a Linux client. To learn more, read about CCFS.
I'd suggest you to consider migrating your VOB server to Linux. This way you get all ClearCase functionality, including dynamic views.
I confirm having Vob server on windows mean they won't be fully accessible from linux client, even though the official documentation from IBM describes the CCFS setting to follow.
(See "Configure UNIX or Linux clients to access Windows VOBs", which you must have seen)
In particular, I never managed to have a credential mapping fully working from Linux to windows (the other way works well).
And you need to make sure your view storage is accessible from Linux (see "Creating a view on a NAS device")
That leaves you with inter-environment solutions, like:
CCRC (ClearCase Remote Client, for CC7.x)
ClearTeam (for CC 8.x)
See "Feature Comparison Matrix for CCRC, CTE, CCWeb, Native ClearCase GUI and SCM Adapter".
This wound up being something stupid. There was a firewall running on the linux machine blocking the albd_server port.
This also did not resolve the credential mapping issues, but it at least let me eliminate one more potential cause. Thanks
Scenario:
Many embedded devices (running Linux) out in the fields, behind routers so NAT'd and we can't make connections to them.
We need for a support person to be able to initiate a terminal/shell session on any of the devices.
Their local terminal will also be NAT'd behind a corporate firewall, so we need some central "meeting point" that both they and the device can connect to.
If necessary, we could require the support person to log into some sort of terminal server, but I'd prefer a solution that just popped up a terminal window on their desktop.
We can (through other means) tell the device to execute some arbitary script or application to start up the session.
Without the NAT, it's just SSH to the device and away we go. But what are my options in this NAT'd environment?
We're OK to develop code at either end or at the meeting point server if required, but obviously if there are apps out there so we don't have to write stuff, even better.
Pointers to other questions I may have missed (although I have looked) or to applications that I should consider for the central "meeting point" server welcomed
How about simply setting up an ssh server that is reachable by both the device and the support user, and have the device set up a reverse tunnel (using remote port forwarding)?
ssh -R 10022:localhost:22 device#server
Then the support personnel can simply connect to the server and log on using
ssh -p 10022 localhost
Of course there are several security aspects that need to be accounted for here, depending on what kind of information the devices hold/have access to and how the support organization is set up.
SSH is an adequate tool for this. You will, as you say, need a middle-man server. But it would be very easy to set up, assuming that your 'other means of executing a script' are remote and can be executed from your office.
So, fire up a new server on a global IP (an Amazon AWS micro node is free for a year and would do the job just fine), and install an ssh deamon. Say it has the hostname middleman.example.org.
The script to put onto your embedded devices would look like;
#!/bin/bash
ssh -i ./middle_id.pem -R 22:localhost:2222 middleuser#middle.example.org
(The private key authentication would be a way of making the login non-interactive)
The script to put onto your desktop machines would look like; (assuming the argument $1 is the IP of the embedded device, and that prod_remote_device.sh executes the above script on the chosen embedded device.)
#!/bin/bash
./prod_remote_device.sh $1
ssh -i ./device_id.pem deviceuser#middle.example.org:2222
And that should forward your connection to the embedded device.
In order to make it bind to all interfaces, use:
ssh -N -R 0.0.0.0:2222:localhost:22 root#example.com
Don't forget to edit /etc/ssh/sshd_config and go to GatewayPorts and enable it and set it to yes.
And Then connect to it from any Loopback or Ethernet interface.