|
If its bursty and you suspect a compromised form Colin, watch for network activity. Since most compromised forms/scripts will use Sendmail, you can watch for messages appearing in the outgoing mail queue.
I'll open two windows and watch the mail queue in one window and inbound connections in the other. Use "watch mailq" in one window, and "watch netstat -na" in the other. Whenever you notice the mailq suddenly filling up with outgoing messages - look for a IP address making a lot of connections to the server all coming from the same IP (usually to port 80). That's usually the source that is using the vulnerable script that generates the SPAM. Once you think you've got the right source - block it to see if the outgoing crap stops. Use "iptables -I accin 1 -s x.x.x.x/32 -j DROP" replacing the x's with the offending IP. I usually leave the last digit of the IP as zero and add a /24 to it -- in case the scumbag has access to more than one IP address in their network - and would just use a different IP to hit your server's vulnerable script. Realize - this is not a fix. You still have to find the vulnerable script and fix it/delete it/whatever. But this can stop the outgoing flood for a while, and hopefully prevent your server from being blacklisted. And of course, if the outgoing flood stops - this has also identified the IP on your server that has the exploited script. So it helps narrow the search for the exploited script. If on the other hand, you see a lot of connections suddenly from the same origin to port 25 or 587 - they've exploited a user account on your server and are relaying through your server. In that case, block again as above - but then determine what account was hacked by checking the maillogs. Once you find it - change the password or delete that user account. I've tried simply SUSPENDing the account - and sometimes, the server will still relay for that user. So I just change the password and wait for the user to contact us. We've actually had users post a account name & password on a webpage, so their remote customers could FTP files to them. Unfortunately, the SPAMMERS found it and started relaying a ton of crapola. Had to educate that user a bit and warn them that if it happened again - we'd bill them for the tech time to track it down and fix it. Then we help them find a secure method of getting their need satisfied without creating a security nightmare. Chuck --------- Original Message ----------- From: Colin Jack <co...@mainline.co.uk> To: BlueOnyx General Mailing List <blueonyx@mail.blueonyx.it> Sent: Sun, 16 Jul 2017 18:43:50 +0000 Subject: [BlueOnyx:21172] Re: Spammer > Hi Tigerwolf, > > On 16/07/2017, 19:05, "Blueonyx on behalf of Tigerwolf" <blueonyx-boun...@mail.blueonyx.it on behalf of tigerw...@tigerden.com> wrote: > > On Sun, 16 Jul 2017, Colin Jack wrote: > > > Looking for ideas. We suspect we have a compromised website on one of > > our servers ÿÿ being used for spam. What is the easiest way to track > > this down? Can see spam being sent via localhost but canÿÿt pin it down. > > There are some spamming scripts that do pretty well at hiding, including > erasing themselves once a run is completed. Those get into the system > through compromised user account passwords. > > Checked those. Nothing obvious. > > Check ftp logs for unusual tranfers and the local account(s) they went to. > Check user shell history for evidence of creating/running/deleting unusual > programs. > > Shell access is not exposed to the internet. > > The spambots don't generally use the system sendmail, so those logs won't > show much for outbound. If the spam is generating lots of remote bounces, > the local sendmail logs may show an abnormal amount of incoming rejected > mail to the spamming account. > > Trawled maillog to no avail. > > Use 'iftop' and/or 'iptraf' to watch for outbound mail connections. If > they're spewing a lot, you should be able to tell easily. If short > bursts, or slow spamming, it could be harder to see. > > Tried that but it is not sustained [UTF-8?]⦠so [UTF-8?]didnât pick up anything. > > When a run is underway, watch 'top' to see who owns the spamming > process(es). > > If I can catch them at it. Seems to be bursty. > > If you can figure out which user account is the source, change the > password immediately, and kill all that user's processes. This may stop > the spambot without it being able to delete itself and provide extra > forensic details. Notify the user and question them about the situation, > and wipe any suspect files not known to belong to the actual user. > > I [UTF-8?]donât think there is a spambot on there [UTF-8?]â I suspect it is a compromised form. > > Thanks for the input. > > Colin > > _______________________________________________ > Blueonyx mailing list > Blueonyx@mail.blueonyx.it > http://mail.blueonyx.it/mailman/listinfo/blueonyx ------- End of Original Message ------- |
_______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
