What is Reddit's opinion of
Fail2ban?
From 3.5 billion Reddit comments
52 reviews of this app found across Reddit:
You can install fail2ban, which is a daemon that parses your logs and blocks all ip's that are trying to bruteforce you. (http://www.fail2ban.org/wiki/index.php/Main_Page) Alternatively, if you want a more simple and immediate solution, and it's currently only one ip, you can block it with iptables:
iptables -I INPUT -s 219.137.228.180 -j DROP
Which will drop all traffic from that ip.
>I know how to use iptables to block ip addresses, but I want something more automated.
Fail2Ban willl automatically ban IPs after repeated failures.
If you run Apache, SSH, FTP, or other server services, I highly recommend fail2ban.
"sudo apt-get install fail2ban", then read the wiki pages about configuration.
I've found that moving off port 22 already drops scans by 99.9%, so on a public server there's really no reason to not do that.
Then do 1) fail2ban or similar, and 2) port knocking
If you're not already, and your environment will support it, I would recommend disabling root login in your SSHD config. Here's a nice document: http://wiki.centos.org/HowTos/Network/SecuringSSH#head-9c01429983dccbf74ade8674815980dc6434d3ba
Ubuntu also has some nice documentation on securing SSH: https://help.ubuntu.com/community/SSH/OpenSSH/Configuring
"However I was wondering if I should I find a way to block IP's after X amount of failed attempts of logging on in X time period?"
You're looking for Fail2Ban: http://www.fail2ban.org/wiki/index.php/Main_Page
> Find some way to mitigate the constant brute-force attempts against the mail server...
Fail2ban?, if you're on a *nix system? Worked great with Postfix for me.
Fail2Ban is exactly what you're looking for :) http://www.fail2ban.org/wiki/index.php/Main_Page It scans logs, such as /var/log/secure, and bans any IP that is showing malicious activity..such as too many login attempts!
It's super easy to install and set up.
Side note: For added security, disable remote root login. Ditch password authentication and switch to public key based auth for SSH. Add a passphrase to the key if you like. Once you have the key based auth up and running, won't have to worry about people bruteforcing their way in
EDIT: how to set up SSH keys for login instead of using passwords
https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2
Personally, I wouldn't use port 80 because it would be among the first ports that a script-kiddy would check.
I use SSH with SSH keys to log into my remote machines and turned off root access along with disabling SSH authentication via password. Assuming you keep your keys private there is little to no chance of someone brute-forcing their way in.
All of /u/somethingeneric's suggests are great, too. Look into Fail2Ban and turn on HTTPS if you can.
It would be worthwhile knowing that it's pretty easy to make it look like you're coming from the US... but a bad guy would need to figure out that's what you were looking for first.
I prefer to lock out ip addresses after 5 failed attempts. I use wp-fail2ban (in conjunction with fail2ban) to achieve this.
No, locking people out after a small number of attempts doesn't help anything. If you want to stop brute force/dictionary attacks you should use something like fail2ban which scans your logs for excessive attempts (and 3 is not excessive!) and automatically updates your firewall config to drop connections from that IP. You should never lock out an account unless you know it's been compromised (the poor user can't help it if they are the target of an attack)!
check /var/log/secure for the matching IP. I bet you will see a bunch of usernames being tried (or some other gibberish)
If this is RHEL 7...
journalctl -b _EXE=/usr/sbin/sshd
I believe you will see the output you see even if they are just trying to connect to break in.
I would probably deploy fail2ban if I were you.
It's just scanning for ways into your system. If the server is configured correctly and all the software is up to date, then there's not much to worry about.
You might look at installing Fail2Ban, searching for some Fail2Ban scripts for the services you're running. You could also write a script for Fail2Ban that bans an IP address of they get a bunch of 404's in a row.
First, are you sure that is a DDoS attack? could be peak hours for your server and if they're legitimate you need to serve it, owtherwise if they're not you need to not respond it
The choice you made are great, you can use Elastic Beanstalk further in the line to ease your deployment workflow now that you are in the autoscale mode.
Things that you can do are: putting fail2ban but you need to do testing and make sure it won't ban your load balancer, try to read your log with logstash and kibana, try to flamegraph your app and try to understand the bottleneck so you can improve your response.
If you could actually know how the attack is done you can bypass your server entirely and serve a 500 to those clients.
Sorry for the answer but it will need further investigation
edit: how many concurrent user/DDoSser you have?
I use fail2ban (http://www.fail2ban.org/wiki/index.php/Main_Page) and also i banned in iptables entire china ip pool (i dont connect or provide service to china in any way). The attacks on my web server dropped 95% since then.
Stupid but works nice :)
Im not sure if it suits you but i leave it here.
I'm a fan of fail2ban on anything with a routable IP. It automatically performs actions in response to suspicious patterns of behavior (both user definable), which in practice mostly means dropping all traffic from IPs for some period of time after >3 failed SSH login attempts.
I would consider looking at Fail2Ban - but that will require that IPtables be enabled. I leave SSH enabled on my systems that are "exposed" but.. I use Fail2Ban and I force ssh-key authentication.
I have found value in AV - however, in my case it was because of Windows machines being used for Dev and a SMB share. Either way - the server itself was not comprimised, but it has infected files on it. AV identififed them so I could remove. ClamAV - ClamAV is not terribly difficult, but it is not terribly straight-forward at first. You'll get it though.
If you are particularlly paranoid, you can look at something like TripWire (I don't know if they have a Free version any more). Also - you can check connections using
netstat -anp more /var/log/secure
Yea, that can be expected when you have an open ssh listening on a public IP. You can build custom iptables rules to block out multiple login attempts or you can use fail2ban (available in the repos). Set fail2ban to filter ssh, ftp, and any other services with login to block an IP after X amount of login attempts.
For reporting, configure logwatch to email out reports daily to your email. Logwatch monitors your auth log, which fail2ban will output to as well. Fail2ban also has email capabilities for login attempts, but logwatch also will monitor your other log files in /var/log and give you a heads up for the general health of your server. For extra security, you can set "PermitRootLogin no" in /etc/ssh/sshd_config and restrict authorized users to pub/priv key access.
Fail2ban and logwatch are fairly easy to set up and are available in the default repos for 14.04.
>4) Should I take any other precautions? What's the easiest way to setup email alerts if there are too many login failures on either wordpress or system access?
fail2ban is a very useful tool that I always install on servers: http://www.fail2ban.org/wiki/index.php/Main_Page
You configure specific logs and emailing to notify you of suspicious behavior otherwise its good for just silently blocking internet "background radiation" of bots, spammers etc.
If you feel comfortable with it, avoiding passwords for SSH and using keys only is a good security practice. Here's another basic, good checklist for things you should immediately when you set up a linux server: http://plusbryan.com/my-first-5-minutes-on-a-server-or-essential-security-for-linux-servers
Additionally, always keep Wordpress and PHP up to date as they tend to be notoriously vulnerable out of the box. This might be overkill but here's some security benchmarking and best practices for PHP (its mostly coding oriented): https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet
1) Don't start your FTP service until you have some sort of IPS/IDS in place. fail2ban is simple to install/use/maintain/expand.
2) No, seriously go back and finish #1
3) Once your FTP group is jailed to their respective home-dir(s), you can simlink other directories for them to share among themselves.
4) I really wasn't kidding 'bout #1
I use Fail2Ban to do exactly what you describe, along with blocking the IP via iptables. It can inspect any log file, not just web logs, so it's also helpful for blocking brute force SSH attacks, DNS probes, etc.
This seems like a great start for the security side of things. Link is here for anybody else looking for it.
Do you do any other log monitoring?
Yea, as others have mentioned, keep everything patched and up-to-date. Have common sense about your usernames and passwords and they will do their jobs. A lot of ISPs now-a-days will recognize and stop high-repetition attacks such as login bots. However another form of counter-defense you could take is to install something like fail2ban. It won't prevent people from actually breaking in if they have the correct credentials, but again, it'll usually slow down spam bots.
Opencart has some really nice SSL features. You mentioned security in your original post, so I would consider enabling and configuring those features. I experienced one breech when a user located and attempted to bruteforce my admin login panel. I learned it is important to hide that page from search engines. Also, if you decide to run this off a server with ftp or ssh enabled (I use ssh) consider installing security to keep bad guys off those services. At the very least, do everything this page says. http://docs.opencart.com/administration/security/ And for ssh protection: http://www.fail2ban.org/wiki/index.php/Main_Page
All in all, the application runs really smoothly right out of the box. It also allows for a good bit of room to add custom features because of the modular design. I developed a plugin to add products and manage fulfillment automatically. Best of luck with your project!
Use a firewall. Make SSH access available only for specified IP or IP range.
Or use fail2ban.
Or if you only need SSH access over LAN, use a router and not to forward the SSH port to your home server.
Or use Port Knocking.
You can in theory set up something yourself, that periodically checks connected hosts against a GeoIP database and handles them as you wish. But it will probably be easier and more reliable to blacklist based on the activity itself than the origin. There are software for that exact purpose like fail2ban that can ban IPs if they perform too many login attempt, connections, requests, etc.
Spam is a major PITA on the MTA side. So is brute-force attempts and mitigating spam. If you're going to handle e-mail on the server, you're going to do very poorly:
1) Spam. The techniques spammers use today is better engineered than before to ensure those spammy e-mails make it to your inbox. Using a free solution like SpamAssassin? It's woefully ill-equipped out of the box. You'd need to enhance it with something like Razor, DCC, and jumpstart its learning with maybe the Enron corpus. Even then, from my personal testing with clients, it fails to tag a considerable amount of spam. I've had to ratchet the spam threshold down as well as use a continuous feedback loop to feed it spam that falls between the first and third deviation. Unless you're willing to invest significant time into perfecting spam filtering on your end - you won't be able too, insufficient samples - you'll lose productivity to false negative spam.
2) Brute-force. Happens quite a bit. On a given day my servers will block around 300-400 connections for brute-force attempts that meet fail2ban guidelines. It's a waste of server resources and if you have a weak account, a perfect vector for your server to begin sending spam as well.
3) Postfix configuration. It's fun. It's tricky. And unless you're willing to take on custodial duties, management can be difficult. I use deep protocol inspection on all clients + a global whitelist shared among servers. Some mail servers loathe best practices and timeout after 15 seconds before these tests can finish. That causes e-mail to hang-up indefinitely, and unless you or your clients are monitoring for these impatient mail servers, mail to or from will never get through.
In organizations there are sysadmins and mail admins. There's a reason for this separation; mail can become quite complex.
Please turn off root password logins with ssh. You'll save us sysadmins some grief down the road.
echo 'PermitRootLogin without-password' >> /etc/ssh/sshd_config
And for the love of god, enable automatic updates with yum.
To save the heartache of stupidity from other users you might gift an account to, on your VPS, install fail2ban
Oh, and for all that is good and holy in this world, update WordPress regularly. Don't be like that idiot a few weeks ago bemoaning MediaTemple, because his 2 year old WP install was hacked.
Good luck. Godspeed. But yeah, really: running an unmanaged VPS yourself is disastrous if you don't have even an ounce of clue to what's going on.
No Linux distro out of the box is secure.
// cut general guidelines for people who don't know anything about server management renting a VPS and dotting servers with illegitimate traffic because it was compromised
I wouldn't recommend setting up XAMPP. You'd only actually use apache out of that and it wouldn't do anything to protect you in terms of security. If you're concerned about people trying to brute-force your login you may want to look into Fail2Ban. Otherwise just make sure you use a strong password.
You should also look into setting up https if you're not doing that already so that people can't steal your login when you're on untrusted networks.
There's probably some bash magic you could do in order to make a log file only get a specific year. Other than that logging is a problem already solved by ssh, utmp, and wtmp.
# you will need sufficient privleges to run some of these commands #show ssh logins, or mosh or whatever is being used last | grep ssh #show the lastlogin for a specific user lastlog | grep user #grep auth log for sshd service login attempts and failures grep "ssh" auth.log
If you suspect bruteforcers or port scanners trying to get in consider fail2ban, that is if they are getting through port forwarded ports on the firewall. There's lots of things out there scanning the internet but a decent firewall with strict rules should stop most of them from finding low hanging fruit.
http://www.fail2ban.org/wiki/index.php/Main_Page
I use fail2ban and I have only managed to ban myself when I send the wrong key to ssh, or screw up a password; the border firewall stops most of the port scans, and I've seen many a port scan bounce off of the firewall. At somepoint I should do an exercise in collecting data on how many port scans bounce off of the firewall for known ports, probably too many to be worth counting.
Fail2Ban isn't enough, or is a bit complicated (removing bans is a bit troublesome) try http://www.sshguard.net/docs/.
There is likely a vuln in your website OP. Just moving to a new vps doesn't fix the problem. Some scanners are here: http://sectools.org/tag/web-scanners/
Also try http://www.fail2ban.org/wiki/index.php/Main_Page and http://sourceforge.net/projects/cband/
Blocking IPs and hostnames is highly futile. My suggestion is realtime block lists. It's a layer of anti-spam I use. It will quickly identify IPs that have either been hacked or are known spammers. Once flagged, you're notified instantaneously.
One of the services I use is Spamhaus: http://www.spamhaus.org/sbl/
Another suggestion is something like fail2ban. You have a service that sits and watches your /var/log files and if an IP matches something, such as a 550, or repeated spam bounces, it will block the IP for a predetermined amount of time.
It might not be readily applicable since it doesn't run on win32.
My "for fun" configuration was: ssh with google authenticator on raspberry pi
https://www.raspberrypi.org/blog/setting-up-two-factor-authentication-on-your-raspberry-pi/
Router NAT on non standard SSH port plus fail2ban on pi http://www.fail2ban.org/wiki/index.php/Main_Page
then tunneling ports with ssh client - so on my phone I put localhost:1888
I recommend fail2ban:
> Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc.
We find it a very powerful way of reducing the volume of unwanted traffic to both Apache and Postfix.
Met dezelfde redenering is het een heel erg slecht idee om überhaupt een port open te hebben. Er kan een lek ontstaan in je operating system waardoor de aanvaller niet eens je wachtwoord nodig heeft om binnen te komen.
SSH openzetten op een andere poort is niet enkel het juiste middel om je te beschermen (security through obscurity). Voor de aanvaller is het slechts een indirectie. Met een simpele port scan heeft de aanvaller alsnog de juiste port.
Het vele malen effectiever om bijvoorbeeld password authentication te verbieden (dus enkel SSH keys toe te staan) en gebruik te maken van whitelisting, rate limiting, etc (bijv. fail2ban).
Alhoewel poort 22 dichtgooien het de aanvaller lastiger maakt, zorgt het naar mijn mening voor te veel gedoe (welke poort ook alweer? staat de firewall goed ingesteld? etc). Zie hier een wat genuanceerdere discussie.
Proxies get around this. Also, people are dumb. If you know their dog's name you have a pretty reasonable chance of guessing their password. Know enough about someone and guess some passwords every day and you'll likely get in eventually. Do this with enough people and you'll get into lots of stuff.
Check the app's documentation for key management - I don't have a clue how you get iOS apps to generate, use or access the generated keys, even assuming that the app supports key authentication at all.
Once you have the public key, append it to /home/whatever/.ssh/authorized_keys on the Raspberry Pi and enable pubkey authentication in /etc/ssh/sshd_config
When you first connect to a server, the client will store the server's key fingerprint, and alert you if it ever changes (which would suggest someone trying to impersonate the server to steal your password). You will probably be ok just accepting the fingerprint when you first connect without manually checking it.
If you can I'd suggest disabling password authentication if the server is going to be exposed to the internet; alternatively, look into fail2ban
You should learn to read documentation. If you had done so you would know that you should not have edited jail.conf, instead local config goes in jail.local.
man jail.conf
It also says it at the top of the configuration file you edited. ಠ_ಠ
Here's the fail2ban wiki. Certainly worth reading http://www.fail2ban.org/wiki/index.php/Main_Page
Unusually there aren't any post install configuration documents in /usr/share/doc beyond the generic. I would recommend search for jail.local examples.
Lastly, obscurity is not security. I hope you're using 2048 or 4096 keys with your ssh and hardened it.
Why would you want to bruteforce your own SSH? You can be sure to be protected by a sufficiently complex password or rate limiting by something like fail2ban
To get your SSH password hash you just want the hash found in /etc/shadow or /etc/passwd for your user.
Well as /u/BigRedS said, you can reduce the amount of log spam if you use fail2ban.
I have a static IP so another option for me is to just use iptables.
# All connectsion from address 1.2.3.4 to SSH (port 22) iptables -A INPUT -p tcp -m state --state NEW --source 1.2.3.4 --dport 22 -j ACCEPT
# Deny all other SSH connections iptables -A INPUT -p tcp --dport 22 -j DROP
Is it a distribution of IP addresses or a single IP address? If it's a single IP address and happens to be your server IP or 127.0.0.1, then it's a misconfiguration in the app. There's also a chance you've got an overlapping virtualhost configuration with port 443 configured with SSLEngine not set.
If, on the other hand, you've got a bevvy of IP addresses, sounds like you're getting hit by a distributed attempt to penetrate your site. Install fail2ban, filter out hosts, and ban them. Problem solved.
Check out fail2ban. It watches your logs for suspicious activity and adds firewall rules to completely block connections from attacking addresses (for a configurable length of time).
I use it primarily for blocking ssh bruteforce attacks, but it also has a wordpress plugin - it might be worth some research.
DO is pretty good from my experience, except some network problems they had when opening the singapore node, but it's stable now.
Your issue is clearly not related to them anyways. If the techie says the mysql socket was off it could mean that there was some configuration mishandling either on app side either on mysql server side.
If you are concerned about ssh breakin attempts (it is a constant issue on any server) consider using fail2ban and/or denyhosts (and above all disable root ssh login).
there is a paid proxypass type module that does this but i cant remember. Heres something ive done before. Its not perfect and there are modules that do the same but better, i just cant think of any at the moment.
every half hour grep through the access log for ips that get file not found. if an ip attempted 3 times for files not found add them to a list and specify the crons timestamp. when finishing the log put the last timestamp of the access log into a file in temp. so when the cron runs again it knows where to start from. from the list that got created of ips and a timestamp of that cron run, i would then set logic to block them for X amount of time in iptables since it can be updated while active while apache can not. this is very hacky and it requires you to know how to do some programming. I wrote this all in bash before a few years ago when i started my career at a webhost. its not perfect but it does the job.
EDIT: adding links to better existing modules:
http://www.fail2ban.org/wiki/index.php/Main_Page <--- automatically blacklist IP addresses in Apache once they have requested X number of files that 404 in a specified time frame
https://library.linode.com/web-servers/apache/mod-evasive <--- possibly can be configured to do the same.
>but how will I block extreme DDoS attacks?
You could do this yourself with something like fail2ban, which is software designed to automatically detect and ban DDoS attackers. On the other hand, you can always just pay somebody else to do it by signing up for a CDN service like Cloudflare, Cloudfront, or Rackspace. These can cache some of your content globally, to serve it up quicker, and give some DDoS protection. There are also a number of DDoS protection services you can buy. However, if your users are going to be running this python script it may not mesh well with a CDN.
>What kind of hardware should I be looking at?
If you're expecting 10,000 concurrent users and regular DDoS attacks, I don't think buying your own hardware is going to be the way to go (especially if you were planning on running this on a consumer broadband connection?). In fact, if there is a great deal of money involved, as you say, I suspect hiring somebody experienced who knows what they're doing is probably not a bad idea.
Well it's the port you connect to for ssh, it's worth changing it to something else - http://www.cyberciti.biz/tips/setup-ssh-to-run-on-a-non-standard-port.html
It might also be worth running something like fail2ban - http://www.fail2ban.org/wiki/index.php/Main_Page
- SSH Public Key auth instead of passwords for ssh login.
- get your firewall thingy set up (google iptables)
- Fail2Ban to help keep the bots & brute forcers out.
- SSH on a non-standard port. This isn't a security measure, but it makes the log files smaller and more readable.
- Check for rootkits every so often
Disclaimer: I am not an expert, but I have had several cheap VPS's for a few years. So far I have had no (obvious) break ins.
Two things have worked quite well for me:
iptables to drop after x attempts on port/protocol
iptables -I INPUT -p tcp --dport (port) -i (iface) -m state --state NEW -m recent --set iptables -I INPUT -p tcp --dport (port) -i (iface) -m state --state NEW -m recent --update --seconds (seconds) --hitcount (attempts) -j DROP
fail2ban to do additional blacklisting
Seriously. In this day/age, there's no good excuse to toss passwords in clear text back and forth.
And now that you have all these services/ports open grab a copy of fail2ban to keep watch over your logs and auto-shun the script kiddies.
CCZE : robust log colorizer will give provide a 'cool display' of your logs in real time if your'e a log watcher.
sudo tail -f /var/log/auth.log /var/log/proftpd/proftpd.log /var/log/fail2ban.log | ccze
For the last two items:
ps aux | grep sshd Will show who's logged in via SSH --including SFTP.
fail2ban will watch logs for indication of brute and dictionary attacks. It will then temparily ban the offending IP for a configured time span via IPTABLES.