Posts Tagged ‘storm’

psych0tik IRC downtime and updates

Monday, June 14th, 2010

As you may have noticed, the pyshc0tik IRC’s primary domain name no longer points to the correct IP address. On May 29th a reboot of Samurai’s router caused a new dynamic IP to be assigned and resulted in the old DNS zone to going stale. We’ve had some issues with getting our DNS entries updated and are working to find a more stable solution, but in the meantime you should still be able to access the IRC via the temporary backup domain: rogue.samurainet.info. The IRC is still on port 6697 and requires SSL.

In addition to our DNS issues, you may also have noticed subtle changes in the blog’s organization. We’ve restructured the menu, removing all the old SamuraiNet Archive sub-categories, to make room for psych0tik categories. Some of the psych0tik posts have moved to newly created categories and all posts have been re-tagged to be more searchable. Samurai has also been kind enough to go through and update a few of his posts in the archive, either correcting known issues or noting dead projects. We’re hoping that these changes to the blog will make it easier to find what you’re looking for.

One of the changes we haven’t been able to implement on the blog is getting a custom psych0tik theme. While we will eventually get to this item, it’s definitely not a high priority on our to-do lists. If you’d like to donate some effort and create a psych0tik theme for WordPress, leave a comment below with your email address and we’ll get in touch with you. For your effort’s we’ll offer you a link on our “prestigious” affiliates category.

The proxyElite project is undergoing some final alpha testing (and a few last minute additions/tweaks) before we release it for public beta. We’ve revived the functionality of the previous version of this project and added some new features and techniques. Keep an eye on the blog for the release post in the next few weeks.

Finally, we still don’t have a WWW set up yet. We’ve hit a few small snafus and have been too busy to sort out what should be simple issues, until recently. We’re back on a roll and will hopefully have our main site up soon.

~psych0tik staff

ESXi 4.0 – Management Methods

Sunday, March 21st, 2010

Introduction

Be it at work or at home, I spend a lot of time in virtual environments consisting mostly of ESXi. As part of the psych0tic network I run storm.psych0tik.net, an ESXi 4.0 box that’s currently running our IRC as well as the psych0tik GSProxy. Managing these environments is a task in itself, and I’ve found that no one tool gives me all of the functionality that I need. Additionally, I’ve found some confusion in what’s what as many of VMWare’s product’s have two names, due to a re-branding from Virtual Infrastructure 4 to vSphere. In this post, I’ll go through the various free management method’s that I’ve come across and use. I’ve also provided a short list of the non-free options. Listing all the features of each method would probably require a blog post or two per item, so I’ll go over some common uses as well as anything I think to be extra useful.

Embedded Web Server

The embedded web server provides a home page populated with links to various resources related to your ESXi 4.0 installation, the ability to browse your server’s datastores, and the ability to browse objects managed by the server. Accessing this service is simple and requires no setup. ESXi 4.0 installs with the VMWare ESX Server httpd and connecting requires nothing more than putting your server’s IP address into your browser (preceded by https://). The connection is protected by SSL (you may have to allow a self-signed certificate) and both the datastore and the objects are protected by basic HTTP authentication, using the same access controls as vSphere or the unsupported console.

vSphere Client (originally branded as the Virtual Infrastructure Client or VIC)

The VMWare vSphere Client provides the ability to monitor and manage multiple physical ESXi servers from the same console. This application runs on a separate machine, under Windows, and connects the the ESXi 4.0 host via the management network. Using the VI API, this tool connects to the hypervisor(s) on ports 443 and 903 and lets you manage the entire infrastructure from the hosts and switches to the server configuration.

For most of my day-to-day management the vSphere client is enough. You are able to start and stop virtual machines, take snapshots,  adjust resources, get performance graphs, spawn consoles on the various virtual machines, and adjust settings for the networking, guests, and host. In addition to the direct management of the guests, vSphere also provides an interface for working with your datastore(s) and allows you to upload/download files from the physical server as well as functionality for importing virtual machines.

Another advantage of the vSphere client is that it’s a standard VMWare product and therefore other products may be built with that in mind. Products like Cisco’s Nexus 1000v (not free), a replacement for ESXi’s native networking, integrates nicely with vSphere.

Maintenance Console/SSH

Sometimes I need to go beyond the high-level management of my servers. For example, sometimes I need to clone a virtual machine and, as far as I know, there isn’t a way to do this through the vSphere client . Tasks like this are better suited to the maintenance console, an unsupported command line interface for ESXi 4.0. As I mentioned, this method isn’t supported by VMWare and may void any sort of support you get. (I have a free license, I don’t expect support anyways.) The maintenance console is similar to the Service Console in ESX 3.5, but with reduced functionality. Using busybox, it’s possible to open this management method up to remote users as well as to allow SCP. (In my experience, vSphere’s upload/download is less stable than SCP.)

In the maintenance console, you’ll find access to the datastore as well as the raw virtual machine files. In addition to basic functionality, various VMWare specific tools have been added for manipulating guests or the hypervisor itself. vmkfstools, for instance, allows you to clone guess.

Also accessible through the maintenance console is the vSphere Interactive Shell (vsish) , another undocumented shell. From the bits of information I’ve found and some mucking around with vsish, it seems to be a mixture of an integration of the service console’s /proc nodes and linux’s mcelog, for polling reliability information. One interesting command I did find was to crash the ESXi VMM with a kernel panic: vsish -e set /reliability/crashMe/Panic

The Virtual Infrastructure metashell (vimsh) is yet another unsupported and undocumented shell accessible via the console or SSH. From what I can tell, after ESXi 3.5, this is only accessible through the non-interactive vim-cmd.

libvirt

libvirt isn’t solely meant for managing VMWare’s ESXi 4.0, rather it’s meant to be a toolkit to interact with various hypvervisors and their features. Because libvirt isn’t designed specifically for ESXi 4.0, there are functions of the API that it does not implement, such as managing vSwitches; however, it does provide a common programmable interface for managing in multiple languages. libvirt natively supports C/C++ and python and has bindings for Perl, Ruby, Java, C#, and OCaml. Beyond the limitations libvirt has in it’s ESX drivers, the free version of ESXi 4.0 restricts your access to read-only, disabling more of the functionality provided through libvirt.

virsh

virsh is the virtual shell that comes with libvirt as a method for managing domains under various hypervisors. Since virsh is built on libvirt, it also is unable to manage ESXi’s vSwitches and is restricted by the read-only nature of ESXi 4.0′s free version.

Among the usable features the virsh provides are the ability to list currently active domains, view information about the host’s and guests’ hardware and capabilities and view configurations. Unfortunately, from my testing it seems that a good majority of the more useful features virsh provides, like the ability to connect to a serial console, aren’t easily available (if at all) under the free version of ESXi 4.0.

NON-FREE

The management methods listed below are not free and therefore I have not been able to test them. Any functionality I’ve listed is based on what I’ve read. In most cases, you’ll be able to find a more in-depth description (read – “sales pitch”) in one of the references at the bottom of this post.

The vSphere Remote Command Line Interface (RCLI) provides the functionality that was previously available in the Service Console, specifically the esxcfg-* commands. The RCLI also allows the administrator to script various tasks. The esxcfg-* commands the RCLI relies on are still available via the unsupported maintenance console.

Functionality in libvirt and virsh seems to be increased through the use of a paid version of ESXi 4.0 as both are heavily restricted due to the read-only nature of the free version of the hypervisor. It appears that libvirt would gain a significant amount of functionality, including the ability to connect to a serial console, to manage domain’s state (start, stop, pause), and to edit configurations.

VMWare also offers the vSphere Management Assistant (vMA), a prepackaged linux VM to be used as a centralized management platform on which to deploy scripts and management applications.

Conclusion

ESXi 4.0 provides a variety of methods, free and licensed, to maintain and manage both the hypervisor and the virtual machines. The majority of my day-to-day tasks are covered in the free version of ESXi 4.0 and the tools available to it. The ability to manage domains, clone vmdk’s, retrieve configurations and device information, as well as to write applications based on both libvirt’s drivers and the VI API are all available for free. Paid options provide added function through the RCLI and tools like libvirt or virsh are made more useful. Beyond the obvious methods listed above, the undocumented and unsupported portions of ESXi 4.0 may provide additional functionality and features that will open new possibilities in the future.

Do you have another way to manage some portion of ESXi 4.0? Have I missed some serious piece of functionality in one of these items listed above? Let psych0tik know what you think in the comments!

[References]

libvirt website

Wikipedia entry on vSphere

Virtual Infrastructure API Reference

Accessing the ESXi maintenance console

VMWare ESXi SSH CLI Commands

Creating Kernel Panics with vsish

vimsh documentation

libvirt mailing list – questions (and answers) on libvirt’s ESX driver

vmkfstools man page

VMWare whitepaper on managing ESXi

VMWare vMA product page

[video] Cisco Nexus 1000v datasheet

psych0tik releases GoogleSharing proxy

Sunday, February 7th, 2010

A few weeks ago we released a post on staying anonymous online through the use of various configuration changes and Firefox add-ons. One of the Firefox add-ons mentioned was the GoogleSharing proxy add-on. This allows Firefox to reroute unauthenticated requests to Google services through a community proxy that hides your identity while you browse the internet. This add-on is still in beta, so we browsed the source and did a few tests with tcpdump to ensure that it was infact doing what it claimed to be.

GoogleSharing will reroute the following Google services (however, it can be configured not to reroute requests to specific services):

  • Maps
  • Groups
  • News
  • Video
  • Products
  • Images
  • Finance

This is a really neat concept for staying anonymous from Google. The proxy itself masks your IP address, cookies and other headers so that even while logged into other Google services, such as Gmail, searches are not linked to you. We validated this through the use of tcpdump [see figure 1 and 2(generated by Wireshark)] and you can also validate it based on the different appearance of Google web pages, including the link for “Sign Out” which reads “Sign In” with GoogleSharing enabled.

Figure 1 – GoogleSharing is disabled. We can see the lookup of google.com via DNS and then the request (with the search string) being sent to an IP address returned from the DNS request

Figure 2 – GoogleSharing is enabled (however, not using SSL.) We can see the lookup of the psych0tik development proxy, storm, and the following request to storm’s IP address with the Google search.

You can access the psych0tik GoogleSharing proxy by adding it to your proxy list.

Proxy Server: storm.psych0tik.net

Non-SSL Port: 8080

SSL Port: 8443

If you choose to use the proxy in SSL mode (highly recommended), you will need to do the following:

  1. Browse to https://storm.psych0tik.net:8443
  2. When prompted, add an exception for the SSL certificate
  3. Verify under GoogleSharing’s options for the psych0tik server that “use SSL” is enabled
  4. Enjoy!

If you have any questions or issues please contact a psych0tik staff member via our psych0tik IRC. We’ve established #googleshareproxy to provide general chat with regards to this service.

-psych0tik Staff

Presenting the psych0tik network…. sort of

Wednesday, January 13th, 2010

And so it begins. We’d like to present to you the beginning of the psych0tik network, a community of security conscious computer experimenters. We say the “beginning” of psych0tik as this isn’t a full release, rather a pre-release and beta. We’ve been working for the last 6 months to get a number of projects pulled in under the umbrella of psych0tik. Currently, we have 2 services ready for launch, a few sitting at around 80% completion, and a half dozen or so “on the whiteboard.”

We’re doing this pre-release to stabilize our IRC so that our faithful users can finally enjoy uninterrupted conversations. We’ve started from scratch, built a new server with a new IRCd, added in services and even did a bit of testing. We’re now releasing the first node of the psych0tik irc, storm, for beta testing. The testing on this node will help us iron out any defects in our configuration or add any additional features we may want before then rolling that out to a 2nd node.

You can connect to the psych0tik irc with any SSL capable IRC client (e.g. irssi, xchat2) at storm.psych0tik.net on port 6697

>/connect -ssl storm.psych0tik.net 6697

This blog will be the source for psych0tik news, research results, random rants, and most other current happenings. The main site, when released, will act more as a central hub for all the projects and provide high level overview of each.

In the weeks to come we’ll be working towards our full release, which will add the following to the psych0tik network:

  • a main site
  • proxyElite
  • the additional irc node

-psych0tik staff

A new mindset – A new box

Friday, November 13th, 2009

It’s been sometime since I’ve last made a post (like a really long time,) but I’m changing that with this post (obviously) and yet again promising to be more attentive. This time however, the change isn’t simply “more blog posts”, but instead a radical change. SamuraiNet will be merging with the psych0tik network and I will be joining with richo and CarbonLifeForm to run the new and improved psych0tik. Over the next couple months we’ll be releasing more information, including a real release date (to hold ourselves to getting this done.)

All these changes mean only one thing, we needed to amp up our gear. As it’d been a while since I bought a new machine and I was itching to get something fun I volunteered to make the first addition to our network, Storm.

Storm’s Specs:

Built on: Shuttle SA76G2 Barebone 

AMD Phenom II x4 Black (4 Cores@3.2Ghz)

4Gb Patriot Viper DDR2 800 (PC2 6400)

Seagate Barracuda 1.5Tb (7200 rpm) SATA drive

Western Digital Velociraptor 150Gb (10000 rpm) SATA drive