hacking attempts

[dentartherdent]

You might consider a package called fail2ban (fail2ban.org), it bans IP addresses after X number of failed login attempts for a configurable amount of time. It can be configured to do many other things as well.

Alternately, or in addition there is an old project called labrea .. as in tar pits, it holds connections open for as long as possible, greatly slowing down brute force scanning/hacking attacks.

Cheers

 

[gmontalvo]

I recently opened port 22 on my router, so I could remotely access files. When I saw the daily security email with all the failed password attempts, I became alarmed (attached "hack attempts.txt" file shows logs). Searching the forums I found this thread.

I had already configured root to use an SSH key and disabled password logins (attached "root_config.png" file shows setup). Can I consider the setup reasonably secure as-is? Can the failed login attempts be safely ignored since I am using a public/private key?

Would it be a good idea to consider disabling password logins for every account I have created? If I do, would it break the CIFS shares for Windows clients?

Thanks in advance to any and all who offer their thoughts/ideas ...

 

[Milhouse]

Will you be using a "static" IP address when you connect remotely to your server? I'd just add some rules to your firewall/router so that only only known IP addresses can connect to port 22.

 

[pirateghost]

The simple solution is dont open up such a common port like 22. use just about anything else....forward to port 22 of your server.

 

[gmontalvo]

I'll be connecting when on the road, so there will be no way for me to know the address. Thanks for the idea though.

 

[Stephens]

The simple solution is dont open up such a common port like 22. use just about anything else....forward to port 22 of your server.

It really doesn't matter. There are "tools" that can scan a given IP address for open ports in seconds. I agree with moving off standard ports, but the truth is it's not much of a deterrent for any real hacker. If you're going to open your NAS up to the internet, you need a good firewall in between.

 

[cyberjock]

I'll be connecting when on the road, so there will be no way for me to know the address. Thanks for the idea though.

Use DYNDns...

 

[titan_rw]

Use DYNDns...

I think what he means is there is no way to know which ip he'll be logging in from, so there's no way to whitelist the ip in advance.

I assume he's already using some kind of dyndns in order to make the connection to freenas.

99% of ssh brute forcing will stop by not using port 22 on the internet facing side. You can leave freenas listening on port 22, so your internal ssh sessions continue as normal. Just forward a different port from the router to port 22 on the freenas ip.

If you really need to use port 22 internet facing, then I'd use some form of 'hammer protection'. I have a VM setup that gets internet port 22 redirected to it. It runs a perl script called 'blocksshd'. It uses iptables rules to block ip's that fail to authenticate after X amount of tries. It then also emails me about the attempt including a whois on the attacking ip. I can ssh into that VM, then ssh over to freenas if I needed too. I do not know how involved it would be to get that to work on freenas itself. Personally, I don't think it's a good idea for freenas to be accessible from the internet directly anyway. I'm more than happy to ssh into my network, then ssh to freenas's internal ip.

 

[gmontalvo]

I appreciate the really good comments - thanks guys! Closing port 22 and moving to a non-standard port is a good idea, and I've just completed the change. As others have said, it's not 100% fix because a port scanner could quickly find the new port assignment. Bad guys may not be bright enough to attempt a port scanner, but the possibility remains.

What would be really nice is if we could setup something in FreeNAS to timeout IP's after 'X' failed attempts. A 1 minute delay would not upset me if I fat-finger the password a few times, but would virtually kill any brute force attempt from a bot.

For reasons unrelated to this post/thread I'd been doing some legwork on brute force attacks. A reasonably equipped laptop could crack virtually any 6 character password over a weekend. 8 characters becomes much tougher, but ... A simple 1 minute delay in these kinds of attacks, would cause them to take years to try every combination (which feels much safer to me).

Experience has shown me that making yourself a harder target than someone else, tends to make bad guys seek out easier prey (and leave you alone). Again, it would be nice if we had something built-in and exposed through the Web UI that we could configure for our FreeNAS box. Remote access to the files on our NAS is a truly valuable feature - if we can do it with a reasonable level of security.

So ... for the community, the best we can do at this point is:
1. Disable password logins for root
2. Use PuTTYgen to create public/private keys, and logon via key exchange
3. Use a non-standard port

Is that a fairly accurate summary? Also, could that setup be considered 'reasonably' safe?

 

[cyberjock]

So ... for the community, the best we can do at this point is:
1. Disable password logins for root
2. Use PuTTYgen to create public/private keys, and logon via key exchange
3. Use a non-standard port

Is that a fairly accurate summary? Also, could that setup be considered 'reasonably' safe?

That's pretty much all I recommend without heavily altering FreeNAS. :)

 

[gmontalvo]

That's pretty much all I recommend without heavily altering FreeNAS. :)

Thanks cyberjock ... The discussion has been helpful for me, and I hope others find it useful as well.

 

[gmontalvo]

Figured I would close the loop on this one ...

I had been receiving 100's of attacks a day. Moving to a non-standard port has eliminated them (0 attacks since my last post). Thanks again to all who replied!

 

[SkyMonkey]

I would further suggest (though I am a newbie) that you login via a non-root user using an key pair nominally. You can always su if needed.

 

[HolyK]

I agree with steps/ways mentioned here (use non-standard port, disable root logging and use "sudo" instead, use key instead of password, use VPN, ... etc). The thing is, that everything will leave the system "visible" from the other side.

- Changing of the port will eliminate most of the bots checking 22port only, but some bots are scanning several ports or port ranges. Also lot of bots/programs are able to detect what kind of service is running on that port.
- Direct approach mostly begining with full port range scan (1-65565) so soon or later it will "find" open SSH port (if there is one)
- Strong password will increase the time of the brute-force cracking to be successful but if someone wants to launch dictionary or brute-force attack on your IP, then he could initiate parallel attack to speed up the process (like hundred or thousand tries each time, or even more if the attacker will use BotNet). Without proper anti-hammering protection (and even with it in case of botnet) on the system (or before), he could be successful.
- Using RSA keys instead of password is very good choice. It is strong protection against the pwd cracking but it will not protect the system against SSH lockout. Thing is that there is limitation how many ssh communication threads can be active in one way. If the attacker will keep sending thousand of the requests, even the authorized person could be unable to connect because of this. Also authorization-check process is more consuming than simple packet dropping.

So, there is a way how to add another layer of protection -> Let the system "disappear" by closing all of the ports out of the local network. But how to open port from outside and connect in case of need? Port knocking is the nice and easy way how to achieve this. The way how it works is very simple. It is "listening" on specific ports and if it detect specific activity on specific ports in specific order in specific time-frame ( :D ), it will open the port for that host who properly "knocked on the door".

Example:
-> SYN packet
--> On ports 2222, 45841, 3178, 3128, 12785 in this order exactly
---> In time frame 10sec
----> Will open port 20202 which is the SSH port for system
-----> For the IP from which the knocking come
------> for 5 hours, or until "closure" knocking sequence is received

Technically it works like this:
1] Firewall rule which will block any communication on port 20202
2] Knock daemon is silently listening incoming communication on specified port. If the first packet match, its expecting next one. If next packet is not the right one or the time is exhausted, it will reset the time.
3] If the knocking sequence is successful, knock daemon will add another firewall rule BEFORE the "blocking" in which will allow incoming connection on port 20202 from IP from which the correct knocking was received. This will allow SSH connection.
4] After the time is expired, or if the "closure" knocking is received, knock daemon will remove that temporary rule and the system is again "closed"

So, when the system is "closed", a full port scan will return that no SSH port is OPEN -> No way how to even try to connect via SSH

For the knocking itself, there are lot of application for windows, linux, android, iphone, MacOS, ... etc. all over the net. Check this for example and also for detailed info about configuring the knock daemon, etc...

NOTE:
- Port knocking is not the replacement of the security, it is just additional protection layer!!!
- It is NOT bullet proof. Best scenario is if there is no another "online" service on the system - NO port is open and system is DROPPING (instead of denying) all incoming connection. It looks like there is NOTHING interesting behind that IP. If there are another services like apache, https, etc ... It could be like "Aaaah, maybe there iiiis somethiiiing and its just hidden!"
- If the attacker is on same network like the knocker, he could sniff packets and reveal knocking sequence to pass this protection. Another danger is IP spoofing. Both of these could be eliminated by hashed port-knocking sequence.
- If the knock daemon crash, there is simple no way how to "open" the port from the outside, so some kind of monitoring which will restart the knockd in case of crash. Or another way how to access the system and restart daemon)
- In some cases the knocking sequence could arrive in wrong order or some of the packets could get lost, which will make the knocking as failed attempt.

Good thing: There is FreeBSD knock daemon
Bad thing: It is not present in FreeNAS version.


If someone does not like the disadvantages or if he is much more paranoid, there a similar, but much more robust (and also a bit complex) way which is SPA.

Holy

 

[cyberjock]

As another alternative you could use a VPN and something like DynDNS if you have a non-static IP.

 

[ProtoSD]

There's also blackholes:

http://www.unix.com/man-page/FreeBSD/4/BLACKHOLE/