How to connect from a Solaris 10 device to the console of a switch via USB adapter:

Step 1: Plug in the USB adapter. In this example, I have a Prolific Technology Inc. USB-Serial Controller plugged into the console port of a Cisco 2900 XL switch.
Step 2: Run dmesg to see if it was recognized, and to find out its device info:


Apr 12 13:42:34 nerdherd-sol usba: [ID 912658 kern.info] USB 1.10 device (usb67b,2303) operating at full speed (USB 1.x) on USB 1.10 root hub: device@6, usbsprl0 at bus address 2
Apr 12 13:42:34 nerdherd-sol usba: [ID 349649 kern.info] Prolific Technology Inc. USB-Serial Controller
Apr 12 13:42:34 nerdherd-sol genunix: [ID 936769 kern.info] usbsprl0 is /pci@0,0/pci108e,534a@2/device@6
Apr 12 13:42:34 nerdherd-sol genunix: [ID 408114 kern.info] /pci@0,0/pci108e,534a@2/device@6 (usbsprl0) online


Step 3: Look for the device number, and remember the path and number, you’ll need it in a second:

[mikes@nerdherd-sol:~] 197 % ls /dev/cua (or /dev/term)
0

Step 4: Edit /etc/remote, and add an entry pointing to the device number above. I copied the ‘hardwire’ line and called my USB adapter ‘softwire’:

-bash-3.00# vi /etc/remote
"/etc/remote" 60 lines, 1969 characters
# The next 17 lines are for the PCMCIA serial/modem cards.
#
## [17+ lines snipped]
hardwire:\
:dv=/dev/term/b:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
softwire:\
:dv=/dev/cua/0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:

Save and exit.
Step 6: Connect using tip (saving /etc/remote was Step 5):

[mikes@nerdherd-sol:~] 199 % tip softwire
connected

C2900XL Boot Loader (C2900-HBOOT-M) Version 11.2(8.2)SA6, MAINTENANCE INTERIM SOFTWARE
Compiled Wed 23-Jun-99 18:03 by boba
starting...

Step 7: Profit! Now I don’t need to keep a Windows machine around just to run putty or hyperterm.
(Note: the ‘connected’ message was from tip, indicating that it was connected to the USB adapter. After that, the console output from the switch is displayed.)

Because having the right tools is half the battle:

Black hat hackers and pen testers alike use these tools to dump data, perform privilege escalations, and effectively take over sensitive databases

via Slide Show: 10 SQL Injection Tools For Database Pwnage – Darkreading.

Oracle has published a handy-dandy 6-page quick reference of Solaris 11 commands, covering ZFS, disks, zones, SMF, and networking.

Grab the PDF from: solaris-11-cheat-sheet-1556378.pdf (application/pdf Object).

ars technica has a good introduction into the tools of Anonymous, covering LOIC, slowloris, HOIC, and VPN anonymizing services.

High Orbits and Slowlorises: understanding the Anonymous attack tools.

burleyman1 sent this link out to LinkedIn’s Cisco Certifications group:

Subnetting, love it or hate it if you are in the networking field it needs to become your friend. I have gone over a bunch of “easy” ways to learn subnetting and wildcard masks and to be honest some of them confused the heck out of me. So what I have written down is something I put together that helped me get it and to be able to do subnetting quicker and in a lot of cases in my head. So here it is, please let me know if this was helpful or confusing.

In subnetting the only thing you really need to memorize is…..

And then he goes through a simple way of finding the Magic Number (256 – subnet mask), and then subtract 2 to find the number of possible hosts on that mask.

via Subnetting and Wildcard masks….love them or hate them | burleyman1.

While running VMware Server 2.0.2-203138 on Windows 7, I experienced the following issue:

• Installed guests assigned to VMnet0 can not ping or access any hosts aside from other VMware guests.
• My NIC is a: Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit Ethernet NIC (NDIS 6.20)
• In the NIC properties, the VMware Bridge Protocol is enabled.

Guests could see each other and communicate on VMnet0, but cannot ping the host or anything beyond the host.

In Windows 7′s Network and Sharing center, only NIC is listed under “Internet Access”, and VMnet1 and VMnet8 are listed under “No network access,” but this seems to be normal.

From the Start menu, I opened Manage Virtual Networks, and the Summary page told me VMnet0 was supposed to automatically bridge to some adapter.  Apparently, it wasn’t doing so.

At the Host Virtual Network Mapping tab, I was able to specify that I wanted VMnet0 to use the Realtek NIC.

After clicking Apply/OK and waiting a bit for VMware and the guests to figure out just what in tarnation had just changed, guest networking began working as expected.

Within my Solaris 10 guest, I then created /etc/resolv.conf, added the two Google DNS servers, and copied /etc/nsswitch.dns to /etc/nsswitch.conf:

# touch /etc/resolv.conf
# vi /etc/resolv.conf

Add the text:

search myhouse.net
nameserver 192.168.0.1 # my router
nameserver 8.8.8.8 # google
nameserver 8.8.4.4 # google

And lastly:

# cp nsswitch.dns nsswitch.conf

Done!

MySQL Master / Slave replication is amazingly easy to set up.

But what if you do everything by the book, log into the slave, and issue the climactic SLAVE START; command, followed by SHOW SLAVE STATUS\G, and see this error?

Last_IO_Errno: 1045
Last_IO_Error: error connecting to master 'slave_user@master.domain.int:3306' - retry-time: 60 retries: 86400

and your log file shows:

110201 22:53:26 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='master.domain.int', master_port='3306', master_log_file='', master_log_pos='4'. New state master_host='10.0.0.10', master_port='3306', master_log_file='mysql-bin.000001', master_log_pos='106'.
110201 22:53:26 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000001' at position 106, relay log '/mnt/mysql/logs/relay-bin.000001' position: 4
110201 22:53:26 [ERROR] Slave I/O: error connecting to master 'slave-user@10.0.0.10:3306' - retry-time: 60  retries: 86400, Error_code: 1045

The master isn’t rejecting your password, and there isn’t useful feedback indicating why the slave cannot connect.

Note the error code 1045, which indicates a credentials problem.  Double-check the length of your password; MySQL has a MASTER_PASSWORD maximum length limit of 32 characters.  Shorten that puppy up and have another try.

From the command line, you can issue a command such as mysql --user=slave-user --host=master -p to verify that your credentials are valid.  However, be aware that you can connect this way with a password that is too long and that will not work for replication.  Also, double-check that neither firewalls nor SELinux are blocking the connection, you can telnet master 3306 to verify that MySQL is listening and accepting connections on that port.

More MySQL variable restrictions at: MySQL :: MySQL 5.1 Reference Manual :: 12.5.2.1 CHANGE MASTER TO Syntax.

A quarterly vulnerability scan by our PCI Approved Scanning Vendor curiously discovered this vulnerability:

Description: Vulnerable Bugzilla version: 2 Severity: Critical Problem Impact: Multiple vulnerabilities could allow remote account hijacking, viewing of restricted data, unauthorized bug editing, SQL injection, cross-site scripting, security-bypass, or command execution. Background: Bugzilla is an open source bug tracking system written in Perl. Resolution [http://www.bugzilla.org/download/] Upgrade to Bugzilla 3.2.7, Bugzilla 3.4.7, Bugzilla 3.6.1, Bugzilla 3.7.2 or higher, or install the latest [http://www.bugzilla.org/download/#cvs] CVS snapshot. Vulnerability Details: Service: https Received: Distributed under version 2 of the GNU GPL.

I say “curious” because Bugzilla has never been installed on this machine. It is a single-purpose httpd server running RT and nothing else.

After some unhelpful back-and-forth with our ASV’s support e-mail alias, I looked closely at the text of the “Vulnerability Details,” which was just the statement of the GNU license under which RT (and Bugzilla, apparently) is distributed.  Taking a close look at the RT login page, I saw:

Could my ASV be interpreting that distribution statement as a false-positive for an insecure version of Bugzilla?  I know how to find out!

I logged into the RT server, made a backup of and then edited /opt/rt3/share/html/Elements/Footer, and removed the line:

<&|/l&>Distributed under version 2 <a href="http://www.gnu.org/copyleft/gpl.html"> of the GNU GPL.</a></&><br />

A re-scan of the site show it is now 100% Bugzilla free.  So there you go, a GPL statement is a Class 5 Vulnerability on the PCI scale, apparently.

I have a few CentOS 5.4 webservers to upgrade from httpd 2.2.3 to 2.2.17, but 2.2.17 isn’t available as an RPM from in any repository that I can find, so I’m making my own.  Here’s how I did it.

First, I built a new CentOS 5.4 x64 virtual machine on a spare 64-bit VMware vCenter server using the same ISO as my production machines.  This VM will have a plethora of build and development tools that I don’t need or want in production.

Then, I googled around and found some helps on setting up an RPM build environment, including wiki.centos.org, and OwlRiver.com.

Next, I logged in as root, and:

# yum update
# yum groupinstall "Development Tools"
# yum install rpmdevtools rpm-build  redhat-rpm-config  openssl-devel

Create a user to run the build process, and then become that user:

# /usr/sbin/useradd rpmbuilder
# su - rpmbuilder

Set up rpmbuilder’s environment, using the Owl River’s tips:

$ wget http://www.oldrpm.org/hintskinks/buildtree/RPM-build-tree.txt
$ chmod 755 RPM-build-tree.txt
$ ./RPM-build-tree.txt

Then wget httpd-2.2.17.tar.gz from one of the Apache mirrors, and try a build and see what else is needed. (NOTE: httpd includes an httpd.spec file in the root of the tarball, which greatly simplifies building an RPM from the source — we do not need to create a .spec file to guide the creation of the RPM. If you want to modify the build parameters of the RPM, extract the .spec file (tar zxvf httpd-2.2.17.tar.gz httpd.spec), modify it, and then specify your .spec file with rpmbuild --rmspec httpd.spec.)

$ rpmbuild -tb httpd-2.2.17.tar.gz
error: Failed build dependencies:
apr-devel is needed by httpd-2.2.17-1.x86_64
apr-util-devel is needed by httpd-2.2.17-1.x86_64
openldap-devel is needed by httpd-2.2.17-1.x86_64
db4-devel is needed by httpd-2.2.17-1.x86_64
expat-devel is needed by httpd-2.2.17-1.x86_64
pcre-devel >= 5.0 is needed by httpd-2.2.17-1.x86_64
/usr/bin/apr-1-config is needed by httpd-2.2.17-1.x86_64
/usr/bin/apu-1-config is needed by httpd-2.2.17-1.x86_64

When you weren’t looking, I added rpmbuilder to the sudoers file. If you didn’t do that, switch back to root and install the missing packages, but as for me, I sudo-install them as my rpmbuilder

$ sudo /usr/bin/yum install apr-devel apr-util-devel openldap-devel db4-devel expat-devel pcre-devel

And try, try, again:

$ rpmbuild -tb httpd-2.2.17.tar.gz

(Lots of text scrolls past, ending with:

configure: error: distcache support failed: can't include distcache headers
error: Bad exit status from /var/tmp/rpm-tmp.71094 (%build)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.1844 (%build)

Install distcache, then try again.
$ sudo yum install distcache distcache-devel
$ rpmbuild -tb httpd-2.2.17.tar.gz

It builds and builds and builds… it’s working! And you are rewarded with this output:

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.55847
+ umask 022
+ cd /home/rpmbuilder/rpmbuild/BUILD
+ cd httpd-2.2.17
+ rm -rf /var/tmp/httpd-2.2.17-1-root
+ exit 0

Look in the RPMs/arch/ dir for the product of your (or my) hard work:

$ ls rpmbuild/RPMS/x86_64/
httpd-2.2.17-1.x86_64.rpm httpd-devel-2.2.17-1.x86_64.rpm mod_ssl-2.2.17-1.x86_64.rpm
httpd-debuginfo-2.2.17-1.x86_64.rpm httpd-manual-2.2.17-1.x86_64.rpm

Copy httpd-2.2.17-1.x86_64.rpm to a test/dev/QA machine, install it, test your websites, and then repeat in production.

Welcome to 2.2.17!

Surprisingly and happily, with ESXi 4.1, VMware has made it possible to enable and disable SSH access to the host via the vSphere client.  No longer is it necessary to enter the top-secret unsupported console via <alt-F1> and edit inetd.conf by hand.

To enable local or remote TSM from the vSphere Client:

• Select the host and click the Configuration tab.
• Click Security profile > Properties.
• Click Local Tech Support or Remote Tech Support SSH and click Options.
• Choose the desired startup policy and click Start, then click OK.
• Verify that the daemon selected in step 3 shows as running in the Services Properties window.

via VMware KB: Using Tech Support Mode in ESXi 4.1.