Lines Matching +full:secure +full:- +full:monitor

47 multi-user systems have some inherent security, the job of building and
53 only as secure as you make them, and security concerns are ever competing
60 As yesterday's mini-computers and mainframes
67 and then carefully monitor the system for intrusions.
74 .Bl -enum -offset indent
89 Typically, DoS attacks are brute-force mechanisms that attempt
99 Brute-force network attacks are harder to deal with.
100 A spoofed-packet attack, for example, is
114 The result is that if you have any moderate-sized user base,
137 may find a bug in a root-run server and be able to break root over a network
138 connection to that server, or the attacker may know of a bug in an SUID-root
152 Security remedies should always be implemented with a multi-layered
155 .Bl -enum -offset indent
159 Securing root \(em root-run servers and SUID/SGID binaries
256 An indirect way to secure the root account is to secure your staff accounts
264 get into their staff accounts through a secure login mechanism such as
270 When you use something like Kerberos you generally must secure
272 When you use a public/private key pair with SSH, you must generally secure
279 .Xr ssh-keygen 1 .
281 to star-out the passwords for staff accounts also guarantees that staff
282 members can only log in through secure access methods that you have set up.
284 thus force all staff members to use secure, encrypted connections for
286 of sniffing the network from an unrelated, less secure machine.
293 In order for your workstation to be reasonably secure
295 at all, and you should run a password-protected screen blanker.
299 consider the fact that the vast majority of break-ins occur remotely, over
311 re-passwording restrictions with Kerberos: not only can a Kerberos ticket
315 .Sh SECURING ROOT \(em ROOT-RUN SERVERS AND SUID/SGID BINARIES
317 Be aware that third party servers are often the most bug-prone.
374 servers as root and rely on other mechanisms to detect break-ins that might
377 The other big potential root hole in a system are the SUID-root and SGID
386 the system-default SUID and SGID binaries can be considered reasonably safe.
402 If an intruder can break an SGID-kmem binary the
410 can monitor keystrokes sent through PTYs,
411 including PTYs used by users who log in through secure methods.
418 program or emulator with a keyboard-simulation feature, the intruder can
423 User accounts are usually the most difficult to secure.
425 draconian access restrictions on your staff and *-out their passwords, you
428 you do have sufficient control then you may win out and be able to secure the
437 The only sure fire way is to *-out as many passwords as you can and
444 attacker cannot obtain root-write access.
515 read-only.
517 what you attempt to protect may prevent the all-important detection of an
521 Any super-user process can raise the level, but no process
524 .Bl -tag -width flag
525 .It Ic -1
526 Permanently insecure mode \- always run the system in insecure mode.
529 Insecure mode \- immutable and append-only flags may be turned off.
532 Secure mode \- the system immutable and system append-only flags may not
555 Highly secure mode \- same as secure mode, plus disks may not be
562 while the system is multi-user.
569 Network secure mode \- same as highly secure mode, plus
611 limited-access system.
612 Writing your security scripts on the extra-secure limited-access system
615 limited-access box significant access to the other machines in the business,
616 usually either by doing a read-only NFS export of the other machines to the
617 limited-access box, or by setting up SSH keypairs to allow the limit-access
620 the least visible method \(em allowing you to monitor the file systems on each
623 limited-access server is connected to the client boxes through a switch,
625 If your limited-access server
627 of routing, the NFS method may be too insecure (network-wise) and using SSH
628 may be the better choice even with the audit-trail tracks that SSH lays.
630 Once you give a limit-access box at least read access to the client systems
631 it is supposed to monitor, you must write scripts to do the actual
640 the client-box files boxes at least once a
647 information the limited-access machine knows is valid, it should scream at
690 week, since the object of this layer is to detect a break-in whether or
691 not the break-in is effective.
696 is a relatively low-overhead feature of
697 the operating system which I recommend using as a post-break-in evaluation
701 the break-in occurs.
704 should be generated in as secure a manner as possible \(em remote syslog can be
708 break-in.
711 continuing basis through a secure machine monitoring the consoles.
728 .Bl -enum -offset indent
755 Note that spoofed-IP attacks will circumvent
761 Some standalone servers have self-fork-limitation parameters.
788 separate from the queue-runs
790 If you still want real-time delivery you can run the queue
809 with connect-back services such as tcpwrapper's reverse-identd, which can
811 You generally do not want to use the reverse-ident
818 services from network-based root compromise.
824 ports A, B, C, D, and M-Z
831 and other internet-accessible services.
839 high-numbered port range on the firewall to allow permissive-like operation
854 internet-accessible ports, of course).
903 .Xr inetd 8 Ns -internal
921 What this means is that if you have a secure workstation holding
941 should only be used for automated tasks from secure machines (something
944 key-forwarding in the SSH configuration, or that you make use of the
960 with backwards-compatibility shims to accept the existing names.
968 .Bl -tag -width security.bsd.unprivileged_proc_debug
981 sub-jails.
991 Controls availability of the process debugging facilities to non-root users.
997 Tunable, amd64-only.
999 tables are sanitized to prevent so-called Meltdown information leak on
1010 cross-process ret2spec attacks.
1027 Controls force-flush of L1D cache on return from syscalls which report
1042 Controls force-flush of L1D cache on NMI;
1061 and do not serialize off-core memory accesses.
1063 Controls system-global Address Space Layout Randomization (ASLR) for
1064 normal non-PIE (Position Independent Executable) 32-bit ELF binaries.
1068 mode, also affected by the per-image control note flag.
1070 Controls system-global Address Space Layout Randomization for
1071 position-independent (PIE) 32-bit binaries.
1076 Enable randomization of the stack for 32-bit binaries.
1080 ASLR control for 64-bit ELF binaries.
1082 ASLR control for 64-bit ELF PIEs.
1084 ASLR sbrk compatibility control for 64-bit binaries.
1086 Controls stack address randomization for 64-bit binaries.
1088 Enables non-executable stack for 32-bit processes.
1091 Enables non-executable stack for 64-bit processes.
1094 32-bit processes.
1097 64-bit processes.
1108 .Xr xdm 1 Pq Pa ports/x11/xorg-clients ,