Slashdot Mirror

list of websites i access and my http data?

Which by the way, if using HTTPS (either because explicitly type it, or because you use a plug-in like HTTPS everywhere) is quite limited. From the outside you only see connection to *IP* address (to the front load-balancing/reverse proxy server, or to the apache server hosting all the virtual domains if that one is straight facing internet). The actual URL (server's full name, and document) is only asked once the encryption is established. (That's why you need stuff like SSL's SNI extension, so the server can hand out the correct certificate corresponding to the peculiar virtual server you want to visit).

so what could they have possibly gained by this devious man in the middle circus?

Indeed, intercepting data isn't probably the main goal. Even back since FireSheep, the security of internet websites has been getting better. Not that the end users care much (I think I remember an article on /. back then that lots of "victims" were amused but didn't really grasp the implication), but the companies have reacted a made HTTPS at least an option if not the main access point.

The risk might comes from the network it self: a public network is an ideal place for an hostile to perform network scan, looking for vulnerable services or even vulnerable network stack component to exploit.
A public Wifi network might not be handing out public IPs/might be NATed/might not be accessibly routed from the internet - thus the various device connected to it might not be scannable from the internet at large.
But from within the network it would be possible to perform a scan (brute force the SSH port of unix-running laptops*), including looking for services which aren't normally routed (like SMB network shares, Zeroconf)

Note that, regarding such a risk, the notoriety of the Wifi sport doesn't play such a big role.
- You might be at risk if you connect to some shady Wifi network operated by hostile.
- But you might as well be at risk if you connect to some well known "clean" public Wifi, but on which there's a rogue device connected scanning its neighborhood for vulnerabilities.

------

*: If you're fed-up with constant hammering on your SSH server - which still pollutes your logs EVEN AFTER you've switched to key-based-only logins or 2-factors, Fail2ban is your friend.

Another useful software for auto-banning bad accesses is fail2ban which can also handle other services, like exim, vsftp, apache, etc.

Why no fail2ban or DenyHosts? I suppose my sshd doesn't allow root login so stuff like that showing up on my logs is not a big concern anyway.

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. Generally Fail2Ban then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email, or ejecting CD-ROM tray) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, curier, ssh, etc).

I have a vpn like most sane people. Leaving port 22 open is just asking for abuse.

I think actively blocking attackers with something like fail2ban is at least as good as an additional standard VPN or using non standard ports.

you're not going to make a dent. Most reports are simply ignored, and for every attacker you see, there are thousands more who simply haven't gotten to you yet.

Make sure you have good passwords, know what ports are exposed, and run something like fail2ban.

Just install fail2ban: http://www.fail2ban.org/wiki/index.php/Main_Page And set it to something like 6 hours locktime. Really cleans up the logfiles and takes the load of the server, espicially with SMTP. Regards Brian Simonsen

I'm using an internet-facing LAMP server. Here's what I do:

1) Make sure remote root logins are disabled on your box.
2) Use complex usernames and passwords. I look at my log files and realized they need a username and password match. A lot of the ssh attacker usernames are pretty simple. Don't use common usernames. A lot of times they spin their wheels trying to log in as root. You should only be able to su to root once logged in as another user.
3) I use MySQL. Don't allow non-localhost logins. Applicable to any database probably. The user would need a successful login to touch your database outside of the interface.
4) Use iptables, the linux firewall. Close all ports that you don't need. Leave open only port 22 and 443 and 80 (ssh, https, http respectively).
5) Use a brute-force attack limiter like fail2ban. It works through iptables which is a packet inspection program. Fail2ban is a python program. It won't allow the connection to get to the password authentication module once an IP is banned.
6) Every piece of input you get on the server must be sanitized. "Stripslashes", "htmlentities", "strip_tags", "mysql_real_escape_string" protect against SQL injection attacks and cross site scripting attacks.
7) Set up file and directory permissions correctly.
8) Use established, commonly used security programs. Don't try to roll your own. The established ones have been out there and have been looked at.
9) Implement https. With Apache, you need to add 2-3 lines to a config file. Get a book on Apache. There's info on the web. Doing this prevents usernames and passwords from being transmitted in clear text. Very important.
10) Check your log files routinely. auth.log, error.log, other_vhosts_access_log. Great fun. Plus you can see if there's any odd activity.
11) Use unusual names for your directories. Typical port 80 scanners just test for like 100 or so common directory names.
12) Turn off the ability to list directory contents.
13) I use PHP sessions. Additionally, I store data about the user (ip address, username), and check it every time they start to execute a script. If what's in the session cache on the server doesn't match what I've stored on their machines, I give them an error page. They can't execute any of my scripts without valid, non-stale login credentials.
14) Use POST instead of GET. Avoids session hijacking that way.
15) Turn off error reporting in PHP on your production server. Fail without comment, unless it's a foreseen failure path.
16) Only allow cookie-only sessions.
17) Encrypt important stored information like passwords. Salt them. I don't know the passwords on my system. That's because they've been run through MD5 with salts.
18) Enforce minimum password lengths for your web interface. Learn about that with regular expressions.
19) Prevent listing of PHP files.

So that leaves... the ughknown. I see in my logfiles where attackers are constantly trying to test different directories on my website. Like I said above, unusually named directories. A custom naming structure perhaps. Read technical websites for talk of new security breaches. That's a big one. There was one recently where big POST strings could bog down a server. I set the right settings in my php.ini file and now it's no longer an issue. Things like that.

What about things like buffer overruns and... what else? Aye there's the rub. The "what else." Make a point of reading about security as much as you can. Complex items like buffer overruns are pretty much scrubbed from the popular tools. If you roll your own security you could be vulnerable.

So, I talked about a LAMP server but the concepts are probably pretty portable to other systems.

So, there's my $0.02.

How about fail2ban? We use it to block multiple SSH attempts. It blacklists IP's for a user-defined amount of time and then unblocks them again. Works like a charm, every time. Hell, it's even locked me out on more than one time (because I didn't update the whitelist file for my workstation's IP).

"Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address."

http://www.fail2ban.org/wiki/index.php/Main_Page

I have used fail2ban for years. Very effective and even stopped DDOS attacks against my ssh server

  http://www.fail2ban.org/wiki/index.php/Main_Page

Instead of adding the rules manually, I've been using fail2ban for a few years now, and haven't had any problems. Well, except when I opened a shell to let my father upload pictures to my VPS, and he kept forgetting his password and getting locked out for a while.

It looks like it hasn't been updated in 2 years, but then again the iptables interface hasn't either, so no big deal.

I've used Fail2ban in the past:

http://www.fail2ban.org/wiki/index.php/Main_Page

http://www.fail2ban.org/wiki/index.php/Main_Page

That should cover automatic banning of repeat offenders. It works by reading logs, so it can work with many services. You could for example make it block all those attempting to exploit your CMSes.

Fail2ban or denyhosts activly target ssh. fail2ban includes rules for other services, but denyhosts includes a mechanism for sharing lists of your denied hosts w/ other admins, as well as using their ban lists to protect your ssh logins.

Fail2ban can do stuff that automatically!

All the systems I have access to or control myself allow only certificate+password logins (with
per-accessing-machine and per-user specific certificates for easy access management and revocation)
but will happily ask for a password on any certificate-less login attempt.
Also, remote root logins are completely disallowed.

Combine this with fail2ban and brute-force attacks of any kind are pretty much a non-issue.

I don't allow password-based logins either (SSH keys only), allow SSH only from specific IP addresses, and I use fail2ban across all services that involve any kind of authentication (mail, ftp, http auth, etc). I've got it set to "two strikes and you're out"; every day I still get hundreds (some days thousands) of IPs banned in the logs. It's pretty sad.

Use SSH keys in addition to passwords. Disable ssh root logins. Use the AllowUsers command in sshd_config to restrict what accounts can log in with ssh. Edit /etc/hosts.deny and add IP ranges for where you are unlikely to login from. Use iptables rules to block people who are hammering your ssh server from the same address. Use tools like Fail2ban and DenyHosts to block other abusers and share abuser information with other victims.

1. Disable root access: in /etc/ssh/sshd_config, set PermitRootLogin no
2. Disable password access (require ssh keys!): in /etc/ssh/sshd_config, set PasswordAuthentication no
3. Use an auto-banning solution like Fail2ban to limit attacking traffic and save bandwidth

SSH keys ensure that you're virtually immune to attacks, since the attack now MUST be brute-force (or break the RSA/DSA algorithms or compromise the server itself rather than an account), and must crack a "password" of over 150 base64 characters representing the 1024 bits of entropy in the key; a completely random printable password of 20 characters has 130 bits of entropy and an 8-word Diceware passphrase has only 120; you're not brute-forcing that.

Preventing root from accessing remotely is just smart (your logs can show who really logged in, your sudo logs show who needed root-level access and when, and you can auto-ban root logins immediately rather than after a set number of failed authentications).

All we're missing is the extension to #3 to handle distributed attack failures (as proposed by the parent post); with the proper protections, this is a bandwidth issue rather than a security issue (unless you're worried about DDoS, but we're talking about low-intensity attacks here).

For those of you stuck permitting passwords, you'll want something like John the Ripper to brute-force users' insecure passwords before the enemies do. This way you can disable their accounts when you find that they are vulnerable and force them to change their password to something more secure.

I use Fail2ban on all of my iptables-based SSH servers, as it eliminates the possibility of brute-force attacks from single IPs (fail2ban will ban any IP with five failed ssh logins in a ten minute period. The ban vanishes after ten minutes).

However, this new botnet attack distributes the attack over the IP-space and time. That bypasses fail2ban!

The only solution I can see to this would be to take an approach similar to the centralized spam-fighting solutions; a DNSBL specialized for brute-force botnets. You run something that monitors your logs for failed logins (with a large scope for time, say ten failed attempts in a month). When an IP triggers it, you block that IP for a month and report it to the DNSBL. The DNSBL operates like Spamcop, trying to verify the nature of the IP (and trying to address the issue), then adding it to the blocklist. Anything listed on a DNSBL gets permanently blocked after one failed authentication, and if your internal list grows too big, any positive IP gets blocked before the login attempt.

I hadn't heard of SSHguard, but I do use fail2ban.
Any thoughts on which is better SSHguard or Fail2ban ?

Does anyone know of a simple SSH honeypot that looks like a ssh server, but just logs the IP address, usernames and passwords that the robots are trying to use ?

Fail2ban is another nice way to deal with these brute force attacks.

I personally use http://www.fail2ban.org/wiki/index.php/Main_Page

First came exotic ports (as if using 922 instead of 22 was security -- it just throws off scripted attacks), then port knocking, and now this ?

Whatever happened to just plain good passwords (including a little helper for good measure), TCPWrappers, sensible firewalling and ssh private/public keys?

I could understand this type of security with more brittle services, things that can be hacked, but this is IMHO going way oervboard.

then you need fail2ban http://www.fail2ban.org
just in case they might eventually get lucky...

Fail2Ban http://www.fail2ban.org/

Use fail2ban, and regarding banning all of China, I didn't see getting more than average attacks from there, a lot of attacks are also from US IPs, this seems to be a worldwide issue.

Fail2Ban is also a great tool for banning repeated attacks against SSH, apache, etc. Its what I use.