Re: Probes on Port 135 and 445 continue
From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: 10/19/04
- Previous message: Security Alert: "SSRT4806 Rev.0 Java on HP-UX XSLT processor privilege escalation"
- In reply to:(deleted message) Leythos: "Re: Probes on Port 135 and 445 continue"
- Next in thread: Leythos: "Re: Probes on Port 135 and 445 continue"
- Reply:(deleted message) Leythos: "Re: Probes on Port 135 and 445 continue"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 18 Oct 2004 19:12:06 -0500
In article <MPG.1bdc59eabe81f1e898987c@news-server.columbus.rr.com>,
Leythos wrote:
>In article <slrncn3p10.njk.ibuprofin@atlantis.phx.az.us>,
>ibuprofin@painkiller.example.tld says...
>> OK "imposed"...
>
>Yea, they had nothing before, free, unrestricted use of the service
>without any consequences - at least until the ISP threatened to cut off
>their service for spam abuse.
Ahhhh, now there's the real reason. OK, not a problem.
>Slow and security were the main reasons.
Slow is better than stopped.
>If Ident was to become a problem, we have a monitoring server installed
>that we could setup an ident service on, but it's not been an issue as
>of yet.
OK, that's been the complaint I've heard most often. We rarely use
services that "need" ident (my understanding is that it's required by
most IRC servers - which we don't use at all), but we normally use
fakeidentd to handle any requests.
>> What all are you recording to generate that much? That's like 100000
>> lines of text.
>
>As I mentioned earlier, they have a NAT box, not a real firewall, and
>the logs track all in/out bound TCP/UDP traffic source, destination,
>local/remote port, time/date, etc...
Still seems like a lot of data. Normally we don't do a lot of logging.
>More than half of the logs are inbound attempts that fail.
External connection attempts that are blocked are of no concern. The
firewall blocked it - end of story. As mentioned, we block nearly all
ports below 1030. Most of the other crap can be defined as some host
in Korea or Kenya attempting to connect to a trojan that we don't have
installed.
>> Obviously would have been better to prevent the infection, but the
>> concept is otherwise OK.
>
>We removed more than 3000 viruses from their machines when they arrived
>at the house this year, many of them were infected while living in the
>dorms. The University offers free AV software, but you have to know
>about it, and you have to believe you need it, to install it.
And keep it up to date. It seems that most users don't seem to think
about this, and happily click "OK" on any dialog box that pops up. It
would be nice if users were educated, but I know that's a dream.
>There were only 3 clean machines in the entire batch of them, and one
>was a MAC (but it didn't have all the OS/X updates).
Gack! What's with the other two - not turned on? ;-) I can
understand the Mac not being infected - there's a .sig I've seen:
-----
>A friend of mine makes the claim that Macs don't get viruses.
Translation: even virus writers don't support mac's anymore...
-----
>Every machine was updated with the latest service packs, latest Office
>service packs, new AV software was installed, spyware detection software
>was installed, and all machines were certified clean before letting them
>on the house network.
Hopefully, you also disabled some of the more abused services on their
systems as well.
>The old IT company gave up on them, didn't want to deal with an
>outbreak, and the ISP was going to shut them off due to a massive SMTP
>virus spammer infection - sending about 250 email's out from 6 infected
>machines (using the viruses SMTP engine) every few seconds.
I wish the ISPs would block all outbound port 25 except to their own
smarthosts. That would go a long way in knocking back spam. Before we
started blocking dynamic addresses, they amounted to around half of the
spam we were receiving. People complaining about spam from China, Korean,
Brazil or where-ever should look at the headers of the spam - they might
be surprised.
Old guy
- Previous message: Security Alert: "SSRT4806 Rev.0 Java on HP-UX XSLT processor privilege escalation"
- In reply to:(deleted message) Leythos: "Re: Probes on Port 135 and 445 continue"
- Next in thread: Leythos: "Re: Probes on Port 135 and 445 continue"
- Reply:(deleted message) Leythos: "Re: Probes on Port 135 and 445 continue"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|