Greetings folks;
In doing some checking of a web server, we found an irc port open on 31377, one of the black hatters favorites. A port that portsentry was supposed to be rejecting but wasn't.
We stumbled over several items over the last few days, but the most obvious one was a directory called .sk, located in /usr/share/misc.
Its payload seemed fairly simple, to make an underground irc chat server out of the box.
It does this with a shell script that echos several kilobytes of octal strings to gzip in the unpack mode > to a file in the local directory called .sk, and it contains a login replacement also. We did not find that login was the one installed however. Which may be a clue that theres even more smoke in this camp than what we've found yet.
The execution installs it by cp .sk /usr/bin/apmd, but puts it in /usr/bin as opposed to the real apmd's location of /usr/sbin, and adds a starter line so its enabled on boot to something we haven't found yet. It also appears to start a third instance of portsentry somehow.
We've cut our bandwidth use in half by getting rid of that. We also checked the logs and added several dozen more addresses to /etc/hosts.deny, including many script based password guess attempts that didn't get in. And put portsentry in its most paranoid anal mode with a few additions yet.
Just thought everybody would like to know about this bit of black hat tomfoolery.
Gene Heskett wrote:
Greetings folks;
In doing some checking of a web server, we found an irc port open on 31377, one of the black hatters favorites. A port that portsentry was supposed to be rejecting but wasn't.
We stumbled over several items over the last few days, but the most obvious one was a directory called .sk, located in /usr/share/misc.
Its payload seemed fairly simple, to make an underground irc chat server out of the box.
It does this with a shell script that echos several kilobytes of octal strings to gzip in the unpack mode > to a file in the local directory called .sk, and it contains a login replacement also. We did not find that login was the one installed however. Which may be a clue that theres even more smoke in this camp than what we've found yet.
The execution installs it by cp .sk /usr/bin/apmd, but puts it in /usr/bin as opposed to the real apmd's location of /usr/sbin, and adds a starter line so its enabled on boot to something we haven't found yet. It also appears to start a third instance of portsentry somehow.
We've cut our bandwidth use in half by getting rid of that. We also checked the logs and added several dozen more addresses to /etc/hosts.deny, including many script based password guess attempts that didn't get in. And put portsentry in its most paranoid anal mode with a few additions yet.
Just thought everybody would like to know about this bit of black hat tomfoolery.
Thanks for the heads-up! Does rkhunter find this crap ?
Regards,
John
On Fri, 2006-03-31 at 13:02 -0500, Gene Heskett wrote:
Greetings folks;
In doing some checking of a web server, we found an irc port open on 31377, one of the black hatters favorites. A port that portsentry was supposed to be rejecting but wasn't.
We stumbled over several items over the last few days, but the most obvious one was a directory called .sk, located in /usr/share/misc.
Your subject says "new rootkit" but you haven't said anything about a "root kit" per se, just a backdoor. That ".sk" directory could be (sounds like) the SK rootkit but I would not have expected you to find it so easily (unless you used something like chrootkit or rkhunter).
If you haven't run them, run both chrootkit and rkhunter and let us know what they turn up. They will identify, by name, rootkits they find. If you turned that rootkit so easily, it's entirely possible that you've still got a rootkit on there that IS effectively hiding itself (essence of a rootkit is "stealth", not just hiding in a . directory).
Both are available in FC Extras. I can highly recommend them both.
Its payload seemed fairly simple, to make an underground irc chat server out of the box.
It does this with a shell script that echos several kilobytes of octal strings to gzip in the unpack mode > to a file in the local directory called .sk, and it contains a login replacement also. We did not find that login was the one installed however. Which may be a clue that theres even more smoke in this camp than what we've found yet.
The execution installs it by cp .sk /usr/bin/apmd, but puts it in /usr/bin as opposed to the real apmd's location of /usr/sbin, and adds a starter line so its enabled on boot to something we haven't found yet. It also appears to start a third instance of portsentry somehow.
We've cut our bandwidth use in half by getting rid of that. We also checked the logs and added several dozen more addresses to /etc/hosts.deny, including many script based password guess attempts that didn't get in. And put portsentry in its most paranoid anal mode with a few additions yet.
Just thought everybody would like to know about this bit of black hat tomfoolery.
-- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
We've cut our bandwidth use in half by getting rid of that. We also checked the logs and added several dozen more addresses to /etc/hosts.deny, including many script based password guess attempts that didn't get in. And put portsentry in its most paranoid anal mode with a few additions yet.
Might have been set up to host a botnet. A hacker will set up a rogue IRC server and then point his army of infected bots to it for instructions. So you'll find a channel with thousands of users in a room, but nobody talking. What you have are all infected machines monitoring the channel for commands from the hacker. This gives the hacker a few layers of protection so very, very difficult to catch. They use these botnets to distribute spam, launch DDOS, or whatever else their imagination came come up with. Either of those would contribute to an increase in bandwidth usage.
Jacques B.
On Friday 31 March 2006 14:08, Jacques B. wrote:
We've cut our bandwidth use in half by getting rid of that. We also checked the logs and added several dozen more addresses to /etc/hosts.deny, including many script based password guess attempts that didn't get in. And put portsentry in its most paranoid anal mode with a few additions yet.
Might have been set up to host a botnet. A hacker will set up a rogue IRC server and then point his army of infected bots to it for instructions. So you'll find a channel with thousands of users in a room, but nobody talking. What you have are all infected machines monitoring the channel for commands from the hacker. This gives the hacker a few layers of protection so very, very difficult to catch. They use these botnets to distribute spam, launch DDOS, or whatever else their imagination came come up with. Either of those would contribute to an increase in bandwidth usage.
Humm, we were in fact subjected to a DDOS attack early last sunday morning, which lead to the traffic servers demise & rebuild. Got us listed at spamcop & our mail died.
Jacques B.
On Fri, 2006-03-31 at 13:20, Gene Heskett wrote:
They use these botnets to distribute spam, launch DDOS, or whatever else their imagination came come up with. Either of those would contribute to an increase in bandwidth usage.
Humm, we were in fact subjected to a DDOS attack early last sunday morning, which lead to the traffic servers demise & rebuild. Got us listed at spamcop & our mail died.
Or more likely, your box was participating in a DDOS. Do you have any idea what exploit might have been used to install the programs you found?
On Fri, 2006-03-31 at 13:39 -0600, Les Mikesell wrote:
On Fri, 2006-03-31 at 13:20, Gene Heskett wrote:
They use these botnets to distribute spam, launch DDOS, or whatever else their imagination came come up with. Either of those would contribute to an increase in bandwidth usage.
Humm, we were in fact subjected to a DDOS attack early last sunday morning, which lead to the traffic servers demise & rebuild. Got us listed at spamcop & our mail died.
Or more likely, your box was participating in a DDOS. Do you have any idea what exploit might have been used to install the programs you found?
---- My money is on sshd - somebody with a weak password.
Craig
On Friday 31 March 2006 15:19, Craig White wrote:
On Fri, 2006-03-31 at 13:39 -0600, Les Mikesell wrote:
On Fri, 2006-03-31 at 13:20, Gene Heskett wrote:
They use these botnets to distribute spam, launch DDOS, or whatever else their imagination came come up with. Either of those would contribute to an increase in bandwidth usage.
Humm, we were in fact subjected to a DDOS attack early last sunday morning, which lead to the traffic servers demise & rebuild. Got us listed at spamcop & our mail died.
Or more likely, your box was participating in a DDOS. Do you have any idea what exploit might have been used to install the programs you found?
My money is on sshd - somebody with a weak password.
We found a couple that were downright stupid/dumb/assinine/all_of_the_above.
Fixed, with a cluex4 upside the head to the parties involved.
Craig
On Fri, 2006-03-31 at 18:30 -0500, Gene Heskett wrote:
On Friday 31 March 2006 15:19, Craig White wrote:
On Fri, 2006-03-31 at 13:39 -0600, Les Mikesell wrote:
On Fri, 2006-03-31 at 13:20, Gene Heskett wrote:
They use these botnets to distribute spam, launch DDOS, or whatever else their imagination came come up with. Either of those would contribute to an increase in bandwidth usage.
Humm, we were in fact subjected to a DDOS attack early last sunday morning, which lead to the traffic servers demise & rebuild. Got us listed at spamcop & our mail died.
Or more likely, your box was participating in a DDOS. Do you have any idea what exploit might have been used to install the programs you found?
My money is on sshd - somebody with a weak password.
We found a couple that were downright stupid/dumb/assinine/all_of_the_above.
Fixed, with a cluex4 upside the head to the parties involved.
---- users do what users do
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
Craig
Craig White wrote:
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
There is quite a deal of well-reasoned debate about what constitutes a good password.
First, one needs to be able to remember it without writing it down. This meets Windows AD complexity requirements,
10:72:94:e5:64:d5:68:51:d1:55:c0:2b:e5:4e:7f:fa
but I defy anyone to remember it any time soon!
"bismcoles" would probably be easy for Bill Smith to remember, and would certainly defy any dictionary attack. As would "bluewatermelon."
The expect package has a password generator that creates passwords like this, but again they're hard to remember: "et3tUfGd."
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
On Sat, 2006-04-01 at 08:42 +0800, John Summerfield wrote:
Craig White wrote:
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
There is quite a deal of well-reasoned debate about what constitutes a good password.
First, one needs to be able to remember it without writing it down. This meets Windows AD complexity requirements,
10:72:94:e5:64:d5:68:51:d1:55:c0:2b:e5:4e:7f:fa
---- of course Windows computers keep the hash lying around which is fairly easily cracked ;-) ----
but I defy anyone to remember it any time soon!
"bismcoles" would probably be easy for Bill Smith to remember, and would certainly defy any dictionary attack. As would "bluewatermelon."
The expect package has a password generator that creates passwords like this, but again they're hard to remember: "et3tUfGd."
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
---- that's why you actually have think about what you are doing when you permit shell account access on a system that is exposed to the Internet. Password complexity is but one part of the equation. The other part is whether you actually have to provide shell access. In this case, it's clear that they neither considered methods to get what they wanted done without shell accounts, password complexity and they even provided a compiler on the system which should have really been just a firewall, but I'm sure that the 'crackers' appreciated the thoughtful touch of a compiler so they could compile their programs.
I hear people talk about the lack of security in Windows but it seems to me, exposing a Linux system to the Internet with shell accounts and weak passwords is far more insecure than a typical Windows system. This kind of system administration will give Linux a bad rap.
Craig
On Sat, 2006-04-01 at 10:28, Craig White wrote:
I hear people talk about the lack of security in Windows but it seems to me, exposing a Linux system to the Internet with shell accounts and weak passwords is far more insecure than a typical Windows system.
There's about 50,000 reasons you are wrong, mostly in the form of windows viruses that attack the rpc and similar services. On windows you don't need the equivalent of shell access since you can do anything through the remote management console. As long as unpatched exploits exist (and they are still being found), passwords don't matter. Even without exploits, anything running with domain admin privileges can do anything/anywhere and if you don't have a domain the same is true for machines that share the same admin password. Thus even if the rpc, netbios, and http ports are firewalled, if you can get an admin to execute a trojan or open an email that auto-executes, you've got access to the whole network.
Not that your point about bad passwords is any less valid... The missing piece on linux is an option to rate-limit password guessing in ssh and automatically blacklist addresses that fail more than a few times. There are some add-on wrappers, but sshd should do it by itself with some sane defaults.
On Sat, 2006-04-01 at 11:19 -0600, Les Mikesell wrote:
On Sat, 2006-04-01 at 10:28, Craig White wrote:
I hear people talk about the lack of security in Windows but it seems to me, exposing a Linux system to the Internet with shell accounts and weak passwords is far more insecure than a typical Windows system.
There's about 50,000 reasons you are wrong, mostly in the form of windows viruses that attack the rpc and similar services. On windows you don't need the equivalent of shell access since you can do anything through the remote management console. As long as unpatched exploits exist (and they are still being found), passwords don't matter. Even without exploits, anything running with domain admin privileges can do anything/anywhere and if you don't have a domain the same is true for machines that share the same admin password. Thus even if the rpc, netbios, and http ports are firewalled, if you can get an admin to execute a trojan or open an email that auto-executes, you've got access to the whole network.
---- but Microsoft is learning - I suspect you haven't used a Windows 2003 server lately because they have made it painful to do web browsing.
Your point does assume that one is actually using the computer to do web browsing and email and that would be plainly stupid on a Windows server that is exposed to the Internet.
On top of that, and clearly getting way off the subject, I make sure that all my Windows users are restricted accounts just because I don't have the time or the energy to continually clean up the mess that comes with running Windows as a privileged account.
I'm not stating that Windows is secure and poor administration techniques on any OS are going to get people into a world of hurt...I'm interested in raising the level of awareness for Linux users since their skill sets or lack thereof might actually impact the perception of others who don't understand and think that someone that knows how to access a shell are skilled computer administrators and we often see evidence that this isn't the case right here on the list. Hence this thread - which evidently started as a warning to the users of this list, which upon the smallest amount of inspection demonstrated that the administrators of this system were their own worst enemies...no firewall system, no dmz, unnecessary shell accounts, weak passwords, poor ssh implementation, etc. Add them all together and you've got a compromised box where the system admin starts to blunder about blaming 'spoiled users' because of the simplified passwords.
This is the bottom line...if you are going to expose a system to the public...
- use a commercial firewall if you don't have a thorough understanding of what constitutes a firewall computer that you can assemble yourself. A firewall system should not have shell accounts, compilers, etc.
- put exposed servers in a DMZ if you care about the data on your LAN because a compromised system on your LAN should cause you to call in a full security audit which would be time consuming and expensive. Why subject your LAN to authorized use?
- investigate methodologies that don't require shell access. If all people need to do is upload documents, try using anonymous ftp and script a 'scrape' of the uploaded documents from the upload directory to be mailed/copied elsewhere. If that isn't feasible, write a php/perl/ruby html page that allows users to html upload files and does proper notification to users that file has been uploaded. Shell access is rarely ever needed on an exposed system.
- use a central authentication mechanism such as kerberos, LDAP, (or better yet, the combination of the two) where you can set up a password policy once and have it apply everywhere. If you are going to put shell access on publicly exposed systems, you must learn to require strong passwords, either by policy or by control.
- learn to configure ssh to block incessant attempts by others to break in - many such methods have been discussed on list.
Craig
From: "Les Mikesell" lesmikesell@gmail.com
On Sat, 2006-04-01 at 10:28, Craig White wrote:
I hear people talk about the lack of security in Windows but it seems to me, exposing a Linux system to the Internet with shell accounts and weak passwords is far more insecure than a typical Windows system.
There's about 50,000 reasons you are wrong, mostly in the form of windows viruses that attack the rpc and similar services. On windows you don't need the equivalent of shell access since you can do anything through the remote management console. As long as unpatched exploits exist (and they are still being found), passwords don't matter. Even without exploits, anything running with domain admin privileges can do anything/anywhere and if you don't have a domain the same is true for machines that share the same admin password. Thus even if the rpc, netbios, and http ports are firewalled, if you can get an admin to execute a trojan or open an email that auto-executes, you've got access to the whole network.
Not that your point about bad passwords is any less valid... The missing piece on linux is an option to rate-limit password guessing in ssh and automatically blacklist addresses that fail more than a few times. There are some add-on wrappers, but sshd should do it by itself with some sane defaults.
Even more effective is firewall them off for too many "syn" attempts in too little time. Then have a recovery function to handle brain dead sales creatures by having the block decay away with time.
{^_^}
Les Mikesell wrote:
On Sat, 2006-04-01 at 10:28, Craig White wrote:
I hear people talk about the lack of security in Windows but it seems to me, exposing a Linux system to the Internet with shell accounts and weak passwords is far more insecure than a typical Windows system.
There's about 50,000 reasons you are wrong, mostly in the form
I don't know how many systems there are with the root password being "root", but I have personal knowlege of several hundred. And they are open, with a modem set to "autoanswer".
of windows viruses that attack the rpc and similar services.
His point is, I believe, that *no* system is inherently secure, unless the security is physical access. And, no computer is inherently insecure.
I have an MSDOS machine which is absolutely secure. More secure than any Linux machine with external access ever could hope to be. It has no cable connected to anything outside my house, except for the power cable. (And that goes through an UPS :-)
And, no system which has an external connection is absolutely secure, no matter what OS it runs (or even if it doesn't run an OS).
[snip]
Not that your point about bad passwords is any less valid... The missing piece on linux is an option to rate-limit password guessing in ssh and automatically blacklist addresses that fail more than a few times. There are some add-on wrappers, but sshd should do it by itself with some sane defaults.
There is no such thing as a system which only has "one missing piece". All systems without physical access level security have missing the one key piece of security, physical access. Any system with a point of ingress like a modem, regardless of how many layers of software "guard" the machine, are insecure, full stop. Once one has accepted that, then it is a matter of *degree* of security, not a matter of security. Some systems are easier to achieve a given level of security than others. MSDOS, for example, is easier to secure than Linux, since unless one has done something foolish like a CTTY COM1, no one can issue commands via a modem. And if no software is listening to the modem, as it is not in MSDOS unless one installs such software, it remains relatively secure.
Mike
On Tue, 2006-04-04 at 00:57 -0500, Mike McCarty wrote:
Some systems are easier to achieve a given level of security than others. MSDOS, for example, is easier to secure than Linux, since unless one has done something foolish like a CTTY COM1, no one can issue commands via a modem. And if no software is listening to the modem, as it is not in MSDOS unless one installs such software, it remains relatively secure.
I don't have a single Linux box here that listens to the modem. I'd have to install a service to do so. Your MS-DOS box is no more secure than any of them, for that point of attack.
Tim wrote:
On Tue, 2006-04-04 at 00:57 -0500, Mike McCarty wrote:
Some systems are easier to achieve a given level of security than others. MSDOS, for example, is easier to secure than Linux, since unless one has done something foolish like a CTTY COM1, no one can issue commands via a modem. And if no software is listening to the modem, as it is not in MSDOS unless one installs such software, it remains relatively secure.
I don't have a single Linux box here that listens to the modem. I'd have to install a service to do so. Your MS-DOS box is no more secure than any of them, for that point of attack.
I respectfully disagree with you on this point. Your Linux machine has a device driver for that device, while my MSDOS machine does not. So you *do* have software listening to that device, which software potentially has security compromising defects. I have no software on my MSDOS machine which listens to the serial port. So if I install a modem on it, it remains relatively secure.
Again, any machine which has an external connection has only *relative* security. My claim is that an MSDOS machine with a modem is relatively more secure than a Linux machine with a modem, but not that it is secure. The only real security is physical access. For serious security, one needs the power source as well as the computer and everything it connects to surrounded by a Faraday cage. Video displays can be snooped from a distance of tens of feet unless caged.
Mike
Mike McCarty wrote:
Tim wrote:
I don't have a single Linux box here that listens to the modem. I'd have to install a service to do so. Your MS-DOS box is no more secure than any of them, for that point of attack.
I respectfully disagree with you on this point. Your Linux machine has a device driver for that device, while my MSDOS machine does not. So you *do* have software listening to that device, which software potentially has security compromising defects. I have no software on my MSDOS machine which listens to the serial port. So if I install a modem on it, it remains relatively secure.
I fail the see the difference between the Linux driver for a serial port, and the DOS driver for COM ports, at least as far as security goes. Nether driver does anything unless there is a program accessing them. The fact that the serial driver is built in with MS-DOS, and may be loadable under Linux does not make much difference. If anything, Linux without the driver loaded would be slightly more secure.
Now, if you have unusual serial ports under DOS< you may have to load extra drivers to use them. I have a couple of multi-port serial cards that need them. But the drivers for COM1 and COM2 are standard in all versions of DOS. Most also have defaults for COM3 and COM4.
The thing that you are overlooking is that DOS has drivers for most of the standard hardware ether built in, or accessible through the system BIOS. If anything, accessing hardware through the system BIOS can be more of a security risk. You never really know what is in the BIOS. It is probably safe, as long as you are careful about updates.
Mikkel
Mikkel L. Ellertson wrote:
Mike McCarty wrote:
Tim wrote:
I don't have a single Linux box here that listens to the modem. I'd have to install a service to do so. Your MS-DOS box is no more secure than any of them, for that point of attack.
I respectfully disagree with you on this point. Your Linux machine has a device driver for that device, while my MSDOS machine does not. So you *do* have software listening to that device, which software potentially has security compromising defects. I have no software on my MSDOS machine which listens to the serial port. So if I install a modem on it, it remains relatively secure.
I fail the see the difference between the Linux driver for a serial port, and the DOS driver for COM ports, at least as far as security goes. Nether driver does anything unless there is a program
You are right, in regards to the software itself. The difference is that MSDOS does not automatically install device drivers for COM ports, whereas Linux does.
accessing them. The fact that the serial driver is built in with MS-DOS, and may be loadable under Linux does not make much
There is no built-in serial driver in MSDOS. MSDOS sits on top of the BIOS. The drivers themselves simply make BIOS calls. Unless some software makes a call to the driver, then the COM port just sits.
difference. If anything, Linux without the driver loaded would be slightly more secure.
I don't follow this, but certainly Linux w/o the driver installed would be as secure as MSDOS.
[snip]
The thing that you are overlooking is that DOS has drivers for most of the standard hardware ether built in, or accessible through the system BIOS. If anything, accessing hardware through the system BIOS
If my MSDOS machine were connected, and someone bombarded the serial port, all that would happen is that the bits would fall on the floor, and the overrun error bit would get set in the UART. With Linux, interrupts would be generated, and the driver would accept the bytes, buffer them, and eventually dump the input. (Unless something has changed since the last time I looked at the Linux serial drivers.)
can be more of a security risk. You never really know what is in the BIOS. It is probably safe, as long as you are careful about updates.
Whatever is in the BIOS, it is still there when Linux is loaded.
Any time there is physical access, there is only *relative* security.
Mike
Mike McCarty wrote:
Mikkel L. Ellertson wrote:
Mike McCarty wrote:
Tim wrote:
I don't have a single Linux box here that listens to the modem. I'd have to install a service to do so. Your MS-DOS box is no more secure than any of them, for that point of attack.
I respectfully disagree with you on this point. Your Linux machine has a device driver for that device, while my MSDOS machine does not. So you *do* have software listening to that device, which software potentially has security compromising defects. I have no software on my MSDOS machine which listens to the serial port. So if I install a modem on it, it remains relatively secure.
I fail the see the difference between the Linux driver for a serial port, and the DOS driver for COM ports, at least as far as security goes. Nether driver does anything unless there is a program
You are right, in regards to the software itself. The difference is that MSDOS does not automatically install device drivers for COM ports, whereas Linux does.
accessing them. The fact that the serial driver is built in with MS-DOS, and may be loadable under Linux does not make much
There is no built-in serial driver in MSDOS. MSDOS sits on top of the BIOS. The drivers themselves simply make BIOS calls. Unless some software makes a call to the driver, then the COM port just sits.
Are you sure about that? As far as I know, the BIOS does not know about serial ports. The settings for I/O and IRQ for a COM port are part of DOS< and not a BIOS setting. You can change them, and swap COM1 and COM2, I have a DOS utility that does this around here somewhere. It will also swap around LPT settings.
difference. If anything, Linux without the driver loaded would be slightly more secure.
I don't follow this, but certainly Linux w/o the driver installed would be as secure as MSDOS.
[snip]
The thing that you are overlooking is that DOS has drivers for most of the standard hardware ether built in, or accessible through the system BIOS. If anything, accessing hardware through the system BIOS
If my MS-DOS machine were connected, and someone bombarded the serial port, all that would happen is that the bits would fall on the floor, and the overrun error bit would get set in the UART. With Linux, interrupts would be generated, and the driver would accept the bytes, buffer them, and eventually dump the input. (Unless something has changed since the last time I looked at the Linux serial drivers.)
From what I remember, the IRQs are not enabled in ether OS until
something opens the port. Once you open the port, both DOS and Linux process the IRQ. Both have code to handle buffer overrun.
can be more of a security risk. You never really know what is in the BIOS. It is probably safe, as long as you are careful about updates.
Whatever is in the BIOS, it is still there when Linux is loaded.
It is still there, but Linux does not use the BIOS to access the hardware. Code that is not executed is not a security risk. DOS uses the BIOS for things like disk access, video access, etc. Now, when you get into ACPI, that is another story. Linux may use the ACPI code, while DOS does not.
Any time there is physical access, there is only *relative* security.
Mike
This is very true. But the risk of hooking a modem to a Linux machine by itself is no greater then hooking one to a DOS machine. The risk depends on the software you use to access the modem. Using a FAX sending program on Linux is a lot less risk then running PC Anywhere on a DOS machine. (Yes, there was a version for DOS.)
Mikkel
Mikkel L. Ellertson wrote:
Mike McCarty wrote:
[snip]
I fail the see the difference between the Linux driver for a serial port, and the DOS driver for COM ports, at least as far as security goes. Nether driver does anything unless there is a program
You are right, in regards to the software itself. The difference is that MSDOS does not automatically install device drivers for COM ports, whereas Linux does.
accessing them. The fact that the serial driver is built in with MS-DOS, and may be loadable under Linux does not make much
There is no built-in serial driver in MSDOS. MSDOS sits on top of the BIOS. The drivers themselves simply make BIOS calls. Unless some software makes a call to the driver, then the COM port just sits.
Are you sure about that? As far as I know, the BIOS does not know about serial ports. The settings for I/O and IRQ for a COM port are
I am absolutely certain.
part of DOS< and not a BIOS setting. You can change them, and swap COM1 and COM2, I have a DOS utility that does this around here somewhere. It will also swap around LPT settings.
MSDOS does *not* use interrupt driven I/O on those ports. It uses BIOS calls, specifically INT 14h. For example, from Ralph Brown's interrupt list
INT 14 - SERIAL - INITIALIZE PORT AH = 00h AL = port parameters bits 7-5 data rate (110,150,300,600,1200,2400,4800,9600 bps) bits 4-3 parity (00 or 10 = none, 01 = odd, 11 = even) bit 2 stop bits (set = 2, clear = 1) bits 1-0 data bits (00 = 5, 01 = 6, 10 = 7, 11 = 8) DX = port number (00h-03h) (04h-43h for Digiboard XAPCM232.SYS) Return: AH = line status (see AH=03h) FFh if error on Digiboard XAPCM232.SYS AL = modem status (see AH=03h) Notes: default handler is at F000h:E739h in IBM PC and 100% compatible BIOSes since the PCjr supports a maximum of 4800 bps, attempting to set 9600 bps will result in 4800 bps various network and serial-port drivers support the standard BIOS functions with interrupt-driven I/O instead of the BIOS's polled I/O the 04/08/93 Compaq system ROM uses only the low two bits of DX SeeAlso: AH=04h"SERIAL",AH=04h"MultiDOS",AH=05h"SERIAL",AH=57h SeeAlso: AX=8000h"ARTICOM",AH=81h"COMM-DRV",AH=82h"COURIERS",AH=8Ch
[snip]
From what I remember, the IRQs are not enabled in ether OS until
something opens the port. Once you open the port, both DOS and Linux process the IRQ. Both have code to handle buffer overrun.
MSDOS does not enable interrupts on the COM ports. The code is all passive, driven by the application making read/write requests. Linux drivers (the ones I am aware of) enable/disable interrupts based on open/close requests. The fact that they *can* enable means that there is a possibility of a defect causing them to enable under incorrect circumstances. The BIOS and MSDOS have no code to do that, so it can't be done inadvertently.
can be more of a security risk. You never really know what is in the BIOS. It is probably safe, as long as you are careful about updates.
Whatever is in the BIOS, it is still there when Linux is loaded.
It is still there, but Linux does not use the BIOS to access the hardware. Code that is not executed is not a security risk. DOS uses
Precisely. And unless an application invokes MSDOS, it will never do anything to the serial port, nor will the BIOS.
[snip]
Any time there is physical access, there is only *relative* security.
Mike
This is very true. But the risk of hooking a modem to a Linux machine by itself is no greater then hooking one to a DOS machine.
If there is more code, there is more exposure. MSDOS has much less code than Linux and the Linux drivers for the serial ports.
The risk depends on the software you use to access the modem. Using a FAX sending program on Linux is a lot less risk then running PC Anywhere on a DOS machine. (Yes, there was a version for DOS.)
Certainly, PC anywhere is a serious security risk.
Please don't lecture me about systems programming for MSDOS, as I wrote my first interrupt-driven serial port handler for MSDOS in 1985.
Mike
On Fri, 2006-04-07 at 16:03, Mike McCarty wrote:
MSDOS does *not* use interrupt driven I/O on those ports. It uses BIOS calls, specifically INT 14h. For example, from Ralph Brown's interrupt list
I don't see how trusting bios equates to secure code.
Precisely. And unless an application invokes MSDOS, it will never do anything to the serial port, nor will the BIOS.
You can say the same for the keyboard - and the input devices are more or less interchangeable. The application might be COPY.
If there is more code, there is more exposure. MSDOS has much less code than Linux and the Linux drivers for the serial ports.
I think you need to take quality of code into account in a statement like that.
Les Mikesell wrote:
On Fri, 2006-04-07 at 16:03, Mike McCarty wrote:
MSDOS does *not* use interrupt driven I/O on those ports. It uses BIOS calls, specifically INT 14h. For example, from Ralph Brown's interrupt list
I don't see how trusting bios equates to secure code.
It doesn't. And I didn't say so. Any system with external connections only enjoys relative security. I don't "trust" BIOS. But the BIOS code is there regardless of whether Linux or MSDOS or whatever OS (or even no OS) sits on top of it.
Precisely. And unless an application invokes MSDOS, it will never do anything to the serial port, nor will the BIOS.
You can say the same for the keyboard - and the input devices are more or less interchangeable. The application might be COPY.
I don't follow the point.
If there is more code, there is more exposure. MSDOS has much less code than Linux and the Linux drivers for the serial ports.
I think you need to take quality of code into account in a statement like that.
Certainly. But no matter how carefully crafted, more code equates to more exposure.
Mike
On Fri, 2006-04-07 at 15:41 -0500, Mikkel L. Ellertson wrote:
Mike McCarty wrote:
Mikkel L. Ellertson wrote:
Mike McCarty wrote:
Tim wrote:
I don't have a single Linux box here that listens to the modem. I'd have to install a service to do so. Your MS-DOS box is no more secure than any of them, for that point of attack.
I respectfully disagree with you on this point. Your Linux machine has a device driver for that device, while my MSDOS machine does not. So you *do* have software listening to that device, which software potentially has security compromising defects. I have no software on my MSDOS machine which listens to the serial port. So if I install a modem on it, it remains relatively secure.
I fail the see the difference between the Linux driver for a serial port, and the DOS driver for COM ports, at least as far as security goes. Nether driver does anything unless there is a program
You are right, in regards to the software itself. The difference is that MSDOS does not automatically install device drivers for COM ports, whereas Linux does.
accessing them. The fact that the serial driver is built in with MS-DOS, and may be loadable under Linux does not make much
There is no built-in serial driver in MSDOS. MSDOS sits on top of the BIOS. The drivers themselves simply make BIOS calls. Unless some software makes a call to the driver, then the COM port just sits.
Are you sure about that? As far as I know, the BIOS does not know about serial ports. The settings for I/O and IRQ for a COM port are part of DOS< and not a BIOS setting. You can change them, and swap COM1 and COM2, I have a DOS utility that does this around here somewhere. It will also swap around LPT settings.
The bios *does* know about the serial ports. It has to make them available to the OS. If it did not know about and initialize the hardware, how could there be settings in bios to enable/disable the ports? Every bios I have used for many years has that option available.
The bios does not use them, nor contain drivers, but it does initialize the hardware and hand it off to the OS.
OTOH, bios can and does use the ethernet ports for PXE boot.
difference. If anything, Linux without the driver loaded would be slightly more secure.
I don't follow this, but certainly Linux w/o the driver installed would be as secure as MSDOS.
[snip]
The thing that you are overlooking is that DOS has drivers for most of the standard hardware ether built in, or accessible through the system BIOS. If anything, accessing hardware through the system BIOS
If my MS-DOS machine were connected, and someone bombarded the serial port, all that would happen is that the bits would fall on the floor, and the overrun error bit would get set in the UART. With Linux, interrupts would be generated, and the driver would accept the bytes, buffer them, and eventually dump the input. (Unless something has changed since the last time I looked at the Linux serial drivers.)
From what I remember, the IRQs are not enabled in ether OS until
something opens the port. Once you open the port, both DOS and Linux process the IRQ. Both have code to handle buffer overrun.
can be more of a security risk. You never really know what is in the BIOS. It is probably safe, as long as you are careful about updates.
Whatever is in the BIOS, it is still there when Linux is loaded.
It is still there, but Linux does not use the BIOS to access the hardware. Code that is not executed is not a security risk. DOS uses the BIOS for things like disk access, video access, etc. Now, when you get into ACPI, that is another story. Linux may use the ACPI code, while DOS does not.
Any time there is physical access, there is only *relative* security.
Mike
This is very true. But the risk of hooking a modem to a Linux machine by itself is no greater then hooking one to a DOS machine. The risk depends on the software you use to access the modem. Using a FAX sending program on Linux is a lot less risk then running PC Anywhere on a DOS machine. (Yes, there was a version for DOS.)
Mikkel
Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Mike McCarty wrote:
Mikkel L. Ellertson wrote:
Mike McCarty wrote:
Tim wrote:
I don't have a single Linux box here that listens to the modem. I'd have to install a service to do so. Your MS-DOS box is no more secure than any of them, for that point of attack.
I respectfully disagree with you on this point. Your Linux machine has a device driver for that device, while my MSDOS machine does not. So you *do* have software listening to that device, which software potentially has security compromising defects. I have no software on my MSDOS machine which listens to the serial port. So if I install a modem on it, it remains relatively secure.
I fail the see the difference between the Linux driver for a serial port, and the DOS driver for COM ports, at least as far as security goes. Nether driver does anything unless there is a program
You are right, in regards to the software itself. The difference is that MSDOS does not automatically install device drivers for COM ports, whereas Linux does.
Linux is about having the freedom to configure your system the way you want it.
I always rebuild my kernel without any serial port drivers. I don't build any modules for devices that I don't use. You can't trigger a bug in code that doesn't exist!
As a positive side effect, my kernel is about 1/2 the size of a standard Fedora kernel and lib/modules is 10 times smaller.
Regards,
John
On Fri, 2006-04-07 at 14:56 -0500, Mike McCarty wrote:
If my MSDOS machine were connected, and someone bombarded the serial port, all that would happen is that the bits would fall on the floor, and the overrun error bit would get set in the UART. With Linux, interrupts would be generated, and the driver would accept the bytes, buffer them, and eventually dump the input. (Unless something has changed since the last time I looked at the Linux serial drivers.)
Are you saying that unexpected data coming through your COM port wouldn't generate IRQ messages (COM ports have an IRQ), which would be kicking the CPU quite hard? That's not exactly a trivial thing to ignore.
From: "Tim" ignored_mailbox@yahoo.com.au
On Fri, 2006-04-07 at 14:56 -0500, Mike McCarty wrote:
If my MSDOS machine were connected, and someone bombarded the serial port, all that would happen is that the bits would fall on the floor, and the overrun error bit would get set in the UART. With Linux, interrupts would be generated, and the driver would accept the bytes, buffer them, and eventually dump the input. (Unless something has changed since the last time I looked at the Linux serial drivers.)
Are you saying that unexpected data coming through your COM port wouldn't generate IRQ messages (COM ports have an IRQ), which would be kicking the CPU quite hard? That's not exactly a trivial thing to ignore.
If you get close enough to my machines to feed high rate data into the unused serial ports on my machines that is the least of my worries, Kemo Sabe. You have physical access to my machines. At that point the only thing that can protect them from a crude level of physical attack is divine intervention.
{^_^}
On Sat, 2006-04-08 at 03:07 -0700, jdow wrote:
If you get close enough to my machines to feed high rate data into the unused serial ports on my machines that is the least of my worries, Kemo Sabe. You have physical access to my machines. At that point the only thing that can protect them from a crude level of physical attack is divine intervention.
That's true enough, though I seem to recall Mike bringing up the subject of a modem left on auto-answer. I've seen that happen. You never set it up for auto-answer, so you forget to check. Unfortunately, it was already set up that way...
Tim wrote:
On Fri, 2006-04-07 at 14:56 -0500, Mike McCarty wrote:
If my MSDOS machine were connected, and someone bombarded the serial port, all that would happen is that the bits would fall on the floor, and the overrun error bit would get set in the UART. With Linux, interrupts would be generated, and the driver would accept the bytes, buffer them, and eventually dump the input. (Unless something has changed since the last time I looked at the Linux serial drivers.)
Are you saying that unexpected data coming through your COM port wouldn't generate IRQ messages (COM ports have an IRQ), which would be kicking the CPU quite hard? That's not exactly a trivial thing to ignore.
The BIOS and MSDOS do not enable interrupts on the UART devices, hence the CPU doesn't see any requests.
Please don't lecture me about MSDOS systems programming. I wrote my first interrupt driven serial comm package for MSDOS in 1985.
Mike
Tim:
Are you saying that unexpected data coming through your COM port wouldn't generate IRQ messages (COM ports have an IRQ), which would be kicking the CPU quite hard? That's not exactly a trivial thing to ignore.
Mike McCarty:
The BIOS and MSDOS do not enable interrupts on the UART devices, hence the CPU doesn't see any requests.
Please don't lecture me about MSDOS systems programming. I wrote my first interrupt driven serial comm package for MSDOS in 1985.
Actually, I was asking a question, not giving a lecture, but since you've taken that attitude, answer this:
In the BIOS you get to set the address and IRQ that a serial port will use. You can also set power wake up options that wake up the PC if a particular IRQ is activated. If you set it to wake up when the IRQ used by the serial port is activated (i.e. an external modem wake-on-ring type of function), the PC will wake up (serial port activity causing an IRQ signal, waking up the system).
Now, *that* seems to refute your first assertion. (The serial port generated an IRQ signal, and the BIOS played a part in it.)
From: "Tim" ignored_mailbox@yahoo.com.au
Tim:
Are you saying that unexpected data coming through your COM port wouldn't generate IRQ messages (COM ports have an IRQ), which would be kicking the CPU quite hard? That's not exactly a trivial thing to ignore.
Mike McCarty:
The BIOS and MSDOS do not enable interrupts on the UART devices, hence the CPU doesn't see any requests.
Please don't lecture me about MSDOS systems programming. I wrote my first interrupt driven serial comm package for MSDOS in 1985.
Actually, I was asking a question, not giving a lecture, but since you've taken that attitude, answer this:
In the BIOS you get to set the address and IRQ that a serial port will use. You can also set power wake up options that wake up the PC if a particular IRQ is activated. If you set it to wake up when the IRQ used by the serial port is activated (i.e. an external modem wake-on-ring type of function), the PC will wake up (serial port activity causing an IRQ signal, waking up the system).
Now, *that* seems to refute your first assertion. (The serial port generated an IRQ signal, and the BIOS played a part in it.)
Tendentious Tim, what was present to RECEIVE the IRQ message and how do you know it was intercepted as a software IRQ and not a hardware signal in a gate array that was enabled by a BIOS setting? I rather suspect it would be a state machine in a gate array that is used for controlling a signal that feeds to the power supply that turns it on.
{^_-}
Tim wrote:
Tim:
Are you saying that unexpected data coming through your COM port wouldn't generate IRQ messages (COM ports have an IRQ), which would be kicking the CPU quite hard? That's not exactly a trivial thing to ignore.
Mike McCarty:
The BIOS and MSDOS do not enable interrupts on the UART devices, hence the CPU doesn't see any requests.
Please don't lecture me about MSDOS systems programming. I wrote my first interrupt driven serial comm package for MSDOS in 1985.
Actually, I was asking a question, not giving a lecture, but since
Sorry. I'm getting hit by others, so I guess I got my hackles up a little bit. I apologize.
you've taken that attitude, answer this:
In the BIOS you get to set the address and IRQ that a serial port will use. You can also set power wake up options that wake up the PC if a particular IRQ is activated. If you set it to wake up when the IRQ used
Some things are getting conflated. First, none of the serial cards I use with MSDOS can be configured this way. They all use jumpers. What you are talking about is which IRQ will be used *if* an interrupt occurs.
by the serial port is activated (i.e. an external modem wake-on-ring type of function), the PC will wake up (serial port activity causing an IRQ signal, waking up the system).
None of my systems supports any sort of sleep mode, except for a laptop which has been retired. So I'm not quite aware of where that boundary occurs. I'd think it is in the OS, not the BIOS, for a few reasons. Primarily, the OS is what knows what really needs to be saved/restored after a sleep mode shutdown.
Now, *that* seems to refute your first assertion. (The serial port generated an IRQ signal, and the BIOS played a part in it.)
As I said, I'm not expert in how this type of function works, nor how much is done in the OS and how much in the BIOS. My GUESS is that these are a function of the OS, not the BIOS. If you boot your "sleepy" system under pure MSDOS, will the sleep function still work? I trow not. Are you willing to give that a try? If you have such a system, I could easily arrange to send you a bootable floppy image which would look for whatever interrupt you have configured, and we could check for that. You'd need to be able to allow it to go to "sleep", and then generate activity on the COM port. Or even if it won't go to sleep, just let it run for a 1/2 hour and try sending it a character.
Mike
Tim:
In the BIOS you get to set the address and IRQ that a serial port will use. You can also set power wake up options that wake up the PC if a particular IRQ is activated. If you set it to wake up when the IRQ used
Mike McCarty:
Some things are getting conflated. First, none of the serial cards I use with MSDOS can be configured this way. They all use jumpers. What you are talking about is which IRQ will be used *if* an interrupt occurs.
This is a motherboard with built-in serial ports. It uses the BIOS to let you set the parameters for the I/O ports, the same as you'd use jumpers on older cards.
Yes, and it's a case of when the serial port gets some use, it generates an IRQ to get the CPUs attention. Once that happens, the CPU interrupts what it's doing and your (your own, the system, whatever) does something based on current conditions.
by the serial port is activated (i.e. an external modem wake-on-ring type of function), the PC will wake up (serial port activity causing an IRQ signal, waking up the system).
None of my systems supports any sort of sleep mode, except for a laptop which has been retired. So I'm not quite aware of where that boundary occurs. I'd think it is in the OS, not the BIOS, for a few reasons. Primarily, the OS is what knows what really needs to be saved/restored after a sleep mode shutdown.
This is a "wake" as in turn on again, no matter what the system state was (e.g. could be sleep, or soft off). And, in this case, it's a function of the motherboard. You don't even need any system software, it's done by BIOS (you could remove the hard drive), and you'd get the turned off systemboard come to life if your modem (or any other IRQ you picked upon in your BIOS power management settings) triggered a wake up event.
NB: This is different from the ring indicator in the RS-232 line. That's yet another event that can be used.
You can wake up the motherboard through the BIOS, which will *then* boot up the system (if it can). Or, you can have a halted OS that unhalts when a wake up event happens, so your OS handles it instead of the BIOS.
All in all, that goes back to the idea that if your serial port has an IRQ associated with it, which they can (*) do. Any activity on the port generates an IRQ (regardless of whether you've got software paying attention to the serial port). Such IRQs are important events that the CPU pays attention to. Now, if you haven't got software configured to do something with the event, it doesn't go and do anything. But the CPU has been interrupted to check whether it should.
Want some IRQ fun? Give someone a PS/2 mouse with an intermittent break in the lead. Nudging the cable sends a mass of IRQs thanks to the PS/2 port, which can bring Win98 to its knees for no obvious reason (especially if the mouse still appears to work). ;-)
* On boards like this, you *can* preset IRQs and addresses for a COM port to use, much the same as jumpers on ye olde systems. You set them for plug and play, where the OS will configure them (or not). Or you can set them for AUTO, where the motherboard will assign IRQs and addresses as it sees fit (which causes some older OSs no end of trouble, if they don't auto-hardware discover each bootup, as interfaces can get assigned different values each time).
Tim wrote:
This is a "wake" as in turn on again, no matter what the system state was (e.g. could be sleep, or soft off). And, in this case, it's a function of the motherboard. You don't even need any system software, it's done by BIOS (you could remove the hard drive), and you'd get the turned off systemboard come to life if your modem (or any other IRQ you picked upon in your BIOS power management settings) triggered a wake up event.
Hmm. In that case Joanne's comment is apropos. It may or may not have anything to do with interrupts.
NB: This is different from the ring indicator in the RS-232 line. That's yet another event that can be used.
You can wake up the motherboard through the BIOS, which will *then* boot up the system (if it can). Or, you can have a halted OS that unhalts when a wake up event happens, so your OS handles it instead of the BIOS.
Sounds like a reasonably complicated I/F which is likely to conceal defects. Too many fingers in the pie.
All in all, that goes back to the idea that if your serial port has an IRQ associated with it, which they can (*) do. Any activity on the port generates an IRQ (regardless of whether you've got software paying attention to the serial port). Such IRQs are important events that the
Any enabled IRQ. Normally, the chipsets emulate the old 16550 chip, which allow separate enables on Transmit Empty, Receive Full, Control Line Change (CTS, etc.).
CPU pays attention to. Now, if you haven't got software configured to do something with the event, it doesn't go and do anything. But the CPU has been interrupted to check whether it should.
In any case, perhaps the BIOS can enable interrupts. I proposed that we try an experiment. Since I'm more interested in Truth than in Being Right, what do you say I build you a bootable floppy image with an interrupt capture program I wrote several years ago, and we'll try it out?
Want some IRQ fun? Give someone a PS/2 mouse with an intermittent break in the lead. Nudging the cable sends a mass of IRQs thanks to the PS/2 port, which can bring Win98 to its knees for no obvious reason (especially if the mouse still appears to work). ;-)
- On boards like this, you *can* preset IRQs and addresses for a COM
port to use, much the same as jumpers on ye olde systems. You set them for plug and play, where the OS will configure them (or not). Or you
I'm aware of this, but thanks for the info, anyway.
[snip]
Mike
Craig White wrote:
On Sat, 2006-04-01 at 08:42 +0800, John Summerfield wrote:
Craig White wrote:
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
There is quite a deal of well-reasoned debate about what constitutes a good password.
First, one needs to be able to remember it without writing it down. This meets Windows AD complexity requirements,
10:72:94:e5:64:d5:68:51:d1:55:c0:2b:e5:4e:7f:fa
of course Windows computers keep the hash lying around which is fairly easily cracked ;-)
If you're that close to the computer, all bets are off, Linux or Windows: you don't need administrative rights to do lots of bad stuff.
but I defy anyone to remember it any time soon!
"bismcoles" would probably be easy for Bill Smith to remember, and would certainly defy any dictionary attack. As would "bluewatermelon."
The expect package has a password generator that creates passwords like this, but again they're hard to remember: "et3tUfGd."
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
that's why you actually have think about what you are doing when you permit shell account access on a system that is exposed to the Internet.
ftp and email are good ways to enumerate accounts and look for passwords. Having opened an account, then try for shell access:-\
On Friday 31 March 2006 19:42, John Summerfield wrote:
Craig White wrote:
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
There is quite a deal of well-reasoned debate about what constitutes a good password.
First, one needs to be able to remember it without writing it down. This meets Windows AD complexity requirements,
10:72:94:e5:64:d5:68:51:d1:55:c0:2b:e5:4e:7f:fa
but I defy anyone to remember it any time soon!
"bismcoles" would probably be easy for Bill Smith to remember, and would certainly defy any dictionary attack. As would "bluewatermelon."
The expect package has a password generator that creates passwords like this, but again they're hard to remember: "et3tUfGd."
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
And how does one go about turning that option on, with say a 15 minute timeout?
Gene Heskett wrote:
On Friday 31 March 2006 19:42, John Summerfield wrote:
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
And how does one go about turning that option on, with say a 15 minute timeout?
Check out pam_abl on http://www.hexten.net/pam_abl/ (SourceForge project).
On Sat, 2006-04-01 at 12:56 -0500, Neil Cherry wrote:
Gene Heskett wrote:
On Friday 31 March 2006 19:42, John Summerfield wrote:
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
And how does one go about turning that option on, with say a 15 minute timeout?
Check out pam_abl on http://www.hexten.net/pam_abl/ (SourceForge project).
If you want to go this route, both denyhosts and pam_abl are available for Fedora Extras.
Rahul
Rahul Sundaram wrote:
On Sat, 2006-04-01 at 12:56 -0500, Neil Cherry wrote:
Gene Heskett wrote:
On Friday 31 March 2006 19:42, John Summerfield wrote:
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
And how does one go about turning that option on, with say a 15 minute timeout?
Check out pam_abl on http://www.hexten.net/pam_abl/ (SourceForge project).
If you want to go this route, both denyhosts and pam_abl are available for Fedora Extras.
I've also use a Perl script to add these IP addresses to an iptables list but even with summarization I had thousands of denies. So I only allow a select few sites to get to my ssh and the attacks have completely stopped. Though I will say I'm not doing this commercially.
Hi,
You can also check this http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts
actually you can use yum to install denyhosts
yum install denyhosts
and then configure it.
regards, Guillermo.
Neil Cherry wrote:
Rahul Sundaram wrote:
On Sat, 2006-04-01 at 12:56 -0500, Neil Cherry wrote:
Gene Heskett wrote:
On Friday 31 March 2006 19:42, John Summerfield wrote:
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
And how does one go about turning that option on, with say a 15 minute timeout?
Check out pam_abl on http://www.hexten.net/pam_abl/ (SourceForge project).
If you want to go this route, both denyhosts and pam_abl are available for Fedora Extras.
I've also use a Perl script to add these IP addresses to an iptables list but even with summarization I had thousands of denies. So I only allow a select few sites to get to my ssh and the attacks have completely stopped. Though I will say I'm not doing this commercially.
Neil Cherry wrote:
Rahul Sundaram wrote:
On Sat, 2006-04-01 at 12:56 -0500, Neil Cherry wrote:
Gene Heskett wrote:
On Friday 31 March 2006 19:42, John Summerfield wrote:
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
And how does one go about turning that option on, with say a 15 minute timeout?
That's the "implemented poorly" bit. The only place I know it's implemented is at the local virtual console where the delay's quite short, not configurable that I know of, and if you time out one, there are (by default, five) others to try, and by then the original getty's accepting logins again. Worse, you can reset the counter by typing ^D as a login name.
Check out pam_abl on http://www.hexten.net/pam_abl/ (SourceForge project).
If you want to go this route, both denyhosts and pam_abl are available for Fedora Extras.
I've also use a Perl script to add these IP addresses to an iptables list but even with summarization I had thousands of denies. So I only allow a select few sites to get to my ssh and the attacks have completely stopped. Though I will say I'm not doing this commercially.
On some machines I administer remotely you need to have an account with my IAP to get past hosts.{allow,deny} with ssh, and the only other entry is via VPN: to breach that you need to know which house to burgle.
From: "Gene Heskett" gene.heskett@verizon.net
On Friday 31 March 2006 19:42, John Summerfield wrote:
Craig White wrote:
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
There is quite a deal of well-reasoned debate about what constitutes a good password.
First, one needs to be able to remember it without writing it down. This meets Windows AD complexity requirements,
10:72:94:e5:64:d5:68:51:d1:55:c0:2b:e5:4e:7f:fa
but I defy anyone to remember it any time soon!
"bismcoles" would probably be easy for Bill Smith to remember, and would certainly defy any dictionary attack. As would "bluewatermelon."
The expect package has a password generator that creates passwords like this, but again they're hard to remember: "et3tUfGd."
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
And how does one go about turning that option on, with say a 15 minute timeout?
Gene, search for prior postings I've made (and others) about the iptables recent feature. How'd you like this? "You get three syn tries in two minutes. More than that and the ssh port is locked for your IP address until the number of attempts falls below three in the last two minutes."
If you forget your password or mangle your typing three times wait about a minute and type more carefully. Then you're in and Bob's your uncle. Imagine a hacker trying to discover "abcdefgh" as a password if he only can try three times every two minutes. Since they try large batches of names and passwords all at once they'll never get more than two tries per run. And users basically never notice it, even if two are sharing the same IP connection behind a NAT firewall.
$IPTABLES -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set $IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: ' $IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset
Every couple weeks I notice some other naif has tried to attack this site. If the IP address is some place I never plan to visit the entire range of APNIC addresses is blocked. (Not much of Asia will ever get even one syn into this machine.)
{^_-}
jdow wrote:
Gene, search for prior postings I've made (and others) about the iptables recent feature. How'd you like this? "You get three syn tries in two minutes. More than that and the ssh port is locked for your IP address until the number of attempts falls below three in the last two minutes."
One system I wrote many years ago used a leaky bucket. The bucket leaked one count per minute. If a threshhold of 3 was reached, then login attempts were denied, with a message exactly like any other login failure, and each successive failure put three more counts into the bucket. So, fail, fail, ok would get you in, but fail, fail, fail would get you a three minute penalty. Each try after that, before the bucket leaked out, netted you an additional three minutes. I limited the total lockout time to one hour.
Mike
Mike McCarty wrote:
jdow wrote:
Gene, search for prior postings I've made (and others) about the iptables recent feature. How'd you like this? "You get three syn tries in two minutes. More than that and the ssh port is locked for your IP address until the number of attempts falls below three in the last two minutes."
One system I wrote many years ago used a leaky bucket. The bucket leaked one count per minute. If a threshhold of 3 was reached, then login attempts were denied, with a message exactly like any other login failure, and each successive failure put three more counts into the bucket. So, fail, fail, ok would get you in, but fail, fail, fail
Perhaps I didn't make that clear. The onset threshhold was 3, the abatement threshhold was 0.
Mike
John Summerfield wrote:
There is quite a deal of well-reasoned debate about what constitutes a good password.
"bismcoles" would probably be easy for Bill Smith to remember, and would certainly defy any dictionary attack. As would "bluewatermelon."
Both of these could be part of a dictionary attack. Consider most straight plain text to be part of a dictionary attack.
The expect package has a password generator that creates passwords like this, but again they're hard to remember: "et3tUfGd."
A better example is Blu3w4terme7on, easier to remember but you need to come up with some kind of rules for remembering it. For myself, I prefer passphrases. I find them easier to remember, such as mUst4rd&Tuna_F1sh. A silly example but I've used sillier. Sometimes funnier works well (easy to remember).
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
I've used pam_abl and it works quite well, it's 3 strikes (adjustable) and you're locked. It can automatically unlock after a setting of time and has additional features which make it pretty flexible.
John Summerfield wrote:
Craig White wrote:
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
There is quite a deal of well-reasoned debate about what constitutes a good password.
Should not be all letters. Should include at least one digit. Should include at least one "special" character. Should not include non-graphic characters (like CR, LF, CTRL-A). Should be at least 6 and preferably over 8 characters long. Should be "rememberable". Should *not* be written down anywhere.
First, one needs to be able to remember it without writing it down. This meets Windows AD complexity requirements,
Very easy to do, and yet generate "random" letters.
tbatstdgagitw
is one which I would find very easy to remember, for example. Each letter is the first letter of a word from a sentence I would find very easy to recall. This particular one is *not* one I would recommend, as it is one which might very well be tested.[1]
10:72:94:e5:64:d5:68:51:d1:55:c0:2b:e5:4e:7f:fa
but I defy anyone to remember it any time soon!
"bismcoles" would probably be easy for Bill Smith to remember, and would certainly defy any dictionary attack. As would "bluewatermelon."
Neither of these is one I would recommend, and I consider the "bismcoles" to be especially weak. Passwords containing anagrams of user names are one of the things I thought of back when I wrote my first password cracker. If a complete novice can break those, then anyone could.
The expect package has a password generator that creates passwords like this, but again they're hard to remember: "et3tUfGd."
A reasonable security system would shut down the login process for a time after some number of consecutive failed login attempts. It's a rule that's been around for a long time, it's even in Linux, but implemented poorly.
I have indeed written just such programs for telephone switches. One of them *permanently* disabled logins from the terminal with attempted compromises, requiring system supervisor manual intervention to restore.
[1] 'Twas brillig, and the slithy toves did gyre and gimble in the wabe
Mike
On Tue, 2006-04-04 at 00:46 -0500, Mike McCarty wrote:
Should include at least one "special" character.
When telling someone that, you really need to define what you mean by "special". I know the next bit goes somewhat towards that, but it's still a bit too vague. You can also get people trying to use characters that can't be used with some password systems. It would really help if password systems would accept any character that you can type on the keyboard.
Should not include non-graphic characters (like CR, LF, CTRL-A). Should be at least 6 and preferably over 8 characters long. Should be "rememberable". Should *not* be written down anywhere.
The last two being a key problem. By now, I've amassed about a dozen passwords that I just cannot remember. Even if I wanted to make memorable passwords, too many systems are so limited that you can't easily do it (e.g. passwords are too short, etc.). Then there's the problem of remembering which password belongs to what account. Writing them down, or writing down the reminder trick, becomes the only way to do so.
Should *not* be written down anywhere.
FWIW, this is no longer the recommendation. It is OK to write down your passwords as long as you keep them in a secure location. So, if you have them/it written on a picture in your wallet then it is as safe as your credit cards.
At 13:57 04/04/2006, you wrote:
Should *not* be written down anywhere.
FWIW, this is no longer the recommendation. It is OK to write down your passwords as long as you keep them in a secure location. So, if you have them/it written on a picture in your wallet then it is as safe as your credit cards.
I have dozens of passwords, all different, all of which would be impossible for me to remember.
So I virtually write them down by storing them in kwallet. That, we are told, is strongly encrypted and therefore fairly secure.
Dave F
Ed Greshko wrote:
Should *not* be written down anywhere.
FWIW, this is no longer the recommendation. It is OK to write down your passwords as long as you keep them in a secure location. So, if you have them/it written on a picture in your wallet then it is as safe as your credit cards.
Well, ok. Should not be written down anywhere which remains near an access point. The main way people break into safes is to look nearby for the combination written down. Carrying it with you would be ok. But having it taped to the underside of a desk drawer is not.
Mike
Tim wrote:
On Tue, 2006-04-04 at 00:46 -0500, Mike McCarty wrote:
Should include at least one "special" character.
When telling someone that, you really need to define what you mean by "special". I know the next bit goes somewhat towards that, but it's still a bit too vague. You can also get people trying to use characters that can't be used with some password systems. It would really help if password systems would accept any character that you can type on the keyboard.
IMO, these rules need to be enforced by the password system itself. So, exactly what constitutes a "special" character should be built into it, and if an invalid character is detected, then a useful error message should be generated.
Anyway, I wasn't trying to write out a fully comprehensive set of rules. I was simply stating what I consider to be the minimum security. Guidelines, not rules.
Another good guide is:
Enforce changing of passwords on at least a monthly basis. Do not permit re-use of old passwords.
Should not include non-graphic characters (like CR, LF, CTRL-A). Should be at least 6 and preferably over 8 characters long. Should be "rememberable". Should *not* be written down anywhere.
The last two being a key problem. By now, I've amassed about a dozen passwords that I just cannot remember. Even if I wanted to make memorable passwords, too many systems are so limited that you can't easily do it (e.g. passwords are too short, etc.). Then there's the problem of remembering which password belongs to what account. Writing them down, or writing down the reminder trick, becomes the only way to do so.
See my other message about writing down.
Mike
On 05/04/06, Mike McCarty Mike.McCarty@sbcglobal.net wrote:
Tim wrote:
On Tue, 2006-04-04 at 00:46 -0500, Mike McCarty wrote:
Should include at least one "special" character.
When telling someone that, you really need to define what you mean by "special". I know the next bit goes somewhat towards that, but it's still a bit too vague. You can also get people trying to use characters that can't be used with some password systems. It would really help if password systems would accept any character that you can type on the keyboard.
IMO, these rules need to be enforced by the password system itself. So, exactly what constitutes a "special" character should be built into it, and if an invalid character is detected, then a useful error message should be generated.
Anyway, I wasn't trying to write out a fully comprehensive set of rules. I was simply stating what I consider to be the minimum security. Guidelines, not rules.
Another good guide is:
Enforce changing of passwords on at least a monthly basis. Do not permit re-use of old passwords.
Should not include non-graphic characters (like CR, LF, CTRL-A). Should be at least 6 and preferably over 8 characters long. Should be "rememberable". Should *not* be written down anywhere.
The last two being a key problem. By now, I've amassed about a dozen passwords that I just cannot remember. Even if I wanted to make memorable passwords, too many systems are so limited that you can't easily do it (e.g. passwords are too short, etc.). Then there's the problem of remembering which password belongs to what account. Writing them down, or writing down the reminder trick, becomes the only way to do so.
See my other message about writing down.
Mike
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that!
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Sorry to be off-topic, but could someone tell a total noob what is that all about?
-- A. Helmy
Ali Helmy:
Sorry to be off-topic, but could someone tell a total noob what is that all about?
en.wikipedia.org/wiki/Rootkit
Rootkit:
A rootkit is a set of software tools frequently used by a third party (usually an intruder) after gaining access to a computer system. These tools are intended to conceal running processes, files or system data, which helps an intruder maintain access to a system without the user's knowledge. Rootkits are known to exist for a variety of operating systems such as Linux, Solaris and versions of Microsoft Windows. A computer with a rootkit on it is called a rooted computer.
From: "Mike McCarty" Mike.McCarty@sbcglobal.net
Tim wrote:
On Tue, 2006-04-04 at 00:46 -0500, Mike McCarty wrote:
Should include at least one "special" character.
When telling someone that, you really need to define what you mean by "special". I know the next bit goes somewhat towards that, but it's still a bit too vague. You can also get people trying to use characters that can't be used with some password systems. It would really help if password systems would accept any character that you can type on the keyboard.
IMO, these rules need to be enforced by the password system itself. So, exactly what constitutes a "special" character should be built into it, and if an invalid character is detected, then a useful error message should be generated.
Anyway, I wasn't trying to write out a fully comprehensive set of rules. I was simply stating what I consider to be the minimum security. Guidelines, not rules.
Another good guide is:
Enforce changing of passwords on at least a monthly basis. Do not permit re-use of old passwords.
Experience indicates that people rotate sets of four or five passwords in that case.
A major part of the whole issue is defining what kind of attacks you are likely to face. Is the attacker likely to be able to read your shadow file?
If not, as with the sshd attack that started this thread, you fall down to a second question, "How fast is the attacked able to recycle failed login requests?"
If the answer is 30 seconds then "bcdefghi" is a password that is good for over 200 years of random guessing. It might run afoul of straight dictionary attacks, though. "ShumphUz", on the other hand, would take just as long against random attacks and is order two on dictionary attacks with a dictionary of four letter pronounceable word fragments. You're probably still good for most of your life expectancy. This advantage evaporates if the shadow file is readable by the attacker. Then brute forcing an eight letter password's the work of a short exercise on a modest machine. And I've never been convinced that increasing the alphabet from 52 "letters" to 62 "letters" or even 95 "letters" is a additional huge win, especially when one presumes the odd character (non-alnum) is usually at a syllable splice. Add another character or two of pure alpha and your pretty much just as well off.
{^_^}
On Tue, 2006-04-04 at 21:58, jdow wrote:
Another good guide is:
Enforce changing of passwords on at least a monthly basis. Do not permit re-use of old passwords.
Experience indicates that people rotate sets of four or five passwords in that case.
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
On Tue, 2006-04-04 at 22:25 -0500, Les Mikesell wrote:
On Tue, 2006-04-04 at 21:58, jdow wrote:
Another good guide is:
Enforce changing of passwords on at least a monthly basis. Do not permit re-use of old passwords.
Experience indicates that people rotate sets of four or five passwords in that case.
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
---- I would presume that they don't have to be stored as plain text or reversible...they simply need to be kept around and when a new password is submitted, encryption is applied and then it is matched against the list of old passwords - much like an attempt to authenticate. I believe that is the methodology of password policy of both FDS and OpenLDAP anyway.
Craig
Les Mikesell:
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
If you're storing *old* passwords that you don't want people to use again, would it matter if they're stored as plain text? I would imagine that you could just add them to a banned passwords list.
Tim wrote:
Les Mikesell:
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
If you're storing *old* passwords that you don't want people to use again, would it matter if they're stored as plain text? I would imagine that you could just add them to a banned passwords list.
Given that people habitually use the same passwords in lots of places, storing old passwords in plain text is probably not a great idea, as what's an old password in one place might be a current password somewhere else.
Paul.
On Fri, 2006-04-07 at 03:21, Tim wrote:
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
If you're storing *old* passwords that you don't want people to use again, would it matter if they're stored as plain text? I would imagine that you could just add them to a banned passwords list.
They may still be used elsewhere, and if you see a sequence of passwords an individual has used you may notice a pattern that will help you guess the current one. But the real issue is that the usual way that you would have such at list is that you saved it from the time each password was created - meaning you had the plain text while they were active too.
Tim:
If you're storing *old* passwords that you don't want people to use again, would it matter if they're stored as plain text? I would imagine that you could just add them to a banned passwords list.
Les Mikesell:
They may still be used elsewhere, and if you see a sequence of passwords an individual has used you may notice a pattern that will help you guess the current one.
Good point. Though you'd have to know which user had used which passwords, and you'd be guessing at where they might use them. On that note, different services having different requirements on what you can use as a password could actually be beneficial - making it less likely that a user will use the same password elsewhere.
But the real issue is that the usual way that you would have such at list is that you saved it from the time each password was created - meaning you had the plain text while they were active too.
Perhaps not necessarily. At the time a password change gets enforced, you could add it to the banned list. Of course that doesn't stop some twit from changing from "secret1" to "secret2", unless your banning list works for partial matches.
On Fri, 2006-04-07 at 17:51 +0930, Tim wrote:
Les Mikesell:
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
If you're storing *old* passwords that you don't want people to use again, would it matter if they're stored as plain text? I would imagine that you could just add them to a banned passwords list.
Actually... You couldn't even if you wanted to. The plain text password is not stored on the system at all. Only the password hashes. If you want to maintain a password history, you just store those hashes and use them in future change password attempts. If you wanted to store the plain text password (in some misguided attempt to catch "similar" passwords) you would have to have the user reenter his old password and store that plain text, since the hashes are not reversible.
Even storing old "banned" passwords as plain text is a very VERY bad idea. Even if they never reuse a password, that same password may be used somewhere else (other systems, web sites, keyrings, databases, etc, etc, etc), may reveal personal information about the user, or may reveal patterns in their password generating methodology (KillRoy1, KillRoy2, KillRoy3).
Obviously, this is something you do NOT want to do.
If you are this paranoid that you even want to catch "similar" passwords, then I would recommend going to an OTP like s/key or OPIE and be done with it.
Mike
Michael H. Warfield wrote:
[snip]
Even storing old "banned" passwords as plain text is a very VERY bad idea. Even if they never reuse a password, that same password may be used somewhere else (other systems, web sites, keyrings, databases, etc, etc, etc), may reveal personal information about the user, or may reveal patterns in their password generating methodology (KillRoy1, KillRoy2, KillRoy3).
Hey! You just gave away my root password to the whole world!
:-)
[snip]
Mike
On Fri, 2006-04-07 at 17:51 +0930, Tim wrote:
Les Mikesell:
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
If you're storing *old* passwords that you don't want people to use again, would it matter if they're stored as plain text? I would imagine that you could just add them to a banned passwords list.
---- actually it would matter for a lot of reasons - and thus, it would never be done which is why Les asked the question.
Craig
Les Mikesell wrote:
On Tue, 2006-04-04 at 21:58, jdow wrote:
Another good guide is:
Enforce changing of passwords on at least a monthly basis. Do not permit re-use of old passwords.
Experience indicates that people rotate sets of four or five passwords in that case.
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
You keep copies of the old encrypted passwords around, and compare the new one to them. If they match, reject the password. After all, you do that to the current one every time someone tries to log in.
Mikkel
On Tue, 2006-04-04 at 23:04, Mikkel L. Ellertson wrote:
Another good guide is:
Enforce changing of passwords on at least a monthly basis. Do not permit re-use of old passwords.
Experience indicates that people rotate sets of four or five passwords in that case.
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
You keep copies of the old encrypted passwords around, and compare the new one to them. If they match, reject the password. After all, you do that to the current one every time someone tries to log in.
I guess I was think of the systems that tell you you haven't made enough of a change from the old one(s).
Les Mikesell wrote:
On Tue, 2006-04-04 at 23:04, Mikkel L. Ellertson wrote:
You keep copies of the old encrypted passwords around, and compare the new one to them. If they match, reject the password. After all, you do that to the current one every time someone tries to log in.
Create a test account, fred. Set fred's password to, say, derf. Take a note of the encrypted password. Change Fred's password to derf. Compare with the previous encrypted password. Are they the same?
On Wed, 2006-04-05 at 21:17 +0800, John Summerfied wrote:
Les Mikesell wrote:
On Tue, 2006-04-04 at 23:04, Mikkel L. Ellertson wrote:
You keep copies of the old encrypted passwords around, and compare the new one to them. If they match, reject the password. After all, you do that to the current one every time someone tries to log in.
Create a test account, fred. Set fred's password to, say, derf. Take a note of the encrypted password. Change Fred's password to derf. Compare with the previous encrypted password. Are they the same?
Probably not if you simply do a new encryption as a new password. The 'salt' will be different and thus the encrypted string will be different. In fact I just tested it, and even though the password was the same twice, the encrypted result was different.
However, note one thing. When a user is logging in, to test the password the system reads the encrypted password and uses the salt found there to encrypt the given password before comparing. Thus any comparison with an encrypted password is done using the embedded salt and the resulting encryption string will be the same if the password is the same.
Saving an old encrypted password and comparing it to the new password would thus reveal they are identical in your example even though the encrypted string in /etc/shadow would be different than the saved one if it were allowed.
Just my $.02
--
Cheers John
-- spambait 1aaaaaaa@computerdatasafe.com.au Z1aaaaaaa@computerdatasafe.com.au Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
John Summerfied wrote:
Les Mikesell wrote:
On Tue, 2006-04-04 at 23:04, Mikkel L. Ellertson wrote:
You keep copies of the old encrypted passwords around, and compare the new one to them. If they match, reject the password. After all, you do that to the current one every time someone tries to log in.
Create a test account, fred. Set fred's password to, say, derf. Take a note of the encrypted password. Change Fred's password to derf. Compare with the previous encrypted password. Are they the same?
They are, taking into account the salt. One doesn't compare the newly encrypted password, one compares the new password encrypted with the salt of the old password, and compares that.
Mike
Les Mikesell:
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
Mikkel L. Ellertson:
You keep copies of the old encrypted passwords around, and compare the new one to them. If they match, reject the password. After all, you do that to the current one every time someone tries to log in.
I don't think that'd work if each time the system encrypts the same password, the encrypted version is a new hash.
Tim wrote:
Les Mikesell:
How do you prevent re-use without keeping plain text or reversibly encrypted copies of the old ones laying around waiting to be stolen?
Mikkel L. Ellertson:
You keep copies of the old encrypted passwords around, and compare the new one to them. If they match, reject the password. After all, you do that to the current one every time someone tries to log in.
I don't think that'd work if each time the system encrypts the same password, the encrypted version is a new hash.
You know what the hashes of the old encrypted passwords are so you just encrypt the new password with the same hash.
Paul.
Tim wrote:
The last two being a key problem. By now, I've amassed about a dozen passwords that I just cannot remember. Even if I wanted to make memorable passwords, too many systems are so limited that you can't easily do it (e.g. passwords are too short, etc.). Then there's the problem of remembering which password belongs to what account. Writing them down, or writing down the reminder trick, becomes the only way to do so.
IMHO, the best way to create passwords (specially when you have a team of sysadmins) is choosing a random fact about one of them (or the boss or a common friend) and create a sentence with it. For example, if Mark loves a soccer team that never wins, a good password may be derived from the sentence Mark is crazy to like X soccer team . Then the password could be Mic2LkX$t . Since the variety of symbols is quite low, we can replace i by 1 or lowercase L, maybe add an exclamation mark before and after (in a reference to the usage of question marks in the beginning and end of sentences in spanish, for example) and you can get something like !Mlc2LkX$t! . It may not be a perfect password, but is good enough to memorize (just remember the sentence and the transformations done to it) and you're good to go. We used this method on all passwords on my last job, with one different set of passwords for class of machines we had (Sun, Linux servers, Linux clients, windows clients, etc) and even today , 3 years after I quit that job, I still remember almost all the passwords (which is quite a feat, since I have quite a lot of trouble remembering names, dates, formulas... pretty much anything useful)
Other method I use is quite insane but secure (I've created two passwords that I have used for the last four years and never have been broken). Find any app that generates a random sequence of characters (keygens or other stuff like that can do the trick.. maybe even a tail -f /dev/random may be useful) . If the generated sequence doesn't have enough variety of symbols, add some more. Then try to find a way to memorize that, using things like the phonetic alphabet, or by finding substrings on the password which can be meaningful when examined alone. Sometimes even reading out loud the password in other languages may help (in my case, only after reading one of my passwords in English I found a good way to memorize it).
-- Pedro Macedo
On Tue, 2006-04-04 at 23:15 -0300, Pedro Fernandes Macedo wrote:
IMHO, the best way to create passwords (specially when you have a team of sysadmins) is choosing a random fact about one of them (or the boss or a common friend) and create a sentence with it.
Yes, I've done that too. Though it's a trick you can't easily do when signing up for some new service that you don't already have something in mind to associate with it.
On Tuesday 04 April 2006 1:46 am, Mike McCarty wrote:
John Summerfield wrote:
Craig White wrote:
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
There is quite a deal of well-reasoned debate about what constitutes a good password.
Should not be all letters. Should include at least one digit. Should include at least one "special" character. Should not include non-graphic characters (like CR, LF, CTRL-A). Should be at least 6 and preferably over 8 characters long. Should be "rememberable". Should *not* be written down anywhere.
snip I would add not easily remembered by someone looking over your shoulder.
Jludwig
users do what users do
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
Craig
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Unfortunately there is no patch for human stupidity...
On Fri, 2006-03-31 at 20:58 -0400, Jacques B. wrote:
users do what users do
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
Craig
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Unfortunately there is no patch for human stupidity...
---- I'd be all over that one for myself
Craig
On Friday 31 March 2006 18:40, Craig White wrote:
On Fri, 2006-03-31 at 18:30 -0500, Gene Heskett wrote:
On Friday 31 March 2006 15:19, Craig White wrote:
On Fri, 2006-03-31 at 13:39 -0600, Les Mikesell wrote:
On Fri, 2006-03-31 at 13:20, Gene Heskett wrote:
They use these botnets to distribute spam, launch DDOS, or whatever else their imagination came come up with. Either of those would contribute to an increase in bandwidth usage.
Humm, we were in fact subjected to a DDOS attack early last sunday morning, which lead to the traffic servers demise & rebuild. Got us listed at spamcop & our mail died.
Or more likely, your box was participating in a DDOS. Do you have any idea what exploit might have been used to install the programs you found?
My money is on sshd - somebody with a weak password.
We found a couple that were downright stupid/dumb/assinine/all_of_the_above.
Fixed, with a cluex4 upside the head to the parties involved.
users do what users do
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
The hell we wouldn't, and I use the word 'we' to be all inclusive... But then its our job to baby the sales dept. since thats what pays everyones salaries at the end of the day. In this case they WILL get used to a new login and password, and its not open for further discussion. Not only that, I think I'm going to insist Jim do regular runs of jack-the-ripper or something along those lines.
In other words, we've been making it easy for sales. Now that sales has also suffered a bit, we won't have near as much trouble as before if we make them actually (heavens to Betsy) remember a login and password. They will of course, if they cannot do business without doing so.
Craig
Craig White wrote:
On Fri, 2006-03-31 at 18:30 -0500, Gene Heskett wrote:
My money is on sshd - somebody with a weak password.
We found a couple that were downright stupid/dumb/assinine/all_of_the_above.
Fixed, with a cluex4 upside the head to the parties involved.
users do what users do
it's actually the fault of the admins who don't use any password checking mechanisms, but I suppose that it's more feasible to blame stupid users...of course, I would never do such a thing ;-)
Several years ago (like 1990 or so) I got interested in UNIX security, etc. and just by poking around on the system found the password file, and guessed maybe crypt(). So I fiddled a little bit, just on my own, you know, and came up with something that could verify my own password. So then I got a small spell checker dictionary, and wrote a little password cracker which would try the user's name, user's name backwords, case variations on both, and words from the spell dictionary.
Cracked about 20 passwords in one afternoon. I went to a guy I knew who worked in system admin, and told him about it. I told him we needed to get some policy on passwords. His response was to shush me, shut his door, and tell me under his breath that I was close to getting fired. Anyway, he agreed, and I copied the files off that system and deleted the originals. I argued that I was no potential risk to the company, actually helping them, and that I had done nothing wrong. He agreed with that, too, but warned me again.
Later, real policies *were* instituted, and the password program began refusing "simple" passwords.
Some years later, a memo went out with password policy written, which we were all supposed to sign and return to H.R. Stupid idea. Anyway, right on its heels came another humorous memo simply circulated around, which stated a very long list of rules about passwords, and then claiming that only one password passed all the tests, and were were all told to come by H.R. and get our copy of it, so we would all be "secure".
Mike
On Friday 31 March 2006 19:32, John Summerfield wrote:
Gene Heskett wrote:
My money is on sshd - somebody with a weak password.
We found a couple that were downright stupid/dumb/assinine/all_of_the_above.
Since the attacker wrote to /usr I'd be looking at how he got to be root.
We haven't found that yet. We're still looking over the forensic copy we made of that drive with dd. And roots password was alpha-numeric, longer than most and certainly not susceptable to a dictionary attack. Interesting, since you made the comment re the compiler being handy, is that it wasn't used to install the irc botnet kit, only a shell, gzip, chmod & cp were used for that according to the install script we read.
On Sunday 02 April 2006 12:06 am, Gene Heskett wrote:
Since the attacker wrote to /usr I'd be looking at how he got to be root.
We haven't found that yet. We're still looking over the forensic copy we made of that drive with dd. And roots password was alpha-numeric, longer than most and certainly not susceptable to a dictionary attack. Interesting, since you made the comment re the compiler being handy, is that it wasn't used to install the irc botnet kit, only a shell, gzip, chmod & cp were used for that according to the install script we read.
I'd suggest that if you have time, format the box clean and start a fresh install. In my opinion, once a box has been compromised, we can never trust it anymore, not even after checking it with any anti-rootkits available. CMIIW,
Gene Heskett wrote:
We've cut our bandwidth use in half by getting rid of that. We also checked the logs and added several dozen more addresses to /etc/hosts.deny,
That is fairly useless. IP addresses of attackers change as quickly at IP addressess of spammers, and they have so many it's like trying to fence off the porn sites of the world.
More important is to discover how the rogue gained entry and to close that loophole. How did the shell script get there? Whose account was used? Does .bash_history include useful clues about what was done? Did the attacker send email after gaining entry? If so, the recipent domain (eg Yahoo) may be interested.
Root's account, eh? Disallow password-based authentication for root. Ensure that only those who need it have shell accounts, and that those have good passwords. _I_ have incoming ssh land on my personal desktop, there there is only my password to worry about.
On Friday 31 March 2006 19:29, John Summerfield wrote:
Gene Heskett wrote:
We've cut our bandwidth use in half by getting rid of that. We also checked the logs and added several dozen more addresses to /etc/hosts.deny,
That is fairly useless. IP addresses of attackers change as quickly at IP addressess of spammers, and they have so many it's like trying to fence off the porn sites of the world.
More important is to discover how the rogue gained entry and to close that loophole. How did the shell script get there? Whose account was used? Does .bash_history include useful clues about what was done? Did the attacker send email after gaining entry? If so, the recipent domain (eg Yahoo) may be interested.
Root's account, eh? Disallow password-based authentication for root. Ensure that only those who need it have shell accounts, and that those have good passwords. _I_ have incoming ssh land on my personal desktop, there there is only my password to worry about.
root ssh is denied. To do normal maintainance we log in as ourselves & su -.
Gene Heskett:
In doing some checking of a web server, we found an irc port open on 31377, one of the black hatters favorites. A port that portsentry was supposed to be rejecting but wasn't.
Why would your web server be write-able?
Configure Secure Defaults:
<Directory /> Order Deny,Allow Deny from all </Directory> <Directory /path/to/html/docs> Order Allow,Deny Allow from all </Directory>
Just my 2 cents.
Krack
-
Ali Helmy -
Craig White -
David Fletcher -
Ed Greshko -
Edward Krack -
Fajar Priyanto -
Gene Heskett -
Guillermo Garron -
Jacques B. -
jdow -
Jeff Vian -
jludwig -
John Summerfield -
John Wendel -
Les Mikesell -
Michael H. Warfield -
Mike McCarty -
Mikkel -
Neil Cherry -
Paul Howarth -
Pedro Fernandes Macedo -
Rahul Sundaram -
Tim