hacking attempts

[creepwood]

I'm getting emai reports of entities trying to brute force their way into my freenas through SSH (I think it is atleast)

Code:

freenas.local login failures:
Jul 28 00:52:15 freenas sshd[84028]: Failed password for root from 174.127.127.165 port 54278 ssh2
Jul 28 00:52:16 freenas sshd[84030]: Failed password for root from 174.127.127.165 port 54407 ssh2
Jul 28 00:52:18 freenas sshd[84032]: Failed password for root from 174.127.127.165 port 54575 ssh2
Jul 28 00:52:19 freenas sshd[84034]: Failed password for root from 174.127.127.165 port 54692 ssh2

Today there were thousands of tries. It makes me uneasy, but I would still like to have my ssh open for me to connect through. Is there any option of making the server block connections from en IP when it fails three times? Or any other kind of measure to stop this from happening?

 

[ProtoSD]

I can't seem to find it now, but *somewhere* I thought I saw a screen where you could Allow or Deny access from certain networks....

 

[creepwood]

Thanks for your reply. Blocking networks is not really an option if its not done automatically. I connect from a variety of different networks and I rather not block them manually one by one when they're already done with their attempts.

 

[matthewowen01]

first, don't let root login through ssh. Never Ever Ever Ever allow root to log in though ssh. then it's not a problem, they need to guess your user name And password.

you can also disallow passwords and go with keys instead, Very secure.

 

[ReggiePerrin]

I assume your NAS is behind a firewall and you're port forwarding SSH traffic to it, and that you're doing this to allow offsite access to the NAS. Might I suggest a better way, if your firewall supports it, is to setup a VPN connection to your firewall and then SSH through this to the NAS (two lines of defense is better than one).

edit:-

If you're port forwarding, then 174.127.127.165 might be the LAN address of your firewall (NAT), so if you block after x number of failed attempts you'll be blocking all remote access (it's been a while since I mucked around with firewalls so this might be wrong??).

 

[creepwood]

I assume your NAS is behind a firewall and you're port forwarding SSH traffic to it, and that you're doing this to allow offsite access to the NAS. Might I suggest a better way, if your firewall supports it, is to setup a VPN connection to your firewall and then SSH through this to the NAS (two lines of defense is better than one).

edit:-

If you're port forwarding, then 174.127.127.165 might be the LAN address of your firewall (NAT), so if you block after x number of failed attempts you'll be blocking all remote access (it's been a while since I mucked around with firewalls so this might be wrong??).

The NAS is Behind a firewall and there is just a simple port forwarding/virtual server configured in the router. Think it's port 22 which makes me wonder what all the ports listed in the log is about.

But VPN is actually an interresting way which I'm going to explore more. I'm on vacation atm. I turned off SSH through the webGUI off site (which is probably also bad that you can access the gui from the outside)

 

[creepwood]

first, don't let root login through ssh. Never Ever Ever Ever allow root to log in though ssh. then it's not a problem, they need to guess your user name And password.

you can also disallow passwords and go with keys instead, Very secure.

Oh thank you. Just to be sure, where is the setting to block root login? I'm looking at the user list and there is no options for the preset system users. And I checked the settings for SSH where there is a setting for "Login as root with password" which is set to off.

 

[ProtoSD]

The one that you just said was set to 'off' is the one that should be disabled.

 

[matthewowen01]

A vpn is overkill. Everything you want to can be done through ssh and be much more secure than pptp.

The root login can be found in the ssh config page.

 

[cbray]

Any impact of FreeBSD Bind security issue on FN8?

Not to hijack this thread; sorry you got me wonderin' and I looked at security advisories from FreeBSD and saw this as recent as: 05-28-2011

Could this Security Issue regarding Bind affect FN8?

From www.freebsd.org
Quotes from Freebsd Security Advisory.
Found here: http://security.freebsd.org/advisories/FreeBSD-SA-11:02.bind.asc

Affects: All supported versions of FreeBSD

FreeBSD-SA-11:02.bind Security Advisory

I. Background

BIND 9 is an implementation of the Domain Name System (DNS) protocols.
The named(8) daemon is an Internet Domain Name Server.

DNS Security Extensions (DNSSEC) provides data integrity, origin
authentication and authenticated denial of existence to resolvers.

II. Problem Description

Very large RRSIG RRsets included in a negative response can trigger
an assertion failure that will crash named(8) due to an off-by-one error
in a buffer size check.

III. Impact

If named(8) is being used as a recursive resolver, an attacker who
controls a DNS zone being resolved can cause named(8) to crash,
resulting in a denial of (DNS resolving) service.

DNSSEC does not need to be enabled on the resolver for it to be
vulnerable.

For Creepwood, are you in Providence Utah at ip 174.127.127.165 ? Know anyone in Utah? Didn't think so...
If your router is wireless, you may have an intruder already connected behind your firewall. Or possibly another of your machines is already compromised.

My 2 cents...:(

 

[matthewowen01]

For Creepwood, are you in Providence Utah at ip 174.127.127.165 ? Know anyone in Utah? Didn't think so...
If your router is wireless, you may have an intruder already connected behind your firewall. Or possibly another of your machines is already compromised.

My 2 cents...:(

the log files do not assert any anything about a current breach. All the log says is some outside computer is trying to connect via ssh as the user root and getting the password wrong. The main issue is root logins are enabled, they should not be enabled, ever.

it's just some owned windows box in utah. sop allowing root to login remotely and everything will be fine.

 

[creepwood]

For Creepwood, are you in Providence Utah at ip 174.127.127.165 ? Know anyone in Utah? Didn't think so...
If your router is wireless, you may have an intruder already connected behind your firewall. Or possibly another of your machines is already compromised.

My 2 cents...:(

Of course a computer on the inside can be compromised. However, it's only my user that have write access to the NAS. I'm unsure if your comment in condescending or what you mean by it. To not do what I can do minimize the risk seem odd?

My WiFi access is probably not an issue since our WPA2 key is 30+ random letters and sign, only a user with access to the key would have access to the WiFi. I'm not ignorant to risk, a cipher is only as safe as the key is.

No Local IP's have shown up in the logs, I feel safe there. it's only foreign IP's that shows up

 

[cbray]

CW, Sorry if you thought my post was condescending. It was not meant in that way.
There are many people here without experience in router or network configuration or security, so I was just trying to be helpful, and in no way meant to be hurtful toward you.
I am sorry if my post offended you.

Peace,
CB

 

[tmacka88]

Hacker?

Hey I just received my email notification from freenas this morning and noticed lots of freenas.local login failures:

Sep 24 02:05:22 freenas sshd[20700]: Invalid user oracle from 81.18.148.190
Sep 24 02:05:22 freenas sshd[20700]: Failed password for invalid user oracle from 81.18.148.190 port 53814 ssh2
Sep 24 02:05:26 freenas sshd[20702]: Invalid user test from 81.18.148.190
Sep 24 02:05:26 freenas sshd[20702]: Failed password for invalid user test from 81.18.148.190 port 54123 ssh2
Sep 24 02:05:29 freenas sshd[20704]: Invalid user apache from 81.18.148.190

there were 100's. Is this someone trying to hack into my system? If so how have they found my system so easy when I only just set up SSH SFTP two days ago?

What should I do so they can not get access to my info? I don't necessarily want to turn my SSH off cause then it defeats the purpose of having it. I want to use it.

ssh setting on freenas: (all of these are ticked should I unstick any of these? if so what function will I lose by doing so)

Login as Root with password
Allow Password Authentication
Allow TCP Port Forwarding


Thanks

 

[Durkatlon]

Well, do you really need the ssh to be accessible from the Internet? If you must and you don't want these dictionary scripts to keep knocking on your door, I'd move the ssh service to a different port (some non-standard high port). That will at least limit the chances of this happening. That said, this is basically "normal" when you expose ssh to the Internet on port 22.

 

[tmacka88]

hey I'm having the same issue with someone trying to hack into my freenas. In this thread sorry for starting a new one didn't been to.
http://forums.freenas.org/showthread.php?2553-Hacker&highlight=hacker

is there a code to enter into ssh to get the logs up to display this below from my email notification.
freenas.local login failures:
Sep 24 02:05:22 freenas sshd[20700]: Invalid user oracle from 81.18.148.190
Sep 24 02:05:22 freenas sshd[20700]: Failed password for invalid user oracle from 81.18.148.190 port 53814 ssh2
Sep 24 02:05:26 freenas sshd[20702]: Invalid user test from 81.18.148.190
Sep 24 02:05:26 freenas sshd[20702]: Failed password for invalid user test from 81.18.148.190 port 54123 ssh2
Sep 24 02:05:29 freenas sshd[20704]: Invalid user apache from 81.18.148.19

I have disabled root login.
How can i ake this more secure e.g key. How do you set these up?

thanks

 

[joeschmuck]

I had a similar thing happen last week, just some random attack that last only a few seconds. They were probably using default passwords for various systems, not necessarily FreeNAS at all. My NAS FTP is the only thing exposed to the internet but I could swear it was an ssh error message. No biggie, guess I'll ensure root cannot log in as well. Better safe than sorry.

 

[louisk]

I don't understand the advice to move ssh to a different port, port scanners make this effort essentially a waste of time. I think you'd be better off to disallow passwords on ssh and be restricted to ssh keys. Then the person logging in is required to have the key. Password becomes irrelevant, and you can essentially ignore these lines.

That said, I would strongly consider not allowing any direct access to your NAS from the internet. If you need remote access, use a tool designed for the job such as a VPN.

 

[ProtoSD]

I agree with Louisk, also disable this setting 'Login as Root with password'. Login with a regular account and use 'su'.

 

[Durkatlon]

Agreed on previous points regarding password logins etc.

However, moving ssh to a high port (50000 or whatever) will definitely help. In principle port scanners would defeat this of course, but in practice it is very unusual for a port scan to actual scan all the ports on a system, unless the hacker was specifically targetting that particular machine.

More than likely the script used to do this attack is simply looking at port 22 in a large subnet, instead of all 65535 ports on a particular machine. Much too time-consuming. I run ssh on multiple ports, leading to different machines on my internal network. Only the one on port 22 sees dictionary style attacks. The others are completely quiet.

Similarly I run websites on high ports instead of on port 80. None of these ever sees "random" traffic and hack attempts, even though the machine the server runs on has a domain name pointing to it.