I've been asked to change all of our current Joomla sites from using PHP Mail to SMTP.
The background: we were recently compromised through a vulnerable component on one of our sites. We have a dedicated server, running CPanel. The hack involved a file being uploaded to one account, which had a file manager (with access to /home, ie. all other accounts). From there, another file was uploaded that began sending emails - not enough to catch with ease, but eventually enough to get our main server IP blacklisted. Because the main IP was blacklisted, many of our other sites (for which we also host email) were also blacklisted.
My argument (your comments/ideas on this are much appreciated!)
Changing to SMTP will not solve this instance
It would solve the issue of any vulnerable components where an email can be sent via a request spoof (ie. option=com_users?task=email&..., or something similar to that)
Because the hacker has access to the files in the account, they also have access to the configuration.php file, which holds the SMTP password in plain text. Access to this means they would also have access to the SMTP server.
The SMTP that we would be using is localhost, which doesn't solve the issue of our IP being blacklisted.
My first idea was to provision/setup SMTP on a separate IP (or server), but that can still be blacklisted if a site gets hacked.
The second idea was to provision each site a unique IP, so no one site can get the rest blacklisted.
So I'm a bit lost. Before we tackle the task of setting the mailing function to SMTP, testing each site (there's roughly 70, with varying components to test) I'd like to have a better idea of what's the best route, if any.
It seems that either setting in Joomla is insecure in the event of a compromised site, no?
Find where your server is blacklisted, and apply to be removed. Note: if any of the sites require payment to be de-listed, ignore them. [eg: SORBS] Nobody cares about extortionists, trust me. I was admin for several busy mail servers for the last few years.
If you're completely switching from PHP-based mail() on all sites, then disable the mail agent on the server. mail() simply submits to the MTA running on the server [usually Sendmail or Postfix] and if your server is compromised again they will still be able to spam out.
Yes, your SMTP credentials will be stored in a config file somewhere, but most instances the intruder won't even bother to look for them. They simply drop in a basic PHP script that calls mail() and that's it.
If mail service is at all important to you you should always monitor:
The reputation of your outbound server.
The abuse mail for your domain. It will either be coming to abuse#yourdomain.com, or the abuse# contact for whoever owns the IP address block.
Related
Our setup is like this: we use a coldfusion 10 server, and files are on a local intranet. Users use a domain login to access any files over https. I'm interested in using html5 websockets, but the first attempt gave me an error because no credentials were supplied. Is there a way around this? If not, is there a recommended technology for this scenario?
The user does log in on the client side. If it's possible, what I'd really like to do here is pass those credentials when making the connection to the server.
you should be able to supply the authentication header to your web socket server before the elevation to web socket read that and send it back in the headers for the elevation (first frame) then when the browser connects it should have the authentication it needs.
if your using a custom authentication E.G in page not authentication header you can also do this by passing any custom header to your server.
Or mandate that the first thing your web client sends is the authentication details this could be something like {username_hash}.{password_hash} if they don't close the socket to them.
Do not do this.
You're now responsible for sending and encrypting the authentication credentials yourself, bypassing something that already works and is tested.
Anyone can snoop on an unencrypted websocket port. Use HTTPs for an intranet, use stable solutions, don't reinvent this wheel because it tickles your fancy.
In a couple of years some colleague will have to maintain this and will have to figure out how your homebrew version works versus something that's solid like plain browser authentication.
My advice: Leave this to the browser and to well-tested coldfusion libraries.
I got a multisite network, and got subsites on it, unfortunately the main domain has expired, and I cannot access my WP admin. I don't worry about the main site but I need to have the subsite.
I am able to access the main site using the IP but not its WP admin. I tried following this but it didn't help. I saw a way via accessing database (this method) but I couldn't access database as its hosted in Digital Ocean, it's pretty hard without a control panel.
want a way to access main sites WP admin
access my subsite via URL (it has a separate domain which is being masked)
If your domain has expired, ordinary DNS will not work. This means that domain-based hosting on the web server will no longer operate as well.
However, you can easily trick your local machine into thinking the domain still exists. This will work on Linux and OS X. You'll need to know the IP address of your web server - if you do not have this, you'll have this in the welcome emails you've received from your web host, or perhaps by logging onto your customer control panel.
Edit your /etc/hosts/ file. In a blank link at the end, add this:
yourdomain.tld 1.2.3.4
where 1.2.3.4 is your IPv4 address. The gap between the two can be any number of spaces or tabs.
Once this file is saved, you should be able to ping it thus, in a console or terminal utility:
ping yourdomain.tld
and it will show you what IP address you have assigned it to.
You can then access it normally. Bear in mind, though, that only you have the DNS information, so it will not work on any other machine. It will however allow you to access your WordPress control panel.
I have successfully set up health monitoring for logging errors on my ASP.NET web page to the Windows Event Log, a SQL Server database, and through email (Microsoft Exchange) when I specify a user name and password in the web.config file. However, if I change from specifying a user name and password to defaultCredentials="true" in web.config, I get the following error message in my Windows Event Log when it tries to generate the email:
System.Web.HttpException (0x80004005): Unable to send out an e-mail to the SMTP
server. Please ensure that the server specified in the <smtpMail> section is
valid. ---> System.Net.Mail.SmtpException: Mailbox unavailable. The server
response was: 5.7.1 Client does not have permissions to send as this sender
I am running Windows Vista on a corporate domain. My Windows login is identical to my Microsoft Exchange login. Can anyone provide some insight as to why specifying my login credentials explicitly in the web.config file works, but using defaultCredentials="true" does not? Are there any known solutions so that I can have an automated email sent through healthMonitoring without having to store my user name and password in the web.config file?
Since I earned the tumbleweed badge for this question, I doubt an answer will be of much value to anyone else; but knowing that I will inevitably fall into the same trap at a later date, I thought I would post an answer to my own question...
Authentication is not necessary for sending emails within the same domain; so instead of specifying defaultCredentials="true", I removed all fields related to authentication, and the emails began working again.
Note that this is only a partial solution. I only need to send emails to addresses within the same domain for now. Sending emails outside of this domain will not work without authentication, so if/when that is needed, it will be back to the drawing board...
Three weeks ago, I found a list of my website's users and info on Paste Bin giving away all privacy. I ran updates and protected against SQL Injections. I also added a pre-request to save the SQL in text format in a LOG table whenever user input is required to be able to analyse any injection if my protection wasn't enough.
Then today the same post was on Paste Bin again with recent entries so I checked the LOG table to find only clean entries. Is there anything else than injections I should worry about? The web seems to give info about Injections only!
Could they have had access to the dbpassword in a php file on the server and could they have connected from and external server?
Should I change the dbpassword frequently?
Are there any solution non-script wise like hosting security plan or something like that which should be efficient enough?
I am receiving physical threats from hacked users and would really like to close this quickly...
If you're implementing your own protection against user input, you're probably doing it wrong. Most standard database libraries will give you a way of passing in parameters to queries where it will be sanitised properly, and these will have been coded with more things in mind than you're probably aware of. Reinventing the wheel in anything security-related is a bad idea!
Other things to worry about:
Password policy (strong passwords)
Access to your database server (is it firewalled?)
SSH access to your server (again, firewalled?)
Keeping all of your software up-to-date
Just to add to the other answers that you've had so far. If someone is posting the contents of your database online then you need to assume that the server(s) running the application and database have been compromised, as once they've gained initial access, it's likely that they'll have placed root-kits or similar tools onto the server to keep access to it.
As to how they got in there's a number of potential options, depending on the architecture of your solution, and it's imposssible to say which is the case without more details. Some of the more likely options options would be
SSH passwords
Administrative web apps (e.g. PHPMyAdmin) with common passwords or vulnerabilities
Access via hosting service (e.g. weak passwords on administrative login panels)
If the site is PHP based Remote File Inclusion issues are a distinct possibility
If you can I'd recommend engaging a forensics or incident response company to help you recover the data and rebuild, but failing that I'd recommend getting a backup from before the compromise and using that to rebuild the server, then ensure that all software is updated and patched and passwords are not the same as the compromised system, before bringing it online.
The best protection for this is to allow connections to the mysql database only from the machine where your application runs.
First of all, make sure, network access to the MySQL database is "need to know" - in most cases this is a simplye bind-address 127.0.0.1.
Next change the DB password, just because yes, you can (C)
Now think of this: If somebody got your DB passwd from your PHP files, you already are in deep s***t: Nothing stops him or her from just repeating that stunt! You need to audit your application for backdoors (after the fact problem) and how the guys got in there (before the fact problem). Check your apache logs for requests with unusual GET parameters - a filename in there mostly is a dead givaway.
I agree with Razvan. Also if you're running any CMS or prepackaged web pages, make sure they're the latest version. They most likely access as localhost from the web server. Hackers follow the change logs of those and every time a security patch is released, they attack published vulnerabilities on servers running the older version. It's often performed in bulk by crawlers. Odds are they have a database with your server listed as running old versions of things.
First you need to ensure that this "php file" containing the DB password(s) is not within the web root directory, otherwise they could simply access it like: http://mydomain.com/dbpassword.php.
Second, immediately change the passwords used to access your database.
Third, ensure that mysql will only accept connections from 'localhost', vs allowing connections from anywhere; '%'. And if it is a dedicated server, then you should "harden" the box and add an IP rule to IPTables where mysql access is only allowed from the server's IP. These changes would ensure that if they did get your db username/password creds, they can not access the database from a remote computer, instead they would have to exploit your application, or ssh into your server to gain access to your database.
Next, you should disable all user accounts to your site, and force them to update their passwords using a closed loop verification process. This will ensure no ongoing malicious activity is occurring with your users or their accounts.
These are just a few steps to take, there are others such as tracking local users login activity. It is possible that one of your system's user accounts has been compromised (rooted). The point is, you need to consider all points of access to your system and services therein, if you are unable to do it, it may be time to hire or contract a seasoned sysadmin to help you.
If this is shared web hosting, and another user is logged in with shell access and is able to guess the path to your web root, and the password configuration (PHP or other script) file is world readable, then the user can read it.
This is one of the most common vulnerabilities and is very easy to exploit.
If this is the case:
To correct the issue, you need to move the configuration file out of your web root folder and/or change the permissions on it so that it's not world readable, and then change your database password.
Most likely, the user would not be able to inject anything into your application.
Changing the database server so that it's only accessible locally or to your web server would do no good, since the malicious user would be on the same web server and still be able to access it.
If you did not see any malicious queries, then they are probably accessing your db via the MySQL command line (or PHPMyAdmin or other tool), and not through your application.
Enabling the general query log would allow you to see all queries in plain text in the log, but if this is shared web (and MySQL server) hosting, you probably won't be able to enable this.
This is something you may wish to report to your web host. They may be able to find the attacker and suspend their account or provide you with evidence.
I have a server with Plesk installed.
On that I've created a domain, my-domain.com, and added and e-mail account noreply#my-domain.com with access to SMTP for sending e-mails.
With PHPMailer or Swift Mailer I am able to send via the SMTP account noreply#my-domain.com whenever the from address is outside the my-domain.com, for example info#my-second-domain.com.
Whenever I'm using an e-mail address that ends on #my-domain.com it fails.
I've tried to look in the /usr/local/psa/var/log/maillog file, but it only stores the mails that doesn't fail.
Can someone help me figure out where the problems is?
You can try this:
Delete the related domain in the qmail file /var/qmail/control/virtualdomains
Then reload/restart qmail. Now it should work.
More technical background at http://forum.parallels.com/pda/index.php/t-93222.html
Benjamin answer didn't work on my installation (Plesk 11.5), but I found another solution:
just turn off the mail service itself. It might not be the solution for everyone but it was for me (my domain's mx records pointing to another server, with some scripts sending emails here and there).
You can turn off the mail service fairly easily using Plesk GUI.
Then uncheck
However, this won't turn it off for subdomains and secondary domains you might have. No problem, just log in with ssh and run this command:
/usr/local/psa/bin/domain -u mydomain.example.com -mail_service false
And if one day you decide you want to turn it back on just replace false by true.