| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 438.1 | :-} | PASTIS::MONAHAN | | Thu Apr 02 1987 05:42 | 10 |
| No. It is the other way round. If you can determine for certain
that the attempt on you system *really* comes from a Corporate Security
"PROBE" then I can supply you with a utility that sends them back
your passwords. This will enable them to check your system more
thoroughly for possible holes than they would otherwise be able to do.
But unless you are *that* sure you should treat the attempt exactly
the same as you treat any other hacker attempt. You surely would
not want to pretend that you are less (or more) secure than you
really are?
|
| 438.2 | Oh Yeah? | ACE::BREWER | John Brewer Component Engr. @ABO | Thu Apr 02 1987 23:00 | 12 |
|
...Its not the other way around. After months of watching login
failures (most of them benign... and tracked thru ACCOUNTING), one
can realize a PROBE. Especially when they mail you a message...
but then mabye youre right... It aint too tough to phony up a
nodename::username.
Just because you're paranoid doesn't mean they're not out to
get you!
All in fun,
-John
|
| 438.3 | Some idle thoughts | WKRP::LENNIG | Dave, SWS, @CYO Cincinnati | Thu Apr 02 1987 23:40 | 30 |
| I was daydreaing about some possible 'responses'. I'm not sure how/if
any of the following will work (but it's fun thinking about them).
1) Define a proxy for the source into a special account with a
login.com containing
$OPEN LINK SYS$NET
$WAIT 99
This will catch incoming links to non-declared objects as long as
explicit access control isn't used.
2) Turn off REMACP and define objects 23 and 42 to be your
own procedure/program.
This will catch incoming attempts via SET HOST
3) For FAL access, define a special account with SYS$REM_NODE as
it's login device. Thus, access to NODE::FILE becomes
NODE::SOURCE::FILE (Interesting side effect - the netserver.log
file ends up on the source node).
4) Define a SYSALF.DAT file listing the RTAn devices, with the username
of a special account with no password. The login.com for this
special account does a $SET HOST 'F$LOGICAL("SYS$REM_NODE")
5) Write a special LOGINOUT.EXE that get's the values for SYS$INPUT,
SYS$OUTPUT, SYS$ERROR [which is how NETACP passes username /
password / sys$net value, etc] and either does another $creprc
with the same values and exits if not the probe, or various
interesting things if it is.
Dave
|
| 438.4 | don't send ANYONE your passwords | VIDEO::OSMAN | type video::user$7:[osman]eric.six | Fri Apr 03 1987 10:24 | 4 |
| Send them back your passwords? NEVER! Don't do it. What's this all
about, anyway?
/Eric
|
| 438.5 | "are we not hackers" | ACE::BREWER | John Brewer Component Engr. @ABO | Fri Apr 03 1987 22:03 | 9 |
|
Re:-1
Agreed. NEVER SEND PASSWORDS!
Whats it all about? Audpack and some harmless fun. (this IS
the hackers' notesfile is it not? :-) )
-John
|
| 438.6 | | PASTIS::MONAHAN | | Sat Apr 04 1987 05:41 | 11 |
| Right! I am *very* concerned about security, and I would not
have suggested shipping passwords around in any notes file where
anyone might take it seriously.
But since I wrote Audpack, it was just too difficult to resist
replying to .0. (I do have a utility that does a reasonably good
job of guessing passwords, but it does not mail them anywhere -
in fact, it only reports the account names for which it could guess
the passwords, not the passwords themselves).
Dave
|
| 438.7 | probe targets publishable? | ACE::BREWER | John Brewer Component Engr. @ABO | Tue Apr 07 1987 15:31 | 11 |
|
Well, we have been Probed, and I have scoured the Accounting
files... does anyone want the accounts probed to be posted here?
Will the moderator mind? Its a good checklist anyway, to ensure
that obvious holes are covered.
What say?
I'll mail 'em to you, or post 'em here.
-John
|
| 438.8 | {RE .7} - Be My Guest! | VAXUUM::DYER | I Park at Mrs. Nelson's Candy House | Tue Apr 07 1987 15:37 | 2 |
| I don't mind if they're published.
<_Jym_>
|
| 438.9 | Sure, dump them in here! | PHENIX::SMITH | William P.N. (WOOKIE::) Smith | Tue Apr 07 1987 16:34 | 2 |
|
|
| 438.10 | From THE PROBER! | TELCOM::MCVAY | Pete McVay, VRO Telecom | Tue Apr 07 1987 17:08 | 3 |
| Yup, I'd like to see them too!
I'm thinking of increasing the list, anyway.
|
| 438.11 | Now we're all curious! | FROST::HARRIMAN | Dialogue...Duologue | Tue Apr 07 1987 17:50 | 1 |
|
|
| 438.12 | -Here's the PROBE- | ACE::BREWER | John Brewer Component Engr. @ABO | Tue Apr 07 1987 22:15 | 48 |
| Date / Time Type Subtype Username ID Source Status
--------------------------------------------------------------------------------
4-APR-1987 01:15:52 LOGFAIL ALLIN1 00001FB3 BYU 00D380F4
4-APR-1987 01:57:02 LOGFAIL BACKUP 000022B7 BYU 00D380F4
4-APR-1987 02:35:39 LOGFAIL DECMAILMGR 0000223C BYU 00D380F4
4-APR-1987 03:15:27 LOGFAIL DEMO 000024C3 BYU 00D380FC
4-APR-1987 03:54:42 LOGFAIL FIELD 00002383 BYU 00D380F4
4-APR-1987 04:33:24 LOGFAIL GAMES 00002412 BYU 00D380F4
4-APR-1987 05:09:56 LOGFAIL GUEST 0000221C BYU 00D380F4
4-APR-1987 05:44:53 LOGFAIL MRGATE 000022A0 BYU 00D380F4
4-APR-1987 06:19:45 LOGFAIL MRMANAGER 000020A6 BYU 00D380F4
4-APR-1987 07:02:29 LOGFAIL MTSMGR 000020AE BYU 00D380F4
4-APR-1987 07:46:22 LOGFAIL NETWORK 00002337 BYU 00D380F4
4-APR-1987 08:29:37 LOGFAIL NOTES$SERVER 00002540 BYU 00D380FC
4-APR-1987 09:08:30 LOGFAIL OPERATOR 00002488 BYU 00D380F4
4-APR-1987 09:46:28 LOGFAIL SYSTEM 00002297 BYU 00D380FC
4-APR-1987 10:28:30 LOGFAIL SYSTEST 000022A8 BYU 00D380FC
4-APR-1987 11:06:58 LOGFAIL USER 000021BD BYU 00D380F4
4-APR-1987 11:45:19 LOGFAIL USERP 00002391 BYU 00D380F4
4-APR-1987 12:21:50 LOGFAIL A1 00002317 BYU 00D380F4
4-APR-1987 13:00:39 LOGFAIL ALLIN1 00002328 BYU 00D380F4
4-APR-1987 13:58:19 LOGFAIL ALLIN1 00002588 BYU 00D380F4
4-APR-1987 14:44:56 LOGFAIL BACKUP 0000241F BYU 00D380F4
4-APR-1987 15:31:19 LOGFAIL BACKUP 000020AB BYU 00D380F4
4-APR-1987 16:10:39 LOGFAIL DECMAILMGR 00000E3A BYU 00D380F4
4-APR-1987 17:31:16 LOGFAIL DECMAILOPS 000000A5 BYU 00D380F4
4-APR-1987 18:08:49 LOGFAIL DEMO 000000AA BYU 00D380FC
4-APR-1987 19:01:19 LOGFAIL FIELD 000000B3 BYU 00D380F4
4-APR-1987 19:41:38 LOGFAIL FIELD 000000BD BYU 00D380F4
4-APR-1987 20:22:21 LOGFAIL FIELD 000000C4 BYU 00D380F4
4-APR-1987 21:02:09 LOGFAIL FIELD 0000010B BYU 00D380F4
4-APR-1987 21:55:18 LOGFAIL GAMES 00000116 BYU 00D380F4
4-APR-1987 22:41:41 LOGFAIL GUEST 0000011B BYU 00D380F4
4-APR-1987 23:32:32 LOGFAIL MRGATE 00000123 BYU 00D380F4
5-APR-1987 00:32:21 LOGFAIL MRMANAGER 0000012B BYU 00D380F4
5-APR-1987 01:08:11 LOGFAIL MRMANAGER 00000130 BYU 00D380F4
5-APR-1987 01:55:12 LOGFAIL MTSMGR 00000137 BYU 00D380F4
5-APR-1987 02:29:29 LOGFAIL NETWORK 0000013A BYU 00D380F4
5-APR-1987 03:03:51 LOGFAIL NOTES$SERVER 0000013E BYU 00D380FC
5-APR-1987 04:10:04 LOGFAIL OPERATOR 00000183 BYU 00D380F4
5-APR-1987 04:46:58 LOGFAIL OPERATOR 0000018B BYU 00D380F4
5-APR-1987 05:22:25 LOGFAIL SYSTEM 00000198 BYU 00D380FC
5-APR-1987 05:58:07 LOGFAIL SYSTEM 0000019D BYU 00D380FC
5-APR-1987 06:35:39 LOGFAIL SYSTEM 000001A3 BYU 00D380FC
5-APR-1987 07:15:46 LOGFAIL SYSTEST 000001AB BYU 00D380FC
5-APR-1987 07:59:05 LOGFAIL SYSTEST 000001B1 BYU 00D380FC
5-APR-1987 08:35:11 LOGFAIL TEST 000001B6 BYU 00D380F4
5-APR-1987 09:16:31 LOGFAIL USER 000001BB BYU 00D380F4
|
| 438.13 | | PASTIS::MONAHAN | | Wed Apr 08 1987 17:18 | 17 |
| Would it be a good thing for Pete (and Sally in Geneva) to publish
here the actual databases they use and request additions?
PRO:
1) It would serve as a checklist of accounts and passwords to avoid
(if only so you don't get shouted at :-)
2) It would ensure that our less security-aware brethren are getting
an even more thorough test.
CON:
1) System managers could make trivial changes to passwords, so that
while no more secure, they would not be picked up.
2) It would also act as a checklist for the nasty sort of hacker.
|
| 438.14 | Is there a PROBE checklist ? | 22609::MIKEWARREN | Mike Warren SWS Malaysia | Wed Apr 15 1987 23:25 | 14 |
| My system was probed not too long ago, and i'm just curious as to
what tests are actually performed in a probe.
I presume the prober trys logging into different accounts, or by
execution of a program that trys out certain passwords (as Dave
mentioned) .. probably checking to see if object TASK is defined
in the net database to try run task-to-task pgms ... but what
else ?
Is there a check list of things one runs thru ??
Regards, Mike.
|
| 438.15 | chain reaction | JON::MORONEY | Don't cloud the issue with the facts! | Sat Apr 18 1987 13:51 | 19 |
| re .3:
> I was daydreaing about some possible 'responses'. I'm not sure how/if
> any of the following will work (but it's fun thinking about them).
> 3) For FAL access, define a special account with SYS$REM_NODE as
> it's login device. Thus, access to NODE::FILE becomes
> NODE::SOURCE::FILE (Interesting side effect - the netserver.log
> file ends up on the source node).
This could get interesting if 2 nodes did this, and one of them (node A) did a
directory of the other (node B). First, the FAL created on node B would create
a NETSERVER.LOG which would be created on node A which would create a FAL on
node A whose NETSERVER.LOG would be on node B, which... until something broke.
This is a non-fatal error, so we'd proceed with the directory lookup. This
will create a link back to A, which would create a link back to B, and so on.
(Don't forget more of those NETSERVER.LOGs, too...)
-Mike
|