"More interesting is that most of the compromised machines were not Windows machines. "The vast majority of [the phishing sites] we saw were on rootkit-ed Linux boxes, which was rather startling. We expected a predominance of Microsoft boxes and that wasn't the case.""
The above comments were made at a MS sponsored conference. MicroSoft has a history of sponsoring stuff like this. Even if it was an exaggeration - I've never heard of a big problem with Linux boxes getting root-kitted - is it something happenning under the radar? I've read over and over that Linux is much more secure than it's big counterpart - what sorts of vulnerabilities are people opening up to allow Linux machines to be root-kitted? I am aware of the ssh problem, and have followed the discussions on locking down ssh for years, including the other thread that's running currently. What other sorts of things must people do to open themselves up to being rootkitted? This is the first time I've seen such a claim, and it took me by surprise...so, I'm asking.
On 10/5/07, Claude Jones cjones@levitjames.com wrote:
"More interesting is that most of the compromised machines were not Windows machines. "The vast majority of [the phishing sites] we saw were on rootkit-ed Linux boxes, which was rather startling. We expected a predominance of Microsoft boxes and that wasn't the case.""
The above comments were made at a MS sponsored conference. MicroSoft has a history of sponsoring stuff like this. Even if it was an exaggeration - I've never heard of a big problem with Linux boxes getting root-kitted - is it something happenning under the radar? I've read over and over that Linux is much more secure than it's big counterpart - what sorts of vulnerabilities are people opening up to allow Linux machines to be root-kitted? I am aware of the ssh problem, and have followed the discussions on locking down ssh for years, including the other thread that's running currently. What other sorts of things must people do to open themselves up to being rootkitted? This is the first time I've seen such a claim, and it took me by surprise...so, I'm asking.
When a Windows server is rooted, its the OS/apps that having problems ... when a *Nix server is rooted, its the admin's head that having problems ..
theres lots of vulnerable Linux servers out there, managed by poorly skilled admins - mainly teenagers playing around - ... IMHO attacking a linux server is more convenient than a windows server .. bcause stuff can be easily ran without GUI and commands input/output can go through lots of medium like a simple listening port , to a nice javascript based web shell ... whereas on windows attacker are usually stuck with a limited telnet or a VNC .. but if the admin at least knows some of the security best practices .. Linux is _very_ secure ..
-- Claude Jones Brunswick, MD, USA
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
On Fri, 2007-10-05 at 02:48 +0800, Hikaru Amano wrote:
On 10/5/07, Claude Jones cjones@levitjames.com wrote:
"More interesting is that most of the compromised machines were not Windows machines. "The vast majority of [the phishing sites] we saw were on rootkit-ed Linux boxes, which was rather startling. We expected a predominance of Microsoft boxes and that wasn't the case.""
The above comments were made at a MS sponsored conference. MicroSoft has a history of sponsoring stuff like this. Even if it was an exaggeration - I've never heard of a big problem with Linux boxes getting root-kitted - is it something happenning under the radar? I've read over and over that Linux is much more secure than it's big counterpart - what sorts of vulnerabilities are people opening up to allow Linux machines to be root-kitted? I am aware of the ssh problem, and have followed the discussions on locking down ssh for years, including the other thread that's running currently. What other sorts of things must people do to open themselves up to being rootkitted? This is the first time I've seen such a claim, and it took me by surprise...so, I'm asking.
When a Windows server is rooted, its the OS/apps that having problems ... when a *Nix server is rooted, its the admin's head that having problems ..
theres lots of vulnerable Linux servers out there, managed by poorly skilled admins - mainly teenagers playing around - ... IMHO attacking a linux server is more convenient than a windows server .. bcause stuff can be easily ran without GUI and commands input/output can go through lots of medium like a simple listening port , to a nice javascript based web shell ... whereas on windows attacker are usually stuck with a limited telnet or a VNC .. but if the admin at least knows some of the security best practices .. Linux is _very_ secure ..
-- Claude Jones Brunswick, MD, USA
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
-- Mohd Izhar Firdaus Bin Ismail Amano Hikaru 天野晃 「あまの ひかる」 http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331
Totally not true
A good hacker don't need GUI, whether is on Windows or any other GUI centric OS.
Moreover, a little bit outdated, but still valid
http://www.theregister.co.uk/2004/10/22/linux_v_windows_security/
Calin
================================================= Math is like love -- a simple idea but it can get complicated. -- R. Drabek
theres lots of vulnerable Linux servers out there, managed by poorly skilled admins - mainly teenagers playing around - ... IMHO attacking a linux server is more convenient than a windows server
After setting up a secure Apache (irrespective of the distribution) a lot of admins go get a "php-this" or "php-that" web program from a repository. Unfortunately, they don't ask the question of how this thing will be automagically updated each time a vulnerability is fixed, so the program never gets updated.
Those programs get a lot of security updates (don't believe me? see http://www.securityfocus.com/bid and query your favorite php program). Look in your /var/log/httpd/error.log and you will probably see several hundred attempts to break into various php scripts.
OT, a famous and recent example is the group in Canada who was busted for cracking web contact forms and sending out truly massive amounts of spam. Their technique required the mental acumen of a 5th grader in my estimate, but worked because of an abundance of really poorly written web contact scripts which never got updated.
If the cracked script runs with sufficient authority to add a web page, the phishers job becomes trivial. The solution is for maintainers to make sure that they can notify their customers each time a security fix is made. This can be done in the script or by mandatory registration before a download. Yum repositories and the equivalent for other distros should be helpful in solving this problem.
On Thu, 4 Oct 2007, Ben Mohilef wrote:
theres lots of vulnerable Linux servers out there, managed by poorly skilled admins - mainly teenagers playing around - ... IMHO attacking a linux server is more convenient than a windows server
After setting up a secure Apache (irrespective of the distribution) a lot of admins go get a "php-this" or "php-that" web program from a repository. Unfortunately, they don't ask the question of how this thing will be automagically updated each time a vulnerability is fixed, so the program never gets updated.
Those programs get a lot of security updates (don't believe me? see http://www.securityfocus.com/bid and query your favorite php program). Look in your /var/log/httpd/error.log and you will probably see several hundred attempts to break into various php scripts.
OT, a famous and recent example is the group in Canada who was busted for cracking web contact forms and sending out truly massive amounts of spam. Their technique required the mental acumen of a 5th grader in my estimate, but worked because of an abundance of really poorly written web contact scripts which never got updated.
If the cracked script runs with sufficient authority to add a web page, the phishers job becomes trivial. The solution is for maintainers to make sure that they can notify their customers each time a security fix is made. This can be done in the script or by mandatory registration before a download. Yum repositories and the equivalent for other distros should be helpful in solving this problem.
This becomes even worse when you consider hosting sites. The last one I dealt with had everyone on virtual servers that had no capacity to update the packages installed. (Yum was not installed. No patches had been applied. You could actually break the system because they had plesk installed and packages would conflict. A real mess.)
People think that just because someone set it up for them, it is secure. Rarely is that the case.
People are trying to do complex things on the cheap. You are not seeing it done under Windows because doing anything useful is either not cheap or not easy.
Under Linux they can do what they want, but they are too cheap to hire someone who has clues and can do it securely.
On Thu, 2007-10-04 at 15:29 -0700, alan wrote:
On Thu, 4 Oct 2007, Ben Mohilef wrote:
---snip---
If the cracked script runs with sufficient authority to add a web page, the phishers job becomes trivial. The solution is for maintainers to make sure that they can notify their customers each time a security fix is made. This can be done in the script or by mandatory registration before a download. Yum repositories and the equivalent for other distros should be helpful in solving this problem.
This becomes even worse when you consider hosting sites. The last one I dealt with had everyone on virtual servers that had no capacity to update the packages installed. (Yum was not installed. No patches had been applied. You could actually break the system because they had plesk installed and packages would conflict. A real mess.)
People think that just because someone set it up for them, it is secure. Rarely is that the case.
People are trying to do complex things on the cheap. You are not seeing it done under Windows because doing anything useful is either not cheap or not easy.
Under Linux they can do what they want, but they are too cheap to hire someone who has clues and can do it securely.
That is a very valid issue. It takes a fair amount of time to design a hardened web server. If I remember correctly, the last time we developed a web server architecture for customers, it took us quite a while to determine all the tricks required to lock web accounts into their own storage space including locking down PHP and Perl so that they could not 'sneak' out. Of course when a web server is locked down tightly, you will run into problems with some PHP and Perl scripts that break because they are written poorly or contain malicious code, so you will need to inspect many scripts before making them executable.
Guy Fraser wrote:
Under Linux they can do what they want, but they are too cheap to hire someone who has clues and can do it securely.
That is a very valid issue. It takes a fair amount of time to design a hardened web server.
Why does such a thing have to be designed more than once?
On Fri, 2007-10-05 at 15:13 -0500, Les Mikesell wrote:
Guy Fraser wrote:
Under Linux they can do what they want, but they are too cheap to hire someone who has clues and can do it securely.
That is a very valid issue. It takes a fair amount of time to design a hardened web server.
Why does such a thing have to be designed more than once?
Ask the developers?
If PHP, Perl, Apache and the FTP server were configured in a hardened way, we would not have had to reconfigure them as much as was needed. Now we pretty much use a cookie cutter on new servers. A lot of time was required developing an application to maintain access accounts and sites.
Guy Fraser wrote:
Under Linux they can do what they want, but they are too cheap to hire someone who has clues and can do it securely.
That is a very valid issue. It takes a fair amount of time to design a hardened web server.
Why does such a thing have to be designed more than once?
Ask the developers?
If PHP, Perl, Apache and the FTP server were configured in a hardened way, we would not have had to reconfigure them as much as was needed.
Did you report the vulnerabilities you fixed to the corresponding projects?
On Thu, 4 Oct 2007, Ben Mohilef wrote:
After setting up a secure Apache (irrespective of the distribution) a lot of admins go get a "php-this" or "php-that" web program from a repository. Unfortunately, they don't ask the question of how this thing will be automagically updated each time a vulnerability is fixed, so the program never gets updated.
So so so correct...some basic policies would be to...
1. always run hosts with own user and apache group, set up vhost dirs permissions accordingly for this 2. always use suexec 3. if possible run php as a cgi 4. lock down php for example: - open_basedir =/var/www:/var/tmp:/tmp:/usr/local/lib/php - disable_functions = exec, shell_exec, system, virtual, show_source, readfile, passthru, escapeshellcmd, popen, pclose, phpinfo - disable safe_mode
4a. (if tehy say their scripts need access to bin like for uptime etc tell em to get a better script) 4b. (make absolutely NO exemptions to the lockdowns)
5. never install vhost sites special programs that need root in any way shape or form
6. use a respected server OS, one that doesnt hack the f#ck out of programs like RH(CentOS) do
6a. use modern current packages of apache2, php5 and MySQL,Sendmail etc from the respective sites, and not by use of RPM's because its too "vendor altered" which is where 90% of the security issues come into it.
7. ban use of any but most current version of phpnuke (ban totally if you can) and those frickin image gallery programs.
8. use a decent detection system
9. use something like MailScanner with spamassassin adn a good anti-virus on your mail server to minimise the exploit opening in the first place
10, follow same rules as you would on winblow$, no running stuff you dont know what it is, no clicking on links in mesgs you dont know the sender, its all basic sence :)
On Fri, 5 Oct 2007, Res wrote:
On Thu, 4 Oct 2007, Ben Mohilef wrote:
After setting up a secure Apache (irrespective of the distribution) a lot of admins go get a "php-this" or "php-that" web program from a repository. Unfortunately, they don't ask the question of how this thing will be automagically updated each time a vulnerability is fixed, so the program never gets updated.
So so so correct...some basic policies would be to...
- always run hosts with own user and apache group, set up vhost dirs
permissions accordingly for this 2. always use suexec 3. if possible run php as a cgi 4. lock down php for example:
- open_basedir =/var/www:/var/tmp:/tmp:/usr/local/lib/php
- disable_functions = exec, shell_exec, system, virtual, show_source,
readfile, passthru, escapeshellcmd, popen, pclose, phpinfo
- disable safe_mode
4a. (if tehy say their scripts need access to bin like for uptime etc tell em to get a better script) 4b. (make absolutely NO exemptions to the lockdowns)
- never install vhost sites special programs that need root in any way
shape or form
- use a respected server OS, one that doesnt hack the f#ck out of
programs like RH(CentOS) do
6a. use modern current packages of apache2, php5 and MySQL,Sendmail etc from the respective sites, and not by use of RPM's because its too "vendor altered" which is where 90% of the security issues come into it.
- ban use of any but most current version of phpnuke (ban totally if you
can) and those frickin image gallery programs.
use a decent detection system
use something like MailScanner with spamassassin adn a good anti-virus
on your mail server to minimise the exploit opening in the first place
10, follow same rules as you would on winblow$, no running stuff you dont know what it is, no clicking on links in mesgs you dont know the sender, its all basic sence :)
and .. 11. if you are vhosting for some friends home pages, that are plain basic, they do not need php so in the vhost block for them, you would also be best to set:
php_value engine off
On Fri, 5 Oct 2007 08:48:25 +1000 (EST) Res res@ausics.net wrote:
- use a respected server OS, one that doesnt hack the f#ck out of programs like RH(CentOS) do
Umm - I hate to toss a munkey wrench into the mix, but if you really want a reliable SERVER OS, my choices would be OpenBSD, NetBSD or FreeBSD
6a. use modern current packages of apache2, php5 and MySQL,Sendmail etc from the respective sites, and not by use of RPM's because its too "vendor altered" which is where 90% of the security issues come into it.
Modern, most current isn't always the best way to go either. You need to be a little savvy.
- ban use of any but most current version of phpnuke (ban totally if
you can) and those frickin image gallery programs.
Read up number 6a.
- use a decent detection system
Agreed
- use something like MailScanner with spamassassin adn a good
anti-virus on your mail server to minimise the exploit opening in the first place
While Mailscanner is very good - you need to know your MTA also. (unless things have changed) Mailscanner and Postfix was a no-no.
10, follow same rules as you would on winblow$, no running stuff you dont know what it is, no clicking on links in mesgs you dont know the sender, its all basic sence :)
*nod*
- use a respected server OS, one that doesnt hack the f#ck out of programs like RH(CentOS) do
Umm - I hate to toss a munkey wrench into the mix, but if you really want a reliable SERVER OS, my choices would be OpenBSD, NetBSD or FreeBSD
I'd choose Centos or RHEL5, especially for bigger servers when BSD just doesn't scale. Better to have code that is stable and has backported fixes than random stuff on a big server box. Each to his own - nowt wrong with FreeBSD, and OpenBSD is neat for building small tightly locked down appliances even if some of the contributors are ermm fun to deal with.
10, follow same rules as you would on winblow$, no running stuff you dont know what it is, no clicking on links in mesgs you dont know the sender, its all basic sence :)
I'd also add
11, If you must have idjits running around installing php toys on your box virtualise them into a safe corner of their own so they can't mess up anyone else.
Alan
(00:17:25 up 927 days, 4:44, 4 users, load average: 0.00, 0.00, 0.00)
On Thu, 4 Oct 2007, Chris wrote:
Umm - I hate to toss a munkey wrench into the mix, but if you really want a reliable SERVER OS, my choices would be OpenBSD, NetBSD or FreeBSD
Thats debateable :) But yes out of the box it is by default where limux takes a a little effort
- use something like MailScanner with spamassassin adn a good
While Mailscanner is very good - you need to know your MTA also. (unless things have changed) Mailscanner and Postfix was a no-no.
It works with Postfix without problems, Weitse detests it and will shy people away from it (maybe because of his relationship with ther author of amavisd), but there are many large organisations using it happily wiki.mailscanner.info has howto, MailScanner even works with Qmail
On Fri, Oct 05, 2007 at 10:06:33AM +1000, Res waffled thusly:
On Thu, 4 Oct 2007, Chris wrote:
<snip>
- use something like MailScanner with spamassassin adn a good
While Mailscanner is very good - you need to know your MTA also. (unless things have changed) Mailscanner and Postfix was a no-no.
It works with Postfix without problems, Weitse detests it and will shy people away from it (maybe because of his relationship with ther author of amavisd), but there are many large organisations using it happily wiki.mailscanner.info has howto, MailScanner even works with Qmail
(Slightly OT)
Wietse doesn't like MailScanner because it's had a nasty history of accessing queue files directly, which will break if the queue file format changes at any stage (for example when DSNs were introduced etc.). I can certainly understand his PoV (and frustration when cluebies blame postfix for breaking MailScanner when it's really MailScanner that's flawed)
--Michael. (I have both amavisd/postfix and MailScanner/exim @ work, so I've dealt with both apps ;-))
On Fri, 5 Oct 2007, mfleming@enlartenment.com wrote:
Wietse doesn't like MailScanner because it's had a nasty history of accessing queue files directly, which will break if the queue file format changes at any stage (for example when DSNs were introduced etc.). I can certainly understand his PoV (and frustration when cluebies blame postfix for breaking MailScanner when it's really MailScanner that's flawed)
--Michael. (I have both amavisd/postfix and MailScanner/exim @ work, so I've dealt with both apps ;-))
That method was discarded ages ago, but it still worked anyway, however i've never been a fan of postfix so personally it doesn't bother me :)
On Fri, Oct 05, 2007 at 08:48:25AM +1000, Res wrote:
- use a respected server OS, one that doesnt hack the f#ck out of
programs like RH(CentOS) do
"Respected" is kind of a funny term here given RHEL sales, but let's let that slide and look at the premise. One of the key tenets of Fedora is "upstream, upstream, upstream". Hacking the "f#ck" out of packages is strongly discouraged.
6a. use modern current packages of apache2, php5 and MySQL,Sendmail etc from the respective sites, and not by use of RPM's because its too "vendor altered" which is where 90% of the security issues come into it.
Do you have any data to back this assertion? I read every security announcement from Red Hat / Fedora, and it's very rare that an issue is due to a RH/Fedora change -- and in fact more likely that the issue being patched isn't normally an issue on default systems due to compile defaults and extra security features added by the distribution.
On Thu, 4 Oct 2007, Matthew Miller wrote:
On Fri, Oct 05, 2007 at 08:48:25AM +1000, Res wrote:
- use a respected server OS, one that doesnt hack the f#ck out of
programs like RH(CentOS) do
"Respected" is kind of a funny term here given RHEL sales, but let's let that slide and look at the premise. One of the key tenets of Fedora is "upstream, upstream, upstream". Hacking the "f#ck" out of packages is strongly discouraged.
but still done, I mean Bind comes in one package, Sendmail in one, bot split up into little pieces, you only have to look in the scr.rpm to see 99 times of out 100 there s a vendor specific patch, that does not exist in say sendmail-version.tar.gz or bind-version.tar.gz You only have to read the lsit of updates from fedora/RH and even debian and others on certain mailing lists to see update update update update, yet the original package is still the same and the authors say no they made changes, this is why we use slackware, and of course why many lazy admins detest it :)
Do you have any data to back this assertion? I read every security
see above
On Fri, 5 Oct 2007, Res wrote:
You only have to read the lsit of updates from fedora/RH and even debian and others on certain mailing lists to see update update update update, yet the original package is still the same and the authors say no they made changes,
should be made no changes :)
Res wrote:
but still done, I mean Bind comes in one package, Sendmail in one, bot split up into little pieces, you only have to look in the scr.rpm to see 99 times of out 100 there s a vendor specific patch, that does not exist in say sendmail-version.tar.gz or bind-version.tar.gz You only have to read the lsit of updates from fedora/RH and even debian and others on certain mailing lists to see update update update update, yet the original package is still the same and the authors say no they made changes, this is why we use slackware, and of course why many lazy admins detest it :)
I can't tell from what you've said above. So, I have to ask. Are you dismissing vendor supplied patches out of hand?
I thought the reason for providing source code was for the community to be able to examine the code and then make changes as they deem necessary. Then, pass the changes back to the original authors who then decide if they will include the changes in their version.
When it comes to the RHEL products one pays for support. They support their vendor supplied changes as well as the original code. So, it isn't clear what the objections would be.
On Fri, Oct 05, 2007 at 10:12:16AM +1000, Res wrote:
split up into little pieces, you only have to look in the scr.rpm to see 99 times of out 100 there s a vendor specific patch, that does not exist in say sendmail-version.tar.gz or bind-version.tar.gz
And most of the time those are patches from newer upstream versions. Many of the others are pushed upstream.
On 10/4/07, Claude Jones cjones@levitjames.com wrote:
"More interesting is that most of the compromised machines were not Windows machines. "The vast majority of [the phishing sites] we saw were on rootkit-ed Linux boxes, which was rather startling. We expected a predominance of Microsoft boxes and that wasn't the case.""
The above comments were made at a MS sponsored conference. MicroSoft has a history of sponsoring stuff like this. Even if it was an exaggeration - I've never heard of a big problem with Linux boxes getting root-kitted - is it something happenning under the radar? I've read over and over that Linux is much more secure than it's big counterpart - what sorts of vulnerabilities are people opening up to allow Linux machines to be root-kitted? I am aware of the ssh problem, and have followed the discussions on locking down ssh for years, including the other thread that's running currently. What other sorts of things must people do to open themselves up to being rootkitted? This is the first time I've seen such a claim, and it took me by surprise...so, I'm asking. -- Claude Jones Brunswick, MD, USA
I'm no expert on this topic. But I do know a case where the application that was running on the web server was exploited due to a vulnerability in that application, not in Apache or the Linux box. I suspect that is the case more often than not. Someone compromises a web site that is running a vulnerable application. That site happens to be hosted on a Linux box (because let's face it, a lot of web servers out there run on *nix).
So it's a matter of making the study say what they wanted it to say. Or say something that is controversial, eye opening, or otherwise worthy of capturing people's attention.
Personally I don't think it's a reflection on the vulnerability of the Linux platform or Apache in many cases. I say this with no real data to back this up so take it as such.
Jacques B.
Jacques B. wrote: <snip />
I'm no expert on this topic. But I do know a case where the application that was running on the web server was exploited due to a vulnerability in that application, not in Apache or the Linux box. I suspect that is the case more often than not. Someone compromises a web site that is running a vulnerable application. That site happens to be hosted on a Linux box (because let's face it, a lot of web servers out there run on *nix).
Hi Jacques.
I think you're right on the money there. Google for phpbb and hack for an example of your point.
Mike Wright :m)
Mike Wright wrote:
Jacques B. wrote:
<snip /> > I'm no expert on this topic. But I do know a case where the > application that was running on the web server was exploited due to a > vulnerability in that application, not in Apache or the Linux box. I > suspect that is the case more often than not. Someone compromises a > web site that is running a vulnerable application. That site happens > to be hosted on a Linux box (because let's face it, a lot of web > servers out there run on *nix). >
Hi Jacques.
I think you're right on the money there. Google for phpbb and hack for an example of your point.
There's also a huge amount of ssh password-guessing going on, and with most distos, ssh is enabled by default on port 22. What I've seen appears to be very carefully time-constrained as though the programs doing it are trying large numbers of machines at once and limiting the attempts to any single machine to avoid notice.
On Thu, 2007-10-04 at 14:32 -0500, Les Mikesell wrote:
There's also a huge amount of ssh password-guessing going on, and with most distos, ssh is enabled by default on port 22.
Why even bother with that? I'd say that there's a huge number of servers which just have plain text password FTP or HTTP access to the site, and a similarly huge number of sites with stupid passwords.
On Thu, 2007-10-04 at 14:32 -0500, Les Mikesell wrote:
Mike Wright wrote:
Jacques B. wrote:
<snip /> > I'm no expert on this topic. But I do know a case where the > application that was running on the web server was exploited due to a > vulnerability in that application, not in Apache or the Linux box. I > suspect that is the case more often than not. Someone compromises a > web site that is running a vulnerable application. That site happens > to be hosted on a Linux box (because let's face it, a lot of web > servers out there run on *nix). >
Hi Jacques.
I think you're right on the money there. Google for phpbb and hack for an example of your point.
There's also a huge amount of ssh password-guessing going on, and with most distos, ssh is enabled by default on port 22. What I've seen appears to be very carefully time-constrained as though the programs doing it are trying large numbers of machines at once and limiting the attempts to any single machine to avoid notice.
In order to reduce the chance of someone successfully hacking in through ssh unnoticed there a couple things I have been using for a number of years.
Change the default sshd config or add this one in hosts.allow : --- snip --- sshd : .domain.tld \ <IP_ADDR/MASK> \ : severity auth.info \ : allow sshd : ALL \ : severity auth.notice \ : deny --- snip --- It will allow you to monitor both rejected and successful ssh authentications, which you can grep from the logs and email irregularities. It also allows you to restrict the IP addresses, and/or host names allowed to connect to ssh. Make sure to disable the 'allow all' stuff. Also adding a "catch all" at the end of the hosts.allow like ; --- snip --- ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." --- snip--- can help you monitor other undefined daemons.
Edit sshd_config and add something like : --- snip --- AllowGroups staff --- snip --- This allows you to restrict ssh access to users assigned to group 'staff'. Using this you can assign only the users that should be allowed ssh access to successfully authenticate. Also stay far away from allowing access to user names like "john", especially since "john" is installed by default by the password cracker of the same name making your machine especially tasty.
You can also experiment with using 'spawn' in hosts.allow to send immediate alerts or log to 'hidden' files like this: --- snip --- sshd : KNOWN EXCEPT PARANOID \ : spawn ( /bin/date "+%%b %%d %%T" | \ /usr/bin/sed 's,$, %H %d[%p] allowed %u from %n [%a],' >> \ /var/log/.wrapper.`date +%%Y-%%m-%%d`.log ) & \ : allow --- snip ---
Be careful to configure something to filter the things you don't want to be alerted to when setting up automatic alerts. I use 'fgrep -vf <filterfile> <logfile>' in a cron job to mail root {me} any unusual ssh attempts. The filter file looks like : --- snip --- logfile turned over Received signal Server listening on refused connect from host name/name mismatch host name/address mismatch can't verify hostname Did not receive identification string from 123.45.67.89 Accepted keyboard-interactive/pam for mister.tee from 45.67.89.123 Accepted keyboard-interactive/pam for john.frakes from 67.89.123.45 Accepted keyboard-interactive/pam for mr.magoo from 89.123.45.67 --- snip --- Remember these are the things you don't want to see.
Hope this gives some of you food for thought. It would be nice if some of it made it into the default setup, but I have given up trying to get helpful stuff added. Go ahead and try if you want.
Happy hacker hunting, and Thanksgiving / Columbus Day to those celebrating this weekend.
On 10/4/07, Claude Jones cjones@levitjames.com wrote:
"More interesting is that most of the compromised machines were not Windows machines. "The vast majority of [the phishing sites] we saw were on rootkit-ed Linux boxes, which was rather startling. We expected a predominance of Microsoft boxes and that wasn't the case.""
How do they know that the attacks are from rooted linux boxes?
On Fri, 5 Oct 2007 16:24:39 -0500 "Arthur Pemberton" pemboa@gmail.com wrote:
On 10/4/07, Claude Jones cjones@levitjames.com wrote:
"More interesting is that most of the compromised machines were not Windows machines. "The vast majority of [the phishing sites] we saw were on rootkit-ed Linux boxes, which was rather startling. We expected a predominance of Microsoft boxes and that wasn't the case.""
How do they know that the attacks are from rooted linux boxes?
A little box pops up and in a high pitched Tennesee mountain hillbilly sorta voice says: Yer root'd - allow me to hep mesef ta yer computer-thingie
Didn't you know this already?!?!
On Fri, Oct 05, 2007 at 04:24:39PM -0500, Arthur Pemberton wrote:
machines. "The vast majority of [the phishing sites] we saw were on rootkit-ed Linux boxes, which was rather startling. We expected a http://tinyurl.com/36nfsm
How do they know that the attacks are from rooted linux boxes?
Because it's generally pretty easy to tell the operating system a given web site is running on. Note that they're talking about *phishing sites*, not the sites from which phishing spam or whatever originates.
On 10/5/07, Matthew Miller mattdm@mattdm.org wrote:
On Fri, Oct 05, 2007 at 04:24:39PM -0500, Arthur Pemberton wrote:
machines. "The vast majority of [the phishing sites] we saw were on rootkit-ed Linux boxes, which was rather startling. We expected a http://tinyurl.com/36nfsm
How do they know that the attacks are from rooted linux boxes?
Because it's generally pretty easy to tell the operating system a given web site is running on. Note that they're talking about *phishing sites*, not the sites from which phishing spam or whatever originates.
The question still stands.... how do they know the attacks are from a _rooted_ linux box? You don't need root to put put a phishing site, esp. on a shared host.
On Sat, Oct 06, 2007 at 12:30:18AM -0500, Arthur Pemberton wrote:
Because it's generally pretty easy to tell the operating system a given web site is running on. Note that they're talking about *phishing sites*, not the sites from which phishing spam or whatever originates.
The question still stands.... how do they know the attacks are from a _rooted_ linux box? You don't need root to put put a phishing site, esp. on a shared host.
Fair enough. They're just using that term incorrectly.
On Sat, 6 Oct 2007, Matthew Miller wrote:
On Sat, Oct 06, 2007 at 12:30:18AM -0500, Arthur Pemberton wrote:
Because it's generally pretty easy to tell the operating system a given web site is running on. Note that they're talking about *phishing sites*, not the sites from which phishing spam or whatever originates.
The question still stands.... how do they know the attacks are from a _rooted_ linux box? You don't need root to put put a phishing site, esp. on a shared host.
Fair enough. They're just using that term incorrectly.
It would certainly be at least a hijacked host account
I have had about 4 over the past 5 years, each time it was only affecting one domain because of the server perms, but it didnt matter, they used either php nuke, or a picture gallery package each time, they simply created a normal sounding subdir that was pointed to under that host, so the host genuine owner logged into ftp, he would probably see the dir but think nothing of it.
No mater how secure the server, there will always be one idiot who will install some script that will get them hijacked.
No mater how secure the server, there will always be one idiot who will install some script that will get them hijacked.
Cheers Res
In fairness it's not always the host owner's fault. If they wrote the code, then yes they created the vulnerability. But many people will buy an application from a company. In those cases the owner of the domain/site can't be faulted. He/she purchased an application from a web developing company. If your machine gets compromised because of an undocumented hence unpatched vulnerability in Apache, or SSH, or whatever, are you the "idiot"? If we hold you to the same standards that you are holding these domain owners, then the answer would be "yes".
Not trying to be politically correct. Just playing devil's advocate to your posting and illustrating the fault in your passing of the blame.
Jacques B.
On Sat, 6 Oct 2007, Jacques B. wrote:
No mater how secure the server, there will always be one idiot who will install some script that will get them hijacked.
Cheers Res
In fairness it's not always the host owner's fault. If they wrote the code, then yes they created the vulnerability. But many people will buy an application from a company. In those cases the owner of the
I can see your point of view, however it's their fault for not making sure they know what they are using, many people "hear" about this php.some.script, d/l it and use it because it does what they want, without looking into it, or even knowing if it's the latest version or fully understanding it.
domain/site can't be faulted. He/she purchased an application from a web developing company. If your machine gets compromised because of an undocumented hence unpatched vulnerability in Apache, or SSH, or whatever, are you the "idiot"? If we hold you to the same standards that you are holding these domain owners, then the answer would be "yes".
There is a difference, I use no daemon that I don't understand the workings of, where as most hosting customers don't even want to know, so long as it does what they want.
However, if a server is taken because of a vulnerability that I read of and still left that service active, then yes, I would be, and if a server was taken because I ran some new daemon that "did this" and I thought it would be cool to have, and installed it without knowing what was it really does either by design fault or mis-configuration, then again, yes I would be.
On 10/6/07, Matthew Miller mattdm@mattdm.org wrote:
On Sat, Oct 06, 2007 at 12:30:18AM -0500, Arthur Pemberton wrote:
Because it's generally pretty easy to tell the operating system a given web site is running on. Note that they're talking about *phishing sites*, not the sites from which phishing spam or whatever originates.
The question still stands.... how do they know the attacks are from a _rooted_ linux box? You don't need root to put put a phishing site, esp. on a shared host.
Fair enough. They're just using that term incorrectly.
Cool. But I mean, an insure web host is a far cry in terms of security from a rooted box. Even with the most strict SELinux policies one may get up a phsishing page. But to get root is a very big deal, and not something to be said lightly i believe
-
Alan -
Alan Cox -
Arthur Pemberton -
Ben Mohilef -
Chris -
Claude Jones -
Ed Greshko -
Guy Fraser -
Jacques B. -
kalinix -
Les Mikesell -
Matthew Miller -
Michael Fleming -
Mike Wright -
Mohd Izhar Firdaus Ismail -
Res -
Tim