Home |
Search |
Today's Posts |
|
Metalworking (rec.crafts.metalworking) Discuss various aspects of working with metal, such as machining, welding, metal joining, screwing, casting, hardening/tempering, blacksmithing/forging, spinning and hammer work, sheet metal work. |
Reply |
|
LinkBack | Thread Tools | Display Modes |
#1
|
|||
|
|||
Warning VIRUS (was: Fw: Do not release, its the internal rls!)
In article ,
Tim Williams wrote: "DoN. Nichols" wrote in message ... And how many know automatically that they should go in and turn it off? At least as many as those think they should bypass it altogether and get Linux. Which, then, leaves an awful lot of systems wide open. I'm not sure whether you want to lump me into that last category, as I'm normally using Sun's Solaris and OpenBSD's unix, not linux. :-) Enjoy, DoN. -- Email: | Voice (all times): (703) 938-4564 (too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html --- Black Holes are where God is dividing by zero --- |
#2
|
|||
|
|||
In article ,
Tim Williams wrote: "DoN. Nichols" wrote in message ... Which, then, leaves an awful lot of systems wide open. But hey, Linux would be just as bad if it had 90% of the market. Maybe so -- though they would have to learn a bit more to *weaken* the security from as-shipped. And OpenBSD is my favorite for secure as it installs. To make the box less secure, you need to *learn* more about the system, and in the process, you will hopefully learn why turning this on or that off is a bad idea. :-) Yes -- there are holes in linux. Not as many as Windows, but a lot more than OpenBSD or even Solaris. That's a very large number of really stupid people. ("Compile my kernel? Y'mean go get dinner from KFC?") Of course, you only have to compile the kernel to add special drivers to the OS, or (in the case of OpenBSD, at least, to freeze the order in which the SCSI drives are presented. By default, the lowest SCSI ID gets to be sd0, the next one sd1, etc. No problem until you hit a box which has a six or twelve slot Multipack hung on it, in which case you wind up with drive names shuffling around if you reboot with one of the middle drives in the series unplugged. (And the Multipack is hot-swappable drives.) Since I intend to make this box into a RAID system, I need to keep the drive names constant, so a little editing on the kernel configuration file, and a recompile, and there we are. With Sun's Solaris (SysV unix) -- neither problem occurs -- SCSI drives have complex names which define exactly where they appear: e.g. /dev/dsk/c0t2d0s6 controller 0 (built in to the CPU board) target 2 (SCSI-IC 2) device 0 (You can have up to seven devices on each SCSI ID -- dates back to a single SCSI board controlling multiple MFM or ESDI disk drives. It is always 0 for modern drives with SCSI built in) slice 6 (Partition number 6 -- of seven possible with Solaris) And all device drivers can be run-time loaded. I'm not sure what would happen on a Windows box with a SCSI card added to talk to a Multipack. Normally, Windows only has to talk to three hard drives (and one CD-ROM) at the most. I'm not sure whether you want to lump me into that last category, as I'm normally using Sun's Solaris and OpenBSD's unix, not linux. :-) Well, anyone who *thinks* they are enlightened enough to dodge M$ altogether... Since I've been doing computing at home since before IBM funded the rip-off of Digital Research's CP/M to become the start of PC-DOS/MS-DOS, and I was already using a multi-user multi-tasking OS (OS-9 -- *not* the later Mac OS by the same name), I already knew how much better things could be. My first experience with MS-DOS was at work. And I even had my first unix system (v7 on 68000 CPU) at home before a MS-DOS box came in. There are some things for which MS-DOS is the only practical choice for me -- these days only the annual Income tax programs -- but for the rest of the time I am quite happy to avoid it. Enjoy, DoN. -- Email: | Voice (all times): (703) 938-4564 (too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html --- Black Holes are where God is dividing by zero --- |
#3
|
|||
|
|||
On 7 Feb 2005 20:48:02 -0500, DoN. Nichols wrote:
In article , Tim Williams wrote: "DoN. Nichols" wrote in message ... And how many know automatically that they should go in and turn it off? At least as many as those think they should bypass it altogether and get Linux. Which, then, leaves an awful lot of systems wide open. I'm not sure whether you want to lump me into that last category, as I'm normally using Sun's Solaris and OpenBSD's unix, not linux. :-) How's OpenBSD? I've been using FreeBSD lately for my intel (and Mac, obvously), and it seems very stable, and everything works. Bull**** and advocacy aside, any good reason to pick Open over Free? Dave Hinz |
#4
|
|||
|
|||
On Mon, 7 Feb 2005 22:12:53 -0600, Tim Williams wrote:
"DoN. Nichols" wrote in message ... Which, then, leaves an awful lot of systems wide open. But hey, Linux would be just as bad if it had 90% of the market. Nope. Every OS except Windows differentiates between the system's files, and the user's files. Only Windows allows a user's actions to break things the system relies on. It's a basic fundamental design difference that makes everything but Windows not susceptable to viruses, not popularity. That's a very large number of really stupid people. ("Compile my kernel? Y'mean go get dinner from KFC?") I haven't had to recompile a Linux kernel in about 8 years. I'm not sure whether you want to lump me into that last category, as I'm normally using Sun's Solaris and OpenBSD's unix, not linux. :-) Well, anyone who *thinks* they are enlightened enough to dodge M$ altogether... ....yes? |
#5
|
|||
|
|||
In article ,
Dave Hinz wrote: On 7 Feb 2005 20:48:02 -0500, DoN. Nichols wrote: [ ... ] I'm not sure whether you want to lump me into that last category, as I'm normally using Sun's Solaris and OpenBSD's unix, not linux. :-) How's OpenBSD? I've been using FreeBSD lately for my intel (and Mac, obvously), and it seems very stable, and everything works. Bull**** and advocacy aside, any good reason to pick Open over Free? That is a good question. I don't use FreeBSD, so I can't do a true comparison, but OpenBSD is predicated on careful analysis of all of the source code, and having only things which are *trusted* turned on in the system as it installs. Things like sendmail (which is of questionable security, just based on history, and which *must* run as root) are run in a "chroot jail", so there are severe limitations on what it can do to the rest of the system. Also -- if you want to establish a truly hardened system as a firewall -- start with "pf" (packet filter), which I understand that FreeBSD has picked up from OpenBSD, get the system configured and running as you want, and then set the bits using "chflags" (like chmod, but it works on a different set of flags). You can set the following flags on a file-by-file basis: ================================================== ==================== arch set the archived flag opaque set the opaque flag (owner or superuser only) nodump set the nodump flag (owner or superuser only) sappnd set the system append-only flag (superuser only) schg set the system immutable flag (superuser only) uappnd set the user append-only flag (owner or superuser only) uchg set the user immutable flag (owner or superuser only) ================================================== ==================== In particular, look at the last four, with "schg" and "sappnd" being the most important. Once you have those set, edit the "/etc/rc.securelevel" file to set "Securelevel" to a value of 1 (the default in mult-user mode) or greater. Here is the man page for securelevel, so you can see just how tight it can make a system. ================================================== ==================== SECURELEVEL(7) OpenBSD Reference Manual SECURELEVEL(7) NAME securelevel - securelevel and its effects SYNOPSIS The OpenBSD kernel provides four levels of system security: -1 Permanently insecure mode - init(8) will not attempt to raise the securelevel - may only be set with sysctl(8) while the system is insecure - otherwise identical to securelevel 0 0 Insecure mode - used during bootstrapping and while the system is single-user - all devices may be read or written subject to their permissions - system file flags may be cleared 1 Secure mode - default mode when system is multi-user - securelevel may no longer be lowered except by init - /dev/mem and /dev/kmem may not be written to - raw disk devices of mounted file systems are read-only - system immutable and append-only file flags may not be removed - kernel modules may not be loaded or unloaded - the fs.posix.setuid sysctl(8) variable may not be raised - the net.inet.ip.sourceroute sysctl(8) variable may not be raised 2 Highly secure mode - all effects of securelevel 1 - raw disk devices are always read-only whether mounted or not - settimeofday(2) and clock_settime(2) may not set the time back- wards or close to overflow - pfctl(8) may no longer alter filter or nat rules - the ddb.console and ddb.panic sysctl(8) variables may not be raised DESCRIPTION Securelevel provides convenient means of ``locking down'' a system to a degree suited to its environment. It is normally set at boot via the rc.securelevel(8) script, or the superuser may raise securelevel at any time by modifying the kern.securelevel sysctl(8) variable. However, only init(8) may lower it once the system has entered secure mode. A kernel built with option INSECURE in the config file will default to permanently insecure mode. Highly secure mode may seem Draconian, but is intended as a last line of defence should the superuser account be compromised. Its effects pre- clude circumvention of file flags by direct modification of a raw disk device, or erasure of a file system by means of newfs(8). Further, it can limit the potential damage of a compromised ``firewall'' by prohibit- ing the modification of packet filter rules. Preventing the system clock from being set backwards aids in post-mortem analysis and helps ensure the integrity of logs. Precision timekeeping is not affected because the clock may still be slowed. Because securelevel can be modified with the in-kernel debugger ddb(4), a convenient means of locking it off (if present) is provided on highly se- cure systems. This is accomplished by setting ddb.console and ddb.panic to 0 with the sysctl(8) utility. FILES /etc/rc.securelevel commands that run before the security level changes SEE ALSO chflags(2), settimeofday(2), mem(4), options(4), init(8), rc(8), sysctl(8) HISTORY The securelevel manual page first appeared in OpenBSD 2.6. BUGS The list of securelevel's effects may not be comprehensive. OpenBSD 3.5 January 4, 2000 2 ================================================== ==================== So -- you see that the combination of the immutable flags on properly selected files and the securelevel make it very difficult for the system to be modified without going to single-user mode -- which means that anyone attacking from the net cannot get in while in single-user mode. (That is -- all networking is turned off in that mode.) Obviously, log files would only get the append-only flag, not the immutable one. But OpenBSD prides itself on the security of the default install of the system. Yes -- you can do things to reduce the security of the system, such as opting to not run apache in a chroot jail, and to not run it in /var, which by default is mounted "nodev" and "nosuid", making it more difficult to get out of the chroot jail. I hope that this helps, DoN. -- Email: | Voice (all times): (703) 938-4564 (too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html --- Black Holes are where God is dividing by zero --- |
#6
|
|||
|
|||
On 8 Feb 2005 21:57:19 -0500, DoN. Nichols wrote:
In article , Dave Hinz wrote: and advocacy aside, any good reason to pick Open over Free? That is a good question. I don't use FreeBSD, so I can't do a true comparison, but (read and saved. Thank you for an obviously non-trivial amount of time and advice, Don.) (huge snip)) I hope that this helps, It does indeed. I need to build a mailhub, I'm thinking postfix, and I'll give OpenBSD a shot. Thanks. Dave |
#7
|
|||
|
|||
In article ,
Dave Hinz wrote: On 8 Feb 2005 21:57:19 -0500, DoN. Nichols wrote: In article , Dave Hinz wrote: and advocacy aside, any good reason to pick Open over Free? That is a good question. I don't use FreeBSD, so I can't do a true comparison, but (read and saved. Thank you for an obviously non-trivial amount of time and advice, Don.) You're welcome. (huge snip)) I hope that this helps, It does indeed. I need to build a mailhub, I'm thinking postfix, and I'll give OpenBSD a shot. Thanks. When you get there -- drop me an e-mail first. It obviously does not belong on this newsgroup, but there are some interesting kinks in the way sendmail is started and messages are inserted in OpenBSD. And you will be setting this up as a replacement for sendmail, I presume? I've not dealt with postfix. (Hmm ... maybe it is in the packages tree already.) I learned about these kinks in the process of setting up qmail to replace sendmail. Oh yes -- and is there a non-spamcop e-mail address for you? I'll probably just drop things if I hit a challenge-and-response type of service -- just general principles. Enjoy, DoN. -- Email: | Voice (all times): (703) 938-4564 (too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html --- Black Holes are where God is dividing by zero --- |
#8
|
|||
|
|||
On 8 Feb 2005 23:32:47 -0500, DoN. Nichols wrote:
In article , Dave Hinz wrote: On 8 Feb 2005 21:57:19 -0500, DoN. Nichols wrote: When you get there -- drop me an e-mail first. It obviously does not belong on this newsgroup, but there are some interesting kinks in the way sendmail is started and messages are inserted in OpenBSD. Good to know, you'll have mail shortly. Oh yes -- and is there a non-spamcop e-mail address for you? I'll probably just drop things if I hit a challenge-and-response type of service -- just general principles. Nope, I don't do the challenge/response thing anymore, and unless you're in one of the dozen or so blacklists I scrub with and/or write to me about mortgages, viagra, or whatever else, I'd see an email immediately. I'm really pleased with how well spamcop filters stuff while not blocking legitimate messages. Dave |
#9
|
|||
|
|||
In article ,
Dave Hinz wrote: On 8 Feb 2005 23:32:47 -0500, DoN. Nichols wrote: In article , Dave Hinz wrote: On 8 Feb 2005 21:57:19 -0500, DoN. Nichols wrote: When you get there -- drop me an e-mail first. It obviously does not belong on this newsgroup, but there are some interesting kinks in the way sendmail is started and messages are inserted in OpenBSD. Good to know, you'll have mail shortly. O.K. Just make sure that it does not exceed 30k in *total* size, or it will be blocked here. (A way of keeping most of the virii at bay -- though they won't hurt anything here, but rather just be an inconvenience. A *big* in convenience in the early days of a new virus when I may get 300+ copies in a single day. :-) Oh yes -- and is there a non-spamcop e-mail address for you? I'll probably just drop things if I hit a challenge-and-response type of service -- just general principles. Nope, I don't do the challenge/response thing anymore, and unless you're in one of the dozen or so blacklists I scrub with and/or write to me about mortgages, viagra, or whatever else, I'd see an email immediately. I'm really pleased with how well spamcop filters stuff while not blocking legitimate messages. I'm not that pleased with spamcop. Every so often, my address winds up in their database for a day or two, as a result of some spammer forging my e-mail address. They (or those who feed them reports) really don't do a proper job of checking the actual IP address which delivers something and verifying it against the domain name. :-( Enjoy, DoN. -- Email: | Voice (all times): (703) 938-4564 (too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html --- Black Holes are where God is dividing by zero --- |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Warning VIRUS (was: Fw: Do not release, its the internal rls!) | Metalworking | |||
Virus Warning | Woodturning | |||
Drilling through internal solid walls........... | UK diy | |||
"Damp" internal wall - initial measurements made. Any ideas? | UK diy | |||
W.C Internal Overflow | UK diy |