And surprisingly enough this is causing large problems for us in New Zealand and Australia. Why? Because Korea has thousands of users running insecure machines that are used for DDoS and email spam, so admins are banning ranges like 210.* and 211.* which while it covers most of Korea and China, also removes large chunks of New Zealand and Australia.
There has been a lot of discussion in NZ recently about people in the US in particular deciding to ban all APNIC listed ranges! We're not all evil spammers and DDoS drones, some of us *do* Want to be able to send legitimate email!
Theres a program called gnu enterprise written by some people that previously used oracle forms. Of course it's Free software, and supports multiple database backends etc. It also supports multiple frontends, although the only one that I'm aware of that supports the full functionality is the wxwindows frontend, although web, and console frontends occasionally show signs of life. It's undergoing continous frantic development as more features are added and bugs are fixed.
FreeBSD (IIRC) has secure levels, that you can go to a higher secure level, but never to a lower one without a reboot. At a reasonable level of security, direct hardware access and kernel access is disabled for root.
But presuming the administrator has physical access to the machine, they can always transplant the hard disk. Even with a machine such as the XBox where the harddisk requires authentication from the BIOS (which requires to be signed by something like TPA....) people have shown though easy it is to get past these restrictions (information how to authenticate with the HDD was quickly avaliable on the internet).
In light of this is limiting what the super user/administrator can do on the machine worthwhile? You have to eventually trust someone sooner or later. The advantage of trusting someone nearer to you in the chain is that they are usually more readily available to be hit with a bat.
assuming the administrator has physical access to the machine, he can diddle with the disk directly, so is this just a false sense of a security?
Presumably the administrator can run programs to defrag the disk and repair the disk, and these require direct (and often online) access to the raw data -- they could probably play with the data while the machine is up bypassing the entire permissions model.
And where does this leave you? With the administrator saying in a court of law "It couldn't be me! You would have noticed!", and the jury nods, and a few minutes later your having a conversation with "bubba".
The Wiki has a page about this discussing peoples experiences. Surf around their wiki a bit, I seem to remember a page talking about "how they would design a cubical farm" but I can't find it right now.
A good discussion on how to survive a cube farm (and things to look out for when designing them) from The Wiki Programming Outside The Cube
IRC's good if you can find a small channel. The larger the channel, the more people they get abusing the channel and the more harsh the rules and the more likely you are to get kicked. The trick is finding a small channel full of people that are interested in the area you are having trouble with. Also, when asking questions, state the full question in as few lines as possible. Saying "is it all right to ask a question?" just adds to the noise in a channel.
I find the local LUG lists a great place to start when asking for help. They often have very experienced people that are around for helping you. In particular, if you screw it up beyond all recognition, they're close enough that you can ask if they can come and fix the problem.
Google for your problem. Learning how to use google effectively to find answers to your problems is great time saver. Searching for "apache won't work" doesn't get you very far but "apache: can not bind to port 80" is likely to get a much better response out of google.
Look for documentation projects that try and help people out. My personal favourite is the Waikato Linux Users Group wiki which tries to encampus as much information about linux as it can. It's an excellent place to go and create a page asking a question and have several knowledgable people wiki'ing the answer, and then having it available for everyone else to find when *they* have the same issue.
The trick here is to put deliberate defects into the version you bring to review. This pushes the inspectors to search hard for every single minor defect, incase they miss one of the "obvious" deliberate defects. Suddenly, the code gets verified to an extremely high level of scruitiny.
we use rsync for backup over ssh onto another machine at a remote location. This works really well, especially if you do a cp with hardlinks each night. rsync will download just the changes since yesterday, and files that are the same just end up being hard links to the same data. This also makes restores reasonably trivial. (just ssh onto the backup machine, cd into the directory for the date you want, cd into the directory and grab the file -- done.)
While I agree with your point, there are a lot of issues with HTTPS.
You can't name virtual host HTTPS, since the certificates are sent before the Host: header is.
Older versions of IE have all kinds of issues with SSL, which is why most sites you see on the internet put you into SSL for one, may be two pages, then set a cookie and go back to using HTTP, since IE screws up SSL as soon as it's persistant connection expires or something. It took us ages to figure out why some people couldn't view more than a handful of pages on a customers site.
You have to buy certificates and keep them up to date. You can get around this by setting up your own CA then pushing our certificates to all your clients sometimes, but if you have to use a "real" CA, then you're looking at the most expensive bits on the planet (8 byte signature, few hundred dollars US?...)
The WAND Research group did a lot of research about this several years ago, when NZ's bandwidth was a piece of string and people were investigating using satellite for most of NZ's traffic.
Their publications are available on their website. You probably want to look at all the ones that mention a high bandwidth delay product.
basically issues you have are not having a large enough tcp window size, and the latency on connection setup/tear down. The tcp window size can be easily tuned on most OS's (including windows), the latency on connection setup issue can be resolved by using proxies at both ends that forward from one to the other and keep their connections open.
One of the lecturers at the local uni did some research into how to have multiple machines interact with a disk over a network without stepping on anyones toes.
A Block-Based Network File System
If you are interested in finding people to trade signatures with you might want to try http://www.biglumber.com They provide a list of people grouped by area who are interested in finding people to trade signatures. They also list 'events' where keysignings take place (eg: LUG meetings)
Of course you often find you need to get people *outside* your area to sign your key to make it any use. So if you're thinking of travel, it's probably an excellent place to go look for someone to trade signatures when you're out of town.
IRC daemons have a varied and chequered history, including some totally bizarre comments.
#define FLAG_TS8/* Why do you want to know? */
/* why 80? why not? */
crule.c:/* type conversions and ()'s are fun!;) here have an asprin.. */
m_pass.c:/* Do something here */
class.c: * XXX - This destroys data
parse.c: * Never "FRANCE " again!!;-)
What "FRANCE " was has more or less dropped out of the IRC knowledge pool, noone really knows what this comment refers to.
Also, the IRC logs of discussions of features in an irc daemon. Kinda expected I guess, but they do tend to take up a lot of space.
My favourite, of course, is:
m_nick.c: * Put this 'if' here so that the nesting goes nicely on the screen
ident isn't inheritantly insecure, just because most of the implementations were written by script kiddies who want to get on IRC, but can't code and are less secure than a naked freshman in a gay bar doesn't mean that all ident daemons are insecure.
I run an ident daemon, but first I audited the entire thing by hand, they're not complicated pieces of software, and are fairly trivial to audit.
I personally think that you shouldn't require ident to connect, and afaik no undernet server requires ident to connect, but I can understand the reasoning of why people would do it.
I'm one of the coders for Undernet (one of the larger IRC networks), and while ident is basically useless for a large portion of the userbase it does have some use.
A lot of people on IRC (for whatever reason) like to IRC from (brought) shell accounts. It's in these shell account owners best interest to run Ident, otherwise the only way to ban an abusive user is to ban the entire netblock of the shell provider, basically killing off their entire customer base. If we see that there are multiple people from the same IP with different Ident and only one of them is abusing we'll ban by ident. If they change ident and come back, we ban the entire IP (or netblock).
Many servers have different "connection classes" or different levels of service to different people. You can say for instance that you will allow 5,000 people from your country to connect, 2,000 other people from around the world that are on helpful and cooperative ISP's, and 1,000 people from elsewhere. Thus, if you're outside an IRC servers catchment area, they start placing harsh rules on you, like requiring ident. eg: If your server is in the US, and it's a lot easier to track down abusers within the US than outside it, so you require people outside the US to make a "better effort" to use your server.
Kinda going back to the previous point, a lot of boxes that are used on IRC are hacked, or people aren't supposed to be IRCing from (eg company machines). Running an ident server is trivial if you (legitmately) have root on the machine, if you don't then it starts making it more obvious that the machine is hacked ("Hmm, I don't remember that machine having ident enabled...")
How about having a process running somewhere on each of the platforms that checks out your source, compiles it and runs some tests against it. As soon as it finishes it checks out a new tree, compiles it, and checks it again.
The advantage of doing this is you have near instant feedback if something you did broke on one of the platforms. This means that fixing problems becomes much faster. And, if your scripts email everyone who checked in since the last automated build then only the people who "caused" the problem get bothered.
You can also use this to track various metrics, such as performance, and produce pretty graphs. You can easily see which commits caused your program to start taking twice as long.
I've seen this used successfully in many software companies to keep their outstanding bug counts down and to keep people moving toward their goals instead of being bogged down fixing integratration issues.
You might want to look at the rest of the ideals in Extreme Programming, such as Pair Programming, Project Velocity, User Stories....
After your inspiring speach about Jabber. You never really tell us exactly what it is, or provide a link for more info. A link wold be nice. We like links.
Open Protocol with open specifications, XML everywhere:)
Easily extended protocol.
Server side everything, including contact lists.
A multitude of clients, for windows, Linux, and other OS's
Server side Transports so you can talk to people on other networks as if they were normal jabber members. This even includes ICQ's ability to send SMS's. Transports exist for at least ICQ,MSN,Yahoo,AIM,IRC,SMTP, I even wrote a transport to talk to my Wiki.
A simple client protocol that can be easily implemented on simple devices (Cellphones etc), most of the hardwork is done on the servers.
Conferencing, multiuser chat.
Lotsa other stuff I don't use.
Some of the proposed extentions including such nifty things such as being able to have a client fill in forms. For example, you could connect to a Pizza delivery transport, it asks you some questions, such as where to deliver the pizza, what kind of pizza you want etc, then delivers the pizza to you.
Jabber is a stable platform now. It's usable as an IM today, and many people do use it. what it does need is more people to start using it.
For more information see:
Slashdot Mirror
If you mount it with the options "hard,intr" then it will allow you to recover nicely if an NFS server goes away.
See the Waikato Linux Users Group page on NFS for more information.
http://vigor.sourceforge.net/
Vigor, the paperclip for vi. It provides helpful hints like "Remember, press [esc] to leave insert mode" and "are you sure you want to move left?"
And surprisingly enough this is causing large problems for us in New Zealand and Australia. Why? Because Korea has thousands of users running insecure machines that are used for DDoS and email spam, so admins are banning ranges like 210.* and 211.* which while it covers most of Korea and China, also removes large chunks of New Zealand and Australia.
There has been a lot of discussion in NZ recently about people in the US in particular deciding to ban all APNIC listed ranges! We're not all evil spammers and DDoS drones, some of us *do* Want to be able to send legitimate email!
Theres a program called gnu enterprise written by some people that previously used oracle forms. Of course it's Free software, and supports multiple database backends etc. It also supports multiple frontends, although the only one that I'm aware of that supports the full functionality is the wxwindows frontend, although web, and console frontends occasionally show signs of life. It's undergoing continous frantic development as more features are added and bugs are fixed.
yeah, but is it wise to limit the administrator when the administrator could so very easily overcome these limitations?
What point is there in limiting the administrator user other than to just irritate people who are trying to function as administrators?
FreeBSD (IIRC) has secure levels, that you can go to a higher secure level, but never to a lower one without a reboot. At a reasonable level of security, direct hardware access and kernel access is disabled for root.
But presuming the administrator has physical access to the machine, they can always transplant the hard disk. Even with a machine such as the XBox where the harddisk requires authentication from the BIOS (which requires to be signed by something like TPA....) people have shown though easy it is to get past these restrictions (information how to authenticate with the HDD was quickly avaliable on the internet).
In light of this is limiting what the super user/administrator can do on the machine worthwhile? You have to eventually trust someone sooner or later. The advantage of trusting someone nearer to you in the chain is that they are usually more readily available to be hit with a bat.
assuming the administrator has physical access to the machine, he can diddle with the disk directly, so is this just a false sense of a security?
Presumably the administrator can run programs to defrag the disk and repair the disk, and these require direct (and often online) access to the raw data -- they could probably play with the data while the machine is up bypassing the entire permissions model.
And where does this leave you? With the administrator saying in a court of law "It couldn't be me! You would have noticed!", and the jury nods, and a few minutes later your having a conversation with "bubba".
... And now I find the links: Lord of the Flies, Programming Outside The Cube. I really hope this helps, I'd hate to be hearded like cattle into a cube farm.
A good discussion on how to survive a cube farm (and things to look out for when designing them) from The Wiki Programming Outside The Cube
I find the local LUG lists a great place to start when asking for help. They often have very experienced people that are around for helping you. In particular, if you screw it up beyond all recognition, they're close enough that you can ask if they can come and fix the problem.
Google for your problem. Learning how to use google effectively to find answers to your problems is great time saver. Searching for "apache won't work" doesn't get you very far but "apache: can not bind to port 80" is likely to get a much better response out of google.
Look for documentation projects that try and help people out. My personal favourite is the Waikato Linux Users Group wiki which tries to encampus as much information about linux as it can. It's an excellent place to go and create a page asking a question and have several knowledgable people wiki'ing the answer, and then having it available for everyone else to find when *they* have the same issue.
The trick here is to put deliberate defects into the version you bring to review. This pushes the inspectors to search hard for every single minor defect, incase they miss one of the "obvious" deliberate defects. Suddenly, the code gets verified to an extremely high level of scruitiny.
we use rsync for backup over ssh onto another machine at a remote location. This works really well, especially if you do a cp with hardlinks each night. rsync will download just the changes since yesterday, and files that are the same just end up being hard links to the same data. This also makes restores reasonably trivial. (just ssh onto the backup machine, cd into the directory for the date you want, cd into the directory and grab the file -- done.)
The WAND Research group did a lot of research about this several years ago, when NZ's bandwidth was a piece of string and people were investigating using satellite for most of NZ's traffic. Their publications are available on their website. You probably want to look at all the ones that mention a high bandwidth delay product. basically issues you have are not having a large enough tcp window size, and the latency on connection setup/tear down. The tcp window size can be easily tuned on most OS's (including windows), the latency on connection setup issue can be resolved by using proxies at both ends that forward from one to the other and keep their connections open.
One of the lecturers at the local uni did some research into how to have multiple machines interact with a disk over a network without stepping on anyones toes. A Block-Based Network File System
there are 10 kinds of people in the world, those that understand trinary, those that don't, and those that confuse it with binary.
Of course you often find you need to get people *outside* your area to sign your key to make it any use. So if you're thinking of travel, it's probably an excellent place to go look for someone to trade signatures when you're out of town.
http://average.matrixnetsystems.com/Daily/markR.h
http://mrtg.nac.net/switch9.oct.nac.net/3865/swit
The advisory announcing the flaws:m /
http://www.boredom.org/~cstone/worm-annotated.txt
http://www.nextgenss.com/advisories/mssql-udp.txt Various disassemblies and discussions: http://www.snafu.freedom.org/tmp/1434-probe.txt http://www.digitaloffense.net/worms/mssql_udp_wor
Writeups:n et.attack.ap/index.html / 20030125/ap_wo_en_po/na_gen_internet_attack_2 r tdetail.jsp?oid=21824
http://www.cnn.com/2003/TECH/internet/01/25/inter
http://news.bbc.co.uk/2/hi/technology/2693925.stm
http://story.news.yahoo.com/news?tmpl=story&u=/ap
http://bvlive01.iss.net/issEn/delivery/xforce/ale
Waikato Linux Users Group also use a wiki (phpwiki).
We spend a lot of time looking at what people search for in the wiki and try and put up useful content for people outside the region to use.
Our wiki gets a lot of use from people inside (and occasional use from people outside) the LUG. I highly recommend using a Wiki.
ident isn't inheritantly insecure, just because most of the implementations were written by script kiddies who want to get on IRC, but can't code and are less secure than a naked freshman in a gay bar doesn't mean that all ident daemons are insecure.
I run an ident daemon, but first I audited the entire thing by hand, they're not complicated pieces of software, and are fairly trivial to audit.
I personally think that you shouldn't require ident to connect, and afaik no undernet server requires ident to connect, but I can understand the reasoning of why people would do it.
A lot of people on IRC (for whatever reason) like to IRC from (brought) shell accounts. It's in these shell account owners best interest to run Ident, otherwise the only way to ban an abusive user is to ban the entire netblock of the shell provider, basically killing off their entire customer base. If we see that there are multiple people from the same IP with different Ident and only one of them is abusing we'll ban by ident. If they change ident and come back, we ban the entire IP (or netblock).
Many servers have different "connection classes" or different levels of service to different people. You can say for instance that you will allow 5,000 people from your country to connect, 2,000 other people from around the world that are on helpful and cooperative ISP's, and 1,000 people from elsewhere. Thus, if you're outside an IRC servers catchment area, they start placing harsh rules on you, like requiring ident. eg: If your server is in the US, and it's a lot easier to track down abusers within the US than outside it, so you require people outside the US to make a "better effort" to use your server.
Kinda going back to the previous point, a lot of boxes that are used on IRC are hacked, or people aren't supposed to be IRCing from (eg company machines). Running an ident server is trivial if you (legitmately) have root on the machine, if you don't then it starts making it more obvious that the machine is hacked ("Hmm, I don't remember that machine having ident enabled...")
How about having a process running somewhere on each of the platforms that checks out your source, compiles it and runs some tests against it. As soon as it finishes it checks out a new tree, compiles it, and checks it again.
The advantage of doing this is you have near instant feedback if something you did broke on one of the platforms. This means that fixing problems becomes much faster. And, if your scripts email everyone who checked in since the last automated build then only the people who "caused" the problem get bothered.
You can also use this to track various metrics, such as performance, and produce pretty graphs. You can easily see which commits caused your program to start taking twice as long.
I've seen this used successfully in many software companies to keep their outstanding bug counts down and to keep people moving toward their goals instead of being bogged down fixing integratration issues.
You might want to look at the rest of the ideals in Extreme Programming, such as Pair Programming, Project Velocity, User Stories....
- Open Protocol with open specifications, XML everywhere
:)
- Easily extended protocol.
- Server side everything, including contact lists.
- A multitude of clients, for windows, Linux, and other OS's
- Server side Transports so you can talk to people on other networks as if they were normal jabber members. This even includes ICQ's ability to send SMS's. Transports exist for at least ICQ,MSN,Yahoo,AIM,IRC,SMTP, I even wrote a transport to talk to my Wiki.
- A simple client protocol that can be easily implemented on simple devices (Cellphones etc), most of the hardwork is done on the servers.
- Conferencing, multiuser chat.
- Lotsa other stuff I don't use.
Some of the proposed extentions including such nifty things such as being able to have a client fill in forms. For example, you could connect to a Pizza delivery transport, it asks you some questions, such as where to deliver the pizza, what kind of pizza you want etc, then delivers the pizza to you. Jabber is a stable platform now. It's usable as an IM today, and many people do use it. what it does need is more people to start using it. For more information see:Actually @1.2.3.4 is illegal according the rfc822, the correct syntax is @[1.2.3.4], ditto for MX's, you can't MX to an IP, nor can you MX to a CNAME.