 | | | Taroon-list Digest, Vol 8, Issue 40 | Taroon-list Digest, Vol 8, Issue 40 2004-10-18 - By Daryl Daly
Back
Bruce,
Here is some info you may be interested in. Look at the messages regarding
the topic "attack ". Looks like this is what is affecting us.
Daryl.
taroon-list-request@(protected) said:
> Send Taroon-list mailing list submissions to
> taroon-list@(protected)
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
http://www.redhat.com/mailman/listinfo/taroon-list
> or, via email, send a message with subject or body 'help ' to
> taroon-list-request@(protected)
>
> You can reach the person managing the list at
> taroon-list-owner@(protected)
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Taroon-list digest... "
>
>
> Today 's Topics:
>
> 1. Re: Apache mod_deflate errors (Brent Goran)
> 2. attack (Rob)
> 3. Re: attack (Stephen J. Smoogen)
> 4. Re: attack (nathan r. hruby)
> 5. Re: attack (nathan r. hruby)
> 6. Re: attack (John Haxby)
> 7. Re: Apache mod_deflate errors (Brent Goran)
>
>
> -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
>
> Message: 1
> Date: Sun, 17 Oct 2004 10:11:22 -0600
> From: Brent Goran <brent@(protected) >
> Subject: Re: Apache mod_deflate errors
> To: Joe Orton <jorton@(protected) >
> Cc: "Discussion of Red Hat Enterprise Linux 3 \(Taroon\) "
> <taroon-list@(protected) >
> Message-ID: <1098029482.19272.0.camel@(protected) >
> Content-Type: text/plain; charset= "us-ascii "
>
> Thank you, you may be onto something that I have overall system memory
> issues. I have a ton of processing running and the only thing which
> shows signs of breakage is apache via mod_deflate. That 's strange, I
> would expect some of my other procs to bomb as well. But you 've given me
> a very good clue, thanks for your help.
>
>
>
> On Sun, 2004-10-17 at 09:15, Joe Orton wrote:
>
> > On Sun, Oct 17, 2004 at 08:57:47AM -0600, Brent Goran wrote:
> > > Thank you, someone knowledgable responding! ;)
> > >
> > > I have MaxRequestsPerChild set to 10. I lowered it from the defaults
> > for
> > > this reason, hoping that, if users started generating this error, at
> > > least it would only generate 10 of them before recycling the server
> > > process. But evidently it didn 't work.
> >
> > You mean you were seeing this error even with M.R.P.C. set to 10? That
> > would imply that something else on the server is causing the memory
> > pressure. And 10 is *very* low, I wouldn 't recommend leaving it like
> > that for long.
> >
> > But first it 's necessary to establish that it really is httpd which is
> > causing the memory problems, using ps, top, sar etc as normal.
> >
> > joe
> -- ---- ------ next part -- ---- ------
> An HTML attachment was scrubbed...
> URL: /archives/taroon-list/attachments/20041017/ff401cfb/attachment.htm
>
> -- ---- ---- ---- ---- ---- --
>
> Message: 2
> Date: Sun, 17 Oct 2004 09:44:41 -0700
> From: Rob <WASGuru@(protected) >
> Subject: attack
> To: "Discussion of Red Hat Enterprise Linux 3 (Taroon) "
> <taroon-list@(protected) >
> Message-ID: <ab24238b041017094479e185c2@(protected) >
> Content-Type: text/plain; charset=US-ASCII
>
> is there any way to detect this kind of attack and block the attacker 's
> ip?
>
> Failed logins from these:
> account/password from 212.145.146.6: 1 Time(s)
> account/password from 67.98.78.111: 1 Time(s)
> adam/password from 212.145.146.6: 1 Time(s)
> adam/password from 67.98.78.111: 1 Time(s)
> adm/password from 212.145.146.6: 2 Time(s)
> adm/password from 67.98.78.111: 2 Time(s)
> alan/password from 212.145.146.6: 1 Time(s)
> alan/password from 67.98.78.111: 1 Time(s)
> apache/password from 212.145.146.6: 1 Time(s)
> apache/password from 67.98.78.111: 1 Time(s)
> backup/password from 212.145.146.6: 1 Time(s)
> backup/password from 67.98.78.111: 1 Time(s)
> cip51/password from 212.145.146.6: 1 Time(s)
> cip51/password from 67.98.78.111: 1 Time(s)
> cip52/password from 212.145.146.6: 1 Time(s)
> cip52/password from 67.98.78.111: 1 Time(s)
> cosmin/password from 212.145.146.6: 1 Time(s)
> cosmin/password from 67.98.78.111: 1 Time(s)
> cyrus/password from 212.145.146.6: 1 Time(s)
> cyrus/password from 67.98.78.111: 1 Time(s)
> data/password from 212.145.146.6: 1 Time(s)
> data/password from 67.98.78.111: 1 Time(s)
> frank/password from 212.145.146.6: 1 Time(s)
> frank/password from 67.98.78.111: 1 Time(s)
> george/password from 212.145.146.6: 1 Time(s)
> george/password from 67.98.78.111: 1 Time(s)
> guest/password from 211.169.202.21: 1 Time(s)
> henry/password from 212.145.146.6: 1 Time(s)
> henry/password from 67.98.78.111: 1 Time(s)
> horde/password from 212.145.146.6: 1 Time(s)
> horde/password from 67.98.78.111: 1 Time(s)
> iceuser/password from 212.145.146.6: 1 Time(s)
> iceuser/password from 67.98.78.111: 1 Time(s)
> irc/password from 212.145.146.6: 2 Time(s)
> irc/password from 67.98.78.111: 2 Time(s)
> jane/password from 212.145.146.6: 1 Time(s)
> jane/password from 67.98.78.111: 1 Time(s)
> john/password from 212.145.146.6: 1 Time(s)
> john/password from 67.98.78.111: 1 Time(s)
> master/password from 212.145.146.6: 1 Time(s)
> master/password from 67.98.78.111: 1 Time(s)
> matt/password from 212.145.146.6: 1 Time(s)
> matt/password from 67.98.78.111: 1 Time(s)
> mysql/password from 212.145.146.6: 1 Time(s)
> mysql/password from 67.98.78.111: 1 Time(s)
> nobody/password from 212.145.146.6: 1 Time(s)
> nobody/password from 67.98.78.111: 1 Time(s)
> noc/password from 212.145.146.6: 1 Time(s)
> noc/password from 67.98.78.111: 1 Time(s)
> operator/password from 212.145.146.6: 1 Time(s)
> operator/password from 67.98.78.111: 1 Time(s)
> oracle/password from 212.145.146.6: 1 Time(s)
> oracle/password from 67.98.78.111: 1 Time(s)
> pamela/password from 212.145.146.6: 1 Time(s)
> pamela/password from 67.98.78.111: 1 Time(s)
> patrick/password from 212.145.146.6: 2 Time(s)
> patrick/password from 67.98.78.111: 2 Time(s)
> rolo/password from 212.145.146.6: 1 Time(s)
> rolo/password from 67.98.78.111: 1 Time(s)
> root/password from 212.145.146.6: 59 Time(s)
> root/password from 67.98.78.111: 59 Time(s)
> server/password from 212.145.146.6: 1 Time(s)
> server/password from 67.98.78.111: 1 Time(s)
> sybase/password from 212.145.146.6: 1 Time(s)
> sybase/password from 67.98.78.111: 1 Time(s)
> test/password from 211.169.202.21: 1 Time(s)
> test/password from 212.145.146.6: 5 Time(s)
> test/password from 67.98.78.111: 5 Time(s)
> user/password from 212.145.146.6: 3 Time(s)
> user/password from 67.98.78.111: 3 Time(s)
> web/password from 212.145.146.6: 2 Time(s)
> web/password from 67.98.78.111: 2 Time(s)
> webmaster/password from 212.145.146.6: 1 Time(s)
> webmaster/password from 67.98.78.111: 1 Time(s)
> www-data/password from 212.145.146.6: 1 Time(s)
> www-data/password from 67.98.78.111: 1 Time(s)
> www/password from 212.145.146.6: 1 Time(s)
> www/password from 67.98.78.111: 1 Time(s)
> wwwrun/password from 212.145.146.6: 1 Time(s)
> wwwrun/password from 67.98.78.111: 1 Time(s)
>
>
>
> -- ---- ---- ---- ---- ---- --
>
> Message: 3
> Date: Sun, 17 Oct 2004 11:10:03 -0600
> From: "Stephen J. Smoogen " <smooge@(protected) >
> Subject: Re: attack
> To: Rob <wasguru@(protected) >, "Discussion of Red Hat Enterprise Linux 3
> (Taroon) " <taroon-list@(protected) >
> Message-ID: <80d7e409041017101012205aa0@(protected) >
> Content-Type: text/plain; charset=US-ASCII
>
> On Sun, 17 Oct 2004 09:44:41 -0700, Rob <wasguru@(protected) > wrote:
> > is there any way to detect this kind of attack and block the attacker 's
> > ip?
> >
> > Failed logins from these:
> > account/password from 212.145.146.6: 1 Time(s)
> > account/password from 67.98.78.111: 1 Time(s)
>
>
> This sounds like one of the many ssh zombie machines constantly
> scanning the Internet. The ways to lock this down are:
>
> 1) Only open up services you want to the internet to the places on the
> internet you want them from. For things like telnet and ssh use
> tcp_wrappers and iptables to only allow the machines you want to talk
> to you access.
>
> 2) Turn off all services you dont need. Make sure that you didnt leave
> on some service that you were playing with and then forgot to turn it
> off.
>
> 3) Use strong passwords. 8 letter minimum with minimums of 2 numbers
> and 2 special characters.
>
> 4) Make sure that when you use ssh that you can verify the client you
> are using. A popular attack is to change out the ssh client and sniff
> passwords.
>
> 5) Be ever vigilant.
>
> --
> Stephen J Smoogen.
> Professional System Administrator
>
>
>
> -- ---- ---- ---- ---- ---- --
>
> Message: 4
> Date: Sun, 17 Oct 2004 13:19:04 -0400 (EDT)
> From: "nathan r. hruby " <nhruby@(protected) >
> Subject: Re: attack
> To: Rob <WASGuru@(protected) >, "Discussion of Red Hat Enterprise Linux 3
> (Taroon) " <taroon-list@(protected) >
> Message-ID: <Pine.LNX.4.61.0410171255120.4774@(protected) >
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Sun, 17 Oct 2004, Rob wrote:
>
> > is there any way to detect this kind of attack and block the attacker 's
> > ip?
> >
> > Failed logins from these: account/password from 212.145.146.6: 1 Time(s)
> > account/password from 67.98.78.111: 1 Time(s)
>
> You too huh? The scanners are out in force this morning.
>
> One, I 'd take the time to email the abuse people for those IP 's, they
> can 't fix it if they don 't know. (Anyone here know someone at SANS to
> maybe drop a clue to the ISC handler on duty?)
>
> There used to be a program called PortSentry that would monitor these
> sorts of things, made by the same folks who made logcheck. Cisco bought
> them and the programs and are now hard to find. I doubt it 'd even run on
> RHEL3 now ....
>
> I 'm sure there 's other stuff that will pro-activly add iptables ruels to
> block these jokers out there somewhere.. search around on freshmeat.net,
> perhaps someone here has a favorite they 'd be willing to divludge as well.
>
> Minimally, you could pipe the report you had and do something like:
> awk '{print $3} ' | sort | uniq | xargs -n1 -iG iptables G <drop >
>
> Hmm.... You know, I dida quick freshmeat search and nothing popped up
> quickly (odd.. I do remember seeing something the last time I looked at
> this....) so a bit of googling reveals this link which does what you want:
>
>
http://www.linuxforums.org/forum/post-119623.html
>
> Also, as a general principal, it 's always nice to maybe have one bastion
> host in your network that you log into and then use as a jump point to
> your other systems, the others being locked down to your local network or
> possibly just the bastion host. This makes these sorts of attacks much
> harder to do (though nothing is impossible, software had bugs, even
> firewall software :)
>
> -n
>
> --
> -- ---- ---- ---- ---- ---- ---- ---- -----
> nathan hruby <nhruby@(protected) >
> uga enterprise information technology services
> production systems support
> metaphysically wrinkle-free
> -- ---- ---- ---- ---- ---- ---- ---- -----
>
>
>
> -- ---- ---- ---- ---- ---- --
>
> Message: 5
> Date: Sun, 17 Oct 2004 13:29:15 -0400 (EDT)
> From: "nathan r. hruby " <nhruby@(protected) >
> Subject: Re: attack
> To: "Stephen J. Smoogen " <smooge@(protected) >, "Discussion of Red Hat
> Enterprise Linux 3 (Taroon) " <taroon-list@(protected) >
> Message-ID: <Pine.LNX.4.61.0410171326230.4774@(protected) >
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Sun, 17 Oct 2004, Stephen J. Smoogen wrote:
>
>
> > This sounds like one of the many ssh zombie machines constantly
> > scanning the Internet. The ways to lock this down are:
> >
> > 1) Only open up services you want to the internet to the places on the
> > internet you want them from. For things like telnet and ssh use
> > tcp_wrappers and iptables to only allow the machines you want to talk
> > to you access.
> >
> > 2) Turn off all services you dont need. Make sure that you didnt leave
> > on some service that you were playing with and then forgot to turn it
> > off.
> >
> > 3) Use strong passwords. 8 letter minimum with minimums of 2 numbers
> > and 2 special characters.
> >
> > 4) Make sure that when you use ssh that you can verify the client you
> > are using. A popular attack is to change out the ssh client and sniff
> > passwords.
> >
> > 5) Be ever vigilant.
>
> Indeed! All good suggestions. CERT has a nice checklist (with
> implementation hints) for locking down the most common security issues in
> a Unix environment. It can be found at:
>
>
http://www.cert.org/tech_tips/unix_configuration_guidelines.html
>
> -n
> --
> -- ---- ---- ---- ---- ---- ---- ---- -----
> nathan hruby <nhruby@(protected) >
> uga enterprise information technology services
> production systems support
> metaphysically wrinkle-free
> -- ---- ---- ---- ---- ---- ---- ---- -----
>
>
>
> -- ---- ---- ---- ---- ---- --
>
> Message: 6
> Date: Sun, 17 Oct 2004 18:36:07 +0100
> From: John Haxby <jch@(protected) >
> Subject: Re: attack
> To: "Discussion of Red Hat Enterprise Linux 3(Taroon) "
> <taroon-list@(protected) >
> Message-ID: <4172AD87.7080006@(protected) >
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Stephen J. Smoogen wrote:
>
> >On Sun, 17 Oct 2004 09:44:41 -0700, Rob <wasguru@(protected) > wrote:
> >
> >
> > >is there any way to detect this kind of attack and block the attacker 's
> > > ip?
> > >
> > >Failed logins from these:
> > > account/password from 212.145.146.6: 1 Time(s)
> > > account/password from 67.98.78.111: 1 Time(s)
> > >
> >3) Use strong passwords. 8 letter minimum with minimums of 2 numbers
> >and 2 special characters.
> >
> >
> >
> I 'd go further than this. Turn off password access, only use public
> key access -- RHEL3 (and FC1 and later) start an ssh-agent for you so
> there 's really no excuse!
>
> As Stephen hinted in his point (1) as well, if you 're in a position to
> restrict the access to the ssh port _from_ a selection of IP addresses
> in the firewall, that 's a good thing to do as well.
>
> >5) Be ever vigilant.
> >
> >
> >
> Indeed.
>
>
>
>
>
> -- ---- ---- ---- ---- ---- --
>
> Message: 7
> Date: Sun, 17 Oct 2004 13:54:25 -0600
> From: Brent Goran <brent@(protected) >
> Subject: Re: Apache mod_deflate errors
> To: Joe Orton <jorton@(protected) >
> Cc: "Discussion of Red Hat Enterprise Linux 3 \(Taroon\) "
> <taroon-list@(protected) >
> Message-ID: <1098042865.20027.3.camel@(protected) >
> Content-Type: text/plain; charset= "us-ascii "
>
> I have many processes running, and available RAM is in the low range. So
> this is a good candidate to suspect. It 's strange that of all the stuff
> I have running, only apache complains (and that, only mod_deflate). But
> thanks for the tip, I will bump up the priority to add more RAM to the
> machine.
>
>
> On Sun, 2004-10-17 at 09:15, Joe Orton wrote:
>
> > On Sun, Oct 17, 2004 at 08:57:47AM -0600, Brent Goran wrote:
> > > Thank you, someone knowledgable responding! ;)
> > >
> > > I have MaxRequestsPerChild set to 10. I lowered it from the defaults
> > for
> > > this reason, hoping that, if users started generating this error, at
> > > least it would only generate 10 of them before recycling the server
> > > process. But evidently it didn 't work.
> >
> > You mean you were seeing this error even with M.R.P.C. set to 10? That
> > would imply that something else on the server is causing the memory
> > pressure. And 10 is *very* low, I wouldn 't recommend leaving it like
> > that for long.
> >
> > But first it 's necessary to establish that it really is httpd which is
> > causing the memory problems, using ps, top, sar etc as normal.
> >
> > joe
> -- ---- ------ next part -- ---- ------
> An HTML attachment was scrubbed...
> URL: /archives/taroon-list/attachments/20041017/e2e04928/attachment.htm
>
> -- ---- ---- ---- ---- ---- --
>
> --
> Taroon-list mailing list
> Taroon-list@(protected)
>
http://www.redhat.com/mailman/listinfo/taroon-list
>
> End of Taroon-list Digest, Vol 8, Issue 40
> ******************************************
>
--
Daryl Daly, B.Sc.
Chief Programmer/Business Analyst
daryld@(protected)
Norco Products Ltd. Really Cool Bikes!!!
Norco __O Tel: 604-552-2930 ext 205
Performance =\ \ Fax: 604-552-2948
Bikes (=)/(=) www.norco.com
1465 Kebet Way, Port Coquitlam, British Columbia, V3C 6L3
--
Taroon-list mailing list
Taroon-list@(protected)
http://www.redhat.com/mailman/listinfo/taroon-list
|
|
|