As soon as the change was made, ChanServ proceeded to kick and ban everyone on #OpenBSD. I heard this happened on quite a few other channels as well. One person even said that ChanServ flooded his channel with messages.
For the most part, things are running fairly smoothly now. Since the services are going to require you to identify yourself at least once a month, it funny watching OPs trying to get forgotten founder passwords replaced for their channels.
Re:Merging parts of VM patch?
on
Linux 2.4.13
·
· Score: 1
I didn't say Linus was a bad coder. I'm just implying something that he admits to, he's a poor maintainer. The stable kernel series is suppose to be that, stable. It's not some place where you make radical VM changes. Linus should hand the 2.4.x kernels over to someone else so that he can do what he's best at, development.
Linus may well be one of the better coders in the world (I'm certainly no judge of that), but I don't think he has the patience to maintain anything. He's creative, he want's to go somewhere with Linux, some call him a visionary. Someone like that needs to use their creative energies, they need to develop something. The slow drudgery that maintaining (bug fixing) a project requires is not him.
Merging parts of VM patch?
on
Linux 2.4.13
·
· Score: 1
From the ChangeLog:
final:
. ..
- me: handle VM write load more gracefully. Merge parts of -aa VM
Isn't that how the latest VM mess started?
The good news is that Linus seems ready to hand 2.4.x over to Alan. From the latest Kernel Traffic Linus was quoted as saying:
. . .
He replied to himself shortly thereafter after noticing more breakage, adding, "On the other hand, the good news is that I'll open 2.5.x RSN, just because Alan is so much better at maintaining things;)"
It seems that Linus is going to do the same thing that he did with the 2.2.x kernels, make a mess out of them (especially VM), have a few back-to-back releases, then hand the whole thing over to Alan.
They are having more than just shipping problems. This was just recently posted to the Bastille mailing list:
Date: Fri, 12 Oct 2001 00:22:18 -0700
From: Jay Beale
To: bastille-linux-discuss@lists.sourceforge.net
Subject: [Bastille-linux-discuss] Available...
Normally, I don't use this as an announcement board, but times are
tough...
I wanted to let everyone know that I'm becoming available for hire, as a
number of people on this list have, as a result of some financial issues
at MandrakeSoft that have a lot to do with the poor retail and financial
markets.
I'm trying to find consulting work, though I'm open to full-time
employment if it's a good match.
With that said, here are a couple good links:
My consulting practice:http://www.bastille-linux.org/jay/consult ing/
My security articles:
http://www.bastille-linux.org/jay/consulting/secur ity-articles-jjb.html
- Jay Beale
Lead Developer, Bastille Linux
soon-to-be-ex-Security Team Director, MandrakeSoft
You forgot to mention the part about Microsoft not releasing the information on the API's that would allow Netscape to run on Windows 95 until long after the Christmas buying season was over.
The military has already shutdown a large number of their websites. Generally, each unit has their own website/server. Sometimes sections within each unit will also have their own website/server depending on how important they view themselves as being. The information those sites provide is usually basic, very rarely has dynamic content, and can very easily be obtained by other means.
Those who have had sites that were shutdown now have to get approval (from several echelons up) before that can put their sites back up. I'm not going to say what the new web servers will be running, but it WILL NOT be Miscrosoft's IIS. The websites that are still running IIS are actively scanned for vulnerabilities (by someone other then several thousand script kiddies).
I will not be surprised if ALL of the webservers run by the military will be moved over to something else.
Yes but,.... that's not free. The monthly fee I pay my ISP includes access to their news servers. I wouldn't want to pay more just to access USENET.
This also sets a bad precedent. If one ISP filters newsgroups in an attempt to stop possible Copyright violations, how long will it be before others follow suit? How long will it take before the RIAA starts threatening ISP's with lawsuits because they allow their users access to forums known to violate Copyright protections?
The sad part is the RIAA will do this all in the name of the DMCA! Which means the ISP's will have no choice but to comply or face an ugly lawsuit...
If this keeps up, the DMCA will make it illegal to even access the internet!!
The recent newsletter from Crypto-gram talks about the DMCA and brings up a few good points:
Dmitry Sklyarov (age 27) landed in jail because the Digital Millennium Copyright Act (DMCA) makes publishing critical research on this technology a more serious offense than publishing nuclear weapon designs. Just how did the United States of America end up with a law protecting the entertainment industry at the expense of freedom of speech?
. . .
There are also provisions in the DMCA to allow for security research, provisions that I and others fought hard to have included. But these provisions are being ignored, as we've seen in the DeCSS case against 2600 Magazine, the RIAA case against Ed Felten, and this arrest.
A few features of RFC 821 have proven to be problematic and SHOULD
NOT be used in Internet mail.
F.1 TURN
This command, described in RFC 821, raises important security issues
since, in the absence of strong authentication of the host requesting
that the client and server switch roles, it can easily be used to
divert mail from its correct destination. Its use is deprecated;
SMTP systems SHOULD NOT use it unless the server can authenticate the
client.
F.2 Source Routing
RFC 821 utilized the concept of explicit source routing to get mail
from one host to another via a series of relays. The requirement to
utilize source routes in regular mail traffic was eliminated by the
introduction of the domain name system "MX" record and the last
significant justification for them was eliminated by the
introduction, in RFC 1123, of a clear requirement that addresses
following an "@" must all be fully-qualified domain names.
Consequently, the only remaining justifications for the use of source
routes are support for very old SMTP clients or MUAs and in mail
system debugging. They can, however, still be useful in the latter
circumstance and for routing mail around serious, but temporary,
problems such as problems with the relevant DNS records.
SMTP servers MUST continue to accept source route syntax as specified
in the main body of this document and in RFC 1123. They MAY, if
necessary, ignore the routes and utilize only the target domain in
the address. If they do utilize the source route, the message MUST
be sent to the first domain shown in the address. In particular, a
server MUST NOT guess at shortcuts within the source route.
Clients SHOULD NOT utilize explicit source routing except under
unusual circumstances, such as debugging or potentially relaying
around firewall or mail system configuration errors.
F.3 HELO
As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to
HELO when the server will accept the former. Servers must continue
to accept and process HELO in order to support older clients.
F.4 #-literals
RFC 821 provided for specifying an Internet address as a decimal
integer host number prefixed by a pound sign, "#". In practice, that
form has been obsolete since the introduction of TCP/IP. It is
deprecated and MUST NOT be used.
F.5 Dates and Years
When dates are inserted into messages by SMTP clients or servers
(e.g., in trace fields), four-digit years MUST BE used. Two-digit
years are deprecated; three-digit years were never permitted in the
Internet mail system.
F.6 Sending versus Mailing
In addition to specifying a mechanism for delivering messages to
user's mailboxes, RFC 821 provided additional, optional, commands to
deliver messages directly to the user's terminal screen. These
commands (SEND, SAML, SOML) were rarely implemented, and changes in
workstation technology and the introduction of other protocols may
have rendered them obsolete even where they are implemented.
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
MAY implement them. If they are implemented by servers, the
implementation model specified in RFC 821 MUST be used and the
command names MUST be published in the response to the EHLO command.
How do you tell someone that they are running a "Honeypot" server unintentionally?
I answered this question in a previous article about Honeypots. This the link to the individual post doesn't work, I'll repost it here:
Re:honeypots, dangers, products (Score:4, Informative)
by tiny69 on Tuesday December 19, @10:28PM EST (#225)
(User #34486 Info) http://www.linuxdoc.org
Spotting a Honeypot is fairly easy. The first thing you do when you gain access to a computer
is ask yourself one simple question,
What is this computer used for?
Then try to answer that question. People don't attach computers to the internet for no reason.
What services is it running? If it's an ftp server, what files are available? Is it a webserver?
Look at the webpage. If ftp services are being provided but the ftp directory is empty or the
webpage has is the default one install with the OS, then something is up.
Check for user activity. Are there any users? Goto ~/.netscape (if the machine is unix). What
are the timestamps on the files. Does the user have any email. By looking at the appropriate
files (depending on OS) you can tell when it was installed. Has anything changed since then?
Do a find on files changed over the last seven days. If there is no user activity, something is
definitly wrong!!
Check for changes made to configuration files. Check the files that a sysadmin would most
likely change. If you can't find any changes (other than LOTS of logging - another Red Flag!),
check to see if the system looks like a default install (if you are into this, you should know what
default installs look like/the common security holes the vendor leaves open/etc.). If it is a
default install and the install is older than a week, congratulations, you've found a Honey Pot.
One last check before getting the hell out of dodge, sniff the network. Who else is one it?
Honey Pots tend to be isolated. If the only activity you see is yourself (unless you are
connected at midnight, but then you deserve to get caught) or the only other traffic is logging
activity (from the one you are on to somewhere else), You've been had!! Just for shits and
grins, ping the subnet you are on. People and companies don't waste network equipment as it
is fairly expensive. If the machine you are on is the only one on that subnet....
do a quick `rm -rf/` and never go back.
I just want to add a few thing:
One of the things the HoenyNet Project does and has hinted at in some it's documents is changing the location of the configuration file for syslogd. Unfortunately it's doesn't seem to mention this in it's new paper. But how do you check it?
If you don't get a response, the configuration file is NOT/etc/syslog.conf. This a DEFINITE indication that you are on a Honeypot.
# strings/usr/sbin/syslogd | grep "^/"
One of those files is being used as the configuration file. They've also done this with Bash's history file:
# strings/bin/bash | grep ".bash_history"
Nothing there, look at one of these responses:
# strings/bin/bash | grep "~"
And since this is a Honeypot, some of the commands used to hide your tracks may be modified or removed. There are more than a dozen ways to erase a hardrive without using `rm -rf/`, get to know some of them.... And as was pointed out in the results of their resent challenge, removing a file doesn't necessarily mean that it has been erased. *grin*
Isn't he the one that cried wolf over ssh not too long ago? If we can't trust the binaries, how are we going to trust the source?
Quick poll, raise your hand if you inspect EVERY piece of software you install for security problems. I thought so.
If are going to be that paranoided, we should do one of two things: 1) Throw our computers away and never use them again because we don't know what we might be installing. 2) Go back to the time when men were men and everyone wrote their own programs, compilers, shells, etc.
Slashdot just can't let the opportunity to smear MS go by. Is this really news? MS has a big security hole in one of their products. Does this surprise anyone?
But when the 2.2.x kernels have a _BIG_ security hole that allows users to exploit it against _ANY_ SUID binary, well that must not be news worthy...
How many people _REALLY_ use encrpytion on a regular basis?
And I'm not talking about ecryption that is fairly transparent to the user, such as SSL or SSH. I mean, how many people go out of their way to encrypt every email they send? Not many. With all the people in this world who send email, I'd be surprised if one percent or two actually make a habit of encrypting email. And that's being generous.
How many of those that do use encryption use it for other than legal purposes? I bet that the percentage he higher than those who send email without encryption. Then law-enforcement officials step in and do one of the things they are best at (regardless on how illegal it may be), stereotyping. With that they can make broad claims such as "Criminals are more likely to use encryption when sending email." Regardless that there is no evidence to back that up. They do this to help fight crime by narrowing the focus of their resources.
The media and politicians take general statements such as the one above and distort it until it suits there own purposes. "Only criminals use encryption!" What's really scarey is the average citizen will not question such statements and accept them as being true! If they do question it, it along the lines of "I don't use encryption, my friends don't use encryption, so it must be true."
"When the Feds -- be they CIA, FBI, NSA, or Treasury Department -- discuss crypto, they make it sound as
if anyone using it must be a child pornographer, drug smuggler, or terrorist."
Statements like that, as disheartening as they are, don't really surprise me. Don't be surprised either when politicians start passing laws making the use of encryption to further criminal activity a crime. Yeah, it sounds stupid, but laws similar to that already exist.
Now, what's the payoff on three blue-screens in a row again?
The payoffs at slot machines is determined by the odds that something (say, three cherries in a row) might happen. The more likely something will happen, the less the payoff will be. So what would the payoff for three blue-screens of death be?
Update: 01/13 01:47 PM by michael: Slackware says - rudely - that 7.2 isn't released yet. This situation - confusion about what is released and what is not - is one that most software developers
avoid by utilizing new-fangled conventions such as "beta".
Well if you would take the time to verify a story submission, they wouldn't have to tell you what a dumbass you are. They didn't use the word BETA because it has not been released as a beta yet.
Slashdot Mirror
As soon as the change was made, ChanServ proceeded to kick and ban everyone on #OpenBSD. I heard this happened on quite a few other channels as well. One person even said that ChanServ flooded his channel with messages.
For the most part, things are running fairly smoothly now. Since the services are going to require you to identify yourself at least once a month, it funny watching OPs trying to get forgotten founder passwords replaced for their channels.
Linus may well be one of the better coders in the world (I'm certainly no judge of that), but I don't think he has the patience to maintain anything. He's creative, he want's to go somewhere with Linux, some call him a visionary. Someone like that needs to use their creative energies, they need to develop something. The slow drudgery that maintaining (bug fixing) a project requires is not him.
The good news is that Linus seems ready to hand 2.4.x over to Alan. From the latest Kernel Traffic Linus was quoted as saying:
It seems that Linus is going to do the same thing that he did with the 2.2.x kernels, make a mess out of them (especially VM), have a few back-to-back releases, then hand the whole thing over to Alan.The scare caused by the Unabomber didn't kill snail mail or the sending of packages. Neither will this.
No, the people that are most concerned about encryption are paranoid enough not to trust commercial apps.
You forgot to mention the part about Microsoft not releasing the information on the API's that would allow Netscape to run on Windows 95 until long after the Christmas buying season was over.
The military has already shutdown a large number of their websites. Generally, each unit has their own website/server. Sometimes sections within each unit will also have their own website/server depending on how important they view themselves as being. The information those sites provide is usually basic, very rarely has dynamic content, and can very easily be obtained by other means.
Those who have had sites that were shutdown now have to get approval (from several echelons up) before that can put their sites back up. I'm not going to say what the new web servers will be running, but it WILL NOT be Miscrosoft's IIS. The websites that are still running IIS are actively scanned for vulnerabilities (by someone other then several thousand script kiddies).
I will not be surprised if ALL of the webservers run by the military will be moved over to something else.
Who here wrote a scathing letter to the editor or someone else regarding this incident when it first came out?
I should see more hands that!
For those that did raise their hand, did you write them an apology for your uncalled for comments? Go on, raise your hand.
I didn't think so.....
Yes but, .... that's not free. The monthly fee I pay my ISP includes access to their news servers. I wouldn't want to pay more just to access USENET.
This also sets a bad precedent. If one ISP filters newsgroups in an attempt to stop possible Copyright violations, how long will it be before others follow suit? How long will it take before the RIAA starts threatening ISP's with lawsuits because they allow their users access to forums known to violate Copyright protections?
The sad part is the RIAA will do this all in the name of the DMCA! Which means the ISP's will have no choice but to comply or face an ugly lawsuit...
If this keeps up, the DMCA will make it illegal to even access the internet!!
So how long would a kernel compile take? Half a second? Less?
F. Deprecated Features of RFC 821
A few features of RFC 821 have proven to be problematic and SHOULD
NOT be used in Internet mail.
F.1 TURN
This command, described in RFC 821, raises important security issues
since, in the absence of strong authentication of the host requesting
that the client and server switch roles, it can easily be used to
divert mail from its correct destination. Its use is deprecated;
SMTP systems SHOULD NOT use it unless the server can authenticate the
client.
F.2 Source Routing
RFC 821 utilized the concept of explicit source routing to get mail
from one host to another via a series of relays. The requirement to
utilize source routes in regular mail traffic was eliminated by the
introduction of the domain name system "MX" record and the last
significant justification for them was eliminated by the
introduction, in RFC 1123, of a clear requirement that addresses
following an "@" must all be fully-qualified domain names.
Consequently, the only remaining justifications for the use of source
routes are support for very old SMTP clients or MUAs and in mail
system debugging. They can, however, still be useful in the latter
circumstance and for routing mail around serious, but temporary,
problems such as problems with the relevant DNS records.
SMTP servers MUST continue to accept source route syntax as specified
in the main body of this document and in RFC 1123. They MAY, if
necessary, ignore the routes and utilize only the target domain in
the address. If they do utilize the source route, the message MUST
be sent to the first domain shown in the address. In particular, a
server MUST NOT guess at shortcuts within the source route.
Clients SHOULD NOT utilize explicit source routing except under
unusual circumstances, such as debugging or potentially relaying
around firewall or mail system configuration errors.
F.3 HELO
As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to
HELO when the server will accept the former. Servers must continue
to accept and process HELO in order to support older clients.
F.4 #-literals
RFC 821 provided for specifying an Internet address as a decimal
integer host number prefixed by a pound sign, "#". In practice, that
form has been obsolete since the introduction of TCP/IP. It is
deprecated and MUST NOT be used.
F.5 Dates and Years
When dates are inserted into messages by SMTP clients or servers
(e.g., in trace fields), four-digit years MUST BE used. Two-digit
years are deprecated; three-digit years were never permitted in the
Internet mail system.
F.6 Sending versus Mailing
In addition to specifying a mechanism for delivering messages to
user's mailboxes, RFC 821 provided additional, optional, commands to
deliver messages directly to the user's terminal screen. These
commands (SEND, SAML, SOML) were rarely implemented, and changes in
workstation technology and the introduction of other protocols may
have rendered them obsolete even where they are implemented.
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
MAY implement them. If they are implemented by servers, the
implementation model specified in RFC 821 MUST be used and the
command names MUST be published in the response to the EHLO command.
That's what they get for using the same login/password combo more thatn once!
I answered this question in a previous article about Honeypots. This the link to the individual post doesn't work, I'll repost it here:
I just want to add a few thing:
One of the things the HoenyNet Project does and has hinted at in some it's documents is changing the location of the configuration file for syslogd. Unfortunately it's doesn't seem to mention this in it's new paper. But how do you check it?
# strings /usr/sbin/syslogd | grep "/etc/syslog.conf"
If you don't get a response, the configuration file is NOT /etc/syslog.conf. This a DEFINITE indication that you are on a Honeypot.
# strings /usr/sbin/syslogd | grep "^/"
One of those files is being used as the configuration file. They've also done this with Bash's history file:
# strings /bin/bash | grep ".bash_history"
Nothing there, look at one of these responses:
# strings /bin/bash | grep "~"
And since this is a Honeypot, some of the commands used to hide your tracks may be modified or removed. There are more than a dozen ways to erase a hardrive without using `rm -rf /`, get to know some of them.... And as was pointed out in the results of their resent challenge, removing a file doesn't necessarily mean that it has been erased. *grin*
Quick poll, raise your hand if you inspect EVERY piece of software you install for security problems. I thought so.
If are going to be that paranoided, we should do one of two things: 1) Throw our computers away and never use them again because we don't know what we might be installing. 2) Go back to the time when men were men and everyone wrote their own programs, compilers, shells, etc.
Give me a break...
Why don't you ask the "resident's" of Area 51.
But when the 2.2.x kernels have a _BIG_ security hole that allows users to exploit it against _ANY_ SUID binary, well that must not be news worthy...
How many people _REALLY_ use encrpytion on a regular basis?
And I'm not talking about ecryption that is fairly transparent to the user, such as SSL or SSH. I mean, how many people go out of their way to encrypt every email they send? Not many. With all the people in this world who send email, I'd be surprised if one percent or two actually make a habit of encrypting email. And that's being generous.
How many of those that do use encryption use it for other than legal purposes? I bet that the percentage he higher than those who send email without encryption. Then law-enforcement officials step in and do one of the things they are best at (regardless on how illegal it may be), stereotyping. With that they can make broad claims such as "Criminals are more likely to use encryption when sending email." Regardless that there is no evidence to back that up. They do this to help fight crime by narrowing the focus of their resources.
The media and politicians take general statements such as the one above and distort it until it suits there own purposes. "Only criminals use encryption!" What's really scarey is the average citizen will not question such statements and accept them as being true! If they do question it, it along the lines of "I don't use encryption, my friends don't use encryption, so it must be true."
"When the Feds -- be they CIA, FBI, NSA, or Treasury Department -- discuss crypto, they make it sound as if anyone using it must be a child pornographer, drug smuggler, or terrorist."
Statements like that, as disheartening as they are, don't really surprise me. Don't be surprised either when politicians start passing laws making the use of encryption to further criminal activity a crime. Yeah, it sounds stupid, but laws similar to that already exist.
I can imagine that there are thousands of people all over the world running `strings` on all of MS's programs to see what other gems they can find.
The payoffs at slot machines is determined by the odds that something (say, three cherries in a row) might happen. The more likely something will happen, the less the payoff will be. So what would the payoff for three blue-screens of death be?
You might get your quarter back.
[snip]
I'm so glad that the (former) American Colonies got fed up with this a long time ago and did the sensible thing.
hmmm... yeah...
Can you say DMCA or UTICA?
MirCorp dumps Mir station by michael on Tue Dec 12, '00 12:17 PM MST 34
At Last, Mir to be Ditched by CmdrTaco on Thu Nov 16, '00 07:45 AM MST 267
Mir To Crash Into Pacific by Hemos on Mon Oct 23, '00 08:48 AM MST 282
Mir Likely To Be Deorbited [Updated] by timothy on Tue Oct 03, '00 12:06 PM MST 321
Well if you would take the time to verify a story submission, they wouldn't have to tell you what a dumbass you are. They didn't use the word BETA because it has not been released as a beta yet.
GET_A_CLUE_SLASHDOT.TXT.
While you are at it, checkout the topic at #slackware on irc.openprojects.net.