[K12OSN] reporting and/or stopping cracking attempts on server
David L. Willson
DLWillson at TheGeek.NU
Fri Mar 18 17:50:29 UTC 2011
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>
More information about the K12OSN
mailing list