Hello all,
Wondering if any of you have experience with this.
I have two domains, wiggly.org (A) and alertferret.com (B).
A has been registered since 1994.
B was registered very recently, within 6 months.
I run email for both of these domains on the same server,
otter.wiggly.org using Exim.
I have the exact same MX and SPF records for both domains;
@ 3600 IN MX 10 mail.wiggly.org.
@ 3600 IN SPF "v=spf1 mx -all"
@ 3600 IN TXT "v=spf1 mx -all"
Sending email from domain A to gmail/hotmail appears in the main inbox.
Sending email from domain B end up in the spam folder for both.
Now, I am wondering why this would be seeing as there has been
practically no email from domain B and therefore I find it unlikely that
the domain itself has been flagged.
All I can see is that domain A is a lot older but I have only recently
added SPF and have never really had problems with my emails from domain
A being consumed by spam folders.
Checking a couple of blacklist checkers I cannot find my domain or my MX
on any of them.
Does anyone have an idea as to why domain B would be getting caught in
spam traps whilst A does not?
I have had someone suggest using mandrill or other external hosted
solution but quite frankly if the mail is being blocked because it is
being sent from domain B then that surely wouldn't give me any improvement?
Any help, ideas, thoughts or further resources would be greatly appreciated.
Regards,
Nigel
Hi all,
I was away on holiday for a while recently, during which time (on 21st
June to be precise) rkhunter started sending me daily report emails
like the one below, indicating that the perl and curl binaries on my
Debian 6.0.7 webserver changed. As far as I'm aware, my system only
gets updated when I manually perform it via apt-get, and I don't
remember doing that in the week or few preceeding the alert, so this
was a bit of a surprise. This report runs daily, yet the last update
I can see in /var/log/dpkg.log for perl is 2013-03-23, and 2013-05-10
for curl. It all seems slightly suspicious, and yet I have not found
any other evidence of the system being compromised. Network traffic
remains low, which I would expect to increase if it was hijacked.
Only thing I noticed is the OOM-killer kicking in a few times over the
last few months, possibly due to an Apache leak, but frankly I think
that's a bug somewhere rather than a symptom of a break-in, since it
started happening much earlier.
dpkg -s says that I have curl-7.21.0-2.1+squeeze3 and
perl-5.10.1-17squeeze6, and debsums says everything's OK.
# apt-cache policy curl
curl:
Installed: 7.21.0-2.1+squeeze3
Candidate: 7.21.0-2.1+squeeze4
Version table:
7.21.0-2.1+squeeze4 0
500 http://apt-cacher.lon.bitfolk.com/debian/security.debian.org/
squeeze/updates/main i386 Packages
*** 7.21.0-2.1+squeeze3 0
100 /var/lib/dpkg/status
7.21.0-2.1+squeeze2 0
500 http://apt-cacher.lon.bitfolk.com/debian/ftp.uk.debian.org/debian/
squeeze/main i386 Packages
# apt-cache policy perl
perl:
Installed: 5.10.1-17squeeze6
Candidate: 5.10.1-17squeeze6
Version table:
*** 5.10.1-17squeeze6 0
500 http://apt-cacher.lon.bitfolk.com/debian/security.debian.org/
squeeze/updates/main i386 Packages
100 /var/lib/dpkg/status
5.10.1-17squeeze5 0
500 http://apt-cacher.lon.bitfolk.com/debian/ftp.uk.debian.org/debian/
squeeze/main i386 Packages
The closest I can find via google is:
http://www.linuxquestions.org/questions/linux-security-4/rkhunter-warnings-…
but that doesn't seem to indicate a compromised system.
I just updated to rkhunter 1.3.8 from squeeze backports and it found a
few additional warnings, but all of them attributable to
non-suspicious causes.
Thoughts? I'm really loathe to re-install this system based on an
extremely vague suspicion.
Thanks!
Adam
---------- Forwarded message ----------
From: root <root(a)adamspiers.org>
Date: 20 July 2013 06:30
Subject: [rkhunter] coral.adamspiers.org - Daily report
To: root(a)adamspiers.org
Warning: The file properties have changed:
File: /usr/bin/curl
Current inode: 37410 Stored inode: 35028
Current file modification time: 1365866469 (13-Apr-2013 16:21:09)
Stored file modification time : 1333198916 (31-Mar-2012 14:01:56)
Warning: The file properties have changed:
File: /usr/bin/perl
Current hash: 400681f383f4a2b63d4615a8d7ad53<wbr>c2a685e3da
Stored hash : be5055e1642bec794804ebf8668a15<wbr>54864d218b
Current inode: 33794 Stored inode: 33812
Current file modification time: 1362591932 (06-Mar-2013 17:45:32)
Stored file modification time : 1361046751 (16-Feb-2013 20:32:31)
One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)
Hi,
I've just noticed that my domains meowc.at and euroelection.co.uk,
both hosted on cosmo.bitfolk.com, don't seem to be working. (They were
working a few days ago.) I can ping them, but the websites are down
and I can't ssh to my VPS (meowcat) either.
I checked with http://www.downforeveryoneorjustme.com/ ansd not only
are my domains down, cosmo.bitfolk.com apparently is too.
What's wrong?
--
Phil Hunt, <cabalamat(a)gmail.com>
Hi everyone,
Please can you recommend a domain registrar that won't treat me like poo and that won't force me to use their name servers so I can host my own DNS? Reasonable pricing and someone that doesn't throw up needless obstacles to leaving would be a plus.
Thanks,
Paul.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Some university famously has a stuffed toy in the corridor where the
computer science department has its offices. The idea is that you can't
bother the staff with a problem until you have explained it to the bear
- just explaining it to someone else often causes an 'ah ha' moment.
Drafting an email to this list has just been that bear :)
Today's tip: if someone complains their ad doesn't display on some site,
check to see if it's blocked by ad blocking browser plugins.
In this case, the name of the banner included '468x60' and this is
caught by some filters, because it's a common ad banner size.
Ian
Hi,
I am in transition from using a managed domain / web service for a couple
of sites.
I'll be cancelling the old web space account but not sure how to proceed
with the domain / dns hosting aspect.
Would appreciate any pointers from your experience.
Cheers,
Richard.
Hi everyone,
I'm a bit late to the Wheezy upgrade party, but successfully got the job
done over the weekend. This has been third dist-upgrade for this VPS,
having started life as an Etch box :-)
One minor gotcha for a VPS of this age is that it started out with a
xen kernel image (my /boot dir still has an Etch era
vmlinuz-2.6.18-6-xen-686 kernel), and Wheezy no longer provides a
separate xen kernel (in fact, it would seem that a xen kernel image
wasn't necessary in a domU in Squeeze).
Switching over to the default kernel from the linux-image-686 meta
package was therefore the way to go. This installs the 686-pae variant,
although I note that the Bitfolk Wiki page suggests the 686-bigmem
kernel, which has 4Gb+ memory support. Is there any particular benefit
to running a bigmem kernel on a smaller VPS with less than 4GB RAM?
--
Phil
On 06/06/2013 21:52, Ian wrote:
> I've got a Fail2Ban jail set up to ban anyone accessing any
> wp-login.php more than five times. It's just triggered a dozen times
> in a minute - there's another major burst of hack attempts going on.
>
> Especially if you or any clients have an account called 'admin' on a
> WP site - not a good idea, as it's the WP default and thus the
> primary
> one hackers go for - you want to watch out.
>
> Ian
>
> (Another eight triggers while writing this...)
I meant to post to the list about this too; I got hit on Tuesday to the
extent that my VPS OOMed.
After working out what was going on and adding to the fail2ban rules,
around 400 different IPs and around 2000 requests to wp-login.php were
blocked over the course of a couple of hours although it's died down
since.
If it helps anyone, my fail2ban filter:
[Definition]
failregex = [[]client <HOST>[]] WP login failed.*
[[]client <HOST>[]] client denied.*wp-login.php
The first line requires a change to your Wordpress theme to log failed
logins, described here:
http://blog.somsip.com/2012/02/using-fail2ban-to-protect-wordpress/
The second one comes from adding rules to .htaccess to deny requests
for wp-login.php and wp-admin to anything outside of the IP ranges I
use. The second rule should be sufficient; I added the first one a while
ago and didn't see any harm in leaving it.
Stuart
The recent WordPress update has reminded me that in the WordPress wiki
page (updated with a couple more tips, BTW) I mention the WP Remote
service which lets you do things like upgrade WordPress on many sites
with a click or two.
When it works, it's great, but I am finding it is not always able to
communicate with my sites. It wasn't working on Saturday, it was on
Sunday, it's not now.
At one point, they were using their own server and a single IP address.
Now they're using AWS and the IP address varies according to whatever
Amazon assign to them at the time.
My suspicion was that assorted nasties are also using AWS, behaving
badly, triggering a Fail2Ban jail one way or another, and this sometimes
leads to WP Remote being caught in the ban when it is assigned the same
IP address as the nasties had.
The problem with that theory is that if I look at the IP addresses that
have been successfully used over the past few months, via looking in the
webserver logfiles, there are three:
50.16.139.168
54.224.171.85
54.242.241.26
.. and none of them are currently being blocked by iptables.
This is affecting both my VPS. Surprisingly few addresses are being
currently being blocked, and none of them look to be anywhere near
those, and I can only spot one in common between the two. And that's
nothing to do with Amazon.
Is anyone else seeing anything similar?
Ian
