What can we learn from this in our attempts to cut down the amount of spam we get? Well, one thing I learnt was that spammers are testing which mail addresses are rejected, and presumably not wasting their time on them. So if you prevent a spammer from sending mail to you (via ESMTP replies), then they are likely to (eventually) remove you from their lists.
For sending mail you can use IPv6, most ISP's have no idea what IPv6 is and ignore it (and pass it through). If you use IPv6 address mapped IPv4 addresses (ie:::FFFF:1.2.3.4) to send mail, then it will be routed out via IPv6, then someone running a IPv6 to IPv4 relay host will convert it for you back to IPv4 to talk to the remote host.
Alternatively, use IPv6 to a host you control outside your ISP that can use SMTP AUTH to let you realy. Or use IPsec to a host you control outside your ISP. Or better yet, use IPv6 AND IPsec to outside your provider.
Jabber is an open source IM and great for company use. You run the server internally so you don't have to worry about company secrets being sent via an untrusted third party potentially in the clear.
It provides "Presence" so you can see who is Online/Away/Busy/etc, which can be great when you want to ask someone a quick question. Being an IM, messages are sent promptly. I've never seen anyone spam the jabber network, and there are checks in place to try and prevent it ever happening, but even if spammers do start "attacking" you can disable the s2s component and disallow external access to your IM.
There are several jabber components out there that support sending you messages when an RSS feed is updated, these are sent as "Headlines" and many clients treat these specially (ie, don't pop up an irritating box).
There are a large number of jabber clients, and as the protocol is open, it's easy to write your own ones. You can integrate jabber with things and use presence to show status of services, for instance have a jabber "client" for some critical service (If the coffee pot is full:) Online (Coffee is ready), Busy (Coffee is brewing), Away (Coffee pot is empty).
Jabber can also support group conferences, and can tie into other protocols (MSN, AIM, ICQ, SMTP...)
Shrug, I don't expect my idea's to be that great, I'm posting them on/.!
GPG is based on the web of trust. Spammers can't "buy" keys, they can perhaps convince people to sign their key, but if they do that then people who sign spammers keys end up with their keys not being trusted for signatures. People hopefully will form their own close knit communities of people who have the same interested/same line of work/relatives/friends etc.
The other PKI idea is to only accept encrypted emails, as encryption is a CPU intensive operation, encrypting emails to hundreds of thousands of people suddenly becomes prohibitive.
Shrug, if you want to stop people sending forged email then use PKI. Don't accept mail from people unless it is signed by someone you trust. It's easy to implement, it's reasonably secure. It doesn't change any of the protocols on the internet today, all you need to do is set up a key and start signing email.
Sure spammers can get a key but if nobody signs their key, then they can't spam. So every time they want to spam they need to get a key signed. People who sign spammers keys regularly are going to get their signatures revoked.
This increases the "cost" of spamming by making it hard for spammers to get legitimate keys, but making it relatively cheap for joe bloggs who just has to create a key and perhaps get it signed by his ISP and a couple of friends.
ISP's signatures wouldn't mean much, but it would be enough to get you started on the web of trust, after a few people have signed your key your key will start becoming more important to more people.
not necessarily a frame buffer, just the disk image. The advantage of using mmap(2) is that it's practically 0 copy instead of copying things two or three times in memory (from disk into kernel buffer, from kernel buffer to buffer provided to read(2) syscall etc). It avoids syscall overheads, and reduces the lines of code you write. The less lines of code you have the less bugs you have.
The kernel stuff may be the same, but since you remove the syscall indirection, it's faster, and easier to code.
Virtual memory space is very important. I have 512mb of memory, but I want to be able to mmap(2) files that are several gig in size. I don't care that it doesn't all fit into memory at the same time, thats why we have virtual memory after all. But when programs ending up taking over 90% of their code managing mmap(2)'ing in the right regions of memory to do stuff, it's rediculous. If I had a 64bit machine, I'd have 90% less code, and 90% less bugs.
Consider editing large uncompressed images (photos?), these make a great candidate to just mmap(2) off disk and manipulate them directly, yet since we only have 2 or 3 gig of address space, we have to write our own memory management routines to page them in and out.
Most "kiddies" now days use DDoS drones. A "small" DDoS network will have a few hundred machines, a large one can have over 30,000. We see DDoS's exceeding 1gb/s against hosts. I don't know of anyone who has 10GE to their desktop with a suitable uplink that it won't get saturated.
First of all, people tend to IRC from where they are, they don't often need to ssh into a machine and IRC from there (although, I must admit, it's not an unreasonable thing to do because of firewalls etc). The people that want to IRC from a shell box are often the ones that want to "hide", and that opens you up to people attacking your machine (via DDoS, exploits, etc), or they want to run a bot which holds a nick. Then the bot gets DDoS'd to get the nick back (and then held by a bot so someone else can have the nick). If you're lucky the bot won't be used to host illegal warez using up any bandwidth that is left over from the DDoS, and now you have the RIAA/MPAA knocking on your door too.
People that want to hide from people are often doing it because they are involved in illegal activities such as CC# trading, and/or DDoS networks. So you are getting paid in illegal money (that people will want back), by someone you can't trace.
The people that want to use IRC shell accounts tend to "trade" them on IRC so that they can get even more obscure ones to hide even better (or to have backups in case their main one gets attacked). So now the account is used by 20 people, none of which are accountable for their actions, who are drawing attacks against your services.
In general, letting people IRC from your shell is just asking for trouble. There are plenty of shell providers that capture this niche market with hundreds of "vhosts" so you can choose which "leet" hostname you will appear to come from. They are better set up to weather DDoS, and they are careful about accepting CC#'s.
One of the reasons that IRC has such a bad rep is that it's very "instantanious" to see the affects that your attacks have on people. You can see someone's real IP, and DDoS them and watch them get disconnected. You could pick some random IP off the internet and DDoS that, but it's not nearly as satisfying as watching someone "Ping timeout" off IRC. Other networks like Jabber, ICQ, MSN etc don't give you the IP address of the remote person without their permission, and you have less of a situation where you can see other people. There are less common resources (such as globally nick names) to fight over. The networks aren't as vunerable to attack (DDoS'ing an IRC hub will make the entire network split in two, not just preventing people of that server from talking, but denying half the network from talking to the other half. DDoS'ing a Jabber server prevents users on just that server from talking).
I personally think that the IRC protocol should die a natural death (and, in fact, should have died it about 10 years ago when it was obvious it wasn't going to work) and should be replaced with something like Jabber.
This time we were lucky, A) the patch had been available before hand (although it was nearly impossible to apply) B) it was for a service that usually shouldn't be Internet facing. C) It was for a service that has "minor" use on the Internet.
What about next time? When someone finds an exploit in a common web server? ssh daemon? smtp daemon? or name server? All things that are much less likely to be firewalled, the exploit can be coded into a virulent worm before the "white hats" know about it, before a patch is announced. And, if like Slammer it can reach >90% of the hosts in under 10 minutes, are you going to have time to even notice, isolate and identify the problem and put a solution in place before it infects your machines? Do you constantly moniter the internet 24 hours a day 7 days a week?
As a sysadmin there is only so much you can do. Sure being a good sysadmin can prevent many of these attacks, but it can't prevent them all. Diversity is the only real defense against worms, and it's something that Microsoft do very very poorly. Under Linux you can get cheap diversity and very little administration overhead by running redundant servers under two different hardware architectures (Intel + PowerPC for instance). once the kernel has booted the administration of the two machines is virtual identical, but they might as well be from different planets as far as a worm is concerned.
Change his language settings. Even better if you can figur out how to do the translations yourself. I changed a friends machine to have a "y2k" fix: Mondak the First of Januark 2000. If you can't figure out how to write your own translations, then just change it to something like Hebrew. It'll keep them guessing for hours how to turn it back and what exactly that important looking message said.
Remap the keyboard to dvorak and then log them out (Try typing your password in in dvorak...)
change the hosts file to change websites they commonly frequent to websites they wouldn't commonly frequent on company time.
Set their machine to use your machine as a proxy with a nice proxy that rewrites URLs for a extended version of the above.
Change the "auto fix" from doing things like "teh" -> "the", to be more imaginative. (eg wifes name => "The ol' hag").
There is lots of fun to be had, just go ahead and do it:)
The varients can be subtle enough that it doesn't impact things too much. If you are running on multiple hardware platforms for instance you have to make sure that your hardware is supported, and that the programs you need is compiled for your platform, but all the "Userspace" issues are all identical.
While doing this within one organisational unit completely screws with your TCO (now instead of sitting smugly every time there is a Linux exploit, you now have to patch servers every time there is an exploit on Windows/Linux/FreeBSD/OpenBSD/....), having different departments or different companies have different distros.
If you really need fault tolerance, having two redundant systems running different software is an excellent idea if you're willing to pay for that level of support.
You can also avoid the monoculture effect by making your "strain" subtly different, for instance prelink lets you randomise the addresses in memory of dynamically loaded libraries making automated exploits harder (since all the addresses changed), or using something like gentoo where you compile everything from scratch with subtly different USE lines, or optimisations.
Even recompiling your kernel with certain options can change the machine enough that common automated exploits won't work.
This is why the proliferation of Linux distros are a good thing, you can have some level of diversity by installing different distros without getting so much diversity that you your support costs go through the roof.
Portability of Linux means you can run Linux on intel and powerpc chips causing almost all automated exploits to fail, but only requiring a recompile as far as software is concerned. This can be a good solution for having two servers in a load balanced, failover cluster by having each server running on a different architecture.
In general, Windows doesn't have these advantages, Windows isn't portable across platforms. Windows doesn't let you recompile large chunks of the OS with different options, Windows only has a limited range of "Editions" and different editions are usually unsuitable for running the same task. Windows is often lacking equivilent software (How many replacements for exchange are there? How many Linux MTA/MDA/MAA's are there?)
Ahh, but if the "communication" is just the worm doing it's usual infection, then there is nothing "extra" to notice. It already sends part of it's payload to other machines, just if it's already infected, it gets sent back some payload in return.
True. It would have to run for x hours, trying to infect other hosts before "delivering its payload".
What would be a good value for x?
When the critical mass has been infected obviously.
You can take the payload and split it up into "n" smaller chunks, then infect "n" initial machines with your virus each with only a small part of the payload. Then every time a virus infects a new host it splits it's payload in half until it's down to one byte/bit/whatever, then it just copies it's payload. When it finds another machine thats already infected, they both give each other their own payload.
If the other side have data that conflicts with your own, throw theirs away to prevent poisoning
So when there are lots of hosts to infect around the world, the payload gets split up, but it's not until almost all the machines are infected that the payload starts being reassembled.
If the payload is encrypted in such a way that you need the entire payload to decrypt the entire thing, then Antivirus researchers can't tell what the payload is going to do before it actually occurs.
You probably want to make sure that there are multiple copies of the initial data in case machines get cleaned that contain the only copy of one bit or so.
We need to organise things like automated detection of abnormal network activity, and some kind of automated way to slow down (but perhaps not stop -- you're not sure if it is an actual virus) the flow of virulent activity.
A technique like this could be used for something like Freenet to hide information until everyone has the information, then release it.
Jabber supports "headlines" and there are several transports around that support sending RSS updates as jabber "headlines". You get a nice descrete notification that somethings happened (new story on slashdot?) and you can deal with it if you like.
You can publish almost anything as a RSS feed, for instance URL's mentioned on an IRC channel.
When combining technologies such as these you can get some real neat stuff happening. Sometime I want to write some scripts using naive bayes to sort out the RSS information I'm interested in vs the stuff I'm not and then have it subscribe to lots of RSS feeds:)
The reason defacements are so frequent, is that insecure PHP code (in particular PHP Nuke) and then they can read/write what the web server can, which often (for some reason) includes the web pages. (Even though usually you don't want your web servers to have write access to your web pages, people set it up this way for some unknown reason).
I've had a server exploited before because some user ran phpnuke. Sigh. It didn't appear they got root, but we had to reinstall everything anyway. Grr, from then on, new sites had to be approved by me.
As one of the security precautions that I ended up adding, was firewalling outgoing network connections from the apache user. Apache needs to connect to port 25 on the SMTP server (since we have some apps that send mail) and port 53 on your DNS server (for various reasons). Also incoming connections to non-port 80/443 are REJECT'd. This mitigates the damage a user can do once they have compromised a system especially as most "exploits" seem to want to try and download the rest of the exploit usually via HTTP, without network access they can't. This is now a standard item on any web server I install. If you're interested in this, look up iptables for --uid-owner.
You can repeat this trick for other services (such as DNS, SMTP etc) that you have to run.
Programmers are ALWAYS wanting help, usually *especially* non programming help.
Some easy (and obvious) ways a non technical user can help:
Documentation! Documentation! Documentation!
Writing documents on how to do things (or why to do things, accounting is a black art to many). Help people out using the program. The article said that the programmers are spending a lot of their time answering questions instead of actually getting on and *doing* the job. Even simple things like "Tips and tricks" are a good start.
Testing
Programmers make awful testers. Non programmers seem to be able to break programs in new and mysterious ways. The trick here is to learn how to give the best information to the programmers about how to reproduce bugs. A Programmer will usually only be able to fix a bug they can see, if you can't make the programmer see your bug, it won't get fixed!
System Administration
If you aren't a programmer, but know Unix well, then you can offer to help manage the site, the article mentions that they are having trouble searching the archives, perhaps setting up a web based archive + htdig or similar would help.
Advocacy
You usually get developers because they use software and have an itch to scratch. I'd guess that GNU/Cash's biggest problem is that programmers don't use the software. Running Tutorials, presentations at local LUGs can be invaluable for getting a larger userbase (and therefore hopefully a larger developer base)
Money
If theres a feature you need (or want) or a bug you need fixed, consider putting a bounty on it. It doesn't have to be much, $10 or so. If enough people put enough bounty on one bug someone's going to bite, or a programmer can do lots of "simple" fixes/features and can make quite a few lots of $10 quickly.
Feedback
Providing feedback on what features are used, and what aren't is important to developers who may spend a lot of time on a feature they think is important instead of a feature that actually is important.
Wiki
If they are going to put the wiki up, go and define terms, and write pages about things. Write answers to FAQ's. Wiki'ing is very addictive and fun. And while you're at it, everyone learns! I run a wiki, we have over 6,000 pages. It's a lot of fun.
First I build most servers from an autoinstall image like Redhat's Kickstart. I'm sure to include the kickstart config in/root. Everything else is built using package management tools and the source rpms/debs are kept on the machine for future generations to easily reproduce the exact same machine. Then finally keep/etc in CVS.
For things that I may not want to take credit for, or not want some people to know who did this work[1] I put a seemingly random string in somewhere, usually out of sight, but visible to anyone who looks for it which is the md5sum of some string. If I want to prove that I wrote it, I can produce the string which generates the same md5sum, nobody else can. Also, if you put the string somewhere out of the way later coders ignore it and/or believe that it's important in some way they don't understand and leave it alone:)
[1]: I do a lot of work on IRC, you really don't want to put "Trojan detector 2002 By Isomer" all over it coz the kiddies whose trojans it detects will DDoS you instead...
IPv6 supports autoconf where you plug your machine in and if there is an IPv6 enabled router on the network it automatically configures itself. IPv6 supports having IPv6 addresses if you are assigned IPv4 addresses.
In theory, I can install a machine and plug it in, and it will do everything using IPv6. Configuring routers I admit requires some thought, but __nobody__, including the various Linux distributions by the default installs support being plugged into an IPv6 network and configuring themselves.
They all require installing "extra" tools, recompiling kernels, or manually configuring interfaces. Where is the automatic 6to4 address use in NAT gateways? Where is the automatic ipv4-compatible ipv6 addresses?
And thats for the PC operating systems, if we look at embedded devices (eg: Wireless bridges/AP's), most of them not only don't support IPv6, they "accidently" drop IPv6 thats forwarded across them!
IPv6 is designed to be so simple that you aren't supposed to realise that you're transitioning to IPv6. One day you update your OS and you just happen to be using IPv6 instead of IPv4 where possible. Except at the moment you have to spend a week futzing about playing with weird options.
The reason people aren't using IPv6 has nothing to do with if the core network is upgraded. IPv6 can support tunneling over that automatically if required using 6to4 addressing, the reason is that you have to conciously go and configure every frig'n device on your network to support IPv6!
C'mon disto-makers, spend a bit of time getting IPv6 support working in your distro by default. Make sure IPv6 tools are shipped by default (where they exist). Make sure that kernels are compiled with IPv6 support. Make sure that your startup scripts configure ipv6-compatible ipv4 addresses on interfaces that have ipv4 addresses, configure 6to4 addressing by default etc. It's not hard!
I wrote a two player web based 4d three-in-a-row game one evening when I was bored.
I didn't find it particularly hard to play, but some people do. I think it's a good way to practise thinking about things abstractly.
Anyway, find a friend, and play a few games, see how you do. The rules are slightly different, you play until you fill the board, and the person at the end with the most numbers of three in a row wins.
I believe the reason that Phoenix renders faster is due to a little known option which delays rendering of the page for a certain time so that more of the page can be d/l'd before it starts rendering it. This apparently gives a better impression of latency in Phenoix (where the delay is lower), but a much better feel to mozilla (where the delay is higher) because text isn't jumping around so much.
I hear a lot of people talk about startup, and while I agree that mozilla's startup time is very slow, I tend to keep my mozilla instance around for multiple days so I don't tend to care too much. If it was faster I might be more inclined to close it I guess
Mozilla's mail I find as being the nicest IMAP email client I've found, so I tend to use it (although my main email client at home is mutt). So removing the mail functionality seems to be a step backwards to me.
Are there any features in Pheonix that aren't in Mozilla?
Why should I use pheonix over other (non IE) browsers? The "why" page lists a whole heap of reasons which don't really make me feel like I should be leaving mozilla, other people are saying why should they leave opera, the page feels a lot more geared towards IE users. Surely some one here uses Pheonix enough to give good comparisons between Mozilla/Opera and why we should switch.
Slashdot Mirror
What can we learn from this in our attempts to cut down the amount of spam we get? Well, one thing I learnt was that spammers are testing which mail addresses are rejected, and presumably not wasting their time on them. So if you prevent a spammer from sending mail to you (via ESMTP replies), then they are likely to (eventually) remove you from their lists.
What other things can we learn from this?
Yes, there are several palm pilot based jabber clients. Poke around, some are even GPL.
For sending mail you can use IPv6, most ISP's have no idea what IPv6 is and ignore it (and pass it through). If you use IPv6 address mapped IPv4 addresses (ie: ::FFFF:1.2.3.4) to send mail, then it will be routed out via IPv6, then someone running a IPv6 to IPv4 relay host will convert it for you back to IPv4 to talk to the remote host.
Alternatively, use IPv6 to a host you control outside your ISP that can use SMTP AUTH to let you realy. Or use IPsec to a host you control outside your ISP. Or better yet, use IPv6 AND IPsec to outside your provider.
Jabber is an open source IM and great for company use. You run the server internally so you don't have to worry about company secrets being sent via an untrusted third party potentially in the clear.
:) Online (Coffee is ready), Busy (Coffee is brewing), Away (Coffee pot is empty).
It provides "Presence" so you can see who is Online/Away/Busy/etc, which can be great when you want to ask someone a quick question. Being an IM, messages are sent promptly. I've never seen anyone spam the jabber network, and there are checks in place to try and prevent it ever happening, but even if spammers do start "attacking" you can disable the s2s component and disallow external access to your IM.
There are several jabber components out there that support sending you messages when an RSS feed is updated, these are sent as "Headlines" and many clients treat these specially (ie, don't pop up an irritating box).
There are a large number of jabber clients, and as the protocol is open, it's easy to write your own ones. You can integrate jabber with things and use presence to show status of services, for instance have a jabber "client" for some critical service (If the coffee pot is full
Jabber can also support group conferences, and can tie into other protocols (MSN, AIM, ICQ, SMTP...)
Try it, see if it works well for you.
Shrug, I don't expect my idea's to be that great, I'm posting them on /.!
GPG is based on the web of trust. Spammers can't "buy" keys, they can perhaps convince people to sign their key, but if they do that then people who sign spammers keys end up with their keys not being trusted for signatures. People hopefully will form their own close knit communities of people who have the same interested/same line of work/relatives/friends etc.
The other PKI idea is to only accept encrypted emails, as encryption is a CPU intensive operation, encrypting emails to hundreds of thousands of people suddenly becomes prohibitive.
Shrug, if you want to stop people sending forged email then use PKI. Don't accept mail from people unless it is signed by someone you trust. It's easy to implement, it's reasonably secure. It doesn't change any of the protocols on the internet today, all you need to do is set up a key and start signing email.
Sure spammers can get a key but if nobody signs their key, then they can't spam. So every time they want to spam they need to get a key signed. People who sign spammers keys regularly are going to get their signatures revoked.
This increases the "cost" of spamming by making it hard for spammers to get legitimate keys, but making it relatively cheap for joe bloggs who just has to create a key and perhaps get it signed by his ISP and a couple of friends.
ISP's signatures wouldn't mean much, but it would be enough to get you started on the web of trust, after a few people have signed your key your key will start becoming more important to more people.
So, step up and use GPG today!
not necessarily a frame buffer, just the disk image. The advantage of using mmap(2) is that it's practically 0 copy instead of copying things two or three times in memory (from disk into kernel buffer, from kernel buffer to buffer provided to read(2) syscall etc). It avoids syscall overheads, and reduces the lines of code you write. The less lines of code you have the less bugs you have.
The kernel stuff may be the same, but since you remove the syscall indirection, it's faster, and easier to code.
Yes but...
Virtual memory space is very important. I have 512mb of memory, but I want to be able to mmap(2) files that are several gig in size. I don't care that it doesn't all fit into memory at the same time, thats why we have virtual memory after all. But when programs ending up taking over 90% of their code managing mmap(2)'ing in the right regions of memory to do stuff, it's rediculous. If I had a 64bit machine, I'd have 90% less code, and 90% less bugs.
Consider editing large uncompressed images (photos?), these make a great candidate to just mmap(2) off disk and manipulate them directly, yet since we only have 2 or 3 gig of address space, we have to write our own memory management routines to page them in and out.
Most "kiddies" now days use DDoS drones. A "small" DDoS network will have a few hundred machines, a large one can have over 30,000. We see DDoS's exceeding 1gb/s against hosts. I don't know of anyone who has 10GE to their desktop with a suitable uplink that it won't get saturated.
First of all, people tend to IRC from where they are, they don't often need to ssh into a machine and IRC from there (although, I must admit, it's not an unreasonable thing to do because of firewalls etc). The people that want to IRC from a shell box are often the ones that want to "hide", and that opens you up to people attacking your machine (via DDoS, exploits, etc), or they want to run a bot which holds a nick. Then the bot gets DDoS'd to get the nick back (and then held by a bot so someone else can have the nick).
If you're lucky the bot won't be used to host illegal warez using up any bandwidth that is left over from the DDoS, and now you have the RIAA/MPAA knocking on your door too.
People that want to hide from people are often doing it because they are involved in illegal activities such as CC# trading, and/or DDoS networks. So you are getting paid in illegal money (that people will want back), by someone you can't trace.
The people that want to use IRC shell accounts tend to "trade" them on IRC so that they can get even more obscure ones to hide even better (or to have backups in case their main one gets attacked). So now the account is used by 20 people, none of which are accountable for their actions, who are drawing attacks against your services.
In general, letting people IRC from your shell is just asking for trouble. There are plenty of shell providers that capture this niche market with hundreds of "vhosts" so you can choose which "leet" hostname you will appear to come from. They are better set up to weather DDoS, and they are careful about accepting CC#'s.
One of the reasons that IRC has such a bad rep is that it's very "instantanious" to see the affects that your attacks have on people. You can see someone's real IP, and DDoS them and watch them get disconnected. You could pick some random IP off the internet and DDoS that, but it's not nearly as satisfying as watching someone "Ping timeout" off IRC. Other networks like Jabber, ICQ, MSN etc don't give you the IP address of the remote person without their permission, and you have less of a situation where you can see other people. There are less common resources (such as globally nick names) to fight over. The networks aren't as vunerable to attack (DDoS'ing an IRC hub will make the entire network split in two, not just preventing people of that server from talking, but denying half the network from talking to the other half. DDoS'ing a Jabber server prevents users on just that server from talking).
I personally think that the IRC protocol should die a natural death (and, in fact, should have died it about 10 years ago when it was obvious it wasn't going to work) and should be replaced with something like Jabber.
Patching is a reactive thing. If you look at SQL Slammer was able to infect over 90% of hosts in under 10 minutes
This time we were lucky, A) the patch had been available before hand (although it was nearly impossible to apply) B) it was for a service that usually shouldn't be Internet facing. C) It was for a service that has "minor" use on the Internet.
What about next time? When someone finds an exploit in a common web server? ssh daemon? smtp daemon? or name server? All things that are much less likely to be firewalled, the exploit can be coded into a virulent worm before the "white hats" know about it, before a patch is announced. And, if like Slammer it can reach >90% of the hosts in under 10 minutes, are you going to have time to even notice, isolate and identify the problem and put a solution in place before it infects your machines? Do you constantly moniter the internet 24 hours a day 7 days a week?
As a sysadmin there is only so much you can do. Sure being a good sysadmin can prevent many of these attacks, but it can't prevent them all. Diversity is the only real defense against worms, and it's something that Microsoft do very very poorly. Under Linux you can get cheap diversity and very little administration overhead by running redundant servers under two different hardware architectures (Intel + PowerPC for instance). once the kernel has booted the administration of the two machines is virtual identical, but they might as well be from different planets as far as a worm is concerned.
Change his language settings. Even better if you can figur out how to do the translations yourself. I changed a friends machine to have a "y2k" fix: Mondak the First of Januark 2000. If you can't figure out how to write your own translations, then just change it to something like Hebrew. It'll keep them guessing for hours how to turn it back and what exactly that important looking message said.
:)
Remap the keyboard to dvorak and then log them out (Try typing your password in in dvorak...)
change the hosts file to change websites they commonly frequent to websites they wouldn't commonly frequent on company time.
Set their machine to use your machine as a proxy with a nice proxy that rewrites URLs for a extended version of the above.
Change the "auto fix" from doing things like "teh" -> "the", to be more imaginative. (eg wifes name => "The ol' hag").
There is lots of fun to be had, just go ahead and do it
The varients can be subtle enough that it doesn't impact things too much. If you are running on multiple hardware platforms for instance you have to make sure that your hardware is supported, and that the programs you need is compiled for your platform, but all the "Userspace" issues are all identical.
While doing this within one organisational unit completely screws with your TCO (now instead of sitting smugly every time there is a Linux exploit, you now have to patch servers every time there is an exploit on Windows/Linux/FreeBSD/OpenBSD/....), having different departments or different companies have different distros.
If you really need fault tolerance, having two redundant systems running different software is an excellent idea if you're willing to pay for that level of support.
You can also avoid the monoculture effect by making your "strain" subtly different, for instance prelink lets you randomise the addresses in memory of dynamically loaded libraries making automated exploits harder (since all the addresses changed), or using something like gentoo where you compile everything from scratch with subtly different USE lines, or optimisations.
Even recompiling your kernel with certain options can change the machine enough that common automated exploits won't work.
This is why the proliferation of Linux distros are a good thing, you can have some level of diversity by installing different distros without getting so much diversity that you your support costs go through the roof.
Portability of Linux means you can run Linux on intel and powerpc chips causing almost all automated exploits to fail, but only requiring a recompile as far as software is concerned. This can be a good solution for having two servers in a load balanced, failover cluster by having each server running on a different architecture.
In general, Windows doesn't have these advantages, Windows isn't portable across platforms. Windows doesn't let you recompile large chunks of the OS with different options, Windows only has a limited range of "Editions" and different editions are usually unsuitable for running the same task. Windows is often lacking equivilent software (How many replacements for exchange are there? How many Linux MTA/MDA/MAA's are there?)
Ahh, but if the "communication" is just the worm doing it's usual infection, then there is nothing "extra" to notice. It already sends part of it's payload to other machines, just if it's already infected, it gets sent back some payload in return.
True. It would have to run for x hours, trying to infect other hosts before "delivering its payload".
What would be a good value for x? When the critical mass has been infected obviously.
You can take the payload and split it up into "n" smaller chunks, then infect "n" initial machines with your virus each with only a small part of the payload. Then every time a virus infects a new host it splits it's payload in half until it's down to one byte/bit/whatever, then it just copies it's payload. When it finds another machine thats already infected, they both give each other their own payload.
If the other side have data that conflicts with your own, throw theirs away to prevent poisoning
So when there are lots of hosts to infect around the world, the payload gets split up, but it's not until almost all the machines are infected that the payload starts being reassembled.
If the payload is encrypted in such a way that you need the entire payload to decrypt the entire thing, then Antivirus researchers can't tell what the payload is going to do before it actually occurs.
You probably want to make sure that there are multiple copies of the initial data in case machines get cleaned that contain the only copy of one bit or so.
We need to organise things like automated detection of abnormal network activity, and some kind of automated way to slow down (but perhaps not stop -- you're not sure if it is an actual virus) the flow of virulent activity.
A technique like this could be used for something like Freenet to hide information until everyone has the information, then release it.
Jabber supports "headlines" and there are several transports around that support sending RSS updates as jabber "headlines". You get a nice descrete notification that somethings happened (new story on slashdot?) and you can deal with it if you like.
:)
You can publish almost anything as a RSS feed, for instance URL's mentioned on an IRC channel.
When combining technologies such as these you can get some real neat stuff happening. Sometime I want to write some scripts using naive bayes to sort out the RSS information I'm interested in vs the stuff I'm not and then have it subscribe to lots of RSS feeds
The reason defacements are so frequent, is that insecure PHP code (in particular PHP Nuke) and then they can read/write what the web server can, which often (for some reason) includes the web pages. (Even though usually you don't want your web servers to have write access to your web pages, people set it up this way for some unknown reason).
I've had a server exploited before because some user ran phpnuke. Sigh. It didn't appear they got root, but we had to reinstall everything anyway. Grr, from then on, new sites had to be approved by me.
As one of the security precautions that I ended up adding, was firewalling outgoing network connections from the apache user. Apache needs to connect to port 25 on the SMTP server (since we have some apps that send mail) and port 53 on your DNS server (for various reasons). Also incoming connections to non-port 80/443 are REJECT'd. This mitigates the damage a user can do once they have compromised a system especially as most "exploits" seem to want to try and download the rest of the exploit usually via HTTP, without network access they can't. This is now a standard item on any web server I install. If you're interested in this, look up iptables for --uid-owner.
You can repeat this trick for other services (such as DNS, SMTP etc) that you have to run.
Writing documents on how to do things (or why to do things, accounting is a black art to many). Help people out using the program. The article said that the programmers are spending a lot of their time answering questions instead of actually getting on and *doing* the job. Even simple things like "Tips and tricks" are a good start.
Programmers make awful testers. Non programmers seem to be able to break programs in new and mysterious ways. The trick here is to learn how to give the best information to the programmers about how to reproduce bugs. A Programmer will usually only be able to fix a bug they can see, if you can't make the programmer see your bug, it won't get fixed!
If you aren't a programmer, but know Unix well, then you can offer to help manage the site, the article mentions that they are having trouble searching the archives, perhaps setting up a web based archive + htdig or similar would help.
You usually get developers because they use software and have an itch to scratch. I'd guess that GNU/Cash's biggest problem is that programmers don't use the software. Running Tutorials, presentations at local LUGs can be invaluable for getting a larger userbase (and therefore hopefully a larger developer base)
If theres a feature you need (or want) or a bug you need fixed, consider putting a bounty on it. It doesn't have to be much, $10 or so. If enough people put enough bounty on one bug someone's going to bite, or a programmer can do lots of "simple" fixes/features and can make quite a few lots of $10 quickly.
Providing feedback on what features are used, and what aren't is important to developers who may spend a lot of time on a feature they think is important instead of a feature that actually is important.
If they are going to put the wiki up, go and define terms, and write pages about things. Write answers to FAQ's. Wiki'ing is very addictive and fun. And while you're at it, everyone learns! I run a wiki, we have over 6,000 pages. It's a lot of fun.
First I build most servers from an autoinstall image like Redhat's Kickstart. I'm sure to include the kickstart config in /root. Everything else is built using package management tools and the source rpms/debs are kept on the machine for future generations to easily reproduce the exact same machine. Then finally keep /etc in CVS.
:)
For things that I may not want to take credit for, or not want some people to know who did this work[1] I put a seemingly random string in somewhere, usually out of sight, but visible to anyone who looks for it which is the md5sum of some string. If I want to prove that I wrote it, I can produce the string which generates the same md5sum, nobody else can. Also, if you put the string somewhere out of the way later coders ignore it and/or believe that it's important in some way they don't understand and leave it alone
[1]: I do a lot of work on IRC, you really don't want to put "Trojan detector 2002 By Isomer" all over it coz the kiddies whose trojans it detects will DDoS you instead...
- OpenBSD: They're out to get me!
- NetBSD: My Toaster needs an IP address!
But where does it leave the FreeBSD people?
IPv6 supports autoconf where you plug your machine in and if there is an IPv6 enabled router on the network it automatically configures itself. IPv6 supports having IPv6 addresses if you are assigned IPv4 addresses.
In theory, I can install a machine and plug it in, and it will do everything using IPv6. Configuring routers I admit requires some thought, but __nobody__, including the various Linux distributions by the default installs support being plugged into an IPv6 network and configuring themselves.
They all require installing "extra" tools, recompiling kernels, or manually configuring interfaces. Where is the automatic 6to4 address use in NAT gateways? Where is the automatic ipv4-compatible ipv6 addresses?
And thats for the PC operating systems, if we look at embedded devices (eg: Wireless bridges/AP's), most of them not only don't support IPv6, they "accidently" drop IPv6 thats forwarded across them!
IPv6 is designed to be so simple that you aren't supposed to realise that you're transitioning to IPv6. One day you update your OS and you just happen to be using IPv6 instead of IPv4 where possible. Except at the moment you have to spend a week futzing about playing with weird options.
The reason people aren't using IPv6 has nothing to do with if the core network is upgraded. IPv6 can support tunneling over that automatically if required using 6to4 addressing, the reason is that you have to conciously go and configure every frig'n device on your network to support IPv6!
C'mon disto-makers, spend a bit of time getting IPv6 support working in your distro by default. Make sure IPv6 tools are shipped by default (where they exist). Make sure that kernels are compiled with IPv6 support. Make sure that your startup scripts configure ipv6-compatible ipv4 addresses on interfaces that have ipv4 addresses, configure 6to4 addressing by default etc. It's not hard!
I didn't find it particularly hard to play, but some people do. I think it's a good way to practise thinking about things abstractly.
Anyway, find a friend, and play a few games, see how you do. The rules are slightly different, you play until you fill the board, and the person at the end with the most numbers of three in a row wins.
I hear a lot of people talk about startup, and while I agree that mozilla's startup time is very slow, I tend to keep my mozilla instance around for multiple days so I don't tend to care too much. If it was faster I might be more inclined to close it I guess
Mozilla's mail I find as being the nicest IMAP email client I've found, so I tend to use it (although my main email client at home is mutt). So removing the mail functionality seems to be a step backwards to me.
Are there any features in Pheonix that aren't in Mozilla?
Why should I use pheonix over other (non IE) browsers? The "why" page lists a whole heap of reasons which don't really make me feel like I should be leaving mozilla, other people are saying why should they leave opera, the page feels a lot more geared towards IE users. Surely some one here uses Pheonix enough to give good comparisons between Mozilla/Opera and why we should switch.