Problems with idsupdate.

s.ferreira · ‎02-14-2002

I have been having problems with updating my sensors with the command ./idsupdate. I have been getting the following output.

./idsupdate username@x.x.x.x/IDS password

idsapply results: [Idsapply: executing as euid [100] egid [100]

The ftp server that I have been using is my laptop using FtpXQ for Windows. If I do the ftp manualy it works. Thanks in advance.

stleary · ‎02-14-2002

What version of IDS are you using? Older versions of Idsupdate are not able to

connect to all ftp servers, Windows servers in particular. Can you temporarily

move your update files to a Solaris or other UNIX server? This problem is resolved

in the latest version of IDS. After you upgrade, you can resume using a Windows

ftp server for future updates.

s.ferreira · ‎02-14-2002

I'm using version 3.0.3 S15 on my sensors.

I'm thinking that maybe it has to do with file permissions.

-rwsr-l--- 1 root netrangr 2394224 Jan 25 11:59 idsapply

-rwsr-l--- 1 root netrangr 113004 Jan 25 11:59 idsupdate

marcabal · ‎02-14-2002

The idsapply and idsupdate commands must be run as user root.

If the command is executed as user netrangr then you should get an error.

I am not sure if this is the issue you are seeing.

From the config note for the for sensor:

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

Step 3 On the Sensor log in as root via Telnet, SSH, or a local console.

Step 4 Change to the /bin directory by typing the following:

cd /usr/nr/bin

Step 5 Type the following to set up idsupdate (see Example 1):

./idsupdate /

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

s.ferreira · ‎02-14-2002

The only time that I get idsupdate to run is if I manually stop the IDS daemons with nrstop. Log on as root an run idsupdate. It will then log in my FTP server , change to the right directory but it will not download the signature updates.

see the output bellow:

=======================================

./idsupdate username@x.x.x.x/IDS pwd

idsapply results: [Idsapply: executing as euid [100] egid [100]

Idsapply: NetRanger is not running.

****************************************************************

Idsapply: starting [Thu Feb 14 15:16:13 2002

]

Idsapply: cmd line: [user] [x.x.x.x] [IDS] [passwd] [/usr/nr/] [0] [0]

Idsapply: using root dir [/usr/nr/]

Idsapply: CSIDS version [3.0] service pak [3] signature [15]

Idsapply: csidsCmdLineStr [0]

Idsapply: csidsCmdLineMajor [0] csidsMajor [3]

csidsCmdLineMinor [0] csidsMinor [0]

csidsCmdLineSp [0] csidsSp [3]

csidsCmdLineSig [0] csidsSig [15]

Idsapply: sapx_main output: [sapx:(x,0,0) FTP Transfer

ftp> open myftpIPaddress

Connected to myftpIPaddress.

220 DataWizard Technologies' FtpXQ LE FTP Server. Free Personal Edition (Version 2.5.5).

Name (myftpIPADDRESS:root): myftpusername

331 OK need password.

Password:

230 Please leave if you are not an authorized user.

ftp> bin

200 OK

ftp> cd IDS

250 Requested file action completed successfully.

ftp> ls

200 OK

150 Opening data connection.

02-12-02 10:55AM 309228 IDSk9-sig-3.0-4-S17.bin

02-13-02 02:07PM 15329828 IDSk9-sp-3.0-4-S16.bin

226 Transfer completed.

127 bytes received in 0.0052 seconds (23.73 Kbytes/s)

ftp> ftpTrans result [0]

]

Idsapply: update list retrieval is complete

Idsapply: No update was found

Idsapply: No update will be applied.

]

#

marcabal · ‎02-15-2002

Really weird.

I would recommend contacting the TAC. This could be a bug in the idsupdate command.

But it may be a few days for the engineers to figure out what is going wrong.

As a workaround for now, to get the emergency fixes on your sensor as soon as possible.

Download the two files to your sensor yourself and execute each with the "-I" option.

Marco

s.ferreira · ‎02-19-2002

I can do the manual upgrades but upgrading 40+ sensors manually is not fun. Thanks for help. I'll open a TAC case.

stleary · ‎02-20-2002

Idsapply connected to the server, so your password should be OK.

It also found the download files. But it looks like the files could not

be validated for update because of the way that the ftp server responded

to the 'ls' command. Idsapply expects the filenames only, and not the

timestamp or filesize. This is a bug in idsapply. When you open a

TAC case, ask them to contact stleary@.cisco.com as the DE, and I

will make sure it gets fixed. As a workaround, try using a different ftp

server.

s.ferreira · ‎02-21-2002

I phoned CISCO TAC and we figured it out. If I make my director the ftp server and put the sensor sp and sig files on /usr/nr the ./idsupdate command works. If I put in any other directory it does not.

marcabal · ‎02-27-2002

idsupdate uses relative path.

When you use: "/idsupdate netrangr@/. password" then idsupdate will look in the default ftp directory when netrangr logs in (which is /usr/nr).

But if you use: "/idsupdate netrangr@/updates password" then idsupdate will wind ip in the default ftp directory when netrangr logs in (which is /usr/nr) and then cd to the updates directory putting you in /usr/nr/updates.

If you want an absolute path simply add another "/" before the directory name: "/idsupdate netrangr@//updates password" then idsupdate will wind up in the default ftp directory when netrangr logs in (which is /usr/nr); it will then cd to the /updates directory. The extra slash here forces it down to the root directory and it looks in /updates instead of /usr/nr/updates.

On other ftp servers, the idsupdate will use a relative path based on the default directory that the ftp server puts that user in. On windows ftp servers there is usually a common ftp server directory rather that using the user's home directory which is typical for unix boxes.

dmorone · ‎02-19-2002

I just had the same symptom when I ran the command and forgot to put the password at the end. I'm sure you checked but just in case I thought I'd let you know.

dchenders · ‎02-27-2002

FYI

I have had the same problem when trying to do non scheduled update, if you schedule the update to run at a specific time and date it should work.