[K12OSN] reporting and/or stopping cracking attempts on server

Fri Mar 18 19:52:03 UTC 2011

All of us would be well advised to listen to Terrell - he is wise and
helpful.

julius

> I'm sorry if you felt I was accusing you of being uncivil. Nothing like
> that was my intent.
>
> My opening the discussion with "keep it civil" was meant as a preventive,
> not as a response to anything you said or did.
> I've been in enough technical discussions over debatable administrative
> philosophy that degraded into flame-fests, that I figured I'd say at the
> beginning that, for me, flame-fests aren't fun, they're an embarrassing
> waste of bandwidth. OTOH, sane discussions of administrative
> policy/philosophy are fun and enlightening.
>
> I think we've covered everything technically. Your findings with regard to
> ssh cracking are very different from my own. I'll try to find time to do a
> little fresh testing, and return with my results.
>
> ----- "Terrell Prude' Jr." <microman at cmosnetworks.com> wrote:
>
>> Not sure what the "keep it civil" comment was for, as I do not believe
>> I
>> was "uncivil".
>>
>> But anyway....
>>
>> Moving ports around unfortunately doesn't work, due to SSH-specific
>> port
>> scanners that can easily and quickly scan all 65,536 TCP ports.  I
>> tried
>> that myself on a test box as an experiment, and the result was all
>> sorts
>> of attack attempts within a week of standing up the server.
>> Everything
>> but that specific port was blocked coming in.  Of course, I had
>> hardened
>> the box so that such attacks would be exceedingly unlikely to succeed,
>>
>> and none did, but the point is that the attackers still found my SSH
>> daemon with the port moved (no, not something obvious like TCP 222,
>> 2222, 31337, or similar).
>>
>> On the other hand, blocking pings is not what I'd call security
>> through
>> obscurity.  That's because there are actual attacks against boxes that
>>
>> use ICMP (e. g. Ping of Death from the 1990's, and there may be other,
>>
>> newer ones).  For this reason, the typical system cracker that I
>> encounter now assumes that ping will be blocked and simply does a TCP
>>
>> port scan without bothering to ping first.
>>
>> Instead, I would consider setting up a "honey-pot" decoy box on
>> another
>> IP address in that same subnet (preferably one that comes "before" the
>>
>> real box due to the way most people port-scan, e. g. the honey-pot
>> would
>> be a.b.c.99 and the real box a.b.c.100), running a pseudo SSH daemon,
>>
>> kinda-sorta like how the OpenBSD project does with SMTP and their
>> excellent SPAMD program.  Have that decoy box configured to email you
>>
>> whenever there is an attack against it, so that you can take action or
>>
>> trigger a script on the "real" box to do an "iptables -A INPUT -s
>> w.x.y.z -j DROP" on the attacking IP address.  Naturally, the
>> honey-pot
>> decoy needs to be very well hardened if it's going to talk to the real
>>
>> box like this.
>>
>> --TP
>>
>>
>> David L. Willson wrote:
>> > This discussion might deserve to be had if we can keep it civil, and
>> I suppose we can.
>> >
>> > There are two major "security through obscurity" maneuvers I approve
>> of:
>> >
>> >  - Decline ping
>> >  - Move ssh to a non-default port
>> >
>> > Both are intended to evade attack by the 99%, and both are proven
>> effective over time on many hosts.
>> >
>> > When you say that "security through obscurity is no security at
>> all", what do you mean? I heard those words many, many years ago, and
>> accepted them verbatim for a time, and took them to mean that a secure
>> host would be secure "no matter what". I pictured in my mind, a
>> hardened, shining server gleaming in a field of rampaging orcs,
>> impervious to their blows. Over time I realized that being obvious, by
>> replying to pings, running ssh on the default port, returning service
>> version numbers, etc. encourages attacks, and makes them more
>> frequent, and that responding to attacks takes up valuable bandwidth,
>> mine and the server's. I came gradually to think that not being
>> attacked might be a valuable part of good security, and that therefore
>> obscuring the target might be a perfectly acceptable way to throw off
>> the enemy's archers, so to speak.
>> >
>> > I suppose you may have heard that perspective, too, and I wonder
>> what you think of it.
>> >
>> > For me, obscurity actually ~is~ a valuable part of security.
>> >
>> > David L. Willson
>> > Trainer, Engineer, Enthusiast
>> > RHCE MCT MCSE Network+ A+ Linux+ LPIC-1 NovellCLA UbuntuCP
>> > tel://720.333.LANS
>> > Freedom is better when you earn it. Learn Linux.
>> >
>> > ----- "Terrell Prude' Jr." <microman at cmosnetworks.com> wrote:
>> >
>> >
>> >> Moving SSH to a nonstandard port has been suggested.  I disagree
>> with
>> >>
>> >> that, because, as an INFOSEC engineer, I've learned over the years
>> >> that
>> >> security through obscurity is no security at all.  I'm in a similar
>>
>> >> situation with a Debian box that I run at work, also accessible
>> from
>> >> the
>> >> Internet.
>> >>
>> >> What I do is packet-filter the daylights out of it and use fail2ban
>>
>> >> (looks like you are, too--very good).  I like the concept of
>> DenyHosts
>> >> a
>> >> lot, and I believe that fail2ban is the improved version of that
>> >> concept, since it uses iptables, thus preventing the "bad" packets
>> >> from
>> >> ever getting to any daemon in the first place.  Reduce your total
>> >> login
>> >> attempts to 3, and block that offending IP address for a month.
>> >>
>> >> Now, that said....
>> >>
>> >> Personally, I wouldn't be running all that stuff on the same box to
>>
>> >> begin with.  Yes, SELinux is helpful, and it should be used.
>> However,
>> >> I
>> >> guess I'm still of the old school that says "one bastion host for
>> >> HTTP,
>> >> one bastion host for email, one bastion host for <insert whatever
>> >> else>", etc.  It's just so much easier to design and keep security
>> >> rules
>> >> (ACL's and such) with those functions on separate servers.
>> >> Virtualization can help out here if you don't want to run more
>> than
>> >> one
>> >> physical box.  Fortunately, CentOS 5 has Xen and KVM, both of which
>>
>> >> actually work pretty well.
>> >>
>> >> --TP
>> >>
>> >>
>> >> Carl Keil wrote:
>> >>
>> >>> Hello folks,
>> >>>
>> >>> For those of you that run servers exposed to the outside world, I
>> >>>
>> >> just
>> >>
>> >>> wanted to send a ping out and see what others are doing about
>> this.
>> >>>
>> >>> I'm seeing an escalation in what I call "brute force" attacks on
>> my
>> >>>
>> >>> server.  Like people trying to SSH in repeatedly from one IP with
>>
>> >>> common sounding user names.  Or lots of http requests (I've got
>> web
>> >>>
>> >> on
>> >>
>> >>> the same server) for ....setup.php or setup.pl etc.  Repeated Auth
>>
>> >>> requests to sendmail.
>> >>>
>> >>> I've started running fail2ban, which, I feel does a great job of
>> >>> cutting this down.  Is there anything better that's about equally
>> as
>> >>>
>> >>> easy to setup?  Is there any point in making the effort to look
>> up
>> >>>
>> >> the
>> >>
>> >>> IP's and contact the ISP's about this?  Or does that just piss
>> off
>> >>>
>> >> the
>> >>
>> >>> script kiddies and make you more of a target.  I don't want to
>> have
>> >>>
>> >> to
>> >>
>> >>> become a full on security expert, but I want to make sure I'm
>> doing
>> >>>
>> >>> all the easy no-brainer stuff that can protect you 99% of the
>> time.
>> >>>
>> >> I
>> >>
>> >>> hope that attitude doesn't offend anyone.  I'm not working for a
>> >>> school.  I got into ltsp for home use and just run it for
>> >>>
>> >> convenience
>> >>
>> >>> and pleasure.  Dealing with idiots who are trying to break in cuts
>>
>> >>> down on both.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> ck
>> >>>
>> >>> _______________________________________________
>> >>> K12OSN mailing list
>> >>> K12OSN at redhat.com
>> >>> https://www.redhat.com/mailman/listinfo/k12osn
>> >>> For more info see <http://www.k12os.org>
>> >>>
>> >> _______________________________________________
>> >> K12OSN mailing list
>> >> K12OSN at redhat.com
>> >> https://www.redhat.com/mailman/listinfo/k12osn
>> >> For more info see <http://www.k12os.org>
>> >>
>> >
>> > _______________________________________________
>> > K12OSN mailing list
>> > K12OSN at redhat.com
>> > https://www.redhat.com/mailman/listinfo/k12osn
>> > For more info see <http://www.k12os.org>
>> >
>>
>> _______________________________________________
>> K12OSN mailing list
>> K12OSN at redhat.com
>> https://www.redhat.com/mailman/listinfo/k12osn
>> For more info see <http://www.k12os.org>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>