Hi Everyone,
Anyone have idea about encryption on raw data on decoder level so none can alter the raw logs,
Basically we are getting raw logs stored in decoder /packtdb in some file format but that files can be open in notepad++ or any tool and easily we can delete the data or we can also delete the stored files from that decoder directory.
is there any way so we can apply encryption on the raw logs or can restrict to delete the files from decoder directory?
So, the concern that I've seen from several auditors is that if you are root, you could modify the contents of the file and hide your - or a collaborator's - tracks. It's a proprietary format, but surely overwriting "Fred" with "Bill" in the raw file would be undetectable (I don't have a crash and burn dev system to try it on!) Yeah, your meta wouldn't match, but then that's going to invalidate your entire case because the integrity of the system is questionable at that point.
We log into our decoders regularly to check file importing, log messages, test network connectivity (most days will see an SSH login from one of my team to one of the log decoders). Sometimes it's just a lot quicker from the command line!
If you have log archiver appliances, this is where you should be worrying about protection from tampering with the logs. The hashing function provided there means simple tampering would be evident. Separation of duties is also important: if you can access the SA back end, you shouldn't be able to modify anything else in the estate.
Well, I agree with the auditor. If you have root access, you can mess with the system. I disagree with the premise that everyone on your team should have root and regularly log in. That machine should be locked down tight. Command line access does not require SSH access to the box. We build NwConsole for Mac, Windows and Linux and it's perfectly capable of being run from your desktop. None of your use cases require access to the LD machine.
Also, you can hash the files on Decoders and Concentrators too. It isn't only offered on Archiver.
Cheers,
Scott
When I say command line access I mean ssh access to the UNIX prompt.
There's an awful lot of stuff you need to be root to do - e.g., tail the log files, check what files are in the upload director, configure new custom typespecs. And then there's all the things that are just so much slower via the GUI like restarting services.
This is the first time I've seen mention of the ability to run NwConsole from anywhere other than an SA appliance - do you have a pointer to where we can obtain that as a customer?
Right. I'm saying you do not need to SSH on a Core services machine to do those things. Therefore it should be locked down. I have no idea what upload director is, but that doesn't sound like something normally running on a Core services appliance. I assume that's something that's part of SA UI.
If NwConsole is not up on SCOL for Mac and Windows, I can have someone put a copy of 10.4.1 up there.
Tailing the logs is part of SA. You can also do it with NwConsole.
login <hostname:port[:ssl]> <username> <password>
mon /logs/tasks/monitor
They will be displayed in console as they are written. If you want to view/search historical logs, use the "dlogs" command. Restarting a core service via NwConsole is also simple: send /sys shutdown reason="Cause I want to"
Editing a custom index file should also be done via SA - Administration | Services | Files tab. It's actually possible to do it with NwConsole too, though obviously SA is far easier.
NwConsole - view the index file:
send /sys fileEdit op=get filename=index-concentrator-custom.xml
Update the file from one stored on the client machine:
send /sys fileEdit op=put filename=index-concentrator-custom.xml file-data=<path of index file to upload>
HTH,
Scott
Hi,
yes, option 1 - not providing root access, is the most effective and manageable.
Option 2. e.g. if NwConsole is too complicated, is to assign root, via sudo, just for specified commands / files, so your guys will be able to e.g. restart services or tail system logs.
Option 3, if your auditors will provide appropriate resources :-), is to implement additional "root monitoring" solutions, where e.g. you will log (save) whatever they (root) do (every keystroke). Such tools exists, but will require unix experts to implement in robust manner, incl. storage, infrastructure (logs to be send online out of source server), access to such logs, etc. As being already said, such segregation of duties, will also require other (independent) staff, spending time with checking such logs. My experience is, when we have been asked for that, prepared proof-of-concept incl. resource estimation (staff especially), and provided access to such logs to auditors, you can imagine, since that time, they are quiet :-)
Jan
Encryption would have to be enabled at the file system level, but that has not been tested and is not supported.
Why are you worried about how the logs are stored? The format is proprietary and you have to be root to even look at them. If you are root, you already have permissions. If you aren't root, you don't have permission to edit or view them. Why is anyone even logging into the Log Decoder machine anyway?
I'm not understanding the real concern here.