Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Modify Remote Login server to block scripted attacks Network
I rely on SSH (Remote Login in Sharing prefs) quite a bit to work on my desktop machine from my laptop and vice-versa. Tonight, I was browsing the system log while trying to find the cause of another (VNC related) issue. I was quite shocked to find the following entries:
Feb 10 07:07:36 localhost sshd[1078]: Illegal user matt from 210.127.248.158
Feb 10 07:07:38 localhost sshd[1080]: Illegal user test from 210.127.248.158
Feb 10 07:07:40 sshd[1082]: Illegal user operator from 210.127.248.158
Feb 10 07:07:42 sshd[1084]: Illegal user wwwrun from 210.127.248.158
Feb 10 07:07:52 sshd[1096]: Illegal user apache from 210.127.248.158
Feb 10 07:07:59 sshd[1104]: Failed password for root from 210.127.248.158 port 58752 ssh2
Feb 10 07:08:01 sshd[1106]: Failed password for root from 210.127.248.158 port 59136 ssh2
Feb 10 07:08:03 sshd[1108]: Failed password for root from 210.127.248.158 port 59176 ssh2
Feb 10 07:08:15 sshd[1122]: Failed password for root from 210.127.248.158 port 60606 ssh2
....
These entries went on and on and on ... over 100 of them in a three minute time period this morning (notice them hitting the logs every two seconds)! So I loaded the entire system log, which goes back to January 24th. There were nearly 1,000 entries! So clearly, somewhere out there, there's an SSH brute-force exploit script (I run no real "servers" at home, just Remote Login and Personal Web Sharing, but that's blocked at my router). Just from reading the log files, it's pretty obvious that the script is trying common user names, and probably common passwords for the root account. Needless to say, this didn't make me feel very comfortable at all, even though my passwords are secure.

While OS X may not be vulnerable to viruses and malware, it's still quite vulnerable to external attacks from zombied machines running scripts such as this one. So I used the fact that my machine was being probed as an incentive to learn more about increasing the security of my Remote Login sessions. What I found out was that, though SSH is quite secure, there are some simple things you can do to make it even more secure (though there is a downside, as you'll see). Read the rest of the article to see how I hardened my Remote Login setup.

Disclaimer: I am not an expert at this stuff. I'm not even really an amateur. I read various sites, tested stuff, and it all seemed to work and do what I wanted it to do. Your mileage may vary, and I make no guarantees that these changes will 100% secure your Remote Login capabilities ... but I think they're a good start!

I was reasonably confident that my machine wouldn't fall to a username/password brute force attack (I have a secure password and a username that won't be in a standard "first name only" attack). However, the root login attempts concerned me more -- although I have a secure root password as well, I do have root enabled. A longgggg time ago, we ran a hint on how to Disable root access via SSH. At the time (10.0.1!), I had followed the hint and blocked root SSH logins. Somehwere between 10.0.1 and 10.3, including a machine migration, I lost it and had never put it back. This really should be disabled by default, but it's not ... so the first step to further securing Remote Login is to re-block root logins. The instructions in the original hint are still basically true, but somewhat non-detailed, so here's a step-by-step walkthrough.

Open the Terminal, and type cd /etc and press Return. The first thing to do is make a backup of the file we're going to modify, so type:
sudo cp sshd_config sshd_config.bak
Enter your password when prompted, and you'll have created a backup of the sshd_config file. This file contains the settings for the process (sshd) that runs the Remote Login service. The next step is to edit this file; pico is the friendliest editor for Terminal newcomers, as it has a nice menu at the bottom of the screen covering most of the basic functions. You'll need to have root privileges to edit the file, so type sudo pico sshd_config and press Return.

First, as long as you're in the file, find this line:
#Protocol 2,1
Remove the # at the beginning (it's a comment marker), and then remove the ,1 at the end. This will disable the SSH1 version of the SSH protocol -- it's my understanding that version one is less secure than version two (SSH2), so you might as well disable it (most newer operating systems will use SSH2 anyway). Next, find the line that reads:
#PermitRootLogin yes
(You can use Control-W and type Root to search for it.) Again, remove the #, and change yes to no. This will disable root login via SSH. That takes care of one potential hole. Save the file (Control-O, then press Return to confirm), and quit the editor. Open the Sharing panel in System Preferences, then stop and restart Remote Login to restart the sshd server. Presto, one hole closed.

The next thing I did is somewhat more complex. One feature of SSH allows password-free logins. Although this sounds insecure, it's actually a more secure way of making a remote connection, as only machines which have previously given a piece of information to the server will be allowed to connect. The piece of information is called a public key, and it's specific to the machine that generated it. In addition to the public key, your machine (the one that's connecting to the server) has its own private key, which is not shared. The private key generates something called a signature, which can then be paired with your public key to prove you are who you say you are -- only your private key can generate that particular signature. So in essence, when you connect, the server says "Ah, I have your public key. Please send me your signature." Your machine does so, and the server then compares them -- if the signature "checks" agains the public key that it knows, you're confirmed. (Note to technical types: this is my best explanation of the process, and it's probably wrong at some level. Please feel free to clarify.)

So by setting up public key authentication for Remote Login, you can actually create a more secure connection method than passwords -- as there are no passwords to guess, and nobody can fake your signature. The downside is that setting this up is a bit of a pain, as you have to create the public key, and then get it to the machine you wish to connect to. I wrote up a very detailed hint a while back that explained the process. (You can ignore the SSH1 instructions in that hint, assuming you're disabling SSH1 anyway as shown above.) Also read the comments to the hint that discuss some of the security implications -- using my method (no passphrase required), if your machine gets out of your hands, whomever has it will be able to connect to your SSH hosts without any passwords. This hint explains a way to tie this all in to a Keychain password, for some added security.

Important: The remainder of this hint assumes you have public key SSH authentication working on each of the machines you'd like to connect to/from. Do not follow the rest of this hint unless that is the case!

OK, so you're still here ... the last step in the securing of Remote Login is also the one with the biggest downside. Just because you've enabled public key authorization doesn't mean you've disabled password authorization. In fact, you haven't. You can still easily login with your username and password from any other machine that uses SSH. So the final step is to completely disable password-based Remote Login access. The downside of this is that you will only be able to connect from machines that have previously provided their public keys to the server. This is fine if you're always traveling with your laptop. It's not so great if you've got to use a lab of public machines, or you're renting some computer time in an airport, etc. Personally, I was willing to give up this flexibility for a bit of added security, but you'll have to make this decision for yourself.

To disable password-based logins, re-edit the sshd_config file (using su, as before). This time, you're looking for two lines in one section of the file:
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
Change this section so it looks like this (only two lines changed):
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no
Save your changes, quit the editor, and restart Remote Login again. After making these changes, I then tried various SSH connections. First, I asked to connect as root:
$ ssh -l root 10.0.0.10
Permission denied (gssapi,publickey)
On the server (the machine I'm connecting to), the system log (edited for narrowness) showed this:
Feb 10 21:26 xinetd[397]: service ssh, IPV6_ADDRFORM setsockopt() failed:
 Protocol not available (errno = 42)
Feb 10 21:26 xinetd[397]: START: ssh pid=1425 from=10.0.0.20
Next, I connected using the public key that I had set up on the server:
$ ssh -l robg 10.0.0.10
Last login: Thu Feb 10 21:15:14 2005 from 10.0.0.20
Welcome to Darwin!
[G5_box]$
Perfect again. The log this time showed this:
Feb 10 21:28 sshd[1427]: Accepted publickey for robg from 10.0.0.20 port 55555 ssh2
Finally, I went to another machine that has not yet shared its public key, and tried to connect:
$ ssh -l root 10.0.0.10
Permission denied (gssapi,publickey)
So I wasn't even allowed to try a password (which will kill the brute force script, since it sends the password after sending a username), and the system log showed the same entry as when I tried to connect as root. There's now no way this script can make a real connection to my machine. I gave up a bit of time (it took more time to write this hint than to modify sshd, actually), and a bit of convenience (as I can no longer use Remote Login from just anywhere). But I will now sleep much better, knowing my machine is safe from this particular script attack.
    •    
  • Currently 3.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[46,067 views]  

Modify Remote Login server to block scripted attacks | 54 comments | Create New Account
Click here to return to the 'Modify Remote Login server to block scripted attacks' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Modify Remote Login server to block scripted attacks
Authored by: legacyb4 on Feb 11, '05 01:13:09AM

Don't forget that you can also add the:

AllowUsers [yourname(s)]

line which will limit SSH connections to your account(s) only.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: wgscott on Feb 11, '05 01:16:30AM
Two more things that can only help are to use TCPwrappers and the IPFW firewall. describes how to get TCPwrappers going. is (uncrippled) shareware that is a nice GUI for IPFW: One security hole I plugged is that I have to connect insecurely to a POP3 server that forced me to send that password in clear text. I made SSH tunnels to solve that problem and described that . HTH someone. My SGIs would get broken into on a regular basis. OS X is more secure than Irix, but nothing is really secure. Thanks for posting this hint. Its importance cannot be over-stated.

[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: tinker on Feb 12, '05 02:03:13AM
I actually posted a hint a while back about using TCP wrappers to prevent unauthorized SSH access, while allowing for access from machines with dynamic IP addresses. It's here. Since then I've set up GeekTool to check my system log and display any intrusion attempts that have happened in the last hour. Believe me, there are a lot of them.

Out of curiosity I checked my system logs and found lots of stuff like this:


Feb 11 20:44:41 wfc xinetd[340]: service ssh, IPV6_ADDRFORM setsockopt() failed: Protocol not available (errno = 42)
Feb 11 20:44:41 wfc xinetd[340]: START: ssh pid=5015 from=203.75.172.19
Feb 11 20:44:41 wfc xinetd[5015]: libwrap refused connection to ssh (libwrap=sshd-keygen-wrapper) from 203.75.172.19
Feb 11 20:44:41 wfc xinetd[5015]: FAIL: ssh libwrap from=203.75.172.19
Feb 11 20:51:50 wfc xinetd[340]: service ssh, IPV6_ADDRFORM setsockopt() failed: Protocol not available (errno = 42)
Feb 11 20:51:50 wfc xinetd[340]: START: ssh pid=5582 from=203.75.172.19
Feb 11 20:51:50 wfc xinetd[5582]: libwrap refused connection to ssh (libwrap=sshd-keygen-wrapper) from 203.75.172.19
Feb 11 20:51:50 wfc xinetd[5582]: FAIL: ssh libwrap from=203.75.172.19
Feb 11 22:04:14 wfc xinetd[340]: service ssh, IPV6_ADDRFORM setsockopt() failed: Protocol not available (errno = 42)
Feb 11 22:04:14 wfc xinetd[340]: START: ssh pid=10977 from=195.151.121.132
Feb 11 22:04:14 wfc xinetd[10977]: libwrap refused connection to ssh (libwrap=sshd-keygen-wrapper) from 195.151.121.132
Feb 11 22:04:14 wfc xinetd[10977]: FAIL: ssh libwrap from=195.151.121.132

So, for what it's worth, it's refusing quite a few connections.

I know that this sort of thing is not especially new and that we don't have much to fear from it, but that doesn't mean that we won't have anything to fear from the next SSH exploit. Better safe than sorry.

[ Reply to This | # ]

filter out IPv6 errors
Authored by: gatorparrots on Feb 13, '05 01:40:15PM
You will see this type of error:
Feb 11 20:51:50 wfc xinetd[340]: service ssh, IPV6_ADDRFORM setsockopt() failed: Protocol not available (errno = 42)
If you have edited /etc/hostconfig and set IPV6=-YES- to IPV6=-NO- If this surmisation on my part is correct, you may want to include a line in your GeekTool chain that filters out these errors:
| grep -v "IPV6_ADDRFORM setsockopt() failed: Protocol not available"

[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: gorefest on Feb 13, '05 11:36:22AM

you don't need to use a firewall to block certain hosts on ssh.
sshd_conf does it for you also...

DenyUsers *@host


I wish apple would update to openssh 3.9 then you could use
MaxAuthTries to limit the login tries...



[ Reply to This | # ]
UI version to modify those settings...
Authored by: aamann on Feb 11, '05 01:33:50AM
For the less command-line inclined people out there, there is a UI program which allows to to make most of those changes (and lets you create passkeys as well):

SSH Helper



[ Reply to This | # ]
Don't forget xinetd can help as well
Authored by: stetner on Feb 11, '05 02:01:34AM

I also use xinetd to refuse connections from machines I don't know:

$ cat /etc/xinetd.d/ssh
service ssh
{
...
only_from = xxx.xxx.0.0/16 xxx.xxx.xxx.0/24 xxx.xxx.xxx.xxx
log_on_success += DURATION HOST USERID
log_on_failure += HOST USERID
}

So you can limit it to particular hosts, subnets etc. And log those successes and failures.



[ Reply to This | # ]
meow
Authored by: gatorparrots on Feb 13, '05 01:50:54PM
Real Security is a looong key!
Authored by: toonerh on Feb 11, '05 04:09:42AM

I only allow shh 2.0 login's from machines I have given my 2048 bit public (actually fairly secret) DSA key, plus pass phrase and user/password. I may be a little paranoid, but most simple password ssh 1 or 2 authentications are easy prey for today's brute force attacks.

...Rest easier, that SOB about to install a rootkit on your Mac is busting his balls trying to crack by 2048 bit DSA key - I love to watch them fail :-)

Tom



[ Reply to This | # ]
I had the same sshd attack 8th of February! Thanks
Authored by: mathieubill on Feb 11, '05 05:11:00AM
Hello,
Your post helped me very much:
First, after reading your post, I browsed my system logs too and I was very surprised to discover that I had the same type of attacks as yours and in the same period (8th of February):

Feb  8 19:41:23 sshd[1535]: Illegal user test from 218.153.147.92
Feb  8 19:41:28 sshd[1538]: Illegal user guest from 218.153.147.92
Feb  8 19:41:33 sshd[1540]: Illegal user admin from 218.153.147.92
Feb  8 19:41:43 sshd[1545]: Illegal user user from 218.153.147.92
Feb  8 19:41:50 sshd[1547]: Failed password for root from 218.153.147.92 port 57640 ssh2
etc.
Then with your advice and the AllowUsers command, I secured my sshd as much as I could.
So your advice arrived just in time!
Thanks once again.

[ Reply to This | # ]
Just in time? For what?
Authored by: daveschroeder on Feb 11, '05 01:20:21PM

This is a **very old** SSH attack. This has been going on for almost a year, and we see it on every machine we administer that has SSH enabled. All it does is try common username/password pairs for names and role accounts. If you have good password security, there is nothing to worry about. Is more security ever bad? Absolutely not; by all means, secure your machine as much as practical. But this is not some kind of "new" attack, and would not compromise any OS X machine in its default configuration with ssh enabled if accounts have reasonable passwords, i.e., not test/test, firstname/firstname, etc. That's all this script does.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: max_zorn on Feb 11, '05 08:10:41AM
Naive question: Where is the system log?

Cheers, Max

[ Reply to This | # ]

Modify Remote Login server to block scripted attacks
Authored by: remolinero on Feb 11, '05 08:20:44AM

I suffer the same problem a time ago... So i have forwarded the SSH port to a very-not-standard port at my firewall (say 51422). I think it is possible to do this in the Mac, too.
This make almost impossible a login from a client that doesn't know the port used and reduced, in my case, the attempts of illegal login to 0.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: thiophene on Feb 11, '05 09:17:46AM

try /var/log/system.log



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: robg on Feb 11, '05 10:28:58AM
Launch Console, then click on Logs in the Toolbar, then click system.log.

You can then use the filter field (top right of toolbar) to find the sshd-related activity; just type sshd into it, and you'll see only the Remote Login-related activity.

You could filter even more directly by looking for either Illegal user or Failed password. That's what I wound up doing.

-rob.

[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: max_zorn on Feb 11, '05 11:32:03AM

Hello Rob and thiophene,

thanks a bunch!

Cheers,

Max



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: eagle on Feb 11, '05 09:04:59AM

Another thught would be to use ipfw to control access to the ssh service, allowing access only from trusted networks. I used to get hundreds of these attempts per day until I did that. As you might expect, since I locked down my server to trusted networks, I have yet to have a single illegitimate login attempt.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: robg on Feb 11, '05 09:35:59AM

That's a great solution, as long as you access from trusted networks all the time. My problem is that I travel a fair bit, and I'm often in some hotel or Internet-capable convention center, and need to find something on the home machine...

-rob.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: timrand on Feb 11, '05 09:58:07AM

I, too, had access attempts. There appears to be something to this. Pay attention folks!

Try this from your command line: grep sshd /var/log/system.log Review the lines for stuff like what shows up in my list below. I see attempts to access common accounts and dummy accounts such as "nobody". I have chosen to include the offending IP addresses so everyone is aware of potential sources of these attacks.

Jan 31 16:24:24 My_Machine sshd[2109]: Did not receive identification string from 66.15.145.131
Jan 31 16:28:38 My_Machine sshd[2110]: Illegal user jordan from 66.15.145.131
Jan 31 16:28:38 My_Machine sshd[2110]: reverse mapping checking getaddrinfo for
 bdsl.66.15.145.131.gte.net failed - POSSIBLE BREAKIN ATTEMPT!

Jan 31 16:30:15 My_Machine sshd[2218]: Illegal user pub from 66.15.145.131
Jan 31 16:30:15 My_Machine sshd[2218]: reverse mapping checking getaddrinfo for
 bdsl.66.15.145.131.gte.net failed - POSSIBLE BREAKIN ATTEMPT!
Feb  1 15:24:02 My_Machine sshd[2602]: Did not receive identification string from 210.100.255.3
Feb  1 15:33:27 My_Machine sshd[2603]: User nobody not allowed because shell /dev/null is not executable
Feb  1 15:33:29 My_Machine sshd[2605]: Illegal user patrick from 210.100.255.3
Feb  1 15:33:32 My_Machine sshd[2607]: Illegal user patrick from 210.100.255.3
Feb  1 15:33:34 My_Machine sshd[2609]: Failed password for root from 210.100.255.3 port 42075 ssh2
Feb  1 15:33:37 My_Machine sshd[2611]: Failed password for root from 210.100.255.3 port 43794 ssh2
Feb  1 15:33:48 My_Machine sshd[2620]: Illegal user rolo from 210.100.255.3
Feb  1 15:33:51 My_Machine sshd[2622]: Illegal user iceuser from 210.100.255.3
Feb  1 15:33:53 My_Machine sshd[2624]: Illegal user horde from 210.100.255.3
Feb  1 15:33:56 My_Machine sshd[2626]: Failed password for cyrus from 210.100.255.3 port 52386 ssh2
Feb  1 15:33:58 My_Machine sshd[2628]: User www not allowed because shell /dev/null is not executable
Feb  1 15:34:01 My_Machine sshd[2630]: Illegal user wwwrun from 210.100.255.3
Feb  1 15:34:03 My_Machine sshd[2632]: Illegal user matt from 210.100.255.3

Feb  1 15:36:51 My_Machine sshd[2768]: Illegal user webmaster from 210.100.255.3
Feb  1 15:36:54 My_Machine sshd[2770]: Illegal user data from 210.100.255.3
Feb  1 15:36:56 My_Machine sshd[2772]: Illegal user user from 210.100.255.3
Feb  1 15:36:59 My_Machine sshd[2774]: Illegal user user from 210.100.255.3
Feb  1 15:37:01 My_Machine sshd[2776]: Illegal user user from 210.100.255.3
Feb  1 15:37:03 My_Machine sshd[2778]: Illegal user web from 210.100.255.3
Feb  1 15:37:06 My_Machine sshd[2780]: Illegal user web from 210.100.255.3
Feb  1 15:37:08 My_Machine sshd[2782]: Illegal user oracle from 210.100.255.3
Feb  1 15:37:10 My_Machine sshd[2784]: Illegal user sybase from 210.100.255.3
Feb  1 15:37:12 My_Machine sshd[2786]: Illegal user master from 210.100.255.3
Feb  1 15:37:15 My_Machine sshd[2788]: Illegal user account from 210.100.255.3
Feb  1 15:37:22 My_Machine sshd[2794]: Illegal user adam from 210.100.255.3

Feb  1 15:37:31 My_Machine sshd[2802]: Illegal user henry from 210.100.255.3
Feb  1 15:37:33 My_Machine sshd[2804]: Illegal user john from 210.100.255.3
Feb  1 15:37:36 My_Machine sshd[2806]: Failed password for root from 210.100.255.3 port 60520 ssh2
Feb  1 15:37:46 My_Machine sshd[2814]: Failed password for root from 210.100.255.3 port 38468 ssh2
Feb  1 15:37:49 My_Machine sshd[2816]: Illegal user test from 210.100.255.3
Admin: Commented edited to narrow display; no content was changed

[ Reply to This | # ]
This is OLD NEWS
Authored by: daveschroeder on Feb 11, '05 01:17:01PM

There is nothing "to this". This is a super old SSH attack that has been going around for almost a year. It simply tries username/password pairs for common first names and common role accounts. You are NOT VULNERABLE to this attack if you have strong passwords set on your account(s).

Also, there are HUNDREDS of hosts that are probably running scripts like these, right now, and many more that have been compromised over time. So while interesting, knowing the source is not valuable on a general scale. They're just other compromised machines themselves (usually).

Now, yes, it's good to secure your machine as much as possible. But ordinary Mac OS X users who have ssh enabled with decent passwords will NOT be vulnerable to this attack. You might have dozens, hundreds, or even thousands of these log entries. We see this ALL THE TIME on all of our UNIX servers; it's nothing new and nothing to worry about if you have good password security.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: chko on Feb 11, '05 01:52:25PM
You can also use:

zgrep sshd /var/log/system.log.x.gz

Where x is a number (like 0, 1, 2, ...). This will allow you to see SSH activity on older rotated logs.

[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: j-beda on Feb 11, '05 10:07:21AM
The downside of this is that you will only be able to connect from machines that have previously provided their public keys to the server. This is fine if you're always traveling with your laptop. It's not so great if you've got to use a lab of public machines, or you're renting some computer time in an airport, etc. Personally, I was willing to give up this flexibility for a bit of added security, but you'll have to make this decision for yourself.

You might be able to carry along a USB drive or key fob or something like that with the necessary PGP keys.

[ Reply to This | # ]

Modify Remote Login server to block scripted attacks
Authored by: drush on Feb 11, '05 11:20:03AM

The best place to keep your key is on your new iPod Shuffle. Always handy that way.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: tinker on Feb 12, '05 02:05:39AM

That's utterly brilliant. Thanks.



[ Reply to This | # ]
Change ssh to obscure port
Authored by: buxtor on Feb 11, '05 10:24:07AM

Another method that helped me dodge those attacks (~100+ attacks per day!) is changing the remote login port from 22 to something very obscure, say something with 4-5 digits. (Just be sure that it's a port you don't currently use for anything else.)

The easiest way to do that is to use Port Forwarding in your router like so:
External Port: 8085 --> Internal Port: 22 IP: (Your mac's ip)

This tells the router to send any traffic from 8085 to your Mac on port 22.

That way, portscanners will skip right over the default ssh port of 22. But remember, when you want to login, you have to specify the port as follows:
ssh -p 8085 user@somewhere.com



[ Reply to This | # ]
Change ssh to obscure port
Authored by: kray on Feb 11, '05 11:48:15AM

Exactly what I was going to say (use a different port). In the Linux world changing the sshd_config file does the trick -- in the Mac world it's a little bit more involved (editing /etc/services). I've done this on all my system and have watched thousands of attempts go un-routed at the firewall.

I like your idea better (for the novice) as I've seen Mac updates re-write my sshd_config and services file on many of the updates (though the last system update [10.3.8] didn't :).

Also changing ssh_config to use a specific port allows you to use ssh "as-is" without the need to always specify the port -- which is nice when you use scp which uses the -P flag and not the -p flag [annoying].

Of course YMMV



[ Reply to This | # ]
Change ssh to obscure port
Authored by: robg on Feb 11, '05 01:12:53PM

Great idea; I'll add that to the body of the main hint tonight. I thought about including the instructions to really re-map sshd's port, but that's a real pain to do (and as the other commenter noted, it can be undone by upgrades).

Thanks;
-rob.



[ Reply to This | # ]
obscure port unaffected by system updates
Authored by: gatorparrots on Feb 13, '05 02:01:11PM
I've been doing this since 10.1 (then the change was simply made in /etc/sshd_config). None of the point updates have undone this change (affected under xinetd in both /etc/services and /etc/xinetd.d/ssh. Apple has seen fit to leave those two files alone through the duration of the point upgrades (10.2-10.2.8, 10.3-10.3.8). Of course, I have done fresh installs of each of the major point releases (10.2, 10.3) and just make the SSH port change as part of my installation routine. In this case, I do indeed believe that there is a lot of peace and rest to be found in "security through obscurity." At least it keeps your server below the radar of the script kiddies and port scanner types.

[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: Honce on Feb 11, '05 10:43:19AM

This is a general networking security hint. Assuming:

1) you have a firewall between your Mac and the Internet and are using port forwarding to expose your Mac
2) the ssh client you're using remotely allows you to set the port to use to connect to the server

then, on your firewall/router change the Internet exposed port to something like 2022 and the leave the internal port to 22.

Today most of the attacks on hosts are from script kiddies who don't even bother to port scan for services. The scripts just bang on known ports.

YMMV -- Moving my Internet exposed port off 22 alone stopped all the attacks against my machine.

Also, by using different Internet exposed ports you can forward ssh connections to all your internal hosts. I usually just expose one host. I hardened that host and use it as a gateway to the rest of the machines on my internal network.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: rhowell on Feb 11, '05 11:08:01AM

Where I work, we have 5 Macs which I ssh between all the time. Thanks Rob for some great pointers. However, the real security experts here at work (they've got PhDs in this stuff, I don't) warned me a few weeks ago:

Since I've got public/private key pairs between all of my machines, and never have to supply a password to get in via ssh, this opens a huge security hole. If one machine gets compromised, they all get compromised with no additional effort. Once an attacker is into one machine posing as you, all of the other machines are immediately available to him.

I know, I know, how is he going to get into my machine without a key? I don't know, he'll wait until I go to the bathroom, or lift my laptop on the subway.

Anyway, the security "experts" here at work highly recommend unique secure passwords only in lab-like environments for this reason.

Can anyone refute their claims (again, I'm no expert)? This, of course, is a real pain. scp-ing files back and forth without the need for a password is almost as easy as cp-ing files locally. I'd love to convince them that key pairs are the way to go.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: robg on Feb 11, '05 11:20:16AM

One of the linked hints above explains how to add a passphrase, then use the keychain so you don't have to enter it all the time...

-rob.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: Don Faulkner on Feb 11, '05 12:41:02PM

Your PhD's are right, of course. ;) However, I'd guess that there are very few (feasible) processes you could envision that they couldn't find a flaw in; it's their (and my) job to find the chink in the armor. Take their comments as a warning: safeguard your private keys like you would the keys to your house (or similar--it of course depends on how important those systems/data are).

First, PUT A PASSPHRASE ON YOUR KEY! I can't stress that enough. Yes, you'll have to type that in until you get an agent set up (keep reading), but it's just the one passphrase.

That said, you probably don't need 5 sets of keys to ssh between 5 systems. You only need one set, with the public key on all systems. The private key should be on the one system you work at. If you sit in front of a different keyboard each day, put the private key on a USB flash drive or something. I suggest a cheap, small device used only for this and other very sensitive stuff--otherwise I'd have said iPod. (You don't want your private key on something that you stick into "untrusted" systems.)

SSH supports "credential forwarding." In other words, you can use your private key to authenticate to the first host. After that, each host you connect to forwards authentication requests through the host(s) you're already connected to. Your single private key stays in one place, which is good because you're more likely to know if you've lost it--and that's what your PhD's are really after.

To get full mileage out of this technique, you'll probably want an SSH Key Agent. These work a lot like Apple's Keychain, but they're for SSH keys. Your SSH client (in terminal, an SFTP client, etc.) hands off the authentication request to your agent, which services it with your private key. If you set things up right, you rarely have to enter any pass-phrases at all, but you retain most or all of the security protections. I use SSHKeychain, and am very satisfied with it because of it's simple integration with Apple's Keychain and its built-in support for SSH tunnels.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: Schamschula on Feb 11, '05 01:30:22PM
Why all this trouble?

All you need to do is enable tcp wrappers. I wrote a quick HowTo about this several years ago, see How To Configure TCP Wrappers Under Mac OS X.

To make a long story short, you need to create the /etc/hosts.allow and /etc/hosts.deny files. See the man page, i.e. 'man hosts_access' for more detaisl.

[ Reply to This | # ]

Modify Remote Login server to block scripted attacks
Authored by: robg on Feb 11, '05 02:50:03PM

Can you explain how to use TCP wrappers to allow access from any unknown IP? That's my challenge; I have no idea what IP number my laptop will have at some hotel in Boston, and yet I still want to reach my home box.

In your writeup, I didn't see anything that would let me do that?

Thanks;
-rob.



[ Reply to This | # ]
TCP Wrappers
Authored by: Schamschula on Feb 11, '05 04:53:50PM

I probably should have been a bit more specific.

I meant the hosts_access (5) man page, i.e. man 5 hosts_access. It explains how to set up rules for specific situations. One can set up a rule like

/etc/hosts.deny:
ALL: ALL

/etc/hosts.allow:
ALL: username@ALL

would restrict access to only the single user in the hosts.allow file. However, the user can log in from any computer in the net.

I work around this issue by using less secure intermediate hosts to log into my secure machines.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: tinker on Feb 12, '05 02:10:50AM

Rob,

See my earlier response. The way to do this is with TCP wrappers and a dynamic IP service like No-IP. Works well, though you have to give No-IP a few minutes to send out your new IP every time you show up someplace new.



[ Reply to This | # ]
Why root?
Authored by: allanmarcus on Feb 11, '05 02:03:52PM

I gotta ask, why do you have root enabled? What can you do as root that you cannot do with sudo or "sudo -s"?



[ Reply to This | # ]
Why root?
Authored by: robg on Feb 11, '05 02:47:46PM

Nothing at all :). It's just been enabled for a long time, and I haven't gotten around to disabling it again...

-rob.



[ Reply to This | # ]
Why root?
Authored by: derrickbass on Feb 12, '05 02:55:11AM

Here's one reason I ran into once. I wanted to copy some system files from one computer to another. The only (easy) way I could think of to do it, preserving permissions, was:
sudo rsync /path/to/source root@remote.host:/path/to/dest
You need root enabled on the remote host in order for this to work.
(Of course, another way would be to copy the files as a user and then use sudo chmod and sudo chown on the remote machine; in this case, the files had a variety of permissions (and perhaps even owners; can't recall now), so that would have been painful.)



[ Reply to This | # ]
Why root?
Authored by: shavenyak on Feb 14, '05 08:51:38AM

You could tar up the files on the source machine, scp the .tar file over, log on to the remote machine and use sudo to un-tar. A couple more steps, but certainly no pain.



[ Reply to This | # ]
Why root?
Authored by: name99 on Mar 07, '06 08:17:37AM

Have you ever actually used rsync?
If one uses rsync for nightly backups, then a tar solution is completely useless --- the rsync solution will copy over maybe 2 or 3 MB and take 15 minutes, the tar solution will copy over 50GB and take 4 hours.

The fact is that one apparently really does have to have a root account active (meaning available via an ssh private/public key) in this case; sudo just won't do it. HOWEVER this does not mean that a password is necessary for root; it is not, so one is protected there.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: geohar on Feb 11, '05 04:04:48PM

Damn! Me too!

I'd be really interested to see how many folks out there have been scanned / had breakin attempted. Any chance you could run a poll rob?

You can determine this with

zgrep sshd /var/log/system.log.[0-9].gz | grep "Illegal user" | less

reguardless of which shell.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: daveschroeder on Feb 11, '05 04:31:41PM

No need to run a poll:

I can tell you right now, pretty much ANY host that has port 22 (SSH) open on a public network for any amount of time has been hit with one of these scripts, period.[1]

There is no need for a "poll". This is *OLD* news; these scripts have been going around forever, and all of our UNIX machines get attempts them several times a day. I'm surprised to see the reaction here, but really, this is *super old* and nothing to worry or poll about. No Mac OS X user with decent password(s) on their account(s) needs to worry about these attacks.

[1] Of course, IP ranges have to be programmed into these scripts; common things to hit will be IP ranges of universities and other academic institutions, home broadband networks, and other public networks. Some people on obscure networks might never be scanned. But, as a rule, almost any host on any public, especially university, network will have been.



[ Reply to This | # ]
One more note:
Authored by: daveschroeder on Feb 11, '05 04:36:49PM

If we want to be paranoid about things, why not also go through your apache logs? I guarantee you will see dozens, if not hundreds, of attempts to "exploit" various vulnerabilities (usually in IIS). Should we go out of our way to "block" those hosts? If you have that kind of time on your hands, knock yourself out. But if you're running a secure configuration - as a fully patched Mac OS X installation in its default configuration is - and have strong passwords (and, for home users, operate behind a hardware NAT/firewall appliance such as a Linksys router or AirPort Base Station), there is no need to jump through all sorts hoops to "protect" yourself from these myriad scripts.

Note: if someone WANTS to go through the motions of allowing only themselves, firewalling everyone except hosts they themselves connect from, etc., that's perfectly fine. But there is no need to panic about this, or think this is something new when it's extremely old (in internet terms, at least), and is, as I said, nothing to worry about if you have strong passwords. These scripts are doing nothing more than trying common username/password pairs, like mary/mary, test/test, admin/admin, tom/tom, etc., and whatever else people have programmed them to do. They're nothing special.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: Schamschula on Feb 11, '05 05:02:36PM
I use logcheck to automatically scan my logs for 'unusual' activity and send me an e-mail if something has happened.

Answering your question, this sort of thing happens on a regular basis. The number of accounts that a given script attempts to compromise varies greatly greatly.

I currently see one of these attacks on my server per day on average.

[ Reply to This | # ]

Modify Remote Login server to block scripted attacks
Authored by: Han Solo on Feb 11, '05 07:15:40PM
I must confess that I don't know a lot about these things, but would Snort be a useful tool in this context? Unfortunately, there is no OS X binary available for the most recent version; a port with a nice GUI (HenWen) seems to be over a year out of date. There is a "hint" about compiling Snort in the Hints database, but it dates from 2001....

[ Reply to This | # ]
HenWen update!
Authored by: Han Solo on Feb 19, '05 11:50:24AM
Good news for anyone looking to use HenWen (a OS X port w/ GUI for Snort): no sooner had I lamented the "outdated" version than did Nick Zitzmann update his app to version 2.1, which incorporates version 2.3.0 of Snort.

[ Reply to This | # ]
Passwordless ssh keys are a bad idea.
Authored by: dsouth on Feb 11, '05 08:30:27PM
As others have pointed out, not putting a password on your ssh keypair is a bad idea.

If the private key is compromised(by someone making a copy of it) there is no way to "revoke" the matching private keys other than delete them from every machine you've placed them on. For this reason, some sites concerned about security don't allow users to authenticate with ssh RSA/DSA keypairs at all.

If you're going to use keypair auth in ssh, put a password on the keypair. If you want "passwordless" logins, use ssh-agent to hold the private keys on a per-session basis (then you'll only have to type the key password once per login session).

[ Reply to This | # ]

SSH key management
Authored by: agraboso on Feb 12, '05 01:31:32PM

Daniel Robbins, creator of keychain and ex-chief architect of Gentoo, has two very nice articles on SSH key management (part 1 and part 2), with clear explanations of the concepts and step by step tutorial on how to set up ssh-agent and keychain to allow for passwordless logins. One of the points we stresses the most is that you should never create keys with an empty passphrase.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: surf on Feb 12, '05 03:15:17PM

As to expand on the public/private mechanism:

It is a combination of two things: the private/public key-pair and a asymetric cryptoalgorithm.

If you encript data with the public key (PUB), you can only decrypt it with the private key (PRI), not with the PUB itself or some other key. And the other way round.

So you can freely give away the PUB. When someone encrypts a message with it, only you, having the secret PRI key, can decrypt it.

So you transfer the PUB to the server.

Then you connect to the server using ssh.

The server encrypts some data with PUB and sends it to you. Only you can decrypt it using PRI. So you now have the plain data.

You then encrypt it with PRI and send it back to the server. It can only be decrypted with PUB and the server does so.

It then checks if the data is the same as the data it has send to you. If it is, it knows it is really you, as only you, the holder of PRI, could have decrypted and reenrypted the data so it "survives" the roundtrip.

Data_A ==> encrypt with PUB ---send to client---> decrypt with PRI ==> Data_A

Data_A ==> encrypt with PRI ---send to server---> decrypt with PUB ==> Data_A

--> Data_A sent, Data_A received ==> OK, this is the user.

Now, someone tries to connect, he does not have the real PRI key:

Data_A ==> encrypt with PUB ---send to client---> decrypt with FALSE_PRI ==> Data_B

Data_B ==> encrypt with FALSE_PRI ---send to server---> decrypt with PUB ==> Data_C

Data_A sent, Data_C received ==> This is not the user, login refused

So it basically checks, if the user connecting is the one having the matching PRI key to the PUB key he left at the server.



[ Reply to This | # ]
Modify Remote Login server to block scripted attacks
Authored by: Ronaldinho on Feb 12, '05 03:47:11PM

Dumb question:

If I have root access disabled via Netinfo Manager, do I have to worry about somebody logging in as root via SSH.

Can I still use sudo in terminal?



[ Reply to This | # ]
disable root, sudoers
Authored by: gatorparrots on Feb 13, '05 02:43:52PM
The answers to your questions are "no" and "yes."

By default, root is disabled (as indicated by the "*" in the passwd field in the NetInfo database). One suggestion I might make is to go ahead and enable the root user in NetInfo Manager and assign a strong, nontrival password. Then, disable the root user again. This marginally increases the security of your system. But of course, there are many ways to reset the System Administrator's password...

The sudoers file indicates:

# User privilege specification
root    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL
In other words, anything root can do, an admin user can do.

[ Reply to This | # ]
disable root, sudoers
Authored by: JohnnyMnemonic on Feb 13, '05 06:51:43PM

In other words, anything root can do, an admin user can do.

Including becoming root. If you can sudo, you can "sudo -s", which gives you persistent root access.

The only advantage is that, if you disable root, you can restrict who is able to sudo. That is, "root" is a guessable user name, but perhaps the single user that you've allowed to sudo is not. Otherwise it appears to be just as much of a security issue.

[ Reply to This | # ]

Modify Remote Login server to block scripted attacks
Authored by: covisp on Mar 19, '06 04:35:25AM

since nslookup is depecrated and spits out errors every time you use it, I played around with this and got it working with dig:

dig $MYNAME | grep -A1 $MYNAME| awk '/^$MYNAME/ { print $5}'

(where $MYNAME is myname.dyndns.org or something similar)



[ Reply to This | # ]