Here are tasks that are going to make CAcert's infrastructure substantially more manageable or secure: 1. confidential information is a lot more confidential 1. auditable - there is great accountability in system access/events 1. availability - items with a high availability requirement are more so 1. integrity - changes to critical items are substantially better protected or detection is easier. == Syslog Integrity == System logs retain integrity even if the operating system is compromised. === Customer Representatives === * Non-critical infrastructure - Daniel || Requirement ID || Description || proposer || remote syslog || || Integrity1 || logs cannot be modified in OS is compromised || dan || yes || || Integrity2|| logs cannot be spoofed by other OS || dan || firewalling on host/unix sockets/dev node??? || || Availability1 || logs are accessible to investigators || dan || yes || || Availability2 || logs are accessible to system administrator on the same box (if no confidentiality requirements) || dan || yes - requires readonly export of filesystem - see below || || || Simple || Should intergrate with syslog || dan || yes || || Scalable || Should be simple to add new servers || dan || yes - syslogng on central server || || Encrypted || Some information should be encrypted || philipp || see below || Current non-critical systems are using linux-vservers. ==== Separation in Vservers ==== Options for separating logs files: * Could this be as simple as mknod'ing /dev/log as you would for a chroot? Close: http://www.paul.sladen.org/vserver/archives/200205/0089.html * Note that a syslogd daemon can setup multiple /dev/log socket. or you can use hard links to setup /dev/log using the root server /dev/log in every vserver. This way, logging would go to the root log files. I'm not sure these would generate unique IP data for Integrity2. Network syslog - possible though need to validate Integrity2. ==== Readonly Export ==== You can do a read only bind mount that gives the original vserver the ability to view its own logs but not modify them (certianly helps the sysadmin working on it). {{{ file /etc/vservers/cacert-mail/fstab: /var/log/IP /var/log/remote none ro,bind 0 0 }}} Other ways include readonly NFS or SAMBA exports. ==== Encrypted Log Files ==== We need a solution for Syslog, Apache and potentially other applications to automatically encrypt all their logfiles to a given public key. We already thought about other solutions like serial links to a dedicated syslog server, or syslog over TCP, but we prefer to store the logfiles directly on the server where they are created, encrypted to a public key. The secret key to decrypt the logfiles should be generated on a dedicated machine. In demand of logfile auditing, the encrypted logfiles should be copied to the dedicated machine, where they can be decrypted and audited. An attacker that succeeds to gain access to the webserver should not be able to decipher the logfiles on the server. All logfiles on the server can be encrypted to the same public key, we currently don't need different settings per logfile. It should be easy to deploy it on a normal Debian+Apache+Postfix server, to install the software and deploy the public key, and to have all logfiles encrypted from then on. Compatibility with OpenPGP Public keys (or X.509 certificates, or even SSH keys) is preferred, but not a requirement. (Perhaps GnuPG can be used directly by syslog in some way?). * Contact for this task: philipp@cacert.org * Working on it: * Comments: * First, we should somehow separate the discussions from the tasklist * We could also use hybrid encryption with regular rekeying of the symmetric key. I think we could encrypt several lines in the logfile together. (Maybe i'm too few to it, but what is hybrid encryption in this context? -GNA) (hybrid encryption = random session key for symmetric encryption + asymmetric encrypted session key. See OpenPGP or S/Mime for examples) I have read a bit about that, so i understand. Still i have problems how to implement it in a data stream like syslog. I would need to create logchunks which would be then separated into small sets of logfiles that can be encrypted. In that way we would not need anything other than gpg in asymetric mode, but we would get a lot of logfiles. Still, because i'm not a programmer there may be a point i'm missing. * Maybe we should go an other way: let the logs created with symmetric encryption so they can be encrypted byt-by-byte, but afterwards let a hashing algorithm create an integity sum, and store the first hash in a safe place. Then we have encrypted logs, and can check for integrity. (-GNA) - I haven´t found any safe places for storing hashes yet. Perhaps TPMs could help there, but I doubt it. And hashes only provide tamper-evidence, not tamper-prevention. - I only thought the symmetric encryption would be tamper prevention, and the hashing (like in mysyslog) would do the integrity. * Another solution might be to use existing infrastructure by generating a random symmetric key at boot, encrypting the key to the public key and storing it, then using it to create an encrypted filesystem and protecting that filesystem from reads (eg make it write only using eg an LSM). Also check out TPMs. Sounds complicated though when syslog could be used. [samj] - The main objective is confidentiality. Integrity is optional. Perhaps OpenPGP is able to concatenate several encrypted packages after each other in a single file. So perhaps you can encrypt every line, and simply add it to the logfile. Since OpenPGP is packet oriented, it might work. Potential solution: http://www.balabit.com/network-security/syslog-ng/ Potential solution: http://ecryptfs.sourceforge.net/ (if it can (be made to) work on public keys alone) Perhaps ccrypt (comes with Ubuntu) could be used? == Action logging == We would like to have a system that collects login-sessions on Unixoid servers (SSH + local sessions), and asks the administrator what he actually did in that session, to collect a report of who logged in when, how long and what they did. * Contact for this task: philipp@cacert.org * Working on it: * Comments: * Possible solutions include scripting sudo, using a shell like sudosh with rc script or sudo alternatives like http://www.sudo.ws/sudo/other.html (samj) * Yes, a sudosh script as an additonal mechanism to ease documenting helps, but the main system should also work in case the user does not enter anything in the sudosh script, or does not use sudo at all. Perhaps we will also want to document other actions like file-transfers (scp, sftp) in the future. * For shells, the BSD script utility might be useful here. ("The script utility makes a typescript of everything printed on your terminal.") (freek) ---- . CategorySystemTasks . CategoryInfrastructure