===========================================================
                        LINUX NEWS
            Resources & Links From CramSession.com
                 Thursday, November 29, 2001
===========================================================

-----------------
TABLE OF CONTENTS
-----------------

1) Sean's Notes

2) Linux News

	Bill Gates Gives Open Source A Boost
	Red Hat to Provide Support to IBM
	Another Linux Success Story
	WU-FTP Remote Root Vulnerability

3) Linux Resources

	Linux Tips
	Destination NAT-ting
	Build A Better Web Server
	Query Tools
	Sharpen Up Those Regex Skills

4) App o' the Week


~~~~~~~~~~~~~~~~~~~~~~ ADVERTISEMENT ~~~~~~~~~~~~~~~~~~~~~~~

Try Our IT Certification Courses FREE! SmartCertify Direct
gives you classroom-quality IT training at a fraction of the
cost of traditional courses. You’ll get 24-hour online mentoring
from certified advisors, hands-on interactive exercises, the
popular Test Prep exams and more! Choose from MCSE, Cisco, A+,
CIW, Linux and many other courses. Click below to try them all
FREE and register to WIN a state of the art Dell PC!

http://ad.brainbuzz.com/?RC06&AID96

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For information on how to advertise in this newsletter
please contact mailto:adsales@CramSession.com or visit
http://cramsession.com/marketing/default.asp

===========================================================
1) Sean's Notes
===========================================================

A UNIX system is bound to have many processes running at the
same time, many of which will be running as something called
a daemon.  The purpose of a daemon is to run detached from a
terminal and do...something.  I've talked about daemons in
the past, such as syslog, which is used for centralized
logging, and cron, which executes tasks at predetermined
times.  Other examples of daemons are services like telnet
and ftp.  However, if you check through your process listing,
the chance of you having a telnet daemon actually running
is remote.  In fact, unless someone is telnetted into your
machine at the moment, you won't see any telnet daemons.

Telnet is one of the many services handled through the inetd
daemon, otherwise known as the "Internet Super Server".
Inetd is a daemon that waits for connections on behalf of
many programs, passing off control once the connection has
been established.  Rather than having the telnet daemon
running in the background waiting for a connection, plus an
FTP daemon, and a dozen other ones, it's a lot easier to
have one process listen on all the appropriate ports and
then run the appropriate daemon when necessary.

Another advantage of centralizing all of this is that you
can also centralize the logging and security.  It's much
easier to say "only these hosts can connect to my system"
for one program than it is to do the same for every single
daemon you want to run.

Most of you running a current distribution will see "xinetd"
rather than inetd.  "xinetd" is a newer daemon that expands
on what inetd can do.  You can choose to rate limit the
amount of connections that can be started (to prevent DOS
attacks), not to mention have more control over how the
child processes themselves get configured.  Another feature
I thought was pretty slick is that you can get xinetd to
accept a connection on a certain port, and then forward it
to another machine.  Don't get me started on how insecure
this could be, but properly implemented I see some good
applications for it.

A full description of xinetd can be found at its home page:

http://www.xinetd.org/

I'm going to postpone an article about xinetd configuration
for later. This week, I thought I'd explain a bit about how
applications that run out of something like xinetd are
different from those that listen on the port themselves (such
as apache).  Then, I'll show you how you can exploit these
differences to make some of your shell scripts and interactive
programs network-enabled with virtually no effort!

In network programming, a program has to bind to a socket and
then let the operating system know that it wants to listen on
that socket.  When a connection comes in, the operating system
lets the application know, and the application accepts the
socket.  In C, it looks something like this (note: this is
fairly incomplete; socket programming involves a lot of
complicated structures).

int socketfd, childfd;
socketfd = socket( ... );
bind(socketfd, ... );
listen(socketfd, ... );
childfd = accept(socketfd, ... );

A socket is created with the socket() system call.  This
creates a file descriptor (a handle) for the created socket.
This file descriptor is then bound to a port with the bind()
system call.  If we were writing a web server, we'd bind() to
port 80.  If this socket was to be outbound (ie connecting to
a web server), we'd bind to socket 0, meaning that the
operating system picks an appropriate port.  Then, we tell
the operating system that we intend this socket to wait for
connections with listen().

The last thing we do is to accept() the connection.  Assuming
there is none, we get blocked (put on hold) until one comes
in.  Upon return from accept(), we're given a file descriptor
for the newly created connection.  We can read and write to
it just like we were reading and writing to the terminal.

As you can see, network programming is a headache, and should
be avoided if possible.  Besides the code above, there is a
lot of other considerations, such as making sure that when
you wrote 1,000 bytes, that 1,000 bytes were actually sent.

The Internet Super Server makes life easier.  It hinges on
the design of Unix -- A file descriptor looks the same to
an application, be it writing to a file, a socket, or the
screen.  Remember, "everything is a file" in Unix.

When a program is run, it has three file descriptors already
opened, 0, 1, and 2.  These correspond to the standard input
(stdin), the standard output (stdout), and the standard error
(stderr) respectively.  In a nutshell, the descriptors
required to write to the terminal.  inetd takes advantage of
this by mapping the daemon's stdin and stdout to the socket
that was built with the remote host.  Put even simpler--
write to the terminal, it goes to the network.  Read from
the terminal, it reads from the network.  An example will
illustrate.

Create a file - /usr/sbin/test.pl  (you'll need to be root
to do most of this)

#!/usr/bin/perl
$|=1;  # Flush output
print "What is your name?\n";
$in = <STDIN>;
print "Hello, $in\n";


Make sure it is executable:
# chmod +x /usr/sbin/test.pl

Try it out from the command line:

# /usr/sbin/test.pl
What is your name?
Sean
Hello, Sean

We're going to add a new service to xinetd.  Each file in
/etc/xinetd.d corresponds to a service, so create
/etc/xinetd.d/test:

service test
{
	socket_type		= stream
	wait			= no
	user			= root
	server			= /usr/sbin/test.pl
	disable			= no
}

Here a service called "test" is created on a stream (TCP)
port, and is associated with our script.  The last thing to
do is tell the operating system what port test is on: I used
34343.  /etc/services contains the mappings of port names to
numbers.  I simply added a line as such:

test            34343/tcp      #test

And then restarted xinetd to enable the test service:

# /etc/rc.d/xinetd restart

Now, we can telnet to our new service:

# telnet localhost test
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
What is your name?
Sean
Hello, Sean

Connection closed by foreign host.
#

By using xinetd, we've turned a regular terminal-based
application into a network application without any extra code.
test.pl could have just as easily been a script that gets
information from the user, and modifies entries in the DNS
table.  The user never has to login to the system or touch a
configuration file, and you can use the same script you normally
would have.  Standard disclaimers apply about security--limit
access to only the addresses you trust to connect, and run the
application with the least privileges necessary!

Not only does inetd/xinetd reduce the resources needed to have
many daemons running at the same time, but it facilitates the
creation of the daemons by eliminating the need to worry about
network programming.

Before signing off, I'd like to welcome new readers that found
this list through the Lockergnome Penguin Shell newsletter.
Tony was kind enough to link to an older newsletter which
brought in a lot of viewers.  He's currently doing a review of
the major Linux distributions -- if you're still up in the air
about which one to use, you can count on sound advice from him:

http://www.lockergnome.com/issues/penguinshell.html


Long live the Penguin,

Sean
swalberg@cramsession.com

Visit the Linux News Board at
http://boards.cramsession.com/boards/vbt.asp?b–2

===========================================================
2) Linux News
===========================================================

-------------------------------------
Bill Gates Gives Open Source A Boost
-------------------------------------
According to this article, the release of XP is a good thing
for Open Source, since the restrictiveness may send people
toward Free and Open alternatives. I don't think it's quite
as drastic as they make it out to be, but I wouldn't be
surprised to see some action on this front.

http://www.business2.com/articles/web/print/0,1650,35655,FF.html

----------------------------------
Red Hat to Provide Support to IBM
----------------------------------
IBM has been pushing Linux on their servers and mainframes
for a while now. In a bid that will surely see improved
support for IBM hardware, Red Hat has announced that it
will be partnering with IBM to provide a customized version
of Red Hat Linux, along with the associated support.

http://www.redhat.com/about/presscenter/2001/press_ibmzip.html

----------------------------
Another Linux Success Story
----------------------------
This time, it's google.com, the preferred search engine of
many (myself included). Owing partly to using Linux (can you
imagine what 6,000 NT licences would cost!?), google.com has
become the dominant search technology.

http://www.newsalert.com/bin/story?StoryId=CparVuaicreeTr09pr0Xf

---------------------------------
WU-FTP Remote Root Vulnerability
---------------------------------
This one really hurts: a remote root exploit in WU-FTPd. A
package plagued by holes, I don't understand why Red Hat even
distributes it. Nevertheless, upgrade if you need to, and be
extra careful in the future if you're offering FTP services.

http://www.securityfocus.com/archive/1/242590

===========================================================
3) Linux Resources
===========================================================

-----------
Linux Tips
-----------
This site is chock full of handy information, and is
constantly updated. It seems to be focused on providing the
answers to everyday things, like finding what user has a
file open, to customization tweaks.

http://www.linux-tips.net/

--------------------
Destination NATting
--------------------
2.2 kernels used the ipmasqadm command to forward an
external port to an inside address, and all was well.
Enter 2.4 kernels, with the new and improved iptables,
and this technique doesn't work any more. It's now called
"Destination NAT", and some helpful hints on its use can
be found in this thread.

http://www.linuxquestions.org/questions/showthread.php?threadid‚53

--------------------------
Build A Better Web Server
--------------------------
I really like reading about the way people choose the
hardware for web site upgrades, mostly because they tend
to get into the various tradeoffs. This one covers Aces
Hardware upgrade from a Sparc 20 to a spiffy new Sun Blade.

http://www.aceshardware.com/read.jsp?idE000240

------------
Query Tools
------------
One of the things I find myself doing quite regularly is
trying to find out where a certain IP address or name comes
from, such as when some obnoxious person is probing my
network. Geektools.com has all the tools I need in one
place, and with a good interface.

http://www.geektools.com/

------------------------------
Sharpen Up Those Regex Skills
------------------------------
To overcome a problem with Perl CGI scripts in IIS, someone
put together a one line statement that added the program's
directory to the module search path. The fix itself isn't so
much the focus of this article, as is the explanation of how
it works, and what Perl features it takes advantage of.

http://www.rcbowen.com/imho/perl_cwd_iis.html

===========================================================
4) App o' the week
===========================================================
The Cisco-centric Open Source Initiative is here to provide
free tools to help you manage your Cisco network. Some of
the utilities in it are quite innovative! The fellow running
the project works for Cisco, so even though it's not
officially endorsed, it should have better access to
documentation and the way things work.

http://cosi-nms.sourceforge.net/

===========================================================
(C) 2001 BrainBuzz.com, Inc. All Rights Reserved.
===========================================================
_______________________________________________________

         This message is from CramSession.com.

You are currently subscribed to the
   Hottest Linux News and Resources
   as: sean@ertw.com

To un-subscribe from this newsletter by e-mail:
   send a blank email message to:
   mailto:leave-linuxnews-3825955Y@list.cramsession.com

-------------------------------------------------------

To Subscribe to this newsletter by e-mail:
   send a blank email message to:
   mailto:join-linuxnews@list.cramsession.com
_______________________________________________________