PF Rapid Flurry of Unwanted IPs on Old Mail Server

Generally, a 'netstat -an' on our old mail server displays only MY local IP address since I'm usually logged-in remotely to monitor the server. However, in recent weeks, I'm seeing several unknown IP addresses (often in PAIRS, each accessing a different local port) that all literally pop-up at the same time. Most of the time, they're on port 25 (this is a mail server, NOT a web server), but sometimes random ports. See attached screenshots (I've blurred the server's and my local IP for security).

Often, when I blackhole or tcpdrop or pfctl-badhost the last (bottom) IP, they'll all instantly disappear. But, within seconds, a completely new set of IPs pop-up at the same time. Because there're so many of them and they come-and-go so frequently, I'm not sure how to track what each IP is doing on the server?

A 'who' or 'w' indicates that I'm the only user logged-in, so I don't think they're able to log into the server. But it worries me that these IPs are SUDDENLY and constantly appearing, always changing with new ones appearing to spawn as I blackhole or dump them.

Any ideas what's going on? Does this look like a script kiddie or foreign government hackers or something like that? There's got to be a reason they keep coming back, especially as I keep trying to dump them.
 

Attachments

  • 1.jpg
    1.jpg
    86.9 KB · Views: 153
  • 3.jpg
    3.jpg
    91.5 KB · Views: 131
  • 2.jpg
    2.jpg
    89.2 KB · Views: 138
It looks like you're doing auth lookups in response to connection attempts. You can turn ident off or update your ancient mail server.
 
It looks like you're doing auth lookups in response to connection attempts. You can turn ident off or update your ancient mail server.

Can you expand a bit on your comments re "doing auth lookups in response to connection attempts"? That is, why do you think "auth lookups" are causing these strange IPs to suddenly begin popping-up on our mail server....and to appear to re-spawn every time I blackhole or dump one of them?
No changes (e.g., enabling "auth lookups", etc.) were made to the server before these IPs started popping-up.

The server is ancient, yes. Unfortunately, as much as I'd like to update BSD, my unix skills are likewise far too ancient to permit me to even attempt to literally recreate a (working) mail server with the current/latest BSD. That is, I don't want to kill a [working] mail server in an attempt to upgrade it. (The last time I tried it, we ended up dead-in-the-water for weeks and it cost a wad o' cash to have a proper Unix Admin come in and straighten everything out. I was told "If you don't know what you're doing, leave it alone." Hence, the "ancient" mail server.)

Where would I check/disable auth lookups?
 
I'm wondering if I could block all incoming IPs to the mail server (while still allowing legitimate incoming/outgoing email) by placing the following .htaccess in /?

Code:
# Block users by IP
order allow,deny
deny from all
allow from <my local IP>


# Prevent viewing of .htaccess file
<Files .htaccess>
order allow,deny
deny from all
</Files>
 
I believe at one time sendmail was configured to do auth lookups in response to connection attempts. So when a connection to your mail server is initiated the mail server then sends out an authentication request to the source of the connection attempt using the ident protocol on port 113. If it is sendmail you could disable this behavior by modifying the appropriate .mc file in /etc/mail and then recompiling the mail server using the new configuration. This is very nearly 'recreating' the server in the same manner updating it is. You're idea to add .htaccess directives doesn't make sense to me as those directives alter the behavior of a web server not the mail server. If you're providing web mail there could be something like squirrelmail bridging the services and while this could prevent connections from outside to the web interface I don't think it's what you want because it looks like port 25 is exposed anyway.
"If you don't know what you're doing, leave it alone." is not bad advice. I'm mean to say auth requests, though I personally would turn them off, are probably not hurting anything.
 
"If you don't know what you're doing, leave it alone." is not bad advice. I'm mean to say auth requests, though I personally would turn them off, are probably not hurting anything.

Just so I'm clear: So you don't think these constant IP connections to our mail server are suspicious?
If they're just auth requests, I guess you're right. But what caused them to start? There've been no recent changes to the server.

It just concerns me that whoever's behind these connections seems VERY intent and willing to expend alotta time and effort to re-connect as fast as I'm able to disconnect them. And to do so almost 24/7.

Why all of a sudden? What're they doing while connected? And what's the draw that keeps them coming back? Is there a relatively simple way to find answers to these questions? I'd feel alot better if I knew what this person (or people) is doing while connected?
 
Every mail server contends with a constant stream of connections looking to deliver spam, for open relays and for other exploits. Keeping your server properly configured, up to date, subscribing it to DNSBL's, and employing spam and antivirus filtering are all worthwhile. Learning to do this without breaking the server, becoming an open relay and getting IP blacklisted or becoming part of a botnet takes some study. Then when you think you know enough, read some more.
 
Every mail server contends with a constant stream of connections looking to deliver spam, for open relays and for other exploits.

We've had [very effective] anti-spam filtering for as long as the server's been operational and we rarely receive spam. In fact, the last spam that actually made it through to my mailbox was ~ three years ago. And it was probably a year or so before that for the previous one. So I'm pretty confident these strange IPs that suddenly began popping-up recently are something entirely new and not just the usual mass spam broadcasts. Again, in all the years the server's been running, I've never seen anything like this before.
 
The Identification Protocol (see [RFC 1413]) allows the user of a particular Transmission Control Protocol (TCP) connection to be queried. In the context of email, the Mail Transport Agent (MTA) such as Sendmail will send a ident connection back to the client to see which user on the sending system is sending mail.

To disable ident support, set the confTO_IDENT timeout in the sendmail.mc file to zero, then rebuild sendmail.cf.

p.s.
you didn't hide your ip address in the screenshot.
 
To disable ident support, set the confTO_IDENT timeout in the sendmail.mc file to zero, then rebuild sendmail.cf.

Between my lack of current unix experience and past experience with rebuilds crashing and/or erroring-out, the last thing I want to do is risk damaging sendmail and/or something else on the mail server since it's currently running perfectly. If it ain't broke and all that...

p.s. you didn't hide your ip address in the screenshot.

Sorry, but I don't see my local [mail server] login IP in any of the three screenshots I posted. Which screenshot did I miss?

UPDATE: Just found (and removed) 'em. Thank you!
 
Back
Top