Re: Hacked - FreeBSD 7.1-Release
On Thu, 31 Dec 2009, Jeremy Chadwick wrote:
On Thu, Dec 31, 2009 at 04:16:07AM +1100, Ian Smith wrote:
On Tue, 29 Dec 2009, David Wolfskill wrote:
On Tue, Dec 29, 2009 at 03:20:37AM -0800, Jeremy Chadwick wrote:
...
I've written my own script to do all of this. It parses periodic
security mails (on a daily basis), and does WHOIS lookups + parses the
results to tell me what netblocks/CIDRs I should consider blocking.
For
example, for a security mail that contains this:
horus.sc1.parodius.com login failures:
Dec 28 15:54:49 horus sshd[74684]: Failed password for root from
199.71.214.240 port 51197 ssh2
Dec 28 15:54:49 horus sshd[74686]: Invalid user test from
199.71.214.240
Dec 28 18:39:24 horus sshd[84742]: Failed password for root from
208.94.235.248 port 42979 ssh2
Dec 28 18:39:25 horus sshd[84744]: Failed password for root from
208.94.235.248 port 43056 ssh2
Dec 28 18:39:25 horus sshd[84746]: Failed password for root from
208.94.235.248 port 43156 ssh2
Dec 28 18:39:26 horus sshd[84749]: Failed password for root from
208.94.235.248 port 43265 ssh2
Dec 28 18:39:27 horus sshd[84751]: Failed password for root from
208.94.235.248 port 43356 ssh2
The script would output the following:
199.71.214.240
199.71.212.0/22Psychz Networks, Walnut, CA, US
208.94.235.248
208.94.232.0/22WZ Communications Inc., Madison, WI, US
208.94.235.0/24Soft-Com.biz, Inc., Panama, NA, PA
Jeremy, care to share your whois lookup / parsing script for this?
Sure. It's a combination of two scripts which I call parse_ssh_deny
(sh) and lookup (perl). How I use them: I get security run output
mails from periodic every night, and use mutt to save them (one per
server) to a single file, which I pipe to parse_ssh_deny, resulting in
the above output.
I read the output by hand and decide manually what to put into
pf.conf.ssh-deny.
Thanks for this, very helpful. Perhaps for others too.
I'll note that some of the servers are multi-user, so users mistyping
their password is common -- I specifically exclude that error message
from the awk line in parse_ssh_deny because I don't want legitimate
users potentially blocked. People should tune the script based on their
needs though.
The lookup perl script uses whois(1) with specific arguments to get
back results from ARIN, and then parses the results. Sometimes WHOIS
records don't have certain details (country code, city, state, etc.),
and other times they do. The script tries to handle all of those.
Many of my lookups, often done adhoc while browsing various logs, are as
likely to be via APNIC and other RIRs, all of which have differences in
format to some extent; I'll have to play with all this when there's a
bit more time.
The reason I chose to parse whois(1) output rather than using something
like Net::Whois or Net::Whois::IP is because I prefer self-contained
scripts (unless there's sufficient justification for reliance on such
third-party code); plus I didn't particularly like either of these perl
modules.
Yes I prefer using the base tools too. I often find lots of perl code
close to unreadable, but yours couldn't be clearer. David Wolfskill
sent some more useful clues too. Thanks again, guys.
cheers, Ian
parse_ssh_deny
#!/bin/sh
for i in `awk '/Failed password for root/ {print $11} /Failed password for
invalid user .+ from/ {print $13} /Invalid user/ {print $NF}' | sort -u -n`
do
lookup $i
done
lookup
#!/usr/local/bin/perl
use strict;
use warnings;
# $ whois -a + 67.205.112.200 | egrep '^CustName|OrgName|CIDR'
# OrgName:iWeb Technologies Inc.
# CIDR: 67.205.64.0/18
# CustName: iWeb Dedicated CL2
# CIDR: 67.205.112.192/27
my $lookup = shift or die Usage: $0 ip\n;
my ($name, $city, $state, $cc, $cidr) = undef;
print $lookup, \n;
open(FH, whois -a '+ $lookup' |) or die;
while(FH)
{
$name = $2if (m#^(CustName|OrgName):\s+(.+)#);
$city = $1if (m#^City:\s+(.+)#);
$state = $1if (m#^StateProv:\s+(.+)#);
$cc= $1if (m#^Country:\s+(.+)#);
$cidr = $1if (m#^CIDR:\s+([\d\./]+)#);
if ($name and $cidr)
{
$city = $city || '?';
$state = $state || '?';
$cc= $cc|| '?';
printf \t%-23s, $cidr;
print join(, , $name, $city, $state, $cc);
print \n;
($name, $city, $state, $cc, $cidr) = undef;
next;
}
}
close(FH);
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making
Re: Hacked - FreeBSD 7.1-Release
On Thu, Dec 31, 2009 at 04:16:07AM +1100, Ian Smith wrote:
On Tue, 29 Dec 2009, David Wolfskill wrote:
On Tue, Dec 29, 2009 at 03:20:37AM -0800, Jeremy Chadwick wrote:
...
I've written my own script to do all of this. It parses periodic
security mails (on a daily basis), and does WHOIS lookups + parses the
results to tell me what netblocks/CIDRs I should consider blocking. For
example, for a security mail that contains this:
horus.sc1.parodius.com login failures:
Dec 28 15:54:49 horus sshd[74684]: Failed password for root from
199.71.214.240 port 51197 ssh2
Dec 28 15:54:49 horus sshd[74686]: Invalid user test from 199.71.214.240
Dec 28 18:39:24 horus sshd[84742]: Failed password for root from
208.94.235.248 port 42979 ssh2
Dec 28 18:39:25 horus sshd[84744]: Failed password for root from
208.94.235.248 port 43056 ssh2
Dec 28 18:39:25 horus sshd[84746]: Failed password for root from
208.94.235.248 port 43156 ssh2
Dec 28 18:39:26 horus sshd[84749]: Failed password for root from
208.94.235.248 port 43265 ssh2
Dec 28 18:39:27 horus sshd[84751]: Failed password for root from
208.94.235.248 port 43356 ssh2
The script would output the following:
199.71.214.240
199.71.212.0/22Psychz Networks, Walnut, CA, US
208.94.235.248
208.94.232.0/22WZ Communications Inc., Madison, WI, US
208.94.235.0/24Soft-Com.biz, Inc., Panama, NA, PA
Jeremy, care to share your whois lookup / parsing script for this?
Sure. It's a combination of two scripts which I call parse_ssh_deny
(sh) and lookup (perl). How I use them: I get security run output
mails from periodic every night, and use mutt to save them (one per
server) to a single file, which I pipe to parse_ssh_deny, resulting in
the above output.
I read the output by hand and decide manually what to put into
pf.conf.ssh-deny.
I'll note that some of the servers are multi-user, so users mistyping
their password is common -- I specifically exclude that error message
from the awk line in parse_ssh_deny because I don't want legitimate
users potentially blocked. People should tune the script based on their
needs though.
The lookup perl script uses whois(1) with specific arguments to get
back results from ARIN, and then parses the results. Sometimes WHOIS
records don't have certain details (country code, city, state, etc.),
and other times they do. The script tries to handle all of those.
The reason I chose to parse whois(1) output rather than using something
like Net::Whois or Net::Whois::IP is because I prefer self-contained
scripts (unless there's sufficient justification for reliance on such
third-party code); plus I didn't particularly like either of these perl
modules.
parse_ssh_deny
#!/bin/sh
for i in `awk '/Failed password for root/ {print $11} /Failed password for
invalid user .+ from/ {print $13} /Invalid user/ {print $NF}' | sort -u -n`
do
lookup $i
done
lookup
#!/usr/local/bin/perl
use strict;
use warnings;
# $ whois -a + 67.205.112.200 | egrep '^CustName|OrgName|CIDR'
# OrgName:iWeb Technologies Inc.
# CIDR: 67.205.64.0/18
# CustName: iWeb Dedicated CL2
# CIDR: 67.205.112.192/27
my $lookup = shift or die Usage: $0 ip\n;
my ($name, $city, $state, $cc, $cidr) = undef;
print $lookup, \n;
open(FH, whois -a '+ $lookup' |) or die;
while(FH)
{
$name = $2 if (m#^(CustName|OrgName):\s+(.+)#);
$city = $1 if (m#^City:\s+(.+)#);
$state = $1 if (m#^StateProv:\s+(.+)#);
$cc= $1 if (m#^Country:\s+(.+)#);
$cidr = $1 if (m#^CIDR:\s+([\d\./]+)#);
if ($name and $cidr)
{
$city = $city || '?';
$state = $state || '?';
$cc= $cc|| '?';
printf \t%-23s, $cidr;
print join(, , $name, $city, $state, $cc);
print \n;
($name, $city, $state, $cc, $cidr) = undef;
next;
}
}
close(FH);
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Tue, Dec 29, 2009 at 08:46:57PM +0100, Oliver Fromme wrote: Brian W. br...@brianwhalen.net wrote: [...] That's probably because OpenBSD doesn't have mac_portacl(4). ;-) [...] Arf, but pf allow to regulate traffic according to the user that own the socket, e.g., pass from any to any port www user www :p -- Stephane Rochoy () ascii ribbon campaign / Against HTML e-mail /\ www.asciiribbon.org / and proprietary attachments smime.p7s Description: S/MIME cryptographic signature
Re: Hacked - FreeBSD 7.1-Release
On Tue, Dec 29, 2009 at 08:10:42AM -0800, Brian W. wrote: On 12/29/2009 3:45 AM, Edwin Groothuis wrote: mpt to pass a Turing test or something. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. Edwin I seem to recall on one of the openbsd lists someone speaking of risks of running sshd or other services on high numbered ports, presumably because a non root user cannot bind ports up to 1024. More than happy to suggest 222 next time :-) Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ ed...@mavetju.org Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Tue, 29 Dec 2009, David Wolfskill wrote:
On Tue, Dec 29, 2009 at 03:20:37AM -0800, Jeremy Chadwick wrote:
...
I've written my own script to do all of this. It parses periodic
security mails (on a daily basis), and does WHOIS lookups + parses the
results to tell me what netblocks/CIDRs I should consider blocking. For
example, for a security mail that contains this:
horus.sc1.parodius.com login failures:
Dec 28 15:54:49 horus sshd[74684]: Failed password for root from
199.71.214.240 port 51197 ssh2
Dec 28 15:54:49 horus sshd[74686]: Invalid user test from 199.71.214.240
Dec 28 18:39:24 horus sshd[84742]: Failed password for root from
208.94.235.248 port 42979 ssh2
Dec 28 18:39:25 horus sshd[84744]: Failed password for root from
208.94.235.248 port 43056 ssh2
Dec 28 18:39:25 horus sshd[84746]: Failed password for root from
208.94.235.248 port 43156 ssh2
Dec 28 18:39:26 horus sshd[84749]: Failed password for root from
208.94.235.248 port 43265 ssh2
Dec 28 18:39:27 horus sshd[84751]: Failed password for root from
208.94.235.248 port 43356 ssh2
The script would output the following:
199.71.214.240
199.71.212.0/22Psychz Networks, Walnut, CA, US
208.94.235.248
208.94.232.0/22WZ Communications Inc., Madison, WI, US
208.94.235.0/24Soft-Com.biz, Inc., Panama, NA, PA
Jeremy, care to share your whois lookup / parsing script for this?
Then manually (this is intentional) I go and add the entries I feel
are relevant to a file called pf.conf.ssh-deny which our systems use to
block SSH access.
...
I do something somewhat similar, though the implementation is rather
different. Like Jeremy, I choose to make the actual actions intentionally
manual.
Me too, apart from one script that tails named.run looking for victims
of DNS attacks using our system as a reflector (common here last Jan-Feb
for a while) that popped IPs straight into a block table within minutes.
Among salient points:
* Because I'm fairly familiar with it, I (still) use IPFW.
No need to apologise, Luigi's beavering away on it again as we speak,
and I'm hoping to try out ipfw+dummynet on Debian fairly soon.
* I received a bit of a prod (thanks, Julian!) to use IPFW tables;
that's been quite helpful.
* I use a moderately quaint (and probably embarrassing) mixture of Perl
Bourne shell scripts, as well as make, to extract the netblock
information from WHOIS, and to construct a persistent store that's
referenced at boot time.
Again, I'm interested in how to query and parse whois info; I've been
mostly using iptools.com and such for manual netblock lookups so far.
* As a general rule, I try to report activity such as the above (to the
listed contact(s) from WHOIS). (When I do, I Bcc: myself and keep a
opy of all salient correspondence. Or bounce-o-grams.)
Apart from stuff originating in .au I've about given up on doing that.
* For SSH (in particular), I do not rely only on the /var/log/security
entries created by sshd. Rather, I also configure IPFW to log all SSH
session-establishment requests. If I report the unwanted ativity, I
provide both sets of log excerpts. (I often find probes logged by
IPFW that sshd does not log. And yes, I check the block list before
IPFW logs a sucessful SSH session-establishment request packet.)
I'm fortunate to be able to only allow SSH access to known hosts; users
on dynamic IPs have to successfully POP their mailbox first which a cron
script notices, adding their current IP to the SSH allow table.
* I use one table to block access to SSH. I have another for extreme
cases of abuse, where I block all traffic in either direction, and a
third for access to my Web server. I suppose I could also do something
similar for SMTP
Here table 1 blocks all IP access (repetitive portscanners and such),
table 25 drops heavier mailserver abusers (apart from those denied by
/etc/mail/access), table 53 for DNS abuse, table 80 for port 80,443
abuse (apart from hosts/browsers/referers declined apache access), and
table 22 for those allowed SSH access, saving much spurious logging.
* I use this for machines that (may) connect directly to the Internet;
thus, my firewall machine certainly qualifies -- but so does my laptop.
* I have no mechanism in place to identify, let alone prune, stale
entries.
Maybe this can help, thanks to clues Michael Butler posted last year.
#!/bin/sh
# addr_to_table 24/11/8 smithi + 31/12/9 CIDR matching for updates
# add ipaddr[/masklen|32] and date (seconds from epoch) to table N
usage() {
[ $1 ] echo $1
echo usage: `basename $0` table address [masklen]
exit 1
}
[ $2 ] || usage
table=$1
[ $table -ge 1 -a $table -le 127 ] || usage table '$table' not 1..127
mlen=32; [ $3 ] mlen=$3
[ $mlen -ge 8 -a $mlen -le 32 ]
Re: Hacked - FreeBSD 7.1-Release
# pfctl -sr | grep ssh_brutes block drop quick from ssh_brutes to any pass quick on em1 inet proto tcp from any to xxx.xxx.xxx.0/23 port = ssh flags S/SA keep state (source-track rule, max-src-conn 20, max-src-conn-rate 3/12, overload ssh_brutes flush global, src.track 12) pass quick on em0 inet proto tcp from any to xxx.xxx.xxx.0/23 port = ssh flags S/SA keep state (source-track rule, max-src-conn 20, max-src-conn-rate 3/12, overload ssh_brutes flush global, src.track 12) # pfctl -t ssh_brutes -T show 24.69.83.139 24.106.149.2 59.108.230.130 59.124.109.227 60.6.237.54 60.212.42.11 61.47.34.67 78.40.82.74 79.136.123.7 79.188.234.58 85.12.25.157 85.38.97.122 85.114.135.208 94.198.49.185 110.12.64.141 114.255.100.163 116.28.64.181 121.254.228.61 123.15.41.98 123.124.236.195 158.49.245.201 173.10.126.225 189.108.172.26 190.9.128.231 193.203.70.180 195.219.57.189 202.103.25.246 203.76.99.62 203.94.231.11 208.87.3.42 210.119.104.170 211.92.149.147 211.144.32.185 212.18.195.102 216.36.150.58 218.97.254.206 218.206.233.43 221.202.118.39 222.221.2.210 # uname -a OpenBSD tereo.xxx.com 4.5 GENERIC#0 amd64 -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Mon, Dec 28, 2009 at 05:50:23PM -0600, Adam Vande More wrote: On Mon, Dec 28, 2009 at 4:59 PM, Chris H chr...@1command.com wrote: My point here was that by increasing the verbosity, you will more easily be able to grep against login /failures/, and more easily discover dictionary/ brute-force attacks. It's certainly made my job easier, and hasn't required any modifications to our current policies. You /have/ considered PF(4), haven't you? It's /really/ an excellent strategy for securing your network. --Chris H To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I use security/denyhosts for this, very simple to setup like 5 minutes if you're a fast reader. There are other options as well that offer similar functionality. I haven't used this software, but based on this page: http://denyhosts.sourceforge.net/features.html It implies that it blocks access to services using /etc/hosts.deny, which means the attackers are still able to obtain TCP connections to your box; e.g. you're still wasting sockets on these attackers, which ultimately means they're still wasting your resources. hosts.deny does not stop the establishment of the socket; only a firewall can do that. If the software can be tuned to add entries to a firewall (e.g. to a pf.conf-included file), rather than hosts.deny, then that would be advised. I've written my own script to do all of this. It parses periodic security mails (on a daily basis), and does WHOIS lookups + parses the results to tell me what netblocks/CIDRs I should consider blocking. For example, for a security mail that contains this: horus.sc1.parodius.com login failures: Dec 28 15:54:49 horus sshd[74684]: Failed password for root from 199.71.214.240 port 51197 ssh2 Dec 28 15:54:49 horus sshd[74686]: Invalid user test from 199.71.214.240 Dec 28 18:39:24 horus sshd[84742]: Failed password for root from 208.94.235.248 port 42979 ssh2 Dec 28 18:39:25 horus sshd[84744]: Failed password for root from 208.94.235.248 port 43056 ssh2 Dec 28 18:39:25 horus sshd[84746]: Failed password for root from 208.94.235.248 port 43156 ssh2 Dec 28 18:39:26 horus sshd[84749]: Failed password for root from 208.94.235.248 port 43265 ssh2 Dec 28 18:39:27 horus sshd[84751]: Failed password for root from 208.94.235.248 port 43356 ssh2 The script would output the following: 199.71.214.240 199.71.212.0/22Psychz Networks, Walnut, CA, US 208.94.235.248 208.94.232.0/22WZ Communications Inc., Madison, WI, US 208.94.235.0/24Soft-Com.biz, Inc., Panama, NA, PA Then manually (this is intentional) I go and add the entries I feel are relevant to a file called pf.conf.ssh-deny which our systems use to block SSH access. Relevant pf.conf entries: # SSH brute-force attacks, with overrides table ssh-allow persist file /conf/ME/pf.conf.ssh-allow table ssh-deny persist file /conf/ME/pf.conf.ssh-deny # Block traffic from SSH brute-force attackers, with overrides pass in quick on $ext_if proto tcp from ssh-allow to any port ssh block in quick on $ext_if proto tcp from ssh-deny to any port ssh Contents of the pf.conf.ssh-deny file resemble this: # # Network blocks which we don't want to allow SSH traffic # from. These are predominantly netblocks or IPs which have shown # signs of brute-force SSH attacks (usually dictionary-based). # # LACNIC (Latin America) # 132.247.0.0/16 132.248.0.0/16 ... # APNIC (Asia-Pacific) # ... # JNIC (Japan) # ... # RIPE (European) # ... # AFRINIC (Africa) # ... # Other (miscellaneous attackers) # ... Then I simply do /etc/rc.d/pf check /etc/rc.d/pf reload. I also have a script that pushes out the pf.conf.ssh-deny machines to other hosts on our network and executes the above commands. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Mon, Dec 28, 2009 at 10:44:41AM -0500, Andresen, Jason R. wrote: The point is, if your machine is on the internet, then bots are going to try password attacks on any open port they can find. It's just the sad fact of life on the current internet. Unfortunately, this activity will also make it much more difficult to determine when you are under attack from an actual person, which was my point earlier. It's one that is not going to be easy to solve either, unless you're willing to rewrite SSH to require every connection attempt to pass a Turing test or something. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ ed...@mavetju.org Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Tue, 29 Dec 2009 12:45:36 +0100, Edwin Groothuis ed...@mavetju.org wrote: On Mon, Dec 28, 2009 at 10:44:41AM -0500, Andresen, Jason R. wrote: The point is, if your machine is on the internet, then bots are going to try password attacks on any open port they can find. It's just the sad fact of life on the current internet. Unfortunately, this activity will also make it much more difficult to determine when you are under attack from an actual person, which was my point earlier. It's one that is not going to be easy to solve either, unless you're willing to rewrite SSH to require every connection attempt to pass a Turing test or something. The turing test is a private/public key with a passphrase. And disable passwords. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. Edwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
Adam Vande More wrote: I use security/denyhosts for this, very simple to setup like 5 minutes if you're a fast reader. There are other options as well that offer similar functionality. Like security/bruteblock -- Tuomo ... The way to a man's heart is through the left ventricle ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On 12/29/2009 3:45 AM, Edwin Groothuis wrote: mpt to pass a Turing test or something. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. Edwin I seem to recall on one of the openbsd lists someone speaking of risks of running sshd or other services on high numbered ports, presumably because a non root user cannot bind ports up to 1024. Brian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Dec 29, 2009, at 10:10 , Brian W. wrote: On 12/29/2009 3:45 AM, Edwin Groothuis wrote: mpt to pass a Turing test or something. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. Edwin I seem to recall on one of the openbsd lists someone speaking of risks of running sshd or other services on high numbered ports, presumably because a non root user cannot bind ports up to 1024. On a multi-user machine, where you want to keep students or others from spoofing on machines on which they have logins but which you manage (i.e., they don't have root or sudo), this makes sense--ON THE SERVER SIDE. The connecting client's port is going to be above 1024 anyway, and the client doesn't really care on which port the server is running. In this day and age, when anyone, black hat or white, can stand up their own *ix box and run whatever they want on whatever port, the notion of only connecting to privileged ports as a way of protecting yourself (e.g., from password sniffing or whatever) is rather quaint and ineffective. -- Chris BeHanna ch...@behanna.org___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Tue, Dec 29, 2009 at 03:20:37AM -0800, Jeremy Chadwick wrote: ... I've written my own script to do all of this. It parses periodic security mails (on a daily basis), and does WHOIS lookups + parses the results to tell me what netblocks/CIDRs I should consider blocking. For example, for a security mail that contains this: horus.sc1.parodius.com login failures: Dec 28 15:54:49 horus sshd[74684]: Failed password for root from 199.71.214.240 port 51197 ssh2 Dec 28 15:54:49 horus sshd[74686]: Invalid user test from 199.71.214.240 Dec 28 18:39:24 horus sshd[84742]: Failed password for root from 208.94.235.248 port 42979 ssh2 Dec 28 18:39:25 horus sshd[84744]: Failed password for root from 208.94.235.248 port 43056 ssh2 Dec 28 18:39:25 horus sshd[84746]: Failed password for root from 208.94.235.248 port 43156 ssh2 Dec 28 18:39:26 horus sshd[84749]: Failed password for root from 208.94.235.248 port 43265 ssh2 Dec 28 18:39:27 horus sshd[84751]: Failed password for root from 208.94.235.248 port 43356 ssh2 The script would output the following: 199.71.214.240 199.71.212.0/22Psychz Networks, Walnut, CA, US 208.94.235.248 208.94.232.0/22WZ Communications Inc., Madison, WI, US 208.94.235.0/24Soft-Com.biz, Inc., Panama, NA, PA Then manually (this is intentional) I go and add the entries I feel are relevant to a file called pf.conf.ssh-deny which our systems use to block SSH access. ... I do something somewhat similar, though the implementation is rather different. Like Jeremy, I choose to make the actual actions intentionally manual. Among salient points: * Because I'm fairly familiar with it, I (still) use IPFW. * I received a bit of a prod (thanks, Julian!) to use IPFW tables; that's been quite helpful. * I use a moderately quaint (and probably embarrassing) mixture of Perl Bourne shell scripts, as well as make, to extract the netblock information from WHOIS, and to construct a persistent store that's referenced at boot time. * As a general rule, I try to report activity such as the above (to the listed contact(s) from WHOIS). (When I do, I Bcc: myself and keep a opy of all salient correspondence. Or bounce-o-grams.) * For SSH (in particular), I do not rely only on the /var/log/security entries created by sshd. Rather, I also configure IPFW to log all SSH session-establishment requests. If I report the unwanted ativity, I provide both sets of log excerpts. (I often find probes logged by IPFW that sshd does not log. And yes, I check the block list before IPFW logs a sucessful SSH session-establishment request packet.) * I use one table to block access to SSH. I have another for extreme cases of abuse, where I block all traffic in either direction, and a third for access to my Web server. I suppose I could also do something similar for SMTP * I use this for machines that (may) connect directly to the Internet; thus, my firewall machine certainly qualifies -- but so does my laptop. * I have no mechanism in place to identify, let alone prune, stale entries. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgprLgGulJKyH.pgp Description: PGP signature
Re: Hacked - FreeBSD 7.1-Release
Tuesday, December 29, 2009, 6:20:37 AM, you wrote:
On Mon, Dec 28, 2009 at 05:50:23PM -0600, Adam Vande More wrote:
On Mon, Dec 28, 2009 at 4:59 PM, Chris H chr...@1command.com wrote:
My point here was that by increasing the verbosity, you will more easily be
able
to grep against login /failures/, and more easily discover dictionary/
brute-force
attacks. It's certainly made my job easier, and hasn't required any
modifications
to our current policies. You /have/ considered PF(4), haven't you? It's
/really/
an excellent strategy for securing your network.
--Chris H
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
I use security/denyhosts for this, very simple to setup like 5 minutes if
you're a fast reader. There are other options as well that offer similar
functionality.
Then I simply do /etc/rc.d/pf check /etc/rc.d/pf reload.
I also have a script that pushes out the pf.conf.ssh-deny machines
to other hosts on our network and executes the above commands.
Increase verbosity ? why not just create a pflog file just for port 22
or whatever you listen on for ssh or some kind of login and parse
that. See attached script for a start on parsing the explained pflog.
I have been toying around with the attached idea that makes use of
connection tracking in pf.
pass in log quick proto { tcp } from any port 1024 to any port \
{ $shports } label SCT/Login:$dstport keep state (max-src-conn 5, \
max-src-conn-rate 15/30 overload blacklist flush global)
This has worked out quite well so far but the script that is attached
has a few bugs and optimizations that could be made to it but it does
its job regardless without third-party utilities. I have added some
parsing of the pflogs through the use of tcpdump and sed to pull bad
IPs out as well but do not use that on a regular basis. I have the
script setup in a cron job to run once a hour and pull the IPs from
the active table and combine the contents with the blacklist file and
ultimately sort, uniq reload the table with the contents of the
blacklist file making adding IPs to the blacklist just add to the
table on the next cron run..
Depending on where you put your blacklist deny rule you can be saving
the rest of your services from the attackers to.
Still lots of work to be done on this but I figured I would put it out
there for someone else to toy with and see what comes out of it.
Best regards.
--
Tuesday, December 29, 2009 12:09:10 PM
jhell
pflog_fil.sh
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
Edwin Groothuis ed...@mavetju.org writes: On Mon, Dec 28, 2009 at 10:44:41AM -0500, Andresen, Jason R. wrote: The point is, if your machine is on the internet, then bots are going to try password attacks on any open port they can find. It's just the sad fact of life on the current internet. Unfortunately, this activity will also make it much more difficult to determine when you are under attack from an actual person, which was my point earlier. It's one that is not going to be easy to solve either, unless you're willing to rewrite SSH to require every connection attempt to pass a Turing test or something. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. This assumes that everybody coming in from the outside is doing so from a location that can reach port 8022 on your network. Restrictive corporate, campus, and hotspot firewalls will often break this assumption. If your network is personal, and you know the other ends of the connections won't be so draconian, this isn't a problem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
Brian W. br...@brianwhalen.net wrote: On 12/29/2009 3:45 AM, Edwin Groothuis wrote: On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. I seem to recall on one of the openbsd lists someone speaking of risks of running sshd or other services on high numbered ports, presumably because a non root user cannot bind ports up to 1024. That's probably because OpenBSD doesn't have mac_portacl(4). ;-) But basically it's right: You should never run any important services (including sshd) on ports that might be bound by unprivileged users. The basic problem is that, if the sshd daemon happens to die for some reason, an unprivileged user could run his own ssh daemon (presumably a hacked/modified one) on the same port. Of course he doesn't have the private host keys, and he can't really let users log in to the real system, so his fake ssh daemon will be discovered rather sooner than later, but it might be enough to steal some sensitive information from unsuspecting users. Historically, unprivileged users cannot bind services to port numbers below 1024, so those port numbers were considered safe regarding the above problem. However, that concept is somewhat diluted today, because you can change the range of privileged port numbers on many (most?) operating systems. On FreeBSD there are some sysctls that default to the historical range: net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 So, theoretically you can set the reservedhigh value to 8022, and then you can safely run sshd on that port number. You can even set the sysctl to 65535, completely preventing users from running _any_ services. However, this also prevents them from using active FTP and other things. A better way is to use FreeBSD's mac_portacl(4) which is quite easy to use. It enables you to install rules that specify exactly to which ports user processes are allowed to bind. So you can specifically protect the single port number 8022, for example. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing. -- Mother Teresa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Tue, Dec 29, 2009 at 02:30:11PM -0500, Lowell Gilbert wrote: On Mon, Dec 28, 2009 at 10:44:41AM -0500, Andresen, Jason R. wrote: The point is, if your machine is on the internet, then bots are going to try password attacks on any open port they can find. It's just the sad fact of life on the current internet. Unfortunately, this activity will also make it much more difficult to determine when you are under attack from an actual person, which was my point earlier. It's one that is not going to be easy to solve either, unless you're willing to rewrite SSH to require every connection attempt to pass a Turing test or something. On all systems which need to be accessible from the public Internet: Run sshd on port 22 and port 8022. Block incoming traffic on port 22 on your firewall. Everybody coming from the outside world needs to know it is running on port 8022. Everybody coming from the inside world has access as normal. This assumes that everybody coming in from the outside is doing so from a location that can reach port 8022 on your network. Restrictive corporate, campus, and hotspot firewalls will often break this assumption. If your network is personal, and you know the other ends of the connections won't be so draconian, this isn't a problem. And let's not forget the fact that the people doing the brute-force attacks already have access to multiple compromised machines (sometimes in the tens or hundreds of thousands), which means they'll eventually change their methods to include portscanning of the remote system rather than just blindly assuming TCP port 22. When you have access to so many systems, completing a full scan (65535 ports) would take a lot less time than, say, if run from a single system. Given that OpenSSH happily spits back an identity string -- including version -- to anyone who establishes a TCP connection to it, detecting if SSH is associated with said port isn't that hard. I don't know if this method is officially part of the SSH protocol or not (I'm not familiar with the protocol). Example FreeBSD box: Connected to localhost. Escape character is '^]'. SSH-2.0-OpenSSH_5.2p1 FreeBSD-20090522 The FreeBSD- string is supposed to come from VersionAddendum in /etc/ssh/sshd_config, except it appears the base system's OpenSSH defines this as the VersionAddendum default. The rest of the string, AFAIK, isn't modifiable outside of editing the source. The justification for the FreeBSD- hard-coded default is in src/crypto/openssh/FREEBSD-upgrade. I don't agree with the logic (basic security starts with give the remote attacker *as little* information about your system as possible), but I'm not going to argue: 0) VersionAddendum The SSH protocol allows for a human-readable version string of up to 40 characters to be appended to the protocol version string. FreeBSD takes advantage of this to include a date indicating the patch level, so people can easily determine whether their system is vulnerable when an OpenSSH advisory goes out. Some people, however, dislike advertising their patch level in the protocol handshake, so we've added a VersionAddendum configuration variable to allow them to change or disable it. So ultimately changing the port number from 22 to something else is just a temporary measure that does little other than annoy legitimate people connecting to your system. Don't have anyone else connecting to it? Then why not just use port 22 and deny 0.0.0.0/0 + allow netblocks you come in from? I guess some people travel a lot and use a multitude of ISPs, but surely it wouldn't take that long to build an appropriate allow/permit list. Ah well. Each to his/her own when it comes to solving this problem. Everyone likes something different/has a different method/etc. based on their needs/styles. :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: Hacked - FreeBSD 7.1-Release
From: Chris H On Tue, December 22, 2009 8:35 am, Andresen, Jason R. wrote: Squirrel wrote: most likely could be some kind of remote code execution or SQLi executed in the context of some php scripts, you should audit php code of your web interface and of the websites you host. also consider the strenght of your passwords, lots of login attempts to ssh/ftp may mean a he has tried a bruteforce (or a dictionary attack maybe). you should also check webmin logs, there are a few bruteforcer for webmin out there, (*hint*) consider the lenght of your average password if it's more than 7-8 characters aplhanumeric with simbols most likely this isn't the case. While it's true that it's a good idea to check your password strength, pretty much any host connected to the internet is going to be hit daily by bots looking for weak passwords. It's one area where you logs don't help much because there is too much noise. That's why there's GREP(1), AWK(1), FIND(1), TAIL(1), and CAT(1) Consider the following... adding the following to your /etc/rc.conf: # SECURITY RELATED syslogd_flags=-ss log_in_vain=YES tcp_keepalive=YES now your log file will /really/ sing (log_in_vain=YES). Of course, unless you have a great deal of time on your hands, visually parsing that noisy log will be quite tedious, and time consuming. So you have a few options... If your running X11, simply run tail in a root window - there are quite a few utilities in ports for doing just this - some that'll only write messages you want to see. You could also create a script out of cron that will only produce messages you are interested in, for example: ~# cat /var/log/messages | ssh will emit any attempt to ssh into your box you can also redirect the messages to a file: ~# cat /var/log/messages | ssh ~/EVIL_DOERS You could also add en entry to PERIODIC(8) that will provide a daily report on any attempts you are interested in. HTH Your solution to excessive noise in the security log is to greatly increase the noise level?!? The point is, if your machine is on the internet, then bots are going to try password attacks on any open port they can find. It's just the sad fact of life on the current internet. Unfortunately, this activity will also make it much more difficult to determine when you are under attack from an actual person, which was my point earlier. It's one that is not going to be easy to solve either, unless you're willing to rewrite SSH to require every connection attempt to pass a Turing test or something. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: Hacked - FreeBSD 7.1-Release
On Mon, December 28, 2009 7:44 am, Andresen, Jason R. wrote: From: Chris H On Tue, December 22, 2009 8:35 am, Andresen, Jason R. wrote: Squirrel wrote: most likely could be some kind of remote code execution or SQLi executed in the context of some php scripts, you should audit php code of your web interface and of the websites you host. also consider the strenght of your passwords, lots of login attempts to ssh/ftp may mean a he has tried a bruteforce (or a dictionary attack maybe). you should also check webmin logs, there are a few bruteforcer for webmin out there, (*hint*) consider the lenght of your average password if it's more than 7-8 characters aplhanumeric with simbols most likely this isn't the case. While it's true that it's a good idea to check your password strength, pretty much any host connected to the internet is going to be hit daily by bots looking for weak passwords. It's one area where you logs don't help much because there is too much noise. That's why there's GREP(1), AWK(1), FIND(1), TAIL(1), and CAT(1) Consider the following... adding the following to your /etc/rc.conf: # SECURITY RELATED syslogd_flags=-ss log_in_vain=YES tcp_keepalive=YES now your log file will /really/ sing (log_in_vain=YES). Of course, unless you have a great deal of time on your hands, visually parsing that noisy log will be quite tedious, and time consuming. So you have a few options... If your running X11, simply run tail in a root window - there are quite a few utilities in ports for doing just this - some that'll only write messages you want to see. You could also create a script out of cron that will only produce messages you are interested in, for example: ~# cat /var/log/messages | ssh will emit any attempt to ssh into your box you can also redirect the messages to a file: ~# cat /var/log/messages | ssh ~/EVIL_DOERS You could also add en entry to PERIODIC(8) that will provide a daily report on any attempts you are interested in. HTH Your solution to excessive noise in the security log is to greatly increase the noise level?!? The point is, if your machine is on the internet, then bots are going to try password attacks on any open port they can find. It's just the sad fact of life on the current internet. Unfortunately, this activity will also make it much more difficult to determine when you are under attack from an actual person, which was my point earlier. It's one that is not going to be easy to solve either, unless you're willing to rewrite SSH to require every connection attempt to pass a Turing test or something. My point here was that by increasing the verbosity, you will more easily be able to grep against login /failures/, and more easily discover dictionary/ brute-force attacks. It's certainly made my job easier, and hasn't required any modifications to our current policies. You /have/ considered PF(4), haven't you? It's /really/ an excellent strategy for securing your network. --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Mon, Dec 28, 2009 at 4:59 PM, Chris H chr...@1command.com wrote: My point here was that by increasing the verbosity, you will more easily be able to grep against login /failures/, and more easily discover dictionary/ brute-force attacks. It's certainly made my job easier, and hasn't required any modifications to our current policies. You /have/ considered PF(4), haven't you? It's /really/ an excellent strategy for securing your network. --Chris H To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I use security/denyhosts for this, very simple to setup like 5 minutes if you're a fast reader. There are other options as well that offer similar functionality. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
Chris H wrote: On Tue, December 22, 2009 8:35 am, Andresen, Jason R. wrote: Squirrel wrote: most likely could be some kind of remote code execution or SQLi executed in the context of some php scripts, you should audit php code of your web interface and of the websites you host. also consider the strenght of your passwords, lots of login attempts to ssh/ftp may mean a he has tried a bruteforce (or a dictionary attack maybe). you should also check webmin logs, there are a few bruteforcer for webmin out there, (*hint*) consider the lenght of your average password if it's more than 7-8 characters aplhanumeric with simbols most likely this isn't the case. While it's true that it's a good idea to check your password strength, pretty much any host connected to the internet is going to be hit daily by bots looking for weak passwords. It's one area where you logs don't help much because there is too much noise. That's why there's GREP(1), AWK(1), FIND(1), TAIL(1), and CAT(1) Consider the following... adding the following to your /etc/rc.conf: # SECURITY RELATED syslogd_flags=-ss log_in_vain=YES tcp_keepalive=YES now your log file will /really/ sing (log_in_vain=YES). Of course, unless you have a great deal of time on your hands, visually parsing that noisy log will be quite tedious, and time consuming. So you have a few options... If your running X11, simply run tail in a root window - there are quite a few utilities in ports for doing just this - some that'll only write messages you want to see. You could also create a script out of cron that will only produce messages you are interested in, for example: ~# cat /var/log/messages | ssh will emit any attempt to ssh into your box you can also redirect the messages to a file: ~# cat /var/log/messages | ssh ~/EVIL_DOERS You could also add en entry to PERIODIC(8) that will provide a daily report on any attempts you are interested in. HTH --Chris H I use security/logcheck: Mails anomalies in the system logfiles to the administrator. Logcheck helps spot problems, anomalies and security violations in your logfiles automatically and will send the summaries to you via e-mail. Logcheck is run as a cron job. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: Hacked - FreeBSD 7.1-Release
On Tue, December 22, 2009 8:35 am, Andresen, Jason R. wrote: Squirrel wrote: most likely could be some kind of remote code execution or SQLi executed in the context of some php scripts, you should audit php code of your web interface and of the websites you host. also consider the strenght of your passwords, lots of login attempts to ssh/ftp may mean a he has tried a bruteforce (or a dictionary attack maybe). you should also check webmin logs, there are a few bruteforcer for webmin out there, (*hint*) consider the lenght of your average password if it's more than 7-8 characters aplhanumeric with simbols most likely this isn't the case. While it's true that it's a good idea to check your password strength, pretty much any host connected to the internet is going to be hit daily by bots looking for weak passwords. It's one area where you logs don't help much because there is too much noise. That's why there's GREP(1), AWK(1), FIND(1), TAIL(1), and CAT(1) Consider the following... adding the following to your /etc/rc.conf: # SECURITY RELATED syslogd_flags=-ss log_in_vain=YES tcp_keepalive=YES now your log file will /really/ sing (log_in_vain=YES). Of course, unless you have a great deal of time on your hands, visually parsing that noisy log will be quite tedious, and time consuming. So you have a few options... If your running X11, simply run tail in a root window - there are quite a few utilities in ports for doing just this - some that'll only write messages you want to see. You could also create a script out of cron that will only produce messages you are interested in, for example: ~# cat /var/log/messages | ssh will emit any attempt to ssh into your box you can also redirect the messages to a file: ~# cat /var/log/messages | ssh ~/EVIL_DOERS You could also add en entry to PERIODIC(8) that will provide a daily report on any attempts you are interested in. HTH --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: Hacked - FreeBSD 7.1-Release
Squirrel wrote: most likely could be some kind of remote code execution or SQLi executed in the context of some php scripts, you should audit php code of your web interface and of the websites you host. also consider the strenght of your passwords, lots of login attempts to ssh/ftp may mean a he has tried a bruteforce (or a dictionary attack maybe). you should also check webmin logs, there are a few bruteforcer for webmin out there, (*hint*) consider the lenght of your average password if it's more than 7-8 characters aplhanumeric with simbols most likely this isn't the case. While it's true that it's a good idea to check your password strength, pretty much any host connected to the internet is going to be hit daily by bots looking for weak passwords. It's one area where you logs don't help much because there is too much noise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: Hacked - FreeBSD 7.1-Release
Hello This is my 6 step check list to bullet proof your any Unix box and render it unhackable by remote access. 1. Jail all services that will touch the open internet 2. Enable file and directory security such as using Tripwire or your distro file integrity program 3. Disable any non used services 4. Set IPchains to allow access to only the services you want the outside to access. 5. Off load your system logs to a NFS mount 6. Set a pass phrase for the password. *7. Make sure the computer you are using to access the Unix system is secure and does not have any key logging Trojans on it or all is for not. Thank You Sean Hulbert Miraculum Laborat Network Systems Specialist www.toolwire.com CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. igitur qui desiderat pacem, praeparet bellum!!! Epitoma Rei Militaris -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Andresen, Jason R. Sent: Tuesday, December 22, 2009 8:36 AM To: FreeBSD-STABLE Mailing List Subject: RE: Hacked - FreeBSD 7.1-Release Squirrel wrote: most likely could be some kind of remote code execution or SQLi executed in the context of some php scripts, you should audit php code of your web interface and of the websites you host. also consider the strenght of your passwords, lots of login attempts to ssh/ftp may mean a he has tried a bruteforce (or a dictionary attack maybe). you should also check webmin logs, there are a few bruteforcer for webmin out there, (*hint*) consider the lenght of your average password if it's more than 7-8 characters aplhanumeric with simbols most likely this isn't the case. While it's true that it's a good idea to check your password strength, pretty much any host connected to the internet is going to be hit daily by bots looking for weak passwords. It's one area where you logs don't help much because there is too much noise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
Hi! This is (most probably) a php coding issue and not e FreeBSD related issue per se. I would look into what type of application you run on your website and the permissions you have on your files. Check if there is something that can be upgraded. I know that at least phpBB2 had these issues in the past. I have seen this for years... If you take some text in from the hacked site text and search google, you will probably not be alone. You will probably also find out what application and what part of the code that are causing this. Also look into what modules that are loaded by php. If you dont need to write anything to disk or execute programs from php, disable it. You can make the files and directories that should be writable to have the write flag and disable it for the rest. Or have another user owning the files and enable write for that user. php does not use with .htaccess, so you cant rely on that. You will maybe find something in the apache access log that can make you find out what have been done. This is quite easy to do if you know what application is running and how it works. Just an example: (Tested and working) If you have something like: ? echo exec($_REQUEST['a']); ? in filename.php. It does not seem too harmful. It will just echo the data from what being executed from a form. like 'ls'. But then you can just add to the URL something similar to: http://www.anything.tld/filename.php?a=echo%20You%20have%20been%20hacked%20%3E%20index.php Which, for clarity, represent: http://www.anything.tld/filename.php?a=echo You have been hacked index.php This will execute exec(echo You have been hacked index.php); and overwrite the file. (That is if its writable and owned by the httpd process) Then if you add a shell script, using 'find . -name index.php -type f' and loop through the results, you end up with a whole site that is hacked. I believe the script kiddie uses a more sophisticated way of executing the overwriting code. Its too easy to write dangerous code in php and you need to be careful when writing it or else something nasty will hit the fan faster than you say dr. Hfuhruhurr... /Bjorn On Thu, 10 Dec 2009, Ganbold wrote: Squirrel wrote: I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports. Don't forget to check vulnerable php codes for SQL injection, LFI/RFI, problematic file uploads etc. Ganbold Thanks for info. -Original message- From: Matthew Seaman m.sea...@infracaninophile.co.uk Date: Thu, 10 Dec 2009 02:24:34 -0600 To: squir...@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release Squirrel wrote: I've just finished the rtld patch. Now in process of regenerating all the keys and certs. Next will look into php. But far as rtld vulnerability, doesn't it require at least a local user account? Looking at all the authentication, there wasn't any authenticated session during the time frame. So I'm leaning more towards php 5.2.9, and checking all my ports. You don't necessarily need to have a login session (ie. recorded in wtmp) to exploit the rtld bug -- just control over some process and the ability to run commands through it. Although the rtld bug is only a local root compromise, since it is so simple to exploit it is a lot more dangerous than most, and in combination with just about any form of remote exploit it means your box get rooted. Upgrading PHP and all ports is a good move. portaudit(1) is a good idea but it doesn't necessarily address the direct route your attackers used_ My suspicions (in the absence of any detailed forensic examination of your machine) are that you are running some vulnerable PHP code. This may be part of a well known application, or it may be something locally written. In this case, I'd recommend a number of measures: * Run a security scanner like nikto (ports: security/nikto) against each of the websites on your server. Do this at regular intervals, and take action to fix any problems it discovers. * Make sure that you only grant the minimum necessary permissions on the filesystem to allow apache to run your applications. In general, everything under your doc root should be *readable* by uid www but not *writable* -- don't be seduced by the idea of making the webroot owned by www:www --- root:wheel is a much better idea, and files should be mode 644, directories mode 755 unless there's a good reason to have them otherwise. * Refuse to run any PHP application that requires you to have 'register_globals = YES' or to similarly poke enormous holes in security through php.ini. Any application developer that has not modified their code to use
Re: Hacked - FreeBSD 7.1-Release
Squirrel wrote: My server was hacked, and the hacker was nice enough to not cause damage except changing index.php of couple of my websites. The index.php had the following info: Hacked By Top First Warning That's Bug From Your Servers Next Time You Must Be Careful And Fixed Your Site Before Coming Another Hacker And Hacked You Again Sorry Admin And Don't Worry Just I Change Index ALTBTA For Contact : l...@hotmail.com Best Wishes i won't be sure he has changed only indexes, it's a good rule to check carefully every other file or revert to a backup precedent to the hacking. Of course, I sent him email, just in case it's valid, asking how he did it or how should I patch things up. But haven't got a reply yet. I've looked at all the log files, particularly auth.log, although there were thousands of login attempts to SSH and FTP, but none succeeded. And I don't know where else to look, please help. I'm using FreeBSD 7.1-Release with below daemons Apache 2.2.11 ProFTP 1.32 OpenSSH 5.1 Webmin 1.480 MySQL 5.0.67 BIND 9.6.0 most likely could be some kind of remote code execution or SQLi executed in the context of some php scripts, you should audit php code of your web interface and of the websites you host. also consider the strenght of your passwords, lots of login attempts to ssh/ftp may mean a he has tried a bruteforce (or a dictionary attack maybe). you should also check webmin logs, there are a few bruteforcer for webmin out there, (*hint*) consider the lenght of your average password if it's more than 7-8 characters aplhanumeric with simbols most likely this isn't the case. check (if you have them) logs of urls requested and mysql errors, the answer could be find here probably. regards ocean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
On Wed, Dec 09, 2009 at 06:40:17PM -0600, Squirrel wrote: My server was hacked, and the hacker was nice enough to not cause damage except changing index.php of couple of my websites. The index.php had the following info: Hacked By Top First Warning That's Bug From Your Servers Next Time You Must Be Careful And Fixed Your Site Before Coming Another Hacker And Hacked You Again Sorry Admin And Don't Worry Just I Change Index ALTBTA For Contact : l...@hotmail.com Best Wishes Of course, I sent him email, just in case it's valid, asking how he did it or how should I patch things up. But haven't got a reply yet. I've looked at all the log files, particularly auth.log, although there were thousands of login attempts to SSH and FTP, but none succeeded. And I don't know where else to look, please help. I'm using FreeBSD 7.1-Release with below daemons Apache 2.2.11 ProFTP 1.32 OpenSSH 5.1 Webmin 1.480 MySQL 5.0.67 BIND 9.6.0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org 1) Immediately disable all forms of network connectivity from the Internet to this box. Do it physically if possible, otherwise cross your fingers (that nothing low-level got tinkered with) and use pf. 2) Format the box + reinstall OS. Don't bother trying to fix up what may have been changed, nor simply rebuilding world/kernel + rebooting. There is absolutely no guarantee the individual did not backdoor something, including libraries or even replace kernel modules. Don't risk it: reinstall the entire OS and rebuild from scratch, or restore necessary (non-OS) pieces from backups (assuming you know absolutely 100% for sure when the person hacked the box -- chances are it could've been hacked long before the person told you and your backups contain the same backdoors). Don't have backups? Use this situation as justification for 'em. :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
But far as rtld vulnerability, doesn't it require at least a local user account? No, it requires a script and a kiddie. ;) You'd expect your index.php (or similar) files would require a ftp/ssh/telnet connection, but useful kids have useful resources 'n which these things are not always required. Anyone can execute any code (apparently) on your machine via the exploit, having anything they want running on your machine, (i.e. that can set their env to whatever they want and get access to your machine pre -p5. Your safest bet especially since you weren't patched to the latest FreeBSD version which includes the rtld patch, is to simply not trust your machine at all; regardless of whether you are patching it now or not. I'd personally save your data, reformat the machine, and reinstall the items you need. ~Cheers This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
As long as you have to re-install everything from scratch, you can consider installing 8.0 and having your services jailed. The new jail is announced to be much improved. Markiyan. Paul Procacci wrote: But far as rtld vulnerability, doesn't it require at least a local user account? No, it requires a script and a kiddie. ;) You'd expect your index.php (or similar) files would require a ftp/ssh/telnet connection, but useful kids have useful resources 'n which these things are not always required. Anyone can execute any code (apparently) on your machine via the exploit, having anything they want running on your machine, (i.e. that can set their env to whatever they want and get access to your machine pre -p5. Your safest bet especially since you weren't patched to the latest FreeBSD version which includes the rtld patch, is to simply not trust your machine at all; regardless of whether you are patching it now or not. I'd personally save your data, reformat the machine, and reinstall the items you need. ~Cheers This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports. Thanks for info. -Original message- From: Matthew Seaman m.sea...@infracaninophile.co.uk Date: Thu, 10 Dec 2009 02:24:34 -0600 To: squir...@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release Squirrel wrote: I've just finished the rtld patch. Now in process of regenerating all the keys and certs. Next will look into php. But far as rtld vulnerability, doesn't it require at least a local user account? Looking at all the authentication, there wasn't any authenticated session during the time frame. So I'm leaning more towards php 5.2.9, and checking all my ports. You don't necessarily need to have a login session (ie. recorded in wtmp) to exploit the rtld bug -- just control over some process and the ability to run commands through it. Although the rtld bug is only a local root compromise, since it is so simple to exploit it is a lot more dangerous than most, and in combination with just about any form of remote exploit it means your box get rooted. Upgrading PHP and all ports is a good move. portaudit(1) is a good idea but it doesn't necessarily address the direct route your attackers used. My suspicions (in the absence of any detailed forensic examination of your machine) are that you are running some vulnerable PHP code. This may be part of a well known application, or it may be something locally written. In this case, I'd recommend a number of measures: * Run a security scanner like nikto (ports: security/nikto) against each of the websites on your server. Do this at regular intervals, and take action to fix any problems it discovers. * Make sure that you only grant the minimum necessary permissions on the filesystem to allow apache to run your applications. In general, everything under your doc root should be *readable* by uid www but not *writable* -- don't be seduced by the idea of making the webroot owned by www:www --- root:wheel is a much better idea, and files should be mode 644, directories mode 755 unless there's a good reason to have them otherwise. * Refuse to run any PHP application that requires you to have 'register_globals = YES' or to similarly poke enormous holes in security through php.ini. Any application developer that has not modified their code to use the $GLOBALS array by now is lazy and incompetent and their code is likely to have all sorts of other holes. * Similarly give your web application only the minimum necessary permissions it needs to access any databases. You'll frequently see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* TO w...@localhost WITH GRANT OPTION;' This is way too much and should be trimmed down. Web apps rarely have any need to make schema changes, and creating other UIDs is right out, so 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO w...@localhost' is a much more reasonable starting point. * Where a web application has a legitimate reason to want to write to the filesystem (eg. uploading files), preferably confine the write access to a separate directory tree outside the web root -- /tmp or /var/tmp aren't bad choices, but it might be better to create a specific location for a particular application. * Where a web application has an administrative mode preferably arrange to run this over HTTPS thus protecting any passwords from snooping. If the administrative mode needs to have generic read/write access to the web tree, then consider running it in a completely separate Apache instance with different user credentials than the generally accessible web server. Making the last point work with some arbitrary web application is frequently challenging, but usually at least possible by a combination of mod_rewrite and mod_proxy functions in the Apache config. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
Squirrel wrote: I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports. Don't forget to check vulnerable php codes for SQL injection, LFI/RFI, problematic file uploads etc. Ganbold Thanks for info. -Original message- From: Matthew Seaman m.sea...@infracaninophile.co.uk Date: Thu, 10 Dec 2009 02:24:34 -0600 To: squir...@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release Squirrel wrote: I've just finished the rtld patch. Now in process of regenerating all the keys and certs. Next will look into php. But far as rtld vulnerability, doesn't it require at least a local user account? Looking at all the authentication, there wasn't any authenticated session during the time frame. So I'm leaning more towards php 5.2.9, and checking all my ports. You don't necessarily need to have a login session (ie. recorded in wtmp) to exploit the rtld bug -- just control over some process and the ability to run commands through it. Although the rtld bug is only a local root compromise, since it is so simple to exploit it is a lot more dangerous than most, and in combination with just about any form of remote exploit it means your box get rooted. Upgrading PHP and all ports is a good move. portaudit(1) is a good idea but it doesn't necessarily address the direct route your attackers used_ My suspicions (in the absence of any detailed forensic examination of your machine) are that you are running some vulnerable PHP code. This may be part of a well known application, or it may be something locally written. In this case, I'd recommend a number of measures: * Run a security scanner like nikto (ports: security/nikto) against each of the websites on your server. Do this at regular intervals, and take action to fix any problems it discovers. * Make sure that you only grant the minimum necessary permissions on the filesystem to allow apache to run your applications. In general, everything under your doc root should be *readable* by uid www but not *writable* -- don't be seduced by the idea of making the webroot owned by www:www --- root:wheel is a much better idea, and files should be mode 644, directories mode 755 unless there's a good reason to have them otherwise. * Refuse to run any PHP application that requires you to have 'register_globals = YES' or to similarly poke enormous holes in security through php.ini. Any application developer that has not modified their code to use the $GLOBALS array by now is lazy and incompetent and their code is likely to have all sorts of other holes. * Similarly give your web application only the minimum necessary permissions it needs to access any databases. You'll frequently see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* TO w...@localhost WITH GRANT OPTION;' This is way too much and should be trimmed down. Web apps rarely have any need to make schema changes, and creating other UIDs is right out, so 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO w...@localhost' is a much more reasonable starting point. * Where a web application has a legitimate reason to want to write to the filesystem (eg. uploading files), preferably confine the write access to a separate directory tree outside the web root -- /tmp or /var/tmp aren't bad choices, but it might be better to create a specific location for a particular application. * Where a web application has an administrative mode preferably arrange to run this over HTTPS thus protecting any passwords from snooping. If the administrative mode needs to have generic read/write access to the web tree, then consider running it in a completely separate Apache instance with different user credentials than the generally accessible web server. Making the last point work with some arbitrary web application is frequently challenging, but usually at least possible by a combination of mod_rewrite and mod_proxy functions in the Apache config. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- I'm glad that I'm an American, I'm glad that I am free, But I wish I were a little doggy, And McGovern
Re: Hacked - FreeBSD 7.1-Release
On Dec 9, 2009, at 4:40 PM, Squirrel wrote: My server was hacked, and the hacker was nice enough to not cause damage except changing index.php of couple of my websites. The index.php had the following info: Hacked By Top First Warning That's Bug From Your Servers Next Time You Must Be Careful And Fixed Your Site Before Coming Another Hacker And Hacked You Again Sorry Admin And Don't Worry Just I Change Index ALTBTA For Contact : l...@hotmail.com Best Wishes While it's unfortunate that your machine was hacked, and it would be nice to assume that no other changes were made, you need to completely rebuild this box, regenerate SSH keys, SSL certs, etc before you can trust anything it talks to. Of course, I sent him email, just in case it's valid, asking how he did it or how should I patch things up. But haven't got a reply yet. I've looked at all the log files, particularly auth.log, although there were thousands of login attempts to SSH and FTP, but none succeeded. And I don't know where else to look, please help. I'm using FreeBSD 7.1-Release with below daemons Apache 2.2.11 ProFTP 1.32 OpenSSH 5.1 Webmin 1.480 MySQL 5.0.67 BIND 9.6.0 You're down-rev on Apache and BIND, for the very least. And, the fact that you mentioned index.php suggests that you're running a lot more than just a basic Apache webserver; PHP is a likely candidate for security vulnerabilities by itself, and if you haven't patched for FreeBSD-SA-09:16.rtld, any local exploit will yield root. Installing /usr/ports/ports-mgmt/portaudit can be helpful Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Squirrel wrote: My server was hacked, and the hacker was nice enough to not cause damage except changing index.php of couple of my websites. The index.php had the following info: Hacked By Top First Warning That's Bug From Your Servers Next Time You Must Be Careful And Fixed Your Site Before Coming Another Hacker And Hacked You Again Sorry Admin And Don't Worry Just I Change Index ALTBTA For Contact : l...@hotmail.com Best Wishes Of course, I sent him email, just in case it's valid, asking how he did it or how should I patch things up. But haven't got a reply yet. I've looked at all the log files, particularly auth.log, although there were thousands of login attempts to SSH and FTP, but none succeeded. And I don't know where else to look, please help. I'm using FreeBSD 7.1-Release with below daemons Apache 2.2.11 ProFTP 1.32 OpenSSH 5.1 Webmin 1.480 MySQL 5.0.67 BIND 9.6.0 It could be tricky to figure out how the attacker gets in. I'd be curious what PHP application are you using right now? Do you have properly set the permissions (i.e. files are either executable, or writable, but not both; www user can't write on where code can be executed, etc), and there is no vulnerability in your web application? By the way, if you use ports you can install ports-mgmt/portaudit and use 'portaudit -Fda' to check if there is known vulnerability with your installed packages, just a hint. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksgTFUACgkQi+vbBBjt66DA5gCeKX9oPnuBJOEznAA6WOxozpTz hZMAoI2CRuXM6o/t9JuKffPli6Uk7uQ/ =rOnr -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
I've just finished the rtld patch. Now in process of regenerating all the keys and certs. Next will look into php. But far as rtld vulnerability, doesn't it require at least a local user account? Looking at all the authentication, there wasn't any authenticated session during the time frame. So I'm leaning more towards php 5.2.9, and checking all my ports. Thanks for info. -Original message- From: Chuck Swiger cswi...@mac.com Date: Wed, 09 Dec 2009 20:12:08 -0600 To: squir...@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release On Dec 9, 2009, at 4:40 PM, Squirrel wrote: My server was hacked, and the hacker was nice enough to not cause damage except changing index.php of couple of my websites. The index.php had the following info: Hacked By Top First Warning That's Bug From Your Servers Next Time You Must Be Careful And Fixed Your Site Before Coming Another Hacker And Hacked You Again Sorry Admin And Don't Worry Just I Change Index ALTBTA For Contact : l...@hotmail.com Best Wishes While it's unfortunate that your machine was hacked, and it would be nice to assume that no other changes were made, you need to completely rebuild this box, regenerate SSH keys, SSL certs, etc before you can trust anything it talks to. Of course, I sent him email, just in case it's valid, asking how he did it or how should I patch things up. But haven't got a reply yet. I've looked at all the log files, particularly auth.log, although there were thousands of login attempts to SSH and FTP, but none succeeded. And I don't know where else to look, please help. I'm using FreeBSD 7.1-Release with below daemons Apache 2.2.11 ProFTP 1.32 OpenSSH 5.1 Webmin 1.480 MySQL 5.0.67 BIND 9.6.0 You're down-rev on Apache and BIND, for the very least. And, the fact that you mentioned index.php suggests that you're running a lot more than just a basic Apache webserver; PHP is a likely candidate for security vulnerabilities by itself, and if you haven't patched for FreeBSD-SA-09:16.rtld, any local exploit will yield root. Installing /usr/ports/ports-mgmt/portaudit can be helpful Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
Taking your advice and checking all ports for problems. Thanks. -Original message- From: Xin LI delp...@delphij.net Date: Wed, 09 Dec 2009 20:18:13 -0600 To: squir...@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Squirrel wrote: My server was hacked, and the hacker was nice enough to not cause damage except changing index.php of couple of my websites. The index.php had the following info: Hacked By Top First Warning That's Bug From Your Servers Next Time You Must Be Careful And Fixed Your Site Before Coming Another Hacker And Hacked You Again Sorry Admin And Don't Worry Just I Change Index ALTBTA For Contact : l...@hotmail.com Best Wishes Of course, I sent him email, just in case it's valid, asking how he did it or how should I patch things up. But haven't got a reply yet. I've looked at all the log files, particularly auth.log, although there were thousands of login attempts to SSH and FTP, but none succeeded. And I don't know where else to look, please help. I'm using FreeBSD 7.1-Release with below daemons Apache 2.2.11 ProFTP 1.32 OpenSSH 5.1 Webmin 1.480 MySQL 5.0.67 BIND 9.6.0 It could be tricky to figure out how the attacker gets in. I'd be curious what PHP application are you using right now? Do you have properly set the permissions (i.e. files are either executable, or writable, but not both; www user can't write on where code can be executed, etc), and there is no vulnerability in your web application? By the way, if you use ports you can install ports-mgmt/portaudit and use 'portaudit -Fda' to check if there is known vulnerability with your installed packages, just a hint. Cheers, - -- Xin LI delp...@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve!Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksgTFUACgkQi+vbBBjt66DA5gCeKX9oPnuBJOEznAA6WOxozpTz hZMAoI2CRuXM6o/t9JuKffPli6Uk7uQ/ =rOnr -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Hacked - FreeBSD 7.1-Release
Squirrel wrote: I've just finished the rtld patch. Now in process of regenerating all the keys and certs. Next will look into php. But far as rtld vulnerability, doesn't it require at least a local user account? Looking at all the authentication, there wasn't any authenticated session during the time frame. So I'm leaning more towards php 5.2.9, and checking all my ports. You don't necessarily need to have a login session (ie. recorded in wtmp) to exploit the rtld bug -- just control over some process and the ability to run commands through it. Although the rtld bug is only a local root compromise, since it is so simple to exploit it is a lot more dangerous than most, and in combination with just about any form of remote exploit it means your box get rooted. Upgrading PHP and all ports is a good move. portaudit(1) is a good idea but it doesn't necessarily address the direct route your attackers used. My suspicions (in the absence of any detailed forensic examination of your machine) are that you are running some vulnerable PHP code. This may be part of a well known application, or it may be something locally written. In this case, I'd recommend a number of measures: * Run a security scanner like nikto (ports: security/nikto) against each of the websites on your server. Do this at regular intervals, and take action to fix any problems it discovers. * Make sure that you only grant the minimum necessary permissions on the filesystem to allow apache to run your applications. In general, everything under your doc root should be *readable* by uid www but not *writable* -- don't be seduced by the idea of making the webroot owned by www:www --- root:wheel is a much better idea, and files should be mode 644, directories mode 755 unless there's a good reason to have them otherwise. * Refuse to run any PHP application that requires you to have 'register_globals = YES' or to similarly poke enormous holes in security through php.ini. Any application developer that has not modified their code to use the $GLOBALS array by now is lazy and incompetent and their code is likely to have all sorts of other holes. * Similarly give your web application only the minimum necessary permissions it needs to access any databases. You'll frequently see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* TO w...@localhost WITH GRANT OPTION;' This is way too much and should be trimmed down. Web apps rarely have any need to make schema changes, and creating other UIDs is right out, so 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO w...@localhost' is a much more reasonable starting point. * Where a web application has a legitimate reason to want to write to the filesystem (eg. uploading files), preferably confine the write access to a separate directory tree outside the web root -- /tmp or /var/tmp aren't bad choices, but it might be better to create a specific location for a particular application. * Where a web application has an administrative mode preferably arrange to run this over HTTPS thus protecting any passwords from snooping. If the administrative mode needs to have generic read/write access to the web tree, then consider running it in a completely separate Apache instance with different user credentials than the generally accessible web server. Making the last point work with some arbitrary web application is frequently challenging, but usually at least possible by a combination of mod_rewrite and mod_proxy functions in the Apache config. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
