[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030306: composite images on MCIDAS (cont.)

>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200303051955.h25Jts318746 McIDAS GOESCOMP MC

Hi Alan,

Sorry I couldn't respond to these as soon as you sent them, but I
was out all day yesterday.

>I would appreciate your offer and will turn telnet back on after
>I send this message;  but I want to provide a bit more information
>on other matters and ask some additional questions.  

OK.  I just made the change which should fix the GOES-East/West
compositing on waldo.

>I turned telnet, ftp and tftp off on waldo just yesterday, after a 
>call from our campus network person.  He said that a network traffic
>was extremely heavy into/out of waldo the previous night ( 60 GB ) 
>and wondered if we were doing something special.  I said no, and 
>we agreed that waldo had likely been hacked.  

I agree.  This definitely sounds like waldo had been hacked.

>When I checked waldo (which only has about an 8 GB disk)  I found 
>that it was running, and our students had not complained about 
>MCIDAS not working.  When I checked,  the disk showed about 65 % 
>which is about what it has been (+/- 10%).  So after reading a bit,
>I decided that I should have turned off telnet and some other services
>long ago.  I turned off  telnet, ftp and tftp.

I agree that these services do not need to be enabled.  I would suggest,
however, that you install (get your computer services folks to install)
ssh so that people can logon from remote machines.  We dumped telnet
and rlogin from external sites in favor of ssh a long time ago.

>Read some more last 
>night and found that there are quite a few services that come 
>standard with Solaris that are turned on by default on OS install
>and that many of them are unnecessary for most users.  

Right.  There are also a number that are tunred on by default and
should not be since they are known to be big security holes.

>This morning, I got a call from another faculty who was having 
>trouble with our MCIDAS terminals not being able to access waldo.
>I believe part of his problem was with individual terminals as one 
>or two were locked up and waldo seems to be running ok.

The other factor to consider is access to waldo on ports 500 and/or
503.  McIDAS ADDE does its transactions through these ports, so if
they are blocked, McIDAS ADDE will appear to not be working.

>He noted that  MCIDAS image products and map plots create ok,
>the listing of text products failed.

This could be something else entirely.

>Examples were WXTLIST  and SFCRPT.  These brought an error message 
>of 'cannot connect to server' or something to that effect.

The error message is strange alright.  More typically, the index
files needed by the McIDAS ADDE text server could be corrupt/damaged/missing.

>My first thought was that my disabling of services might have caused 
>this,

This should have had no effect as long as you didn't remove the ADDE
information from /etc/inetd.conf and /etc/services.

>but now I suspect that perhaps the hacking event may have 
>damaged or changed something.

Perhaps.  I will take a look while I am on.

>The ldm on waldo seems to be running 
>and ingesting data as expected.
>
>So, my questions are as follows
>
>1.  Can most services such as telnet, ftp and others be turned 
>    off ?

Yes.  I took a quick look at your TCP wrapper allow file, /etc/hosts.allow,
and saw that rlogind, rshd, and telnetd were wide open.  I closed them
down to only allowing connections from your local net and Unidata.

>    Maybe a better question is what services are required
>    for waldo to do its job of ingesting and serving data to our 
>    terminals.

/etc/services and /etc/inetd.conf will need to be configured to support
McIDAS ADDE.  I just checked and see that waldo's inetd.conf is no longer
configured with the appropriate things for McIDAS ADDE, but /etc/services
is.

Since I know the 'root' login, I redid the McIDAS ADDE configuration steps:

<become 'root'>
cd /home/mcidas
sh ./mcinet2002.sh uninstall mcadde                <- to clean up
sh ./mcinet2002.sh install mcadde

After doing this, waldo is once again setup to serve McIDAS data through
the remote ADDE server, at least, _if_ other hosts are allowed to 
access waldo.

>    The terminals list waldo as a primary adde site
>    and we also still have them mounted to waldo's disk (I know 
>    I need to upgrade, then the mount will be unnessary).

From what I see, other systems at St. Cloud State should be able to
access the remote adde server on waldo.

>2.  Any ideas as to why the text commands listed fail ?

I am betting that the other machines were configured to access the
text data (the stuff that WXTLIST and SFCRPT uses) through the remote
ADDE server on waldo, but the access to the imagery was through LOCAL-DATA
datasets.  LOCAL-DATA datasets are ones where the dataset definition is
done in the user's account itself.  Going to a remote server allows you
to not have to define the dataset, and, therefore, makes it easier
to setup user accounts to use McIDAS.

Now that I redid the remote ADDE server access on waldo, the text access
stuff should once again work _if_ my surmise above is correct.

>From address@hidden Thu Mar  6 10:30:21 2003

>Well things are starting to get interesting, at least for me.   As I
>noted in my earlier message this morning,  I  went back to waldo and
>turned telnet back on (un-commented the telnet line in
>/etc/inet/services and /etc/inet/inetd.conf  files)  Then restarted the
>inetd process  with

>kill -1  pid

>This doesn't restart inetd, but, rather sends it a signal to reread
>its configuration file (assuming that 'pid' is the process id for inetd).

>I still cannot telnet into waldo.   Have also tried a complete shutdown
>and reboot of waldo,  still cannot telnet into it.   get the message
>'could not open a connection on port 23,  connect failed '

>I looked in the /usr/sbin directory at the executable file  inetd to
>and it is there with a date that matches several other files in that
>directory, thinking that maybe the file has been replaced by the
>hacker.

>At any rate,  I cannot get telnet to work on waldo, so ....  My network
>guy seems stumped also.

>Ideas ?

Not really, but your next note shows that you figured it out.

>From address@hidden Thu Mar  6 10:52:23 2003

>Telnet now works on waldo.   I found that part of the line that lists
>the telnet service in the inetd.conf file listed it as tcp6.   There is
>a discussion of this in the file (IVP6 vs IVP4 protocols)  and in any
>case I did not change this before, so it worked before.

>by editing  tcp6  to just  tcp,  restarting inetd,  I can now telnet on
>to waldo.

Good sleuthing!

OK, as I send off this email, I have only done the following:

for McIDAS:

o edited ~mcidas/mcidas2002/src/makefile and moved the build for the MC
  executable (mc.k) down into the section that contains other old routines
  that still need to be built.  After making mc.k:

  cd ~mcidas/mcidas2002/src
  make mc.k VENDOR=-gcc

  I linked it to the ~mcidas/bin directory so it can be found along with
  the other v2002 executables:

  ln mc.k ~/bin

for LDM-6:

o I brought over and built LDM-6.0.2.  The build went normally:

<login as 'ldm'>
cd ~ldm
ftp ftp.unidata.ucar.edu
  <user> anonymous
  <pass> full_email_address
  cd pub/ldm/test
  binary
  get ldm-6.0.2.tar.Z
  quit

zcat ldm-6.0.2.tar.Z | tar xvf -
cd ldm-6.0.2/src
setenv CC gcc                      <- /usr/ucb/bin/cc is not an ANSI C compiler
./configure
make
make install
sudo make install_setuids

cd ../bin
<edit ldmadmin and set:
      $hostname to waldo.stcloudstate.edu
      size of LDM queue to 1 GB
      number of log files to 14

      (these settings match the ldmadmin script for LDM-5.2.1)

<edit ~ldm/etc/ldmd.conf and:

      split the request for DDPLUS|IDS|FSL2|MCIDAS into two different
      requests:

request DDPLUS|IDS|FSL2 ".*"    papagayo.unl.edu

and

request UNIWISC ".*"    papagayo.unl.edu

       You may ask why...  LDM-5 would aggregate different requests
       to the same upstream host into a single rpc.ldmd process.
       LDM-6 does not do this.  I split the feed to cut down the
       amount of data being transferred on each rpc.ldmd so that
       the product latencies seen on waldo are as low as possible.
       This splitting may have been unnecessary, but it can't hurt.

When I tried to start the LDM, I found that syslogd was not running.
I started it:

<become 'root'>
/usr/sbin/syslogd
<exit out of 'root'>

So, you are now running the latest LDM-6 release candidate on waldo.
So far, it is running smoothly.  Please let me know if you see anything
strange/bad.

Tom