Timothy Alberts (tal...@msiscales.com)

Oh no..they're out there.  They're watching us now.  They know we're 
talking about them.  :)

That sounds great for getting around a remote dynamic IP address, but
some more authentication/security on that web page is necessary,
otherwise, anyone who finds that web page is given access?

Just a virus you think?  They are some pretty lame account names: judy, 
frank, bob..However they are mixed with general linux accounts:  root, 
ftp, webmaster, mysql, named, etc.  I feel less worried about that (or 
should I)?

Or are you just trying to lull me into a false sense of security?  
Muawhahahaha..

I could do that, but if they already know about it, a simple port scan
and they'll probably find it again.  Plus I gotta go tell all my client 
programs the new port and I don't know how to do that on most of them
(what a hassle).

> 2. use only SSH protocol 2
got it.
> 3. Install some brute force protection which can automatically ban an
> IP on say 5 / 10 failed login attempts
The only software I know that could do this isn't supported anymore
(trisentry) or is too confusing and I don't know it yet (snort).  
Suggestions?

> 4. ONLY allow SSH access from your IP, if it's static. Or signup for a
> DynDNS account, and then only allow SSH access from your DynDNS domain
>
Yeah my home account is on dynamic IP.  I'd love to setup the firewall 
to only allow my home computer.  You're talking about these guys?  
http://www.dyndns.com/ never used them before, but it looks like a good
idea.  Especially since it's free (for 5 hosts) if I read correctly.

iptables..add the ip of the attack source to reject?  They keep moving 
IP, this is very time consuming (but I am doing it).  I don't allow root 
login.  I think I got a good password, and I got keys setup so I know 
I'm talking to my server.

Tim Alberts wrote:
> So I setup ssh on a server so I could do some work from home and I
> think the second I opened it every sorry monkey from around the world
> has been trying every account name imaginable to get into the system.
>
FYI, here's a list of the losers (so far).  I suggest everyone wish 
horrible things happen to these people.

*201.70.39.3
**201.6.116.177
**200.161.198.16
**164.164.33.73
**66.114.252.200
**24.202.149.253
**218.201.147.80
**200.42.174.109
**128.135.195.122
**67.19.188.210
**24.202.149.253
**203.82.65.252
**124.1.204.61
**210.206.124.211
**61.128.122.13
**202.106.62.197

*

So I setup ssh on a server so I could do some work from home and I think
the second I opened it every sorry monkey from around the world has been
trying every account name imaginable to get into the system.

What's a good way to deal with this?

John that is perfect, exactly what I was looking for.

Thank you and thanks to everyone that contributed.

I guess it's apparent I don't read man pages very well.

OK, that's what I was suspicious of.

I've been reading the sendmail docs for header tests thinking I can
write something in sendmail that will look for the X-Spam-flag header
and reject based on that.  Anyone try that yet?

http://www.sendmail.org/m4/anti_spam.html#header_checks

John Hinton wrote:
>
> There are milters for SpamAssassin. You can set them to reject mail at
> a particular score level. So, if for instance you felt comfortable
> with rejecting mail at a score of 10, which is pretty reliable, you
> can also do that at smtp level.
BINGO  That's exactly what I'm trying to do with spamass-milter.  
However it either won't do it, or my configuration is incorrect.  Mail 
marked as spam is still being delivered as normal?



>
> Just in case it hasn't been said, never bounce mail but only reject.
Indeed, reject at the smtp level..yes..that's the goal.

I think it's a wonderful idea to not let spam into the server at all.  
If a legitimate sender is sending email that is inadvertently marked as
spam, it will be returned to sender and they will be notified.  That's 
actually why I'm trying to switch to a 'don't let it in to begin with'
policy.  Currently I use the spamassassin to mark spam and clients get 
their email and have a habit of giving the spam folder a glance over
looking for legitimate email.  Well, that completely defeats the purpose 
of marking them spam to begin with?

I'm basing this decision on having run an email server for the last 8
years, listening to the complaints of huge spam folders and mail being
'lost' in the trash because it was falsely marked as spam.

I also use all the dnsbl above plus spamcop.net which, I believe blocks
far more spam than anything else.

FEATURE(`dnsbl', `bl.spamcop.net', `"Spam blocked see:
http://spamcop.net/bl.shtml?"$&{client_addr}')dnl

That's exactly what I don't want to do.  I don't want the mail being 
delivered to my system.  That's why I'm using the milter.  However the 
milter is doing the exact same thing as delivering it when it is marked
as spam.  That's what I am hoping to get some help with.

Sorry, not a direct CentOS question, but I know there's a lot of
experienced users on this list...I'm using CentOS with sendmail and
spamassassin. I've got it configured with spamass-milter and it is
working correctly.  However, I was expecting to be able to reject mail 
that is marked as spam, not just deliver it as usual.  Anyone know if it 
can be done and how?  I know a milter can reject mail, because I've used 
milter-grelist in the past to give temporary fail messages.

Following is my sendmail.m4 directive for spamass-milter:

INPUT_MAIL_FILTER(`spamassassin',
`S=unix:/var/run/spamass-milter/spamass-milter.sock, F=,
T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name},
{if_name}, {if_addr}')dnl
define(`confMILTER_MACROS_HELO',`s, {tls_version}, {cipher},
{cipher_bits}, {cert_subject}, {cert_issuer}')dnl