Menu
▾
▴
tripwire-announce
|
From: Ron F. <ro...@tr...> - 2001-04-10 18:18:48
|
Hey Gary, do me a favor and plop the bug you show below into the tripwire bug database on tripwire. Also, when you guys say "Old report", you mean v1.3 reports? I started here long after v1.3, so if one of you can forward me an example 1.3 report, I will see what I can do with the current report format. Thanks. rjf (aka itripn)& > -----Original Message----- > From: Gary E. Miller [mailto:ge...@re...] > Sent: Saturday, April 07, 2001 10:33 PM > To: Olli Artemjev > Cc: Tri...@li... > Subject: Re: [Tripwire-announce] what to do?? > > > Yo Olli! > > I agree 110% The old reports are better. > > Higher on my list arrer these two bugs: > > The bug that prevents you from doing something like this in > your config file: > /var -> $(SEC_INVARIANT) (recurse = true); > !/var/log/radius; > > And the bug that just prints "## Internal Error" when I run it on > one of my hosts. > > RGDS > GARY > -------------------------------------------------------------- > ------------- > Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 > ge...@re... Tel:+1(541)382-8588 Fax: +1(541)382-8676 > > On Sat, 7 Apr 2001, Olli Artemjev wrote: > > > time. In old version I was able to find what is strange & > what is OK. but > > now I see only a dumb list. What a stupidity. :/ I spend a > day digging > > tripwire dox & man pages & found nothing related to this. > Are this options > > present in the "commercial versions only" or what? :/ > > > _______________________________________________ > Tripwire-announce mailing list > Tri...@li... > http://lists.sourceforge.net/lists/listinfo/tripwire-announce > |
|
From: Ron F. <ro...@tr...> - 2001-04-10 22:51:22
|
Gary, attached is a report from 2.3, and honestly, I don't see what you mean. This report shows exactly what was modifed, and it seems to me more clearly. Can you point out what about this report is lacking? I'm happy to hack up the format until we all agree it is as concise as possible. Thanks. rjf& ==-=-=-=-=-=-=-=-=- Tripwire(R) 2.3.0 Integrity Check Report Report generated by: Report created on: Tue Apr 10 14:00:01 2001 Database last updated on: Sat Apr 7 22:03:38 2001 ============================================================================ === Report Summary: ============================================================================ === Host name: main Host IP address: Unknown IP Host ID: None Policy file used: /root/tss/policy/tw.pol Configuration file used: /root/tss/tw.cfg Database file used: /root/tss/db/main.twd Command line used: /root/tss/tripwire -m c -n -c /root/tss/tw.cfg -M ============================================================================ === Rule Summary: ============================================================================ === ---------------------------------------------------------------------------- --- Section: Unix File System ---------------------------------------------------------------------------- --- Rule Name Severity Level Added Removed Modified --------- -------------- ----- ------- -------- * standard 0 0 0 5 proc 0 0 0 0 Total objects scanned: 2914 Total violations found: 5 ============================================================================ === Object Detail: ============================================================================ === ---------------------------------------------------------------------------- --- Section: Unix File System ---------------------------------------------------------------------------- --- ---------------------------------------------------------------------------- --- Rule Name: standard (/etc) Severity Level: 0 ---------------------------------------------------------------------------- --- ---------------------------------------- Modified Objects: 2 ---------------------------------------- Modified object name: /etc/rc.d/rc.portfw Property: Expected Observed ------------- ----------- ----------- Object Type Regular File Regular File Device Number 769 769 Inode Number 104008 104008 Mode -rwxr-xr-x -rwxr-xr-x Num Links 1 1 UID 0 0 GID 0 0 * Size 1151 1316 * Modify Time Thu Feb 15 13:47:41 2001 Mon Apr 9 06:05:32 2001 Blocks 4 4 * CRC32 DSBqPk AwneSj * MD5 B9C6iM+h+k7koU+m6zwtpt D/jgBrXJwzYnwxmq9CJP1j Modified object name: /etc/sendmail.st Property: Expected Observed ------------- ----------- ----------- Object Type Regular File Regular File Device Number 769 769 Inode Number 120400 120400 Mode -rw-r--r-- -rw-r--r-- Num Links 1 1 UID 0 0 GID 9 9 Size 616 616 * Modify Time Sat Apr 7 21:58:12 2001 Tue Apr 10 14:01:24 2001 Blocks 2 2 * CRC32 CZgNS/ BXirqM * MD5 Bdu7a7mZrx8TDyOqoPdnQS A5MHtU2IIHgqyPlU0ZVKNn ---------------------------------------------------------------------------- --- Rule Name: standard (/root/tss) Severity Level: 0 ---------------------------------------------------------------------------- --- ---------------------------------------- Modified Objects: 3 ---------------------------------------- Modified object name: /root/tss Property: Expected Observed ------------- ----------- ----------- Object Type Directory Directory Device Number 769 769 Inode Number 8060 8060 Mode dr-x------ dr-x------ Num Links 6 6 UID 0 0 GID 0 0 Size 1024 1024 * Modify Time Mon Apr 2 15:04:47 2001 Sat Apr 7 22:03:45 2001 Blocks 2 2 Modified object name: /root/tss/db Property: Expected Observed ------------- ----------- ----------- Object Type Directory Directory Device Number 769 769 Inode Number 80050 80050 Mode drwx------ drwx------ Num Links 2 2 UID 0 0 GID 0 0 Size 1024 1024 * Modify Time Mon Apr 2 15:04:59 2001 Sat Apr 7 22:04:12 2001 Blocks 2 2 Modified object name: /root/tss/db/main.twd Property: Expected Observed ------------- ----------- ----------- Object Type Regular File Regular File Device Number 769 769 Inode Number 80054 80054 Mode -rwx------ -rwx------ Num Links 1 1 UID 0 0 GID 0 0 Size 152772 152772 * Modify Time Mon Apr 2 15:05:14 2001 Sat Apr 7 22:04:27 2001 Blocks 302 302 * CRC32 CD7N4f DRHI5q * MD5 BSAeKhOGZw/rmDB+7fNhbx CfATyy4v1++EI8KSlMSQes ============================================================================ === Error Report: ============================================================================ === No Errors ---------------------------------------------------------------------------- --- *** End of report *** Tripwire 2.3 Portions copyright 2000 Tripwire, Inc. Tripwire is a registered trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY; for details use --version. This is free software which may be redistributed or modified only under certain conditions; see COPYING for details. All rights reserved. |
|
From: Gary E. M. <ge...@re...> - 2001-04-10 23:11:33
|
Yo Ron! On Tue, 10 Apr 2001, Ron Forrester wrote: > Gary, attached is a report from 2.3, and honestly, I don't see what you > mean. This report shows exactly what was modifed, and it seems to me more > clearly. Maybe to you, but not to me. Here are some of the many problems I have with your report: 1. too much white space. I hate to have to scroll my mail when I am checking dozens of these every morning. Rows of equal signs? 2. NOTHING usefull is at the top. I know what the hostname is. It was in the from address of the email. Same for the IP, and the date. Remove all this. I want meat and I want it at the top. 3. Summaries? This is useless. I want facts, not aggregates. Knowing that 5 files were changed is useless. I need to know WHICH 5 files and what was changed, in one glance. I often get good reports when 1,000 files were changed and bad reports when only 1 file is changed. That is not useful information. 4. Then WAY too much details. I already get reports that are 100k in the OLD format. The new format is WAY to much stuff to wade through. It takes 20 lines to provide almost the same detail as the OLD report does in one line. Multiply by 1000 changed files and the results are horrendous. Looking at 1 change to a screen is just not possible. > Can you point out what about this report is lacking? I'm happy to hack up > the format until we all agree it is as concise as possible. It is lacking a consistent focus on the important details in a compact format. The pseudo "ls" format of the top half is the old report is the ideal starting point. Any sysadmin worth his salt can grok a huge "ls" in seconds and pick out the important stuff. It is a format that he already feels in his bones. Learning UNIX is learning not to reinvent wheels. Instead of seeing what I need in one or two screens I now need to read 20 or 40 screens. This is not good. It makes it very hard to eyeball the type and scope of changes. If someone has changed a lot in the system then the new format is just HUGE. If some people like the new format then keep it, but a LOT of us have many years of experience with the old one and are having a hard time converting to Tripwire 2 because of it. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 ge...@re... Tel:+1(541)382-8588 Fax: +1(541)382-8676 |
|
From: Olli A. <ol...@me...> - 2001-04-11 10:01:45
|
On Tue, 10 Apr 2001, Gary E. Miller wrote: > 1. too much white space. agree. > 2. NOTHING usefull is at the top. I know what the hostname is. It > was in the from address of the email. Same for the IP, and the date. > Remove all this. I want meat and I want it at the top. agree. > 3. Summaries? This is useless. I want facts, not aggregates. Knowing > that 5 files were changed is useless. I need to know WHICH 5 files > and what was changed, in one glance. I often get good reports when 1,000 > files were changed and bad reports when only 1 file is changed. That > is not useful information. agree! > 4. Then WAY too much details. I already get reports that are 100k in > the OLD format. The new format is WAY to much stuff to wade through. > It takes 20 lines to provide almost the same detail as the OLD report does > in one line. Multiply by 1000 changed files and the results are > horrendous. Looking at 1 change to a screen is just not possible. agree. > > Can you point out what about this report is lacking? I'm happy to hack up > > the format until we all agree it is as concise as possible. > It is lacking a consistent focus on the important details in a compact > format. The pseudo "ls" format of the top half is the old report > is the ideal starting point. Any sysadmin worth his salt can grok > a huge "ls" in seconds and pick out the important stuff. It is a > format that he already feels in his bones. Learning UNIX is learning > not to reinvent wheels. > Instead of seeing what I need in one or two screens I now need > to read 20 or 40 screens. This is not good. It makes it very > hard to eyeball the type and scope of changes. If someone has changed > a lot in the system then the new format is just HUGE. > If some people like the new format then keep it, but a LOT of us > have many years of experience with the old one and are having a hard agree. The main (& the HUGEST) bad changes in report was tat I CAN'T know from it what it WAS & what it NOW. I _NEED_ this information for all parameters set to be checked. What da hell means /bin/ls has changed? What of MANY parameters changed. & HOW them where changed. :? I've some scripts running from crond. I've new installed software. I've a huge .bash_history & so on. So many things may cause changes but only a small amount are illegal changes that tripwire should track. Instead of showing the DETAILED subject of changes new version just gives me a list of files. Some day I see thousands of files & what? I should WASTE my time to dig EACHE ONE of these THOUSANDS files & investigate what was the subject of reporting that change has happen. These new reports are USELESS. I decided to remove tripwire because old one with fine reports has bugs with non-"C"-locale-based file names & the new one is just a WASTE of CPU cicles & human reading time. Anyway I'm steel on the announce list - hope somewhen the reports will go to the better view? :? -- Bye.Olli MISiS Telecommunications phone: +7(095)955-0087 |
|
From: Ron F. <ro...@tr...> - 2001-04-11 00:46:45
|
> 1. too much white space. I hate to have to scroll my mail when I > am checking dozens of these every morning. Rows of equal signs? Okay. > 2. NOTHING usefull is at the top. I know what the hostname is. It > was in the from address of the email. Same for the IP, and the date. > Remove all this. I want meat and I want it at the top. This isn't always the case though. People have their systems setup to mail in bizarre ways, and often run on many system with emails going to a central place. I agree it could be cut down to a couple of lines though. > 3. Summaries? This is useless. I want facts, not > aggregates. Knowing that 5 files were changed is useless. > I need to know WHICH 5 files > and what was changed, in one glance. I often get good Okay, I can see this -- but the v1.3 report doesn't give you exactly what you are looking for either, you have to wade through a list _what_ changed before you get to the details of how it changed. Some happy medium here would be nice. > 4. Then WAY too much details. I already get reports that are 100k in > the OLD format. The new format is WAY to much stuff to wade through. > It takes 20 lines to provide almost the same detail as the > OLD report does in one line. Multiply by 1000 changed files and the results are > horrendous. Looking at 1 change to a screen is just not possible. Again, I can see your point. You only want the properties which changed to be listed. > If some people like the new format then keep it, but a LOT of us > have many years of experience with the old one and are having a hard > time converting to Tripwire 2 because of it. I don't know that anyone has expressed a strong opinion outside of you. I will certainly make a pass at cleaning up the report format, and it looks like I can count on you to provide some feedback. rjf& |
|
From: Gary E. M. <ge...@re...> - 2001-04-11 01:55:47
|
Yo Ron! On Tue, 10 Apr 2001, Ron Forrester wrote: > > 2. NOTHING usefull is at the top. I know what the hostname is. It > > was in the from address of the email. Same for the IP, and the date. > > Remove all this. I want meat and I want it at the top. > > This isn't always the case though. People have their systems setup to mail > in bizarre ways, and often run on many system with emails going to a central > place. I agree it could be cut down to a couple of lines though. One line is all I need: hobbes.rellim.com 204.17.205.2 Tue Apr 10 18:40:22 PDT 2001 > > 3. Summaries? This is useless. I want facts, not > > aggregates. Knowing that 5 files were changed is useless. > > I need to know WHICH 5 files > > and what was changed, in one glance. I often get good > > Okay, I can see this -- but the v1.3 report doesn't give you exactly what > you are looking for either, you have to wade through a list _what_ changed > before you get to the details of how it changed. Still no way to know HOW it changed and I usually do not care WHAT changed. If /bin/login changed AT ALL, I have a problem. If it changed and the date did not, then I have been hacked. "ls" tells me all I need to know in almost all cases. Often 20 files changed, but the simple "ls" report shows me they are all in a package that I recognize. No need to check the details. I only use the bottom, detail, part of the report to fine tune my policies. Even then the old bottom part takes less than half the space of the new detail report. > > 4. Then WAY too much details. I already get reports that are 100k in > > the OLD format. The new format is WAY to much stuff to wade through. > > It takes 20 lines to provide almost the same detail as the > > OLD report does in one line. Multiply by 1000 changed files and the > results are > > horrendous. Looking at 1 change to a screen is just not possible. > > Again, I can see your point. You only want the properties which changed to > be listed. Not exactly. Maybe at the bottom the changes would be nice. I know this is an option now. The point is I want an "ls" style report at the top. Like in 1.3 > > If some people like the new format then keep it, but a LOT of us > > have many years of experience with the old one and are having a hard > > time converting to Tripwire 2 because of it. > > I don't know that anyone has expressed a strong opinion outside of you. One, that is not true, because someone else brought this up first on this mailing list. Two, that is because of the long years that tripwire, inc. turned it's back on the open source community and refused to listen to anyone. A lot of us just gave up trying. I am just trying to see if you guys are ready to re-enter the real world. > I will certainly make a pass at cleaning up the report format, and it looks > like I can count on you to provide some feedback. Hehehehe, yes, that and more. Any ideas on how to find those blasted "## Internal Error" things, or am I going to have to get out the debugger? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 ge...@re... Tel:+1(541)382-8588 Fax: +1(541)382-8676 |
|
From: Ron F. <ro...@tr...> - 2001-04-11 17:31:41
|
> The main (& the HUGEST) bad changes in report was tat I > CAN'T know from it what it WAS & what it NOW. I _NEED_ this information for > all parameters set to be checked. Maybe I misunderstand you Olli, but here is an excerpt from a 2.3 report: Property: Expected Observed ------------- ----------- ----------- Object Type Regular File Regular File Device Number 769 769 Inode Number 104008 104008 Mode -rwxr-xr-x -rwxr-xr-x Num Links 1 1 UID 0 0 GID 0 0 * Size 1151 1316 * Modify Time Thu Feb 15 13:47:41 2001 Mon Apr 9 06:05:32 2001 Blocks 4 4 * CRC32 DSBqPk AwneSj * MD5 B9C6iM+h+k7koU+m6zwtpt D/jgBrXJwzYnwxmq9CJP1j It clearly shows what the properties were (Expected), and what they are now (observed), and marks the changed ones with an '*' to highlight them. Is this not what you are asking for above? > What da hell means /bin/ls has changed? What of MANY > parameters changed. & HOW them where changed. :? I've some scripts running from I am beginning to think you have your report level set at something below 3. You need to add to your config file: EMAILREPORTLEVEL = 4 and I think you will get a lot more information (too much according to some <cough><g>). > These new reports are USELESS. I decided to remove tripwire > because old one with fine reports has bugs with non-"C"-locale-based file > names & the new one is just a WASTE of CPU cicles & human reading time. With all due respect, that is really just plain silly. I mean, come on. You are going to compromise you system security policy because the reports are a little _too_ verbose? I really think if you explore the EMAILREPORTLEVEL values from 0 to 4 you will find one that you can live with until Gary and I come up with something better, and in the meantime at least your system(s) are more secure for having tripwire running on them. rjf& |
|
From: Olli A. <ol...@me...> - 2001-04-11 17:50:11
|
On Wed, 11 Apr 2001, Ron Forrester wrote: > > The main (& the HUGEST) bad changes in report was tat I > > CAN'T know from it what it WAS & what it NOW. I _NEED_ this information > > for all parameters set to be checked. > Maybe I misunderstand you Olli, but here is an excerpt from a 2.3 report: > Property: Expected Observed > ------------- ----------- ----------- > Object Type Regular File Regular File > Device Number 769 769 > Inode Number 104008 104008 > Mode -rwxr-xr-x -rwxr-xr-x > Num Links 1 1 > UID 0 0 > GID 0 0 > * Size 1151 1316 > * Modify Time Thu Feb 15 13:47:41 2001 Mon Apr 9 06:05:32 2001 > Blocks 4 4 > * CRC32 DSBqPk AwneSj > * MD5 B9C6iM+h+k7koU+m6zwtpt D/jgBrXJwzYnwxmq9CJP1j > It clearly shows what the properties were (Expected), and what they are now > (observed), > and marks the changed ones with an '*' to highlight them. Is this not what > you are asking for above? yep. The only thing left for this is not to say what has not changed. Probably with special variable from config? > > What da hell means /bin/ls has changed? What of MANY > > parameters changed. & HOW them where changed. :? I've some scripts running > from > I am beginning to think you have your report level set at something below 3. > You need > to add to your config file: > EMAILREPORTLEVEL = 4 If it is really the case I'll have to sorry for things I said... To check this I'll reinstall tripwire again. > and I think you will get a lot more information (too much according to some > <cough><g>). > > These new reports are USELESS. I decided to remove tripwire > > because old one with fine reports has bugs with non-"C"-locale-based file > > names & the new one is just a WASTE of CPU cicles & human reading time. > With all due respect, that is really just plain silly. I mean, come on. You > are going to compromise you system security policy because the reports are > a little _too_ verbose? If them where meaningfully verbose (at least saing all quoted above) I won't remove tripwire then. I meant what I said - without the subject of changes reading reports is wasting of time. I'll reinstall tripwire again & check what you said. If that's why I got so dumb reports - I'll say "I'm sorry for producing my stupid noise at the list". > I really think if you explore the EMAILREPORTLEVEL values from 0 to 4 you > will find one that you can live with until Gary and I come up with > something better, and in the meantime at least your system(s) are more > secure for having tripwire running on them. The system security doesn't rase if I install tripwire (& any other passive intrusion detection tool). It rases by, for example www.openwall.org kernel patches, libsafe preloading & strict login / group / passwprd / permissions / software_installation_policy & so on things. But monitoring the system for changes is really required thing, I agree. Without this I'm at risk lose the moment of intrusion. I'm not happy that I was unable to use new tripwire reports. Thank you, I'll install it again & look if my problem was in verbosity level. -- Bye.Olli MISiS Telecommunications phone: +7(095)955-0087 |
|
From: Gary E. M. <ge...@re...> - 2001-04-11 20:28:08
|
Yo Ron! On Wed, 11 Apr 2001, Ron Forrester wrote: > I really think if you explore the EMAILREPORTLEVEL values from 0 to 4 you > will find one > that you can live with until Gary and I come up with something better, and > in the meantime > at least your system(s) are more secure for having tripwire running on them. I think the frustration he has here is similar to one I initially had with the new tripwire. The problem we both had is that there is no obvious way to increase the verbosity when you do a simple run like this: tripwire -m c Is there? The only ways I found to get the expanded reports were to do the EMAILREPORT thing, or run a separate "twreport". So maybe one thing to do is to increase the default verbosity. One problem that should also be in a FAQ is how to just set a global emailto for the entire run. Putting it in every subsection is a pain. I think this was just added as a feature but should be made simpler. Maybe just a command line option? My main problem with the emailto is that the report is sent as a blank message with an attachment. This means I have to dowload and read the attachment separately. Is there really a point to this? Just put in in line. These may seem like simple things to you guys that have been using Ver 2 for a while, but they are major hurdles for newbies and upgraders. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 ge...@re... Tel:+1(541)382-8588 Fax: +1(541)382-8676 |
|
From: Ron F. <rj...@sk...> - 2001-04-11 21:14:03
|
On Wed, Apr 11, 2001 at 01:24:47PM -0700, Gary E. Miller wrote:
> with the new tripwire. The problem we both had is that there is no
> obvious way to increase the verbosity when you do a simple run
> like this:
> tripwire -m c
./tripwire --help --check:
.
.
.
-M --email-report
-t { 0|1|2|3|4 } --email-report-level { 0|1|2|3|4 }
So something like the following:
./tripwire --check --email-report --email-report-level 3
should do the trick. If not, there is a bug.
> One problem that should also be in a FAQ is how to just set a global
> emailto for the entire run. Putting it in every subsection is a
> pain. I think this was just added as a feature but should be made
> simpler. Maybe just a command line option?
Yes, the global email feature was just added. Adding the following:
GLOBALEMAIL = root,rj...@th...
to you config file, for instance, sends an email report to the two
recipients listed, after every integrity check.
There is a really good reason we don't just add command line options
arbitrarily, and prefer the config file route. There are known
exploits involved in spoofing command lines, etc. So we tend to use
the signed config files to help avoid these types of problems.
> My main problem with the emailto is that the report is sent as a
> blank message with an attachment. This means I have to dowload and
> read the attachment separately. Is there really a point to this?
> Just put in in line.
Hmmm. I get them inline. Are you using a MAILMETHOD of SMTP, or
SENDMAIL?
If you can, use SMTP, in which case you will also need the SMTPHOST
variable to point to your mail server.
If you still have problems with this, let me know.
> These may seem like simple things to you guys that have been using
> Ver 2 for a while, but they are major hurdles for newbies and
> upgraders.
A FAQ would be nice. In the meantime, have you read the PDF doc's on
sourceforge? They are quite good:
http://prdownloads.sourceforge.net/tripwire/tripwire-2.3.0-docs-pdf.tar.gz
rjf&
|
|
From: Gary E. M. <ge...@re...> - 2001-04-11 23:56:48
|
Yo Ron! On Wed, 11 Apr 2001, Ron Forrester wrote: > On Wed, Apr 11, 2001 at 01:24:47PM -0700, Gary E. Miller wrote: > > with the new tripwire. The problem we both had is that there is no > > obvious way to increase the verbosity when you do a simple run > > like this: > > tripwire -m c > So something like the following: > > ./tripwire --check --email-report --email-report-level 3 You misunderstand. I do not want to increase the verbosity of the email report, I want to increase the verbosity of the report on stdout. If I have just been hacked I probably turned off SMTP and maybe even TCP/IP. I just need a local report, fast. > > My main problem with the emailto is that the report is sent as a > > blank message with an attachment. This means I have to dowload and > > read the attachment separately. Is there really a point to this? > > Just put in in line. > > Hmmm. I get them inline. Are you using a MAILMETHOD of SMTP, or > SENDMAIL? The default, SENDMAIL. I tried changing twcfg.txt and I am back to this dreaded place: dogbert:/etc/tripwire# twadmin -m F -S site.key twcfg.txt Please enter your site passphrase: Incorrect site passphrase. Please enter your site passphrase: ### Internal Error. ### Terminate Handler called. ### Exiting... > If you can, use SMTP, in which case you will also need the SMTPHOST > variable to point to your mail server. I always run local sendmail, so that just points back to localhost. If I ever get past "### Internal Error." I will try it. > If you still have problems with this, let me know. > A FAQ would be nice. In the meantime, have you read the PDF doc's on > sourceforge? They are quite good: > > http://prdownloads.sourceforge.net/tripwire/tripwire-2.3.0-docs-pdf.tar.gz Oh, yeah, I love reading PDFs on Linux routers that have no X. :-) If PDFs are not good enough for the IETF and RFCs then they are not good enough for me. The lack of a portable way to search or edit PDF files makes them a huge pain. Finding the3 right reader that reads the right version of the current PDF is also a huge pain. Give me ASCII, man pages or html. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 ge...@re... Tel:+1(541)382-8588 Fax: +1(541)382-8676 |
|
From: Ron F. <rj...@sk...> - 2001-04-12 01:06:19
|
On Wed, Apr 11, 2001 at 04:56:40PM -0700, Gary E. Miller wrote: > You misunderstand. I do not want to increase the verbosity of the > email report, I want to increase the verbosity of the report on > stdout. If I have just been hacked I probably turned off SMTP and > maybe even TCP/IP. I just need a local report, fast. Ah, my bad. Yeah, I think the only way to do that is to modify the REPORTLEVEL variable in the config file, setting it to 4 for max verbosity. > I tried changing twcfg.txt and I am back to this dreaded place: > > dogbert:/etc/tripwire# twadmin -m F -S site.key twcfg.txt > Please enter your site passphrase: > Incorrect site passphrase. > Please enter your site passphrase: > ### Internal Error. > ### Terminate Handler called. > ### Exiting... Whoa. Would you mind sending me your config file? You are using the very latest, 2.3.1-2, right? > Oh, yeah, I love reading PDFs on Linux routers that have no X. :-) Yeah, well, PDF isn't the greatest thing in the world, but you must have access to some system you can print them out on...:) I will see what I can do about a more palatable format. Until then you might checkout: http://atrey.karlin.mff.cuni.cz/~clock/twibright/pdf2html/ rjf& |
|
From: Gary E. M. <ge...@re...> - 2001-04-10 21:27:40
|
Yo Ron! I will forward a copy of a real tripwire 1.3 report next. The first bug I mentioned below has been in the bugbase since 28 Nov 00 as bug 223756. The second was reported in the open discussion list on 4 Apr 01 as "Install Failure". I have added it to the bugbase as bug 415248. I think in it I mention how much I loathe c++ exceptions.... No response to either. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 ge...@re... Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Tue, 10 Apr 2001, Ron Forrester wrote: > Hey Gary, do me a favor and plop the bug you show below into the tripwire > bug database on tripwire. > > Also, when you guys say "Old report", you mean v1.3 reports? I started here > long after v1.3, so if one of you can forward me an example 1.3 report, I > will see what I can do with the current report format. |
|
From: Gary E. M. <ge...@re...> - 2001-04-10 21:29:42
|
Yo Ron! On Tue, 10 Apr 2001, Ron Forrester wrote: > Also, when you guys say "Old report", you mean v1.3 reports? I started here > long after v1.3, so if one of you can forward me an example 1.3 report, I > will see what I can do with the current report format. Here is a tripwire 1.3 report. This is the way it SHOULD be done. The tripwire 2 report is almost all fat and very little meat. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 ge...@re... Tel:+1(541)382-8588 Fax: +1(541)382-8676 Tripwire(tm) Intrusion Detection Software v1.3 This release is for single CPU, single-site, end-use purposes. For commercial applications or product information, please visit the Visual Computing Corporation web site at http://www.visualcomputing.com/tripwire, or call us at (503) 223-0280. Tripwire(tm) Copyright 1992-98 by the Purdue Research Foundation of Purdue University, and distributed by Visual Computing Corporation under exclusive license arrangements. ### Phase 1: Reading configuration file ### Phase 2: Generating file list ### Phase 3: Creating file information database ### Phase 4: Searching for inconsistencies ### ### Total files scanned: 54604 ### Files added: 1 ### Files deleted: 6 ### Files changed: 18 ### ### Total file violations: 25 ### added: -rw------- root 7233536 Apr 10 14:15:42 2001 /usr/local/adm/tcheck/twzhyzffv deleted: -rw------- root 0 Mar 23 10:08:37 2001 /usr/local/adm/tcheck/twz0o6jgV deleted: -rw------- root 4984832 Mar 23 10:09:54 2001 /usr/local/adm/tcheck/core deleted: -rw------- root 0 Mar 23 10:08:58 2001 /usr/local/adm/tcheck/twz8suNIv deleted: -rw------- root 0 Mar 23 10:09:21 2001 /usr/local/adm/tcheck/twzcQpd9c deleted: -rw------- root 0 Mar 23 10:09:54 2001 /usr/local/adm/tcheck/twzVQ9sAE deleted: -rw------- root 741376 Mar 23 10:11:58 2001 /usr/local/adm/tcheck/twz5plgO2 changed: -rw-r--r-- root 14029 Apr 10 04:02:01 2001 /usr/lib/perl5/man/whatis changed: -rw-r--r-- root 525385 Apr 10 04:02:01 2001 /usr/man/whatis changed: -rw-r--r-- root 84823 Apr 10 04:02:01 2001 /usr/X11R6/man/whatis changed: -rw-r--r-- root 295 Apr 10 04:02:00 2001 /var/lib/logrotate.status changed: crw--w---- michael 0 May 5 13:32:27 1998 /dev/vcs1 changed: crw--w---- michael 0 May 5 13:32:27 1998 /dev/vcsa1 changed: -rw-r--r-- root 697 Apr 3 14:52:07 2001 /etc/group changed: -rw-r--r-- root 1826 Apr 5 21:52:59 2001 /etc/hosts.allow changed: -rw-r--r-- root 2624 Apr 3 14:51:14 2001 /etc/passwd changed: -rw------- root 691 Mar 29 10:59:02 2001 /etc/group- changed: -rw-r--r-- root 2624 Apr 3 14:50:42 2001 /etc/passwd- changed: -r-------- root 2796 Apr 3 14:49:35 2001 /etc/shadow- changed: -rw------- root 697 Mar 29 10:57:20 2001 /etc/gshadow- changed: -r-------- root 2841 Apr 3 14:51:14 2001 /etc/shadow changed: -r-------- root 707 Apr 3 14:49:36 2001 /etc/gshadow changed: -rw-r--r-- root 7 Apr 10 13:22:07 2001 /etc/ntp/drift changed: -rw-r--r-- root 1236 Apr 10 04:02:01 2001 /usr/local/man/whatis changed: -rw------- root 8190023 Mar 23 10:26:48 2001 /usr/local/adm/tcheck/databases/tw.db_transfer.allegrix.net ### Phase 5: Generating observed/expected pairs for changed files ### ### Attr Observed (what it is) Expected (what it should be) ### =========== ============================= ============================= /usr/lib/perl5/man/whatis st_mtime: Tue Apr 10 04:02:01 2001 Fri Mar 23 04:02:01 2001 st_ctime: Tue Apr 10 04:02:01 2001 Fri Mar 23 04:02:01 2001 /usr/man/whatis st_mtime: Tue Apr 10 04:02:01 2001 Fri Mar 23 04:02:00 2001 st_ctime: Tue Apr 10 04:02:01 2001 Fri Mar 23 04:02:00 2001 /usr/X11R6/man/whatis st_mtime: Tue Apr 10 04:02:01 2001 Fri Mar 23 04:02:01 2001 st_ctime: Tue Apr 10 04:02:01 2001 Fri Mar 23 04:02:01 2001 /var/lib/logrotate.status st_size: 295 302 st_mtime: Tue Apr 10 04:02:00 2001 Fri Mar 23 04:02:00 2001 st_ctime: Tue Apr 10 04:02:00 2001 Fri Mar 23 04:02:00 2001 md5 (sig1): 0xjDTN5Rxa8sXzpkMG6XhU 3pN9GhiY97feUvQXFp8T4W snefru (sig2): 0VzvqV2ZkvYdDWnh80ABPg 0Hrt.055g:.Dt6RHelpihX /dev/vcs1 st_uid: 500 528 /dev/vcsa1 st_uid: 500 528 /etc/group st_size: 697 686 st_mtime: Tue Apr 3 14:52:07 2001 Mon Mar 12 10:37:03 2001 st_ctime: Tue Apr 3 14:52:07 2001 Mon Mar 12 10:37:03 2001 md5 (sig1): 27KerQWEpFJta.OFna7DGZ 3mUEQ8hTqkS9QCCvox2jUd snefru (sig2): 3JIUZduXIFZbMEsRGRwSDS 1mOsXoAW4lv:qGDSOT7q.4 /etc/hosts.allow st_size: 1826 1755 st_mtime: Thu Apr 5 21:52:59 2001 Mon Mar 12 10:39:42 2001 st_ctime: Thu Apr 5 21:52:59 2001 Mon Mar 12 10:39:42 2001 md5 (sig1): 2RptjC2kXO2rxF8afczwDt 39cDXrQciNd0MMEvj8656c snefru (sig2): 1n8:8O34eJVv:tatCrme26 1ighVLOiv:wY8GZi7m.1OE /etc/passwd st_ino: 321613 321616 /etc/group- st_size: 691 681 st_mtime: Thu Mar 29 10:59:02 2001 Tue Mar 6 14:47:05 2001 st_ctime: Tue Apr 3 14:49:36 2001 Mon Mar 12 10:34:47 2001 md5 (sig1): 2fQSoP:5w.ct0BQ7O44vZ6 3l4HuP0OBMGyBF42TH9vN7 snefru (sig2): 0qkLCYnHo0ZFxiy8gDvG01 1mJaV9tUi5WTpo2HY3aPOY /etc/passwd- st_size: 2624 2488 st_mtime: Tue Apr 3 14:50:42 2001 Mon Mar 12 10:36:26 2001 st_ctime: Tue Apr 3 14:51:14 2001 Thu Mar 22 23:58:05 2001 md5 (sig1): 1zLGAEqWoRW5VNnMQS659W 1ZxD4xY5.KMNtOWysDnw9F snefru (sig2): 0Miz:0gDbygJJfdgMbOdCt 2K9cKa5LO4kfHMy2dPnC9U /etc/shadow- st_size: 2796 2696 st_mtime: Tue Apr 3 14:49:35 2001 Mon Mar 12 10:36:27 2001 st_ctime: Tue Apr 3 14:51:14 2001 Thu Mar 22 23:58:06 2001 md5 (sig1): 0SzEo7WExMtbIVV24QIakd 10Jpn3gWnakAumveGlN.8H snefru (sig2): 2upF4RZPSoSlBqyD:dK9il 3d943r56qOr4s8bKOTWlh8 /etc/gshadow- st_size: 697 679 st_mtime: Thu Mar 29 10:57:20 2001 Tue Mar 6 14:47:05 2001 st_ctime: Tue Apr 3 14:49:36 2001 Mon Mar 12 10:34:47 2001 md5 (sig1): 3XvU3RwrYhHxxYI3JK1fbj 3eFW:86SVJmGAs7A30krDp snefru (sig2): 39t238ZFrh94q8hAKfTZT1 2fVAciA4eGRlLyoDvLzbCi /etc/shadow st_ino: 321614 321613 st_size: 2841 2696 st_mtime: Tue Apr 3 14:51:14 2001 Thu Mar 22 23:58:06 2001 st_ctime: Tue Apr 3 14:51:14 2001 Thu Mar 22 23:58:06 2001 md5 (sig1): 2UJI7BQnU5cEPsAaNZHPWV 2L.IqZzCV1z2.CtGtnHPcg snefru (sig2): 0yXHciYdHsYLkgxP6tI9pw 1Dydgjhg25I.lpo2EYb6Gm /etc/gshadow st_size: 707 688 st_mtime: Tue Apr 3 14:49:36 2001 Mon Mar 12 10:34:47 2001 st_ctime: Tue Apr 3 14:49:36 2001 Mon Mar 12 10:34:47 2001 md5 (sig1): 1nexrkzuF8bkaaVmxw8BEY 2BNITvUv6iiVt:bULWAeGq snefru (sig2): 0VAZ7E1EiNbDWB9JRNM7BM 0toAxNQQ1V0bjj.Epj.Csy /etc/ntp/drift st_mtime: Tue Apr 10 13:22:07 2001 Fri Mar 23 10:21:34 2001 st_ctime: Tue Apr 10 13:22:07 2001 Fri Mar 23 10:21:34 2001 md5 (sig1): 0C4T:n.Up7EvsvzlV4EXrJ 1moNuaLOub.lElXnj8DFLR snefru (sig2): 2Z17DKvzIqtt5h0mJIXEjc 3Pf7Lo2:DuJgyKbPr9VROi /usr/local/man/whatis st_mtime: Tue Apr 10 04:02:01 2001 Fri Mar 23 04:02:00 2001 st_ctime: Tue Apr 10 04:02:01 2001 Fri Mar 23 04:02:00 2001 /usr/local/adm/tcheck/databases/tw.db_transfer.allegrix.net st_size: 8190023 8142848 st_mtime: Fri Mar 23 10:26:48 2001 Fri Mar 23 10:26:34 2001 st_ctime: Fri Mar 23 10:26:48 2001 Fri Mar 23 10:26:34 2001 md5 (sig1): 0tuztgBmifd4T7k3AhqGTe 12Oh0msOUud5MAgnTmbRNS snefru (sig2): 0aodN9ji6svoUdxPTwkpDn 2vOEFYauc2A:z:G47kUpIA |
Thanks for helping keep SourceForge clean.
X