Re: Hacked - FreeBSD 7.1-Release

2010-01-02 Thread Ian Smith
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()
 > {
 >   $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

Re: Hacked - FreeBSD 7.1-Release

2009-12-31 Thread Jeremy Chadwick
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()
{
  $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

2009-12-30 Thread Ian Smith
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 -

Re: Hacked - FreeBSD 7.1-Release

2009-12-30 Thread Edwin Groothuis
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

2009-12-30 Thread Stephane Rochoy
On Tue, Dec 29, 2009 at 08:46:57PM +0100, Oliver Fromme wrote:
> Brian W.  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

2009-12-29 Thread Jeremy Chadwick
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

2009-12-29 Thread Oliver Fromme
Brian W.  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

2009-12-29 Thread Lowell Gilbert
Edwin Groothuis  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

2009-12-29 Thread jhell

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  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  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

2009-12-29 Thread David Wolfskill
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

2009-12-29 Thread Chris BeHanna
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

2009-12-29 Thread Brian W.

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

2009-12-29 Thread Tuomo Latto
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

2009-12-29 Thread Ronald Klop
On Tue, 29 Dec 2009 12:45:36 +0100, Edwin Groothuis   
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

2009-12-29 Thread Edwin Groothuis
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

2009-12-29 Thread Jeremy Chadwick
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  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  persist file "/conf/ME/pf.conf.ssh-allow"
table  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  to any port ssh
block in quick on $ext_if proto tcp from  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

2009-12-29 Thread Jordi Espasa Clofent

# pfctl -sr | grep ssh_brutes
block drop quick from  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  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

 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

2009-12-28 Thread Adam Vande More
On Mon, Dec 28, 2009 at 4:59 PM, Chris H  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

2009-12-28 Thread Chris H
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

2009-12-28 Thread Andresen, Jason R.
>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

2009-12-25 Thread Dan Langille

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

2009-12-24 Thread 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

--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

2009-12-22 Thread Sean Hulbert
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

2009-12-22 Thread Andresen, Jason R.
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

2009-12-14 Thread kama

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:



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 filesys

Re: Hacked - FreeBSD 7.1-Release

2009-12-10 Thread Ganbold
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 challen

Re: Hacked - FreeBSD 7.1-Release

2009-12-10 Thread Squirrel
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

2009-12-10 Thread Markiyan Kushnir
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

2009-12-10 Thread Paul Procacci

>> 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

2009-12-10 Thread Jeremy Chadwick
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

2009-12-10 Thread ocean

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

2009-12-09 Thread Matthew Seaman

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


Re: Hacked - FreeBSD 7.1-Release

2009-12-09 Thread Squirrel
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   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

2009-12-09 Thread Squirrel
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

2009-12-09 Thread Xin LI
-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 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

2009-12-09 Thread Chuck Swiger
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"


Hacked - FreeBSD 7.1-Release

2009-12-09 Thread Squirrel
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"