[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cobalt-security] RE: Newbie at wits end with spammers through server - cobalt-security digest, Vol 1 #470



Thanks to both Michael and Kevin for their replies.

Have gone back into the GUI and deactivated the Telnet/Shell to start off
with.

The server has all the latest Cobalt patches so there shouldn't be an issue
there.

What I did do this morning and it's maybe a ploy that all hosts should use
if they are in the same situation is the following:-

Sent out a general email to all hosters stating that the security of the
servers is being updated to fight against SPAM....blah blah. Giving a bit of
blurb about recent US legislation and what course of action receipients can
now take. Then state that with the security updates it'll now be even easier
to trace the originators and a termination fee will apply etc.

After sending out the email to our customers I received two cancellations
within 10 minutes of them receiving it. These guys had been hosting on the
server for over 6 months just after we took over the lease.

Kinda of makes you wonder - doesn't it. Anyway I'll be watching the logs
closely and have a good ferrett through sendmail.org etc.

Thanks again

Chae


-----Original Message-----
From: cobalt-security-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of
cobalt-security-request@xxxxxxxxxxxxxxx
Sent: Tuesday, 14 August 2001 19:16
To: cobalt-security@xxxxxxxxxxxxxxx
Subject: cobalt-security digest, Vol 1 #470 - 13 msgs


Send cobalt-security mailing list submissions to
	cobalt-security@xxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	http://list.cobalt.com/mailman/listinfo/cobalt-security
or, via email, send a message with subject or body 'help' to
	cobalt-security-request@xxxxxxxxxxxxxxx

You can reach the person managing the list at
	cobalt-security-admin@xxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cobalt-security digest..."


Today's Topics:

   1. RE: No telnet on saturdays?? (Ervin Tarkhanian)
   2. Re: DANGER WILL ROBINSON!!!  A tool for MIM/c*apfilt and poisoning
listed on /. (Paul Gillingwater)
   3. RE: No telnet on saturdays?? (Mike King)
   4. RE: No telnet on saturdays?? (Ervin Tarkhanian)
   5. Newbie at wits end with spammers through server (Render-Vue)
   6. Re: DANGER WILL ROBINSON!!!  A tool for MIM/c*apfilt and poisoning
listed on /. (Mark Anderson)
   7. Re: Newbie at wits end with spammers through server (Michael Stauber)
   8. Re: Newbie at wits end with spammers through server (Kevin D)
   9. Re: Redhat upgrade??? (Kevin D)
  10. Re: DANGER WILL ROBINSON!!!  A tool for MIM/c*apfilt and poisoning
listed on /. (Kevin D)
  11. Re: ARP and its variations (Paul Gillingwater)
  12. Re: PHP script to notify contacts related to IP
       initiating Code Red attack (baltimoremd@xxxxxxxxxxxxxxx)

--__--__--

Message: 1
From: "Ervin Tarkhanian" <ervin@xxxxxxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>
Subject: RE: [cobalt-security] No telnet on saturdays??
Date: Mon, 13 Aug 2001 22:02:44 -0700
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

Kevin,

Thanks for the tip, but what are ps and ax reports, and how can I access
them.  Thanks for bearing with me, I'm barely getting the hand of all this.

Best regards,
Ervin Tarkhanian


-----Original Message-----
From: cobalt-security-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of Kevin D
Sent: Monday, August 13, 2001 12:51 PM
To: cobalt-security@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-security] No telnet on saturdays??

From: "Ervin Tarkhanian" <ervin@xxxxxxxxxx>

> I'm wondering if anyone else has experienced anything like this before.

Not yet.

Log into your server on a weekend and compare ps ax reports with those on
the weekdays. Check for fishy cron jobs. My suspicion is that you've been
hacked. What result do you get when trying to connect to port 109 with
telnet on a weekend?

Kevin

_______________________________________________
cobalt-security mailing list
cobalt-security@xxxxxxxxxxxxxxx
http://list.cobalt.com/mailman/listinfo/cobalt-security


--__--__--

Message: 2
To: cobalt-security@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-security] DANGER WILL ROBINSON!!!  A tool for
MIM/c*apfilt and poisoning listed on /.
Date: Tue, 14 Aug 2001 07:45:07 +0200 (CEST)
From: Paul Gillingwater <paul@xxxxxxxxxxx>
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

Quoting cronus <cronus@xxxxxx>:

> If you are careful when using ssh you can avoid falling victim
> to this monkey-in-the-middle attack. Simply issue that command
> as follows;
>
> ssh -l cronus -2 66.70.14.70
>
> Rather than...
>
> ssh -l cronus -2 www.whitedust.net
>
> ARP poisoning can be made useless by using IP addresses over
> hostnames whenever possible. If I am wrong - someone please
> tell me

Sorry, but ARP poisoning is independent of whether you use the
host name or not.  It happens at a lower layer, i.e., L2 of
the ISO 7-layer model.  When you resolve a name, you end up
with one or more IP addresses anyway -- and if the ARP cache
is poisoned, there's not much you can do about it.

To see your ARP cache, type in arp -a from the command line
interface.  Note that every router also has an ARP cache,
which could also be the point of attack.  There's a nice
utility called arpwatch, which keeps track of the ARP cache,
and e-mails you whenever something changes (like a new
address found.)

For those who are still reading, ARP means Address Resolution
Protocol.  Basically, what happens is that when your host
tries to reach an IP address which isn't already in your local
ARP cache, then it does a broadcast on your local subnet,
asking for someone to give it the correct MAC (machine)
address for a given IP address.  If the IP address you
request is in a different subnet, then the default gateway
(usually your router or firewall) will respond with its
own MAC address.  This means that different ARP caches will
have different MAC<->IP mappings, depending upon where they
are in your network.


*********************************
        Paul Gillingwater
        Managing Director
 CSO Lanifex Unternehmensberatung
 & Softwareentwicklung G.m.b.H.
      NEW BUSINESS CONCEPTS

E-mail:  paul@xxxxxxxxxxx
Teleph:  +43/1/2198222
Mobile:  +43/699/1922 3085
Webhome: http://www.lanifex.com/
Address: Praterstrasse 60/1/2
         A-1020 Vienna, Austria
*********************************

--__--__--

Message: 3
Date: Mon, 13 Aug 2001 23:02:39 -0700
To: cobalt-security@xxxxxxxxxxxxxxx
From: Mike King <mikkel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [cobalt-security] No telnet on saturdays??
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

At the telnet command prompt, type in

ps ax

The resulting output is a process list

To find out more type

man ps

To find out more, buy a O'Reilly book on Unix

Have fun

Mike

At 10:02 PM 8/13/2001 -0700, you wrote:
>Kevin,
>
>Thanks for the tip, but what are ps and ax reports, and how can I access
>them.  Thanks for bearing with me, I'm barely getting the hand of all this.
>
>Best regards,
>Ervin Tarkhanian
>
>
>-----Original Message-----
>From: cobalt-security-admin@xxxxxxxxxxxxxxx
>[mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of Kevin D
>Sent: Monday, August 13, 2001 12:51 PM
>To: cobalt-security@xxxxxxxxxxxxxxx
>Subject: Re: [cobalt-security] No telnet on saturdays??
>
>From: "Ervin Tarkhanian" <ervin@xxxxxxxxxx>
>
> > I'm wondering if anyone else has experienced anything like this before.
>
>Not yet.
>
>Log into your server on a weekend and compare ps ax reports with those on
>the weekdays. Check for fishy cron jobs. My suspicion is that you've been
>hacked. What result do you get when trying to connect to port 109 with
>telnet on a weekend?
>
>Kevin
>
>_______________________________________________
>cobalt-security mailing list
>cobalt-security@xxxxxxxxxxxxxxx
>http://list.cobalt.com/mailman/listinfo/cobalt-security
>
>_______________________________________________
>cobalt-security mailing list
>cobalt-security@xxxxxxxxxxxxxxx
>http://list.cobalt.com/mailman/listinfo/cobalt-security


--__--__--

Message: 4
From: "Ervin Tarkhanian" <ervin@xxxxxxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>
Subject: RE: [cobalt-security] No telnet on saturdays??
Date: Mon, 13 Aug 2001 23:23:30 -0700
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

Thanks Mike,

I Should've started with Unix, but got sucked into M$'s nifty development
tools.  Now that I'm on Linux and see the power of PHP, ASP just seem like a
waste of time.

Thanks a gain.

Best regards,
Ervin Tarkhanian


-----Original Message-----
From: cobalt-security-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of Mike King
Sent: Monday, August 13, 2001 11:03 PM
To: cobalt-security@xxxxxxxxxxxxxxx
Subject: RE: [cobalt-security] No telnet on saturdays??

At the telnet command prompt, type in

ps ax

The resulting output is a process list

To find out more type

man ps

To find out more, buy a O'Reilly book on Unix

Have fun

Mike

At 10:02 PM 8/13/2001 -0700, you wrote:
>Kevin,
>
>Thanks for the tip, but what are ps and ax reports, and how can I access
>them.  Thanks for bearing with me, I'm barely getting the hand of all this.
>
>Best regards,
>Ervin Tarkhanian
>
>
>-----Original Message-----
>From: cobalt-security-admin@xxxxxxxxxxxxxxx
>[mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of Kevin D
>Sent: Monday, August 13, 2001 12:51 PM
>To: cobalt-security@xxxxxxxxxxxxxxx
>Subject: Re: [cobalt-security] No telnet on saturdays??
>
>From: "Ervin Tarkhanian" <ervin@xxxxxxxxxx>
>
> > I'm wondering if anyone else has experienced anything like this before.
>
>Not yet.
>
>Log into your server on a weekend and compare ps ax reports with those on
>the weekdays. Check for fishy cron jobs. My suspicion is that you've been
>hacked. What result do you get when trying to connect to port 109 with
>telnet on a weekend?
>
>Kevin
>
>_______________________________________________
>cobalt-security mailing list
>cobalt-security@xxxxxxxxxxxxxxx
>http://list.cobalt.com/mailman/listinfo/cobalt-security
>
>_______________________________________________
>cobalt-security mailing list
>cobalt-security@xxxxxxxxxxxxxxx
>http://list.cobalt.com/mailman/listinfo/cobalt-security

_______________________________________________
cobalt-security mailing list
cobalt-security@xxxxxxxxxxxxxxx
http://list.cobalt.com/mailman/listinfo/cobalt-security


--__--__--

Message: 5
From: "Render-Vue" <sales@xxxxxxxxxxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>
Date: Tue, 14 Aug 2001 20:30:27 +1200
Subject: [cobalt-security] Newbie at wits end with spammers through server
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

Hi yah excuse me if this has been discussed prior but I'm at wits end ...

Have taken over the lease of Cobalt RAQ3i from a previous hosting company
(they went bankrupt too many customers with them so we took on the lease
easier than moving everyone). Anyway over the last few weeks my server
provider has shut us down twice because of spam complaints.

First of all it was smtp relying through the server - after resolving this I
had one of providers techs jump into the machine to check that what was done
was correct and also they confirmed that the pop before smtp was working
correctly... excellent no more spamming.

Wrong several days later I'm shut down again and I'm told that it's because
the one of the spammers is using a yahoo.com address now but the IP is still
resolving to the server. 3 Days later they decide to turn the server back
on - after trying to phone them and find out why this is happening and how I
can stop this from happening again before I loose all my customers. I was
told by their tech support to switch off the email services and check the
log files.

The IP in question was the main IP address for the server, I found that
there were also 4 other customers using the same IP (set-up by previous
server owners). When I checked the site settings/DNS records I found one
didn't have reverse lookup in the dns and none including the ns had any MX
records.

Being none the wiser I have now corrected that so every customer account now
has mx records and reverse lookup in the DNS.

I've told their tech support that I'd even pay for a tech to check the
machine as long as they can guarantee that after checking they are not going
to shut me down again...

I'm at the end of my tether with the spamming and if it continues I can see
me loosing the server and the customers. Can any of you knowledgeable
users/administrators say where I'm going wrong, is the server set-up wrong
or is it just life and hope that it all dies down.

Many thanks in advance

Chae


--__--__--

Message: 6
From: "Mark Anderson" <cronus@xxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>
Subject: Re: [cobalt-security] DANGER WILL ROBINSON!!!  A tool for
MIM/c*apfilt and poisoning listed on /.
Date: Tue, 14 Aug 2001 09:53:31 +0100
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

> Sorry, but ARP poisoning is independent of whether you use the
> host name or not.  It happens at a lower layer, i.e., L2 of
> the ISO 7-layer model.  When you resolve a name, you end up
> with one or more IP addresses anyway -- and if the ARP cache
> is poisoned, there's not much you can do about it.
Thanks for that. I am grateful for the correction and worried about
how blasse I was when I was wrong... ;]




--__--__--

Message: 7
From: Michael Stauber <cobalt@xxxxxxxxxxxxxx>
Organization: Stauber Multimedia Design
To: cobalt-security@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-security] Newbie at wits end with spammers through
server
Date: Tue, 14 Aug 2001 14:05:15 +0200
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

Hi Chae,

> I'm at the end of my tether with the spamming and if it continues I can
see
> me loosing the server and the customers. Can any of you knowledgeable
> users/administrators say where I'm going wrong, is the server set-up wrong
> or is it just life and hope that it all dies down.

One of the problems with the Cobalt's sendmail setup is as follows:

Sendmail will relay mail if at least one of the following conditions is met:

a) Sender's email address matches an email address which exists on the
server

b) Recipient's email address matches existing email address on the server

c) Sender's domain name has an MX entry which points to the machine where
sendmail is running.

d) User is local

So (a) can be easily faked, (b) doesn't need to be faked and everyone with
control over a DNS server can arrange for (c).

I had it myself a looong time ago that cybersell.net was using my SMTP
server
to send spam. They even used my own business email address as sender address
in the beginning. When I had shut that down and implemented stricter
sendmail
rules they just set up an MX entry which associated cybersell.net with my
primary IP. Due to that they were able to again send spam through me. Back
then I complained to Network Solutions and had their domain deleted, which
only worked because all three contacts listed for the domain were fakes and
I
had sufficient proof of that at hand.

What you might want to look for is the following:

POP-before-SMTP is fine, but it can be circumvented by some MX tricks. Also
you need to be very suspicious of your webhosting customers, especially
those
with shell accounts, and/or accounts with cgi, PHP and/or ASP access, which
is what I mean with option (d). Local users can *always* send mail, so any
PERL or PHP script can send emails, too.

The only way to find out who the bad guys are and where they come from is to
check /var/log/maillog very thoroughly.

If you find out that they send from another server out there which simply
forwards the mail to your box and has a faked MX entry, then the best thing
to do first is to setup IPChains and to block them. Then start to complain
to
them and send them an invoice for the damage they caused. If they're using
your infrastructure to make money, then you have the right to bill them for

it.

Additionally you might want to look up information about how to fortify your
sendmail. Good starting points are sendmail.org and cauce.org, but you might
also want to use google.com to search for additional material.

--

With best regards,

Michael Stauber
Solarspeed.net

--__--__--

Message: 8
From: "Kevin D" <kdlists@xxxxxxxxxxxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>
Subject: Re: [cobalt-security] Newbie at wits end with spammers through
server
Date: Tue, 14 Aug 2001 09:24:28 -0400
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

From: "Michael Stauber" <cobalt@xxxxxxxxxxxxxx>

> One of the problems with the Cobalt's sendmail setup is as follows:

I'm not sure how long ago you've had these problems, but I've had my raq3i
for over a year now and it does not have the problems that you suggest.

> Sendmail will relay mail if at least one of the following conditions is
met:
>
> a) Sender's email address matches an email address which exists on the
server

Raq3i with all the patches does not allow this. I know because I routinely
set up new users on DSL lines and forget to add their IPs to my relaying
tables. Regardless of their sender email address, they still get relaying
denied errors.

> b) Recipient's email address matches existing email address on the server

This is always the case with any SMTP server, because that is how the
protocol works. By the way, this is not relaying, it is delivering to a
recipient on the server.

> c) Sender's domain name has an MX entry which points to the machine where
> sendmail is running.

This is not the case either. Same reasons as a).

> d) User is local

This is correct, any local user on the box can send.

You might also want to check out info on the pop before relay bug which
allows hackers to relay through your box. Search the archives.

>Also
> you need to be very suspicious of your webhosting customers, especially
those
> with shell accounts, and/or accounts with cgi, PHP and/or ASP access,
which
> is what I mean with option (d). Local users can *always* send mail, so any
> PERL or PHP script can send emails, too.

The /var/log/maillog will tell you which user, if this is the case. Ask for
a copy of the spammed email's headers, and you can search for the message ID
in your logs and know exactly who sent it.

Kevin


--__--__--

Message: 9
From: "Kevin D" <kdlists@xxxxxxxxxxxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>
Subject: Re: [cobalt-security] Redhat upgrade???
Date: Tue, 14 Aug 2001 09:32:08 -0400
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

From: "John Bailey" <support@xxxxxxxxxxxxxxxxxxxxxx>

> > This is completely OT, but the version of GCC in 7.1 isn't broken, but
it is
> > different.
>
> Well, I hate to beg to differ, but when it's spewing out messages along
> the lines of "internal error, please report bugs to gcc@xxxxxxx", that's
> broken in my book.

Honestly, its really not broken. Here's the problem:

"The problem of compatibility, first argued in the earlier linux-kernel
thread, is that programs created with the 2.96 version of GCC are not
compatible with GCC 2.95.2, the last official release, and the future GCC
3.0 release, due to incompatible object files."

Quoted from:
http://linuxtoday.com/news_story.php3?ltsn=2000-10-09-005-21-NW-CY-RH

Kevin


--__--__--

Message: 10
From: "Kevin D" <kdlists@xxxxxxxxxxxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>
Subject: Re: [cobalt-security] DANGER WILL ROBINSON!!!  A tool for
MIM/c*apfilt and poisoning listed on /.
Date: Tue, 14 Aug 2001 09:06:42 -0400
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

From: "Paul Gillingwater" <paul@xxxxxxxxxxx>

> If the IP address you
> request is in a different subnet, then the default gateway
> (usually your router or firewall) will respond with its
> own MAC address.

I thought that if the IP address you requested was in a different subnet,
your PC/network device would automatically forward that request to the
default gateway? Otherwise, why would you need to tell your PC/network
device what your default gateway was?

ARP, I thought, only dealt with mapping IPs to MAC address. It should have
nothing to do with routing to a default gateway, right?

Kevin


--__--__--

Message: 11
To: cobalt-security@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-security] ARP and its variations
Date: Tue, 14 Aug 2001 16:33:16 +0200 (CEST)
From: Paul Gillingwater <paul@xxxxxxxxxxx>
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

Quoting Kevin D <kdlists@xxxxxxxxxxxxxxx>:

> From: "Paul Gillingwater" <paul@xxxxxxxxxxx>
>
> > If the IP address you
> > request is in a different subnet, then the default gateway
> > (usually your router or firewall) will respond with its
> > own MAC address.
>
> I thought that if the IP address you requested was in a different
> subnet,
> your PC/network device would automatically forward that request to the
> default gateway? Otherwise, why would you need to tell your PC/network
> device what your default gateway was?

We're talking at two different levels here, in the OSI 7-layer model.

IP works at Layer 3 -- Ethernet and Token Ring work at Layer 2.

You are correct that if the IP address you request is in a different
subnet, then it will be routed via the default gateway, in which case
your node will do an ARP broadcast for the gateway.  It's also possible
to have a Proxy ARP configuration, where the router will itself
respond for devices it "knows" are beyond it.

I agree, most people aren't doing this, and I apologise for including
too much detail which didn't really help to illustrate the point.
Proxy ARPs are mostly used with dial-up devices.  There are also
DHCP ARPs (which is used to prevent address duplication), Gratuitous
ARPs (used as a kind of "I'm not dead yet" message) and not to
forget Reverse ARP (used by diskless workstations to find their own
IP address) and the little-used un-ARP (beloved of hackers for
man-in-the-middle attacks) which forces devices to remove their
entries from their local ARP caches.

Note that ARP is not for IP only -- it can also be used with other
protocols.  It's not part of IP.

> ARP, I thought, only dealt with mapping IPs to MAC address. It should
> have
> nothing to do with routing to a default gateway, right?

See above -- it certainly can.  Let's not even get into the use
of LAyer 3 switching, where the switch will bridge packets
transparently into other segments by responding to an ARP with
its own address.

Back to security -- most of these MITM attacks can only succeed
if the hacker can compromise a device in the path between you
and your target.  For your local network, it's helpful to
program your switches to prevent unknown MAC addresses being
able to connect to a port, and on the Cobalt side, run ARPwatch.

*********************************
        Paul Gillingwater
        Managing Director
 CSO Lanifex Unternehmensberatung
 & Softwareentwicklung G.m.b.H.
      NEW BUSINESS CONCEPTS

E-mail:  paul@xxxxxxxxxxx
Teleph:  +43/1/2198222
Mobile:  +43/699/1922 3085
Webhome: http://www.lanifex.com/
Address: Praterstrasse 60/1/2
         A-1020 Vienna, Austria
*********************************

--__--__--

Message: 12
From: baltimoremd@xxxxxxxxxxxxxxx
Date: Tue, 14 Aug 2001 10:49:06 -0400 (EDT)
To: Steve Werby <steve-lists@xxxxxxxxxxxx>
cc: cobalt-security@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-security] PHP script to notify contacts related to IP
 initiating Code Red attack
Reply-To: cobalt-security@xxxxxxxxxxxxxxx

On Mon, 13 Aug 2001, Steve Werby wrote:

> to write such a script I'm including a link to one I came across while
> reading another list.
>
> http://www.klippan.seths.se/default.phps

If I wasn't php brain-dead I'd be half tempted to modify the script to
notify sysadmins who have users portscanning me...I'm catching them, but
there might be some merit in letting the sysadmin at the other end know
he/she is being used.

thom
baltimoremd@xxxxxxxxxxxxxxx             Thom LaCosta K3HRN Webmaster
             http://www.baltimoremd.com/cobaltfacts/
                Home of the CobaltFacts Web Ring



--__--__--

_______________________________________________
cobalt-security mailing list
cobalt-security@xxxxxxxxxxxxxxx
http://list.cobalt.com/mailman/listinfo/cobalt-security


End of cobalt-security Digest