Uh... until they compromise an internal host, or internal router, that is. If you think that you can lock down a network simply by using private IP's, think again.
This is why smart admins only use them as yet another layer in their defense perimiter.
Use security in depth. I would recommend using all the layers of security you can.
Physical, keep that network you communicate to the satalite separated from all other networks.
Encryption, I'd recommend encrypting the uplink command stream as a minimum. Encrypting the downlink would also be good. This makes the pool of information about what was done small and thus makes crypto analisys harder. Temper this with the fact that all known encryption methods can be brute forced with enough time and CPUs. The encryption is there to make the job harder.
On going to standard IP protocals for talking to the satalite, I'm not convinced it is needed and may be detrimental security wise as it provides a more common element that can be worked from. On the other hand if the protocals have a good security setup in them that is proven secure, then it would be better than developing your own. At this point any security relaying on digital information can be faked. There is no absolute security in the digital world.
What I would do: Keep the network physically separated from all other networks. Keep the protocal secret as nobody else needs to know. Encrypt the uplink and downlink data streams. For the encryption methods, I would choose well known and throughly checked out methods for setting up and maintaing keys, etc. It would be best if the keys are rotated often. This helps keep down the possibility of a key being brute forced before you stop using it.
I've found that the intensity of the light is almost more important than the color ballance. Good color ballence is esential for some tasks, but most interior lighting is just way to dim. I'm a strong beliver in full spectrum lighting but it isn't everything. I light my appartment with number of full spectrum fluorescent lights and regular ones. Right now I have 4 tubes on. I can turn on as many as 12 at one time. They are all reflected off the ceiling and provide a very even light level all over my appartment.
Untill the bad press of late, M$ didn't release timely patches to problems. This was especially true if the application package with the coding error wasn't the absolute latest one out. They still don't want to really do the right thing. I really hope they get hauled over the coals for their latest major fuckup.
Hum, I get 4.2% linux users by IP address to my server. OpenBSD got.05%. Windows has a ton of different browser tags that I haven't gotten a clean number for them yet. I don't care either.
Looks like something in the eEye security setup isn't configured right. Maybe it is protecting the server from being DOSed by blocking access to frequently requested web pages.:)
Management is usually to blame for lax security policies and lax enforcement there of. Not the admins. If management dosen't make it a priority, then it usually dosen't get done. Another area where management can fsck things up is by not backing up the admins on security issues. I've run into both problems ant many companies. The admins knew good security was needed, but management consistanly undermined them.
The effected system is the one that manages $500 million a year in royalties from land owned by 300,000 American Indians. It is esentially operating like a bank, but hasn't got the level of security that a bank is required to have. This Minneapolis Star Tribune article has some additional details.
"Balaran's consultant used a normal Internet connection and free software to access the system. Once
inside, he found no firewalls, numerous missing passwords and no system to detect intruders. He had unfettered access to the Indians' accounts and once even set up a fake account in Balaran's name."
It doesn't sound like it had anything to do with what software they were running, database or otherwise. Bad admin, pure and simple.
To me it sounds like lax security standards enforcement, lax security standards, or lack of knolege and/or ability on the admin's part. All deserve sanctions. Security is mandatory if your systems are connected to the internet.
Actually in the case of a bank the government has the right to shut the bank down, not just yank their FDIC insurance. Security is required by law at banks. I don't know how it is worded, but it basically says that one must keep banking transactions and information secure from unauthorised disclosure and tampering.
Government collected personal information should only accessabel without showing up in person as a query test. Give the name and ID#/date/whatever and the system replies only with a true/false or valid/invalid. That satisfies the need for verification, but also allows for privacy.
I've used tripwire on developer boxes where they had to have root. Combined with an initial install backup it works nicely to see what they are changing, etc. OpenBSD has a better system for monitering the contents of system configuration files. It will email you the differences between the old and new versions of a file.
As said, "Which OS do you plan to use on the box?" This is a major determining factor in the RAID selected. RAID0, stripped is fully supported in the Linux/*BSD kernels. No special RAID controller needed. Multiple SCSI chains will make it faster, but the PCI bus will force a practicle upper limit in both slots and bandwidth.
I know I've heard of another distribution that is specifically tailored for the blind. It assumes the installer is blind. I can't remember it's name off the top of my head, but I belive that it is based on Slackware.
For heavy access non root level name servers you might be able to get by with a SQL backend, but you better have lots of memory and good caching. For the root level servers, nothing but an in memory DB will do. They have way to many requests to deal with.
It bothers me that rather than coming up with creative and interesting ways to target advertisements to certain groups, interesting ways to add value while serving ads, etc, inif* these marketing droids would rather have your computer become a TV that just happens to be connected to the internet. I hope the online community is strong enough to stave off the "dumbing down" of the internet.
For alot of people, that is what the home computer is. It is yet another appliance that is used for entertainment. Not everybody out there is a creative genious. Many people are only consumers.
replace the connector (which is basically a bundle of wires in shrinkwrap) with slightly longer cabling
LCD signal cable suffers horribly from attenuation, so the cable is slightly special and has a very limited maximum length.
Yes it does, but only a few inches is needed. Cretively hack the case and you will find you don't need to extend the cable at all. As a side note, the cable is not special, the drivers used to send the signals down it are of a low cost design. This means they can't send a clean signal for all that far of a distance.
All programs and window managers I have worked with fail on placing the window in the right virtual terminal. I use a number of virtual terminals (ok, 12 currently) and usually place spacific applications in specific virtual terminals. It is a way of mannaging the high number of windows I work with daily. Some are dedicated to certain tasks like system monitoring, email, news web browsing, etc. Other virtual terminals are for genaral tasks, or get dedicated to temporary projects.
I think that going from movable windows to a fixed-frame desktop will be like switching from a low-level language to a high-level one. Those who are used to C will complain that Java (or Perl, or other high-level languages) won't let you control memory... but new programmers will be thankful that you don't have to.:)
Yes, both moveable windows and fixed frame styles have their uses, but they also don't work for all applications. A fixed frame desktop is fine for an instrument, even preferable, but when the application mix isn't known it falls flat on it's face quite quickly. Better flexibility in what a user gets to do at the window manager level is what is needed. As an example I want it so my MP3 player of choice comes up in virtual window #1 with its song selection list to show up right next to it. As is right now I have to switch to virtual window #1, start the MP3 play, wait for it to load, move it to the desired location, open up the song selection list, resize and move it to wher I want it. If at any point I swith to a differnt virtual window while the MP3 player is loading it shows up in that window, not in #1 where started it and want it.
The analogy of low level versus high level language dosen't fit. Matter of fact I'd say you have it reversed. A fixed position window manager is really a lower level example of a moveable pane window manager.
Re:Osama bin Bert ... a message
on
Bert Is Evil
·
· Score: 2
The chosen icon needs to be large enough to still be visible after shrinking. The scarry part is even the placement of Bert could be partially an indicator.
Slashdot Mirror
Nah, just a lab of plain old ordinary primates. ;-)
This is why smart admins only use them as yet another layer in their defense perimiter.
Physical, keep that network you communicate to the satalite separated from all other networks.
Encryption, I'd recommend encrypting the uplink command stream as a minimum. Encrypting the downlink would also be good. This makes the pool of information about what was done small and thus makes crypto analisys harder. Temper this with the fact that all known encryption methods can be brute forced with enough time and CPUs. The encryption is there to make the job harder.
On going to standard IP protocals for talking to the satalite, I'm not convinced it is needed and may be detrimental security wise as it provides a more common element that can be worked from. On the other hand if the protocals have a good security setup in them that is proven secure, then it would be better than developing your own. At this point any security relaying on digital information can be faked. There is no absolute security in the digital world.
What I would do: Keep the network physically separated from all other networks. Keep the protocal secret as nobody else needs to know. Encrypt the uplink and downlink data streams. For the encryption methods, I would choose well known and throughly checked out methods for setting up and maintaing keys, etc. It would be best if the keys are rotated often. This helps keep down the possibility of a key being brute forced before you stop using it.
I've found that the intensity of the light is almost more important than the color ballance. Good color ballence is esential for some tasks, but most interior lighting is just way to dim. I'm a strong beliver in full spectrum lighting but it isn't everything. I light my appartment with number of full spectrum fluorescent lights and regular ones. Right now I have 4 tubes on. I can turn on as many as 12 at one time. They are all reflected off the ceiling and provide a very even light level all over my appartment.
Untill the bad press of late, M$ didn't release timely patches to problems. This was especially true if the application package with the coding error wasn't the absolute latest one out. They still don't want to really do the right thing. I really hope they get hauled over the coals for their latest major fuckup.
I wonder how many "users" were worms like Nimda or CodeRed?
Hum, I get 4.2% linux users by IP address to my server. OpenBSD got .05%. Windows has a ton of different browser tags that I haven't gotten a clean number for them yet. I don't care either.
Looks like something in the eEye security setup isn't configured right. Maybe it is protecting the server from being DOSed by blocking access to frequently requested web pages. :)
Management is usually to blame for lax security policies and lax enforcement there of. Not the admins. If management dosen't make it a priority, then it usually dosen't get done. Another area where management can fsck things up is by not backing up the admins on security issues. I've run into both problems ant many companies. The admins knew good security was needed, but management consistanly undermined them.
The effected system is the one that manages $500 million a year in royalties from land owned by 300,000 American Indians. It is esentially operating like a bank, but hasn't got the level of security that a bank is required to have. This Minneapolis Star Tribune article has some additional details.
inside, he found no firewalls, numerous missing passwords and no system to detect intruders. He had unfettered access to the Indians' accounts and once even set up a fake account in Balaran's name."
It doesn't sound like it had anything to do with what software they were running, database or otherwise. Bad admin, pure and simple.
To me it sounds like lax security standards enforcement, lax security standards, or lack of knolege and/or ability on the admin's part. All deserve sanctions. Security is mandatory if your systems are connected to the internet.
Actually in the case of a bank the government has the right to shut the bank down, not just yank their FDIC insurance. Security is required by law at banks. I don't know how it is worded, but it basically says that one must keep banking transactions and information secure from unauthorised disclosure and tampering.
Government collected personal information should only accessabel without showing up in person as a query test. Give the name and ID#/date/whatever and the system replies only with a true/false or valid/invalid. That satisfies the need for verification, but also allows for privacy.
I've used tripwire on developer boxes where they had to have root. Combined with an initial install backup it works nicely to see what they are changing, etc. OpenBSD has a better system for monitering the contents of system configuration files. It will email you the differences between the old and new versions of a file.
As said, "Which OS do you plan to use on the box?" This is a major determining factor in the RAID selected. RAID0, stripped is fully supported in the Linux/*BSD kernels. No special RAID controller needed. Multiple SCSI chains will make it faster, but the PCI bus will force a practicle upper limit in both slots and bandwidth.
They belived a salesman. They don't know how get independent verification. They don't do the needed research. They... OOooo! a shiny object.
ZipSpeak is the distribution I was thinking of.
I know I've heard of another distribution that is specifically tailored for the blind. It assumes the installer is blind. I can't remember it's name off the top of my head, but I belive that it is based on Slackware.
Why still running on BIND?
It is there and working...
For heavy access non root level name servers you might be able to get by with a SQL backend, but you better have lots of memory and good caching. For the root level servers, nothing but an in memory DB will do. They have way to many requests to deal with.
For alot of people, that is what the home computer is. It is yet another appliance that is used for entertainment. Not everybody out there is a creative genious. Many people are only consumers.
I myself have made a low velocity coil gun and have a more powerfull one in the planning stages.
LCD signal cable suffers horribly from attenuation, so the cable is slightly special and has a very limited maximum length.
Yes it does, but only a few inches is needed. Cretively hack the case and you will find you don't need to extend the cable at all. As a side note, the cable is not special, the drivers used to send the signals down it are of a low cost design. This means they can't send a clean signal for all that far of a distance.
All programs and window managers I have worked with fail on placing the window in the right virtual terminal. I use a number of virtual terminals (ok, 12 currently) and usually place spacific applications in specific virtual terminals. It is a way of mannaging the high number of windows I work with daily. Some are dedicated to certain tasks like system monitoring, email, news web browsing, etc. Other virtual terminals are for genaral tasks, or get dedicated to temporary projects.
Yes, both moveable windows and fixed frame styles have their uses, but they also don't work for all applications. A fixed frame desktop is fine for an instrument, even preferable, but when the application mix isn't known it falls flat on it's face quite quickly. Better flexibility in what a user gets to do at the window manager level is what is needed. As an example I want it so my MP3 player of choice comes up in virtual window #1 with its song selection list to show up right next to it. As is right now I have to switch to virtual window #1, start the MP3 play, wait for it to load, move it to the desired location, open up the song selection list, resize and move it to wher I want it. If at any point I swith to a differnt virtual window while the MP3 player is loading it shows up in that window, not in #1 where started it and want it.
The analogy of low level versus high level language dosen't fit. Matter of fact I'd say you have it reversed. A fixed position window manager is really a lower level example of a moveable pane window manager.
The chosen icon needs to be large enough to still be visible after shrinking. The scarry part is even the placement of Bert could be partially an indicator.