Select (or exclude) AUDIT entries by IP Address?

[operagost]

I use VMS's auditing facility to log breakin attempts.  However, our network scanner triggers false positives. How can I use the ANA/AUDIT command to exclude the IP address of the network scanner from its output?  I perused the criteria available for  the IGNORE qualifier, and none of them seem to be the IP address of the remote host.  Searching the output for the IP address is not really feasible, as I'm currently only able to handle BRIEF output and it doesn't include the IP address either.

[Richard Brodie_1]

It depends exactly what your TCPIP stack passes to the auditing system. On mine it logs the 32-bit big-endian IP address as the DECNET id, and /ignore=remote=id=3483948345 works fine.

[operagost]

That would be handy... but I use HP TCPIP, so I'll bet it's not supported!

[John Gillings]

Although ANALYZE is DECnet oriented, you should find most of the network fields populated with something sensible in an IP environment.

/IGNORE and /SELECT for ANALYZE/AUDIT or ACCOUNTING can be useful if you can find the right combination, but that's not always easy. I find it's sometimes easier to use brute force. use /FULL/OUTPUT=file to convert into text, then a short DCL or Perl script to extract or exclude the stuff you want.

Before going down that path, start with a /FULL listing of the smallest subset that you've been able to find. You may find there are things you can key on. For example,  Here's a sample breakin audit

Security alarm (SECURITY) and security audit (SECURITY) on NODEA, system id: 3176
Auditable event:          Network breakin detection
Event time:               16-FEB-2012 10:50:36.86
PID:                      21427D7D
Process name:             TCPIP$FTPC00036
Username:                 SYSTEM
Password:                 <invalid>
Remote node id:           2130706433
Remote node fullname:     LOCALHOST
Remote username:          FTP_7F000001
Status:                   %LOGIN-F-INVPWD, invalid password

 As Richard suggested, the "Remote node id" is a decimal encoded IP address. Check for a pattern in your records. Also look at things like Status, remote username.

[operagost]

In the version of TCPIP we have, you can actually see the TCP/IP address in the /FULL output; that's not the problem.  The problem is that I have a DCL that runs every two minutes, dumping the last two minutes of the audit logs using BRIEF, and BRIEF doesn't contain the IP address.  I have to use BRIEF because I have to send the dump to a logging device via the syslog service, and it is impossible to send the output from an entire FULL entry in one message so that all that data is kept together in one entry.  If I was able to exclude any incidents involving the IP address of the scanner, they wouldn't get to the logger in the first place, it wouldn't see the "breakin", and it wouldn't page me at 5:30 AM for no reason.

[Bill Hall]

It sounds like the real problem is that your "network scanner" is trying to "breakin" to your system.  Why is your "network scanner" trying to "breakin"?  Why not fix your "network scanner" so that it can login successfully?

[abrsvc]

An alternative here would be to "pre-process" the output from the /FULL and send along the processed info to the syslog service.

Dan

[operagost]

The point of a network scanner is to find vulnerabilities.  I'm not sure why or how I would let it log in.  It's basically a script kiddie you run on yourself.

I can't "preprocess" the output from /FULL because the ANALYZE/AUDIT command does not maintain context.  There's no way I can reread the last entry.  I'm going to have to ask HP how to do this.

[abrsvc]

Perhaps I wasn't clear.

Since you are runing a DCL procedure to generate the /BRIEF listing. Modify the procedure to send the output from the /FULL to a file and process that file. Send the "processed" info to the syslog application. Delete the file or re-use it later.

Dan

[John Gillings]

Ah, so what you really want is something to send audit information to Syslog? Rather than using ANALYZE/AUDIT to scrape the journal, what about using an AUDIT Listener to catch the messages as they occur and reformat them into something suitable for Syslog. You can then filter them any way you want.

See the Guide to OpenVMS System Security for details of audit listeners. It's entirely possible that such a beast already exists. Try Google.

Looking back at your current approach

> ANALYZE/AUDIT command does not maintain context

True, but you can maintain context of the last time you dumped records and use that with /SINCE to extract just the new stuff.

>it wouldn't page me at 5:30 AM for no reason.

All that said, I wouldn't have thought a breakin attempt on an OpenVMS system was worth paging. Sure you want to know about it, but it's not something that needs immediate attention. More than likely it's a legitimate user with fat fingers or a memory lapse. Even if it is a real attack, the chances of anyone actually getting in after the system has decided it's a breakin attempt are vanishingly small.  Crank up LGI_HID_TIM to make them even smaller.

[operagost]

I would tend to agree with you, John, but PCI DSS auditors don't.

I considered the AUDIT listener, but when I realized it could cause a system hang I discarded that idea immediately.

[Doug Phillips]

---

@Richard Brodie wrote:

it depends exactly what your TCPIP stack passes to the auditing system. On mine it logs the 32-bit big-endian IP address as the DECNET id, and /ignore=remote=id=3483948345 works fine.

@operagost wrote:

That would be handy... but I use HP TCPIP, so I'll bet it's not supported!

---

Have you tried that? On every version of HP TCPIP that I can access each breakin from a particular source is uniquely identified and can be either /ignore(d) or /select(ed). It would be helpful if you posted the output from $tcpip show version

AFA your network scanner, I guess we'll presume that it logs its activity and reports a successful breakin, but if it were my system I'd also want to select those (if there are any) from the audit.

[John Gillings]

> but when I realized it could cause a system hang I discarded that idea immediately.

Lots of things can cause system hangs, but that doesn't stop people using them! Indeed, the audit server itself is effectively just another audit listener. If it stops, so does the system. The warnings in the security manual aren't supposed to scare you away, just to make sure you understand the implications and take appropriate care in using the feature.

If you write an audit listener process carefully you can minimise the risk. One fairly simple approach is to use a "deadman lock". Run two (or even three or more) processes simultaneously. Have the process attempt to get the deadman lock exclusively. When granted, start a new copy of self. That way there's always one or more processes waiting on the lock. If the currently active process goes away for any reason, the lock is dropped and another process takes over immediately (and starts another copy). About the only problem with this design is it's difficult to kill when you want to!

Create the listener mailbox with a healthy allocation and use an AST threaded design. The reader AST just shovels messages from the mailbox into a large internal buffer, processed by another thread, or the main line.