Operating System - OpenVMS
1751975 Members
4964 Online
108784 Solutions
New Discussion

Re: Select (or exclude) AUDIT entries by IP Address?

 
operagost
Occasional Advisor

Re: Select (or exclude) AUDIT entries by IP Address?

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
Trusted Contributor

Re: Select (or exclude) AUDIT entries by IP Address?


@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
Honored Contributor

Re: Select (or exclude) AUDIT entries by IP Address?

> 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. 

A crucible of informative mistakes