Any way I can make sshd more accessable without opening it to the world?

Nazo

2[H]4U
Joined
Apr 2, 2002
Messages
3,672
Well, I've really wanted to be able to access my sshd server when not at home. I didn't particularly want to open it to the whole world because I just don't like the idea that someone could eventually maybe brute force their way in. Since that system is still one I plan to use for non-server purposes on a few rare occasion (ok, at this point it almost is just a dedicated server, but, every now and then I use it as an HTPC) I don't particularly like the idea that someone could just get in and wipe out the harddrive given enough time (not easy, you have to login as a user then root because direct root login is disabled on the system -- not just sshd) and, for that matter, that system has unrestricted access to the internal network (it's a firewall right now) which are both windows systems.

I added a dns address for the school I'm usually trying to access from when I try to access it while away, but, I still aways get connection refused, so I can only conclude that it's not getting a DNS but just going by IP. Is my only option to try to figure out the entire IP range the school uses and allow all those ranges? They seem to have multiple ranges that as nearly as I can tell are randomly assigned even (at least it felt random on the few systems I tried -- I didn't go around checking the whole school.) Right now it does look to me like that's the only way to do it, but, just to be sure, isn't there any other? Or, are there any alternatives to handling the whole situation more cleanly?
 
There are a few options available

1) make sure ROOT does not have SSH access
2) have some obscure named user and it onlt have ROOT access
2a) equally for the obscure named user a really obcure & long passwd
2b) with this user the only one to SSH you can then "su" to root

THIS stops attack via known usernames, my log filled with ppl trying:
test,temp,admin,ftp,ssh,root...

To get in its not just a case of breaking the passwd it is a case of knowing the username as well.

3) change the default port number. Most attempts are script-kiddies scanning for open port 22. I have mine moved up to a port >10,000

4) port knocking. One of the most secure ways of preteting yr machine
 
I'm not quite sure I understand what you're asking. You say you have a server at home that you want to access via SSH. But I'm confused as to how you're trying to access it. Do you have a public IP address for this server? If the server isn't somehow publicly accessible (either you have a static IP for it or you have a router that's doing port-forwarding to it), you won't be able to access it from outside your home network no matter what you do.

If you can get to the server from outside networks, you might want to take a look at hosts.deny and hosts.allow to let only specific IP addresses or IP address ranges to connect to the server.

EDIT: ^^ what he said, too, if you're still concerned about security. Never hurts to be careful.
 
I'm using a dyndns service to get my dynamic IP configured to a DNS address. A service runs on the server to check every now and then (I think I have it configured to 30 minutes) for changes in the internet IP and it updates the IP configured to the dynamic DNS as needed. IMO the dyndns type system is a pretty neat one since it solves a lot of problems associated with connections like mine.

And I'm usings hosts.deny and hosts.allow. I don't actually get a choice since sshd seems to be serious about using it.

eeyrjmr said:
There are a few options available

1) make sure ROOT does not have SSH access
2) have some obscure named user and it onlt have ROOT access
2a) equally for the obscure named user a really obcure & long passwd
2b) with this user the only one to SSH you can then "su" to root

THIS stops attack via known usernames, my log filled with ppl trying:
test,temp,admin,ftp,ssh,root...

To get in its not just a case of breaking the passwd it is a case of knowing the username as well.

3) change the default port number. Most attempts are script-kiddies scanning for open port 22. I have mine moved up to a port >10,000

4) port knocking. One of the most secure ways of preteting yr machine
Well, first of all, there is no way to log in to root. You can su, but, the root account isn't allowed by default at the selected Mandriva security level (see, people don't like Mandriva, but, it's security has it's ups.) Oh, I'm using the "higher" security level which does lock down some things, but, according to the information is the minimum you need to be running a server (the only thing higher is "paranoid" which in my past experience was a bit too much.)

Anyway, I'll be honest with you. I'm actually not very fond of having to go back and forth a lot with users and such to get to su, but, I still have to use su more than I should really have to. If I got down and dirty and spent who knows how many hours I could get it all right and never ever use su again, but, it's just too much for me for such a simple server type setup. Anyway, my user account isn't very hard to guess though at least the password is pretty random with letters and numbers and all that. I think it could hold up against a brute attack for a while, but, I do worry if they keep at it long enough since sshd has no inherant security to stop brute attacks that I could see (other than by making it very hard to tell whether you have a wrong user or wrong password or both.) I found a little script, I think called sshdeny or something, but, I'm not even sure that I installed it correctly as it's pretty darned silent. Supposedly it blocks people who try too often.

So, I admit some security is compromised by the fact that to me it's just too much work to do all that. That's why I don't just go in there and set sshd to allow all. But, I'll have to take some risk, I'll accept that and bear it since that's what you get for being too lazy. I'll still do reasonable amounts to do what I can to avoid a problem though. Such as by not setting sshd to accept connections from just any IP out there. Also, I am using a nonstandard port number at least. Lol, I didn't even have to be told not to use plain old port 22. If I were a hacker that's the first thing I'd try since it's probably easier to break into an easy user account (what was it, "sex, god, and password"?) than to try to figure out exactly which vulnerability in exactly which way to use on a server.

What is port knocking? Sorry, lol, I admit I'm still a little bit newbieish when it comes to the parts of networking security beyond the most basic things. To me port knocking sounds just like another term for port scanning or something, but, that wouldn't make sense since it's bad for security.


Anyway, for one thing, I noticed at the school systems at least that everything resolved to an address on my school's domain. That's what I'd hoped to use in the hosts.allow file. Actually, it strikes me now that perhaps the issue wasn't lack of reverse lookups on the IP addresses, but, perhaps the school systems really are just showing the DNS addresses on the internal network but not really properly assigned to the external?
 
I do this by only allowing specific IP ranges from connecting (using iptables). If they aren't inside that range, it drops the packet just like any other.
 
Xipher said:
I do this by only allowing specific IP ranges from connecting (using iptables). If they aren't inside that range, it drops the packet just like any other.

Thats what I do.

If you are unsure of what the school uses, tail the auth.log file (or whatever it is) for your system on the ssh connects to see where (and when) it was denied. The where would be the external IP of your school's firewall(s) and the when would have to be known by you.

example from my /var/log/auth.log (I don't know who this dude is, but lets say it was actually me)
Code:
Apr 16 19:22:43 nade sshd[12208]: refused connect from webcorreio.atarde.com.br (::ffff:200.223.87.146)
I would then modify my firewall and/or hosts.allow to permit logins via this ip address. Restart sshd and you should be golden.

I don't 100% trust hosts.allow and hosts.deny, but I use them to allow certain ranges of IP's access. Its backed up by my IPtables configured to block most spoofing attempts.
 
I guess that is the best I can do. It's a little hard because the school is a one hour drive away (well, that's adding in traffic) so even if I go there and straight back it's hard to remember exactly where to look. Still, probably the best I can do. I was hoping there was an easier way like some way to fix the fact that setting hosts.allow to allow the DNS address range like some of the FAQs suggested, but, since I just see no way to fix it, I'm probably going to have to go on IP alone.

BTW, I remember the name of the script I'm trying to use. Denyhosts. Actually, when I look at my hosts.deny file and am flooded, I'm inclined to say that the program is probably working (it's set to get a blacklist from a host server.) Don't know, maybe some of you may want to look into it (I like the idea of being able to ban abusive addresses.)
 
If you're accessing your own server from a *nix server on campus, you could always SSH into the campus server from home and then try to SSH from your campus account back into your server. Then you can sit right there at home and troubleshoot. I use this tactic a lot when I need an outside host to test from. It's lazyness to the max :)
 
Lol, ssh account on the campus? Yeah right. I'll be honest, my school's computer systems are pitiful. I think they are even using Win2k or something for their servers. I'm not sure, but, I know they are the sort to be using WebCT (the CT stands for craptastic) rather than hiring people to make real software for their online stuff. I'm just using putty (started with a cygwin compile of ssh, but, putty is more suitable) in WinXP on their computers and I don't think they even have a *nix system. Pitiful, I know.

Nah, I think I'll just have to figure out what IP ranges they currently own and allow all those. I may be able to just look at a few systems or something, or, I think DNS records tell you what is owned by a particular organization if you know where to look.
 
Nazo said:
Lol, ssh account on the campus? Yeah right. I'll be honest, my school's computer systems are pitiful. I think they are even using Win2k or something for their servers. I'm not sure, but, I know they are the sort to be using WebCT (the CT stands for craptastic).

LOL...yeah, we use WebCT too. I agree about the craptastic part. That's too bad about your campus computer situation. I have a couple of unix accounts at my school (Cal State Chico) at any one time, depending on the classes I'm enrolled in. They were supposed to delete my computer science account...but I don't think they have yet. The admins are probably too busy keeping WebCT from crashing ;)
 
Nazo said:
What is port knocking? Sorry, lol, I admit I'm still a little bit newbieish when it comes to the parts of networking security beyond the most basic things. To me port knocking sounds just like another term for port scanning or something, but, that wouldn't make sense since it's bad for security.


Ahh port-knocking is a fantastic invention

imagine all yr port's closed so yr computer is effectively non-accesible to the world GREAT the world cant get in BUT how do you?

port-knocking!
you setup a server (low-resource btw) daemon and you configure it with a sequence of ports say
47,10045,6734

ie a sequence
Now you get a client program (dont need a program a simple python script can do the knocking)
Now you run this program with EXACTLY the same sequence as you configured. When the server sees this sqeunce on yr server-ports it then opens a pre-configured port ONLY for the source IP address

its like a secret knock you have to do on a door to be let in
 
Now that's a neat idea. Darn, sounds like it'd need one heck of a complicated setup between the firewall and everything though. I suppose in theory a hacker could accidentally do the knock every now and then, but, it's questionable that he'd even know he did it, what exactly he did to repeat it, and so on. You could allow SSHd to listen to the world that way... At least, any parts of the world that do the correct knock first.


Q-Ball said:
LOL...yeah, we use WebCT too. I agree about the craptastic part. That's too bad about your campus computer situation. I have a couple of unix accounts at my school (Cal State Chico) at any one time, depending on the classes I'm enrolled in. They were supposed to delete my computer science account...but I don't think they have yet. The admins are probably too busy keeping WebCT from crashing ;)
Crashing? WebCT doesn't crash. You have to actually work to begin with to crash. I changed colleges once and my previous school did it the way it's supposed to be done. You automatically had an account the moment you officially signed up for a CS course. It used a linux domain with randomly generated very thorough passwords (they gave you a printout with the thing, but, I still lost it and forgot the password half the time.) It had the windows stuff too set up so that you could log in with windows or linux and the systems dual booted between the two. You automatically had network storage and everything. These systems I have to use now have only a read only windows share and the harddrives are wiped automatically somehow with each reboot (it must be a hardware solution because it's FAST.) Of course, all the settings are wrong, such as number of colors/etc (16-bit, what the heck? It has no noticable performance effect even in a game these days even on crappy onboard, and you're not supposed to be playing games anyway) and of course a few settings that really need to be changed require a reboot. One of my classes required us to use a program which wouldn't run until you switched a video driver setting that required a reboot. Yep. High quality stuff going on there.

Oh well, anyway, thanks for your help people.
 
Nazo said:
Now that's a neat idea. Darn, sounds like it'd need one heck of a complicated setup between the firewall and everything though. I suppose in theory a hacker could accidentally do the knock every now and then, but, it's questionable that he'd even know he did it, what exactly he did to repeat it, and so on. You could allow SSHd to listen to the world that way... At least, any parts of the world that do the correct knock first.


Well no. SSHd isn't even running at this stage.

imagine as far as the world is concerned yr machine has NOTHING running on any port (since nothing is replied when a request is sent).

Now you have a knock sequence

13065,1045,45,14078,...

as long as you like, the Chances of a hacker getting the same knock sequence (he would have to know port-knocking is enabled) is rediculously remote

There are 16'383 ports to choose from. Each port knocking sequence increases the probablity by the product

Standard defence: Change default port: Hacker has 1-in-16,383 of getting right port
2-port-knocks : Chance of it being found: 16,383*16,383 and again *16383 (since you then specifiy what port)

a 5port-knock sequence has a rediculously large amount of combinations.

And that is ONLY to get the port open AND the correct port, they then have to get the right username && passwd

Nothing beats port-knocking


its not even complicated IF you use IPtables as yr firewall, PortKnockD modifys the firewall WHEN the right knock is sent
 
I use a non-standard port number. Make up a 16-bit integer and use that as SSH's port (e.g. 15908). I really doubt anyone will even notice you have a server running that way. You will also avoid the thousands of bot-scans one would normally get.

And couple that with a good username/password.
 
Ah, I forgot to say. My ADSL modem automatically responds to the most basic of hacker methods to find a computer, ping requests, without any way of disabling it. Lol, no use trying to be truly invisible to the internet since all anyone has to do is ask and my modem tells them I'm there.

Anyway, I'm going to look into this PortKnockD. It still sounds like it could be handy. The trick is that I can't be truly stealthed, but, if they don't know ssh is there, or, for that matter where there is, then chances are they'll not bother to waste any more time on it when there are so many easy systems to turn into zombies.

Quick question, is there any "official" PortKnockD? Closest I find doesn't look very official at all. Also, can it be set to only block certain things? I'm running Apache for testing various things in one of my classes and want to be able to get to it without having to port knock first.
 
LazyBastard said:
Installed by default on most linux distros I think. I know it is on Mandriva.

Beyond hosts.deny/hosts.allow, does it offer other options related to the question?
 
You have to get in first to do that, lol.

Here's a question. Does anyone have any opinion on DenyHosts? I'm wondering if this is reliable enough to just go ahead and open SSH to all, but, use that to block abusive attempts (as well as the blacklist.)

Is this just too risky? I believe I actually already have it set up correctly (certainly my hosts.deny has a huge list of blocks I didn't put in there.)
 
eeyrjmr said:
port-knocking!
Security through obscurity!

Seriously, if someone figured out the port knocking sequence, they would run into the "I need a key file" bit. If that's not secure enough, making people guess several 16-bit ints isn't gonna help. Once you figure it out once (or snoop the traffic once, or read the python script out of your directory on $untrusted-machine!) you're past it, and it's not convenient to change the knock sequence, especially if you're not the only one logging in.

I've got several machines with SSH on port 22 either NATed to the outside world or directly connected (with no NAT) and no problems. The intrusion logs are mailed to their respective admins weekly (they log to other machines) and they're still safe. They've got all of doh's steps applied except the first. I probably should do that, too, but it's not a priority as far as I'm concerned.

 
unhappy_mage said:
Security through obscurity!

Seriously, if someone figured out the port knocking sequence, they would run into the "I need a key file" bit. If that's not secure enough, making people guess several 16-bit ints isn't gonna help. Once you figure it out once (or snoop the traffic once, or read the python script out of your directory on $untrusted-machine!) you're past it, and it's not convenient to change the knock sequence, especially if you're not the only one logging in.

I've got several machines with SSH on port 22 either NATed to the outside world or directly connected (with no NAT) and no problems. The intrusion logs are mailed to their respective admins weekly (they log to other machines) and they're still safe. They've got all of doh's steps applied except the first. I probably should do that, too, but it's not a priority as far as I'm concerned.

Two seconds with vim will save you two days of trying to figure out how you got rooted.
 
Well, I'm trying to figure out how to get the whole RSA/DSA key thing to work between sshd and putty I guess. I'll do that and DenyHosts, then allow the world through the firewall to that one port I guess. I don't mind not having a passwordless login, so it doesn't have to be the full passwordless trick with the key file, but, getting PuTTY to send the right data seems to be tricky and I can't get the key file thing to work right at all.

Looks like portknocking is out. First of all, I couldn't figure out any less than painful way to implement it. Second of all, and I suppose more importantly, from what I read it looks like it would definitely require a portknock for any incoming connection. I run the occasional P2P thing and I don't think they're going to be nice enough to portknock for me. (I doubt I'm the only one, I've noticed more and more distros and programs and such are distributed via BitTorrent to save on bandwidth.)


And yeah, there's no reason to allow direct root login. A simple fake user with su access or something is all you need and it's so little extra work that even I don't mind doing it. d-: On the other hand, with direct root login enabled you give them a target (after all, why break into Sue from accounting's account when you can go straight for the system administrator?)

PS. Vim isn't enough btw, lol, don't forget you have to spend another half second restarting sshd. So it's actually two and a half seconds.


EDIT: Got it! I now have it authenticating via a DSA key file but requiring a password to unlock it (I prefer the idea of it requiring a password.) If anyone is interested in figuring out how to make PuTTY work, apparently it uses it's own format. Here's how to get it working: http://the.earth.li/~sgtatham/putty/0.53b/htmldoc/Chapter8.html#8.2.12
 
If you get rooted 'cuz you have SSH 'open to the world' you fucked up.

There's plenty of sites that are a lot bigger targets than your random broadband box that have no problems keeping hackers out.
 
Nazo said:
You have to get in first to do that, lol.

Here's a question. Does anyone have any opinion on DenyHosts? I'm wondering if this is reliable enough to just go ahead and open SSH to all, but, use that to block abusive attempts (as well as the blacklist.)

Is this just too risky? I believe I actually already have it set up correctly (certainly my hosts.deny has a huge list of blocks I didn't put in there.)

I highly recommend DenyHosts. It works great, and is a simple/elegant solution, which makes it easy for you to log in, impossible for any brute force attacks.

The other option is dameonShield (http://daemonshield.sourceforge.net/). Rather than using a hosts.deny file, it uses an iptable to ban the IPs. This is nice in that instead of sending a rejection reply (as is done with hosts.deny), it simply drops any attempt of connection from the offending IP. Essentially, your machine becomes invisible to them. (I use dameonshield myself)
 
ameoba said:
If you get rooted 'cuz you have SSH 'open to the world' you fucked up.

There's plenty of sites that are a lot bigger targets than your random broadband box that have no problems keeping hackers out.
I'm not the one with root access enabled.

And I'm not that worried, but, it seems kind of dumb to risk someone coming in and doing who knows what. I couldn't stop a REAL hacker probably, but, I'd like to at least keep out the script kiddies and make a real hacker hopefully decide it's not really worth wasting time on. I mean, even a real hacker might actually take a little time out to ruin some little random system if it's doing something really stupid like one of those three passwords I mentioned earlier (I'm not so sure about the password "password" though. The third could have been something else.) Thing is, even playing around, anyone who got in could still do enough damage to make things unpleasant for me even if they hopefully couldn't do enough to get to my real data (the data on that system isn't horribly important.)


MarkLT1, Daemonshield sounds like a good idea. I may give it a shot later. Well, dropping does little good since, as I said, my modem just happily pings away letting anyone who asks know that there definitely is a computer here, so stealthing is out, but, nonetheless, as I understand it, the hosts.deny/allow solution takes more processing power and such. Since I'm running it on a really low end machine, if I start doing anything serious (I may use it for encoding if I ever learn mencoder for example) I may need to consider something like that.

Anyway, I've actually already been using DenyHosts for a while, I just wasn't sure it was working until today when I actually found the new entries in hosts.deny added by it. It was questionable whether I set it up right, but, it seems I did manage to get it right. Between DenyHosts and an encrypted DSA key file, I feel at least a bit confident.
 
Nazo said:
I couldn't stop a REAL cracker probably, but, I'd like to at least keep out the script kiddies and make a real cracker hopefully decide it's not really worth wasting time on. I mean, even a real cracker might actually take a little time out to ruin some little random system if it's doing something really stupid like one of those three passwords I mentioned earlier (I'm not so sure about the password "password" though. The third could have been something else.)

Fixed. s/hacker/cracker/g

My ssh key passphrase is... a phrase. It takes time to type. Furthermore if someone knows the passphrase it is useless unless they have the key. Likewise it is virtually useless for someone to have the key without the passphrase.

Don't complicate your system with programs which may have security flaws in them. I'm sure daemonshield is spiffy and all but I'm betting it has to run as root to issue iptables commands. When daemonshield gets cracked and a root escalation you're fucked. Miminse your points of failure; rely on opensshd.
 
Actually, I really meant a hacker I think. I'm pretty sure they're the ones who hack into a system via any of several means, and they're more the sort to just do it for fun such that they may hack into a system just to see if it can be done and maybe not even actually damage anything, just leave a playful little note informing you that you're not as secure as you may have thought. And that's the thing. It's not just a matter of guessing the keyphrase (which can be done via brute force methods if you're dumb enough to use a real phrase.) If a real hacker decided he wanted in, I doubt he would waste time trying to brute force his way through ssh. Instead, he'd know all the vulnerabilities in the various distributions and softwares (in particular the services.) Buffer overflows and such make for a much easier way to get in to someone who knows how to do them and which ones to do than sitting there trying to guess a password. Unfortunately nothing is perfect and few of us can patch every single peice of software that has some little known security flaw.

Anyway, it's no use worrying about programs so much. I mean, you have to run some programs on your system. There's always something with more access than you might like somewhere. And I doubt this Daemonshield program is a server type of thing, so it should at least be as complicated to crack as anything else (besides, can't you configure things such that some kind of network admin user or something can be set up for controlling iptables?) Oh, and DenyHosts is just a script, so the only thing I can imagine reasonably doing is either find a way to get enough access to modify it (I think it's owned by root on my copy -- I guess I should probably check that to be sure) or I guess you could intercept the information to/from the server and maybe add your own hosts to deny, but, it doesn't control hosts to allow, so you can't do much beyond make it inconvenient. I don't know, maybe you could use such a trick to remove yourself from the hosts.deny list.

The fact is, beyond becoming truly paranoid and locking down everything so that you are 100% stealthed from the internet, you can never be 100% safe. It's no use worrying overmuch, and programs like those at least help keep out the script kiddies. A real hacker/cracker/whatever you want to call them will find a way no matter what if they really feel like it, so the best thing to do is just do your best and minimize the damage they could do (eg BACKUP!) while making it at least unpleasant to waste time on the likes of yourself when they could be screwing around with Bill Gates' servers for more fun.
 
unhappy_mage said:
Security through obscurity!

Seriously, if someone figured out the port knocking sequence, they would run into the "I need a key file" bit. If that's not secure enough, making people guess several 16-bit ints isn't gonna help. Once you figure it out once (or snoop the traffic once, or read the python script out of your directory on $untrusted-machine!) you're past it, and it's not convenient to change the knock sequence, especially if you're not the only one logging in.

I've got several machines with SSH on port 22 either NATed to the outside world or directly connected (with no NAT) and no problems. The intrusion logs are mailed to their respective admins weekly (they log to other machines) and they're still safe. They've got all of doh's steps applied except the first. I probably should do that, too, but it's not a priority as far as I'm concerned.


Why is is "security through obsurity" ?
It is another layer to the protection its not ment to be on its own

IF they figure out the knock sequence they still have to get the key-file
IF they manage to get the key-file they still have to figure out the valid username
IF they manage to figure out the valid username they still need the valid passwd
IF they manage to figure out the valid passwd they still need root-passwd (to su)

IF all that is satified you have more problems then a casual hacker, someone went out of the way to ROOT your box!!! and if someone really wanted to get it, they will get it.
Equally you proolly got a leak on the inside (social engineering) to allow this entry to get so far, again stressing the more problems point

All these things (port-knock, change default port,...) are ment to disuade the casual hacker, the ones that have a crib-sheet of know ports,known passwds and known usernames.



I use port-knocking on my home server so I can control/access from work with no problems at all
 
eeyrjmr said:
Why is is "security through obsurity" ?
It is another layer to the protection its not ment to be on its own

IF they figure out the knock sequence they still have to get the key-file
IF they manage to get the key-file they still have to figure out the valid username
IF they manage to figure out the valid username they still need the valid passwd
IF they manage to figure out the valid passwd they still need root-passwd (to su)

IF all that is satified you have more problems then a casual hacker, someone went out of the way to ROOT your box!!! and if someone really wanted to get it, they will get it.
Equally you proolly got a leak on the inside (social engineering) to allow this entry to get so far, again stressing the more problems point

All these things (port-knock, change default port,...) are ment to disuade the casual hacker, the ones that have a crib-sheet of know ports,known passwds and known usernames.



I use port-knocking on my home server so I can control/access from work with no problems at all
I'm with you on this one (go figure :) ). This is not "security through obsurity". It is a basic multilayered defense strategy. The only difference being that it's dealing with layers inside of a single machine and not seperate devices.
 
eeyrjmr said:
All these things (port-knock, change default port,...) are ment to disuade the casual hacker, the ones that have a crib-sheet of know ports,known passwds and known usernames.
True. However, treating port knocking as a secure system implies trust in it - if it isn't adding anything, nobody would use it. And while it may well be secure, it adds more layers of complexity - there has to be a daemon listening to these ports as well as a daemon for ssh. As doh mentioned, there's another possible problem. Two programs running are inherently more insecure than one program running. Not to mention that if anyone else should have need to legitimately get into your machine, they have to know how to generate knocks. SSH is an easy thing to do these days; port knocking is not standardized. If I tell my nine-year-old brother to ssh to another machine, he knows how to do that - open PuTTY, type in hostname, select ssh, open, username, password, in. But if I tell him to port knock, he'll have no idea how to go about that.

I appear to have gone off on a tangent. Here's my point: if you don't trust SSH to be secure, why do you trust port knocking to be secure? One was designed by professional cryptographers, the other by some guys who said, "Y'know, it'd be cool if...". Have it your way, I won't stop you, but I'll keep running ssh by itself, thanks.

 
unhappy_mage said:
True. However, treating port knocking as a secure system implies trust in it - if it isn't adding anything, nobody would use it. And while it may well be secure, it adds more layers of complexity - there has to be a daemon listening to these ports as well as a daemon for ssh. As doh mentioned, there's another possible problem. Two programs running are inherently more insecure than one program running. Not to mention that if anyone else should have need to legitimately get into your machine, they have to know how to generate knocks. SSH is an easy thing to do these days; port knocking is not standardized. If I tell my nine-year-old brother to ssh to another machine, he knows how to do that - open PuTTY, type in hostname, select ssh, open, username, password, in. But if I tell him to port knock, he'll have no idea how to go about that.

I appear to have gone off on a tangent. Here's my point: if you don't trust SSH to be secure, why do you trust port knocking to be secure? One was designed by professional cryptographers, the other by some guys who said, "Y'know, it'd be cool if...". Have it your way, I won't stop you, but I'll keep running ssh by itself, thanks.


I do trust SSH to be secure, what I don't like is my log file being filled with attempts (however, futile). I have a linksys NSLU2 fileserver at home (fantasic little thing) it only have 32meg or RAM and something like 133MHz (I have overclocked to 266).

NOw I did just have it running on the default port but my log kept filling up and if you looked at the RAM being used it ends up swapping alot.

I changed to a non-standard port number and nearly all traffic went, but still some kiddies were port-scanning and some would find the port I was using (and again my log & RAM would be filling up)

Enabling port-knocking and they cannot find my port. The thing is when port-knocking is running SSHd isn't running. When hte knock is validated knockD starts SSH but only allows the IP I was using (then I need to go through the standard auth).

So as far as resources concernd a very small knock daemon is a small price to pay to ensure log not getting spammed (or my mem getting raped).


I see the point of "doh" that 2 progs more insecure then 1, but they would have to find my box first and know it is using a knock.
 
You don't need any daemons listening from what I understand. You can use iptables to pull off the port knocking (meaning you just hit the ports, and it doesn't even have to send a rst packet). It won't look any more open then before. Any one that found this by chance of luck (maybe by nmap some how randomly doing the right ports in their order), who knows if they will ever catch on, and even be able to figure out which ports where the right ones


Here, found a link showing what I mean http://www.debian-administration.org/articles/268
 
doh said:
Two seconds with vim will save you two days of trying to figure out how you got rooted.

QFT

It seems so unlikely with all the other measures in place, but why take the chance? Disabling SSH root login is to me a basic, common sense security policy.

As an aside, this port-knocking business seems pretty darn cool. I may have to give it a try.
 
Well last weekend I decided to change my SLUG from Unslung-Linux to OpenSlug (wanted more flexability and a more "linux" feel)

on my Unslung I had it so Root couldn't log in & also port knocking. just to try it out I decided to configure DSA key login mainly since my work has decided to really close down un-used ports (ie I cannot knock or login on silly-number ports).

This is forcing me back to port-22 (and equally stopping me from using knocking unless I port-scanned work and I would prolly get a nice letter for that).


SO setup easy (one extra line to change in the sshd_config file) and a nice key generated (that is on my memory stick as well as putty).

However I now get log content :rolleyes:

May 22 20:33:51 (none) syslog.info -- MARK --
May 22 20:53:51 (none) syslog.info -- MARK --
May 22 21:13:51 (none) syslog.info -- MARK --
May 22 21:33:51 (none) syslog.info -- MARK --
May 22 21:43:52 (none) auth.info sshd[1140]: Did not receive identification string from 222.66.108.61
May 22 21:45:48 (none) auth.info sshd[1143]: Invalid user staff from 222.66.108.61
May 22 21:53:51 (none) syslog.info -- MARK --
May 22 22:03:41 (none) auth.info sshd[1147]: Did not receive identification string from 82.224.139.101
May 22 22:05:32 (none) auth.info sshd[1154]: Invalid user postgres from 82.224.139.101
May 22 22:05:33 (none) auth.info sshd[1158]: Invalid user oracle from 82.224.139.101
May 22 22:05:35 (none) auth.info sshd[1166]: Invalid user test from 82.224.139.101
May 22 22:05:37 (none) auth.info sshd[1170]: Invalid user local from 82.224.139.101
May 22 22:05:38 (none) auth.info sshd[1174]: Invalid user toto from 82.224.139.101
May 22 22:05:39 (none) auth.info sshd[1178]: Invalid user toto from 82.224.139.101
May 22 22:05:42 (none) auth.info sshd[1182]: Invalid user lotto from 82.224.139.101
May 22 22:05:43 (none) auth.info sshd[1186]: Invalid user doctor from 82.224.139.101
May 22 22:05:45 (none) auth.info sshd[1190]: Invalid user doctor from 82.224.139.101
May 22 22:05:46 (none) auth.info sshd[1194]: Invalid user local from 82.224.139.101
May 22 22:05:51 (none) auth.info sshd[1210]: Invalid user test from 82.224.139.101
May 22 22:06:01 (none) auth.info sshd[1214]: Invalid user toor from 82.224.139.101
May 22 22:13:51 (none) syslog.info -- MARK --
May 22 22:33:51 (none) syslog.info -- MARK --


Now before I had not a single thing, now I am getting a few determined buggers trying (wont get far they need the key, they then need to guess the one valid user (everyone else has a shell /bin/false and ROOT not allowed), even then they must guess the pass-phrase and even then they then have to guess the ROOT passwd - so nice and secure

However, my arguement for using knocking still stands! my logfile is still gettting spammed, admitidly no where near as bad but still

If it wasn't for work blocking pretty much all ports I would of stayed with port-knocking to keep log-file traffic down
 
Oh and as I power

//LKGD718D2/# tail -f /var/log/messages
May 22 22:05:38 (none) auth.info sshd[1174]: Invalid user toto from 82.224.139.101
May 22 22:05:39 (none) auth.info sshd[1178]: Invalid user toto from 82.224.139.101
May 22 22:05:42 (none) auth.info sshd[1182]: Invalid user lotto from 82.224.139.101
May 22 22:05:43 (none) auth.info sshd[1186]: Invalid user doctor from 82.224.139.101
May 22 22:05:45 (none) auth.info sshd[1190]: Invalid user doctor from 82.224.139.101
May 22 22:05:46 (none) auth.info sshd[1194]: Invalid user local from 82.224.139.101
May 22 22:05:51 (none) auth.info sshd[1210]: Invalid user test from 82.224.139.101
May 22 22:06:01 (none) auth.info sshd[1214]: Invalid user toor from 82.224.139.101
May 22 22:13:51 (none) syslog.info -- MARK --
May 22 22:33:51 (none) syslog.info -- MARK --
May 22 22:53:51 (none) syslog.info -- MARK --
May 22 22:54:33 (none) auth.info sshd[1219]: Did not receive identification string from 221.186.210.230
May 22 22:59:31 (none) auth.info sshd[1222]: Invalid user slapme from 221.186.210.230
May 22 22:59:34 (none) auth.info sshd[1226]: Invalid user oracle from 221.186.210.230
May 22 22:59:37 (none) auth.info sshd[1230]: Invalid user www from 221.186.210.230
May 22 22:59:39 (none) auth.info sshd[1234]: Invalid user master from 221.186.210.230
May 22 22:59:42 (none) auth.info sshd[1238]: Invalid user info from 221.186.210.230
May 22 22:59:47 (none) auth.info sshd[1246]: Invalid user computer from 221.186.210.230
May 22 22:59:50 (none) auth.info sshd[1250]: Invalid user webmaster from 221.186.210.230
May 22 22:59:53 (none) auth.info sshd[1254]: Invalid user info from 221.186.210.230
May 22 22:59:55 (none) auth.info sshd[1258]: Invalid user webmaster from 221.186.210.230
May 22 23:00:16 (none) auth.info sshd[1290]: Invalid user jack from 221.186.210.230
May 22 23:00:19 (none) auth.info sshd[1294]: Invalid user jack from 221.186.210.230
May 22 23:00:21 (none) auth.info sshd[1298]: Invalid user student from 221.186.210.230
May 22 23:00:27 (none) auth.info sshd[1306]: Invalid user user from 221.186.210.230
May 22 23:00:29 (none) auth.info sshd[1310]: Invalid user alex from 221.186.210.230
May 22 23:00:32 (none) auth.info sshd[1314]: Invalid user alex from 221.186.210.230
May 22 23:00:35 (none) auth.info sshd[1318]: Invalid user paul from 221.186.210.230
May 22 23:00:37 (none) auth.info sshd[1322]: Invalid user paul from 221.186.210.230
May 22 23:00:40 (none) auth.info sshd[1326]: Invalid user valentin from 221.186.210.230
May 22 23:00:42 (none) auth.info sshd[1330]: Invalid user love from 221.186.210.230
May 22 23:00:45 (none) auth.info sshd[1334]: Invalid user access from 221.186.210.230
May 22 23:00:48 (none) auth.info sshd[1338]: Invalid user game from 221.186.210.230
May 22 23:00:50 (none) auth.info sshd[1342]: Invalid user sex from 221.186.210.230
May 22 23:00:53 (none) auth.info sshd[1346]: Invalid user web from 221.186.210.230
May 22 23:00:55 (none) auth.info sshd[1350]: Invalid user url from 221.186.210.230
May 22 23:00:58 (none) auth.info sshd[1354]: Invalid user user from 221.186.210.230
May 22 23:01:01 (none) auth.info sshd[1358]: Invalid user run from 221.186.210.230
May 22 23:01:03 (none) auth.info sshd[1362]: Invalid user check from 221.186.210.230
May 22 23:01:06 (none) auth.info sshd[1366]: Invalid user server from 221.186.210.230
May 22 23:01:09 (none) auth.info sshd[1370]: Invalid user evil from 221.186.210.230
May 22 23:01:11 (none) auth.info sshd[1374]: Invalid user turbo from 221.186.210.230
May 22 23:01:14 (none) auth.info sshd[1378]: Invalid user player from 221.186.210.230
May 22 23:01:16 (none) auth.info sshd[1382]: Invalid user player from 221.186.210.230
May 22 23:01:19 (none) auth.info sshd[1386]: Invalid user abc from 221.186.210.230
May 22 23:01:22 (none) auth.info sshd[1390]: Invalid user abc from 221.186.210.230
May 22 23:01:24 (none) auth.info sshd[1394]: Invalid user abc from 221.186.210.230
May 22 23:01:27 (none) auth.info sshd[1398]: Invalid user linux from 221.186.210.230
May 22 23:01:30 (none) auth.info sshd[1402]: Invalid user linux from 221.186.210.230
May 22 23:01:32 (none) auth.info sshd[1406]: Invalid user power from 221.186.210.230
May 22 23:01:35 (none) auth.info sshd[1410]: Invalid user power from 221.186.210.230
May 22 23:01:38 (none) auth.info sshd[1414]: Invalid user mimi from 221.186.210.230
May 22 23:01:40 (none) auth.info sshd[1418]: Invalid user mimi from 221.186.210.230
May 22 23:01:43 (none) auth.info sshd[1422]: Invalid user mimi from 221.186.210.230
May 22 23:01:45 (none) auth.info sshd[1426]: Invalid user compaq from 221.186.210.230
May 22 23:01:48 (none) auth.info sshd[1430]: Invalid user compaq from 221.186.210.230
May 22 23:01:51 (none) auth.info sshd[1434]: Invalid user compaq from 221.186.210.230
May 22 23:01:53 (none) auth.info sshd[1438]: Invalid user shop from 221.186.210.230
May 22 23:01:56 (none) auth.info sshd[1442]: Invalid user shop from 221.186.210.230
May 22 23:01:58 (none) auth.info sshd[1446]: Invalid user shop from 221.186.210.230
May 22 23:02:01 (none) auth.info sshd[1450]: Invalid user shop from 221.186.210.230
May 22 23:02:04 (none) auth.info sshd[1454]: Invalid user captain from 221.186.210.230
May 22 23:02:06 (none) auth.info sshd[1458]: Invalid user robert from 221.186.210.230
May 22 23:02:09 (none) auth.info sshd[1462]: Invalid user nelson from 221.186.210.230
May 22 23:02:12 (none) auth.info sshd[1466]: Invalid user robert from 221.186.210.230
May 22 23:02:14 (none) auth.info sshd[1470]: Invalid user nelson from 221.186.210.230
May 22 23:02:17 (none) auth.info sshd[1474]: Invalid user robert from 221.186.210.230
May 22 23:02:19 (none) auth.info sshd[1478]: Invalid user nelson from 221.186.210.230
May 22 23:02:22 (none) auth.info sshd[1482]: Invalid user james from 221.186.210.230
May 22 23:02:25 (none) auth.info sshd[1486]: Invalid user james from 221.186.210.230
May 22 23:02:27 (none) auth.info sshd[1490]: Invalid user james from 221.186.210.230
May 22 23:02:30 (none) auth.info sshd[1494]: Invalid user xxx from 221.186.210.230
May 22 23:02:35 (none) auth.info sshd[1502]: Invalid user temp from 221.186.210.230
May 22 23:02:38 (none) auth.info sshd[1506]: Invalid user dan from 221.186.210.230
May 22 23:02:40 (none) auth.info sshd[1510]: Invalid user fred from 221.186.210.230
May 22 23:02:43 (none) auth.info sshd[1514]: Invalid user bill from 221.186.210.230
May 22 23:02:45 (none) auth.info sshd[1518]: Invalid user paul from 221.186.210.230
May 22 23:02:48 (none) auth.info sshd[1522]: Invalid user dan from 221.186.210.230
May 22 23:02:51 (none) auth.info sshd[1526]: Invalid user fred from 221.186.210.230
May 22 23:02:53 (none) auth.info sshd[1530]: Invalid user bill from 221.186.210.230
May 22 23:02:56 (none) auth.info sshd[1534]: Invalid user paul from 221.186.210.230
May 22 23:02:59 (none) auth.info sshd[1538]: Invalid user dan from 221.186.210.230
May 22 23:03:01 (none) auth.info sshd[1542]: Invalid user fred from 221.186.210.230
May 22 23:03:04 (none) auth.info sshd[1546]: Invalid user bill from 221.186.210.230
May 22 23:03:06 (none) auth.info sshd[1550]: Invalid user paul from 221.186.210.230
May 22 23:03:09 (none) auth.info sshd[1554]: Invalid user dan from 221.186.210.230
May 22 23:03:12 (none) auth.info sshd[1558]: Invalid user fred from 221.186.210.230
May 22 23:03:14 (none) auth.info sshd[1562]: Invalid user bill from 221.186.210.230
May 22 23:03:17 (none) auth.info sshd[1566]: Invalid user paul from 221.186.210.230
May 22 23:03:19 (none) auth.info sshd[1570]: Invalid user dan from 221.186.210.230
May 22 23:03:22 (none) auth.info sshd[1574]: Invalid user fred from 221.186.210.230
May 22 23:03:25 (none) auth.info sshd[1578]: Invalid user bill from 221.186.210.230
May 22 23:03:27 (none) auth.info sshd[1582]: Invalid user paul from 221.186.210.230
May 22 23:03:30 (none) auth.info sshd[1586]: Invalid user dan from 221.186.210.230
May 22 23:03:32 (none) auth.info sshd[1590]: Invalid user fred from 221.186.210.230
May 22 23:03:35 (none) auth.info sshd[1594]: Invalid user bill from 221.186.210.230
May 22 23:03:38 (none) auth.info sshd[1598]: Invalid user paul from 221.186.210.230
May 22 23:03:40 (none) auth.info sshd[1602]: Invalid user fun from 221.186.210.230
May 22 23:03:43 (none) auth.info sshd[1606]: Invalid user file from 221.186.210.230
May 22 23:03:46 (none) auth.info sshd[1610]: Invalid user america from 221.186.210.230
May 22 23:03:48 (none) auth.info sshd[1614]: Invalid user usa from 221.186.210.230
May 22 23:03:51 (none) auth.info sshd[1618]: Invalid user emil from 221.186.210.230
May 22 23:03:53 (none) auth.info sshd[1622]: Invalid user snake from 221.186.210.230
May 22 23:03:56 (none) auth.info sshd[1626]: Invalid user time from 221.186.210.230
May 22 23:03:59 (none) auth.info sshd[1630]: Invalid user carmen from 221.186.210.230
May 22 23:04:01 (none) auth.info sshd[1634]: Invalid user doctor from 221.186.210.230
May 22 23:04:04 (none) auth.info sshd[1638]: Invalid user server from 221.186.210.230
May 22 23:04:06 (none) auth.info sshd[1642]: Invalid user data from 221.186.210.230
May 22 23:04:09 (none) auth.info sshd[1646]: Invalid user frank from 221.186.210.230
May 22 23:04:12 (none) auth.info sshd[1650]: Invalid user kevin from 221.186.210.230
May 22 23:04:14 (none) auth.info sshd[1654]: Invalid user tamara from 221.186.210.230
May 22 23:04:17 (none) auth.info sshd[1658]: Invalid user tamara from 221.186.210.230
May 22 23:04:19 (none) auth.info sshd[1662]: Invalid user tamara from 221.186.210.230
May 22 23:04:22 (none) auth.info sshd[1666]: Invalid user tamara from 221.186.210.230
May 22 23:04:25 (none) auth.info sshd[1670]: Invalid user jack from 221.186.210.230
May 22 23:04:28 (none) auth.info sshd[1674]: Invalid user jack from 221.186.210.230
May 22 23:04:30 (none) auth.info sshd[1678]: Invalid user jack from 221.186.210.230
May 22 23:04:33 (none) auth.info sshd[1682]: Invalid user jack from 221.186.210.230
May 22 23:04:35 (none) auth.info sshd[1686]: Invalid user love from 221.186.210.230
May 22 23:04:38 (none) auth.info sshd[1690]: Invalid user love from 221.186.210.230
May 22 23:04:41 (none) auth.info sshd[1694]: Invalid user love from 221.186.210.230
May 22 23:04:44 (none) auth.info sshd[1698]: Invalid user love from 221.186.210.230
May 22 23:04:47 (none) auth.info sshd[1702]: Invalid user love from 221.186.210.230
May 22 23:04:50 (none) auth.info sshd[1706]: Invalid user love from 221.186.210.230
May 22 23:04:53 (none) auth.info sshd[1710]: Invalid user love from 221.186.210.230
May 22 23:04:55 (none) auth.info sshd[1714]: Invalid user kid from 221.186.210.230
May 22 23:04:58 (none) auth.info sshd[1718]: Invalid user kid from 221.186.210.230
May 22 23:05:01 (none) auth.info sshd[1722]: Invalid user kid from 221.186.210.230
May 22 23:05:03 (none) auth.info sshd[1726]: Invalid user sport from 221.186.210.230
May 22 23:05:06 (none) auth.info sshd[1730]: Invalid user sports from 221.186.210.230
May 22 23:05:08 (none) auth.info sshd[1734]: Invalid user run from 221.186.210.230
May 22 23:05:11 (none) auth.info sshd[1738]: Invalid user slow from 221.186.210.230
May 22 23:05:14 (none) auth.info sshd[1742]: Invalid user thc from 221.186.210.230
May 22 23:05:16 (none) auth.info sshd[1746]: Invalid user nasa from 221.186.210.230
May 22 23:05:19 (none) auth.info sshd[1750]: Invalid user mark from 221.186.210.230
May 22 23:05:22 (none) auth.info sshd[1754]: Invalid user mark from 221.186.210.230
May 22 23:05:24 (none) auth.info sshd[1758]: Invalid user mark from 221.186.210.230
May 22 23:05:27 (none) auth.info sshd[1762]: Invalid user mark from 221.186.210.230
May 22 23:05:29 (none) auth.info sshd[1766]: Invalid user mark from 221.186.210.230
May 22 23:05:32 (none) auth.info sshd[1770]: Invalid user wolf from 221.186.210.230
May 22 23:05:35 (none) auth.info sshd[1774]: Invalid user dog from 221.186.210.230
May 22 23:05:37 (none) auth.info sshd[1778]: Invalid user cat from 221.186.210.230
May 22 23:05:40 (none) auth.info sshd[1782]: Invalid user tom from 221.186.210.230
May 22 23:05:42 (none) auth.info sshd[1786]: Invalid user tom from 221.186.210.230
May 22 23:05:45 (none) auth.info sshd[1790]: Invalid user tom from 221.186.210.230
May 22 23:05:48 (none) auth.info sshd[1794]: Invalid user tom from 221.186.210.230
May 22 23:05:50 (none) auth.info sshd[1798]: Invalid user karla from 221.186.210.230
May 22 23:05:53 (none) auth.info sshd[1802]: Invalid user king from 221.186.210.230
May 22 23:05:55 (none) auth.info sshd[1806]: Invalid user linux from 221.186.210.230
May 22 23:09:02 (none) auth.info sshd[2098]: Invalid user mysql from 221.186.210.230
May 22 23:09:05 (none) auth.info sshd[2102]: Invalid user mysql from 221.186.210.230
May 22 23:09:08 (none) auth.info sshd[2106]: Invalid user mysql from 221.186.210.230
May 22 23:09:10 (none) auth.info sshd[2110]: Invalid user mysql from 221.186.210.230
May 22 23:09:13 (none) auth.info sshd[2114]: Invalid user sybase from 221.186.210.230
May 22 23:09:16 (none) auth.info sshd[2118]: Invalid user sybase from 221.186.210.230
May 22 23:09:18 (none) auth.info sshd[2122]: Invalid user sybase from 221.186.210.230
May 22 23:09:21 (none) auth.info sshd[2126]: Invalid user sybase from 221.186.210.230
May 22 23:09:23 (none) auth.info sshd[2130]: Invalid user sybase from 221.186.210.230
May 22 23:09:26 (none) auth.info sshd[2134]: Invalid user www from 221.186.210.230
May 22 23:09:29 (none) auth.info sshd[2138]: Invalid user www from 221.186.210.230
May 22 23:09:32 (none) auth.info sshd[2142]: Invalid user www from 221.186.210.230
May 22 23:09:34 (none) auth.info sshd[2146]: Invalid user www from 221.186.210.230
May 22 23:09:37 (none) auth.info sshd[2150]: Invalid user www from 221.186.210.230
May 22 23:09:39 (none) auth.info sshd[2154]: Invalid user www from 221.186.210.230
May 22 23:09:42 (none) auth.info sshd[2158]: Invalid user oracle from 221.186.210.230
May 22 23:09:45 (none) auth.info sshd[2162]: Invalid user oracle from 221.186.210.230
May 22 23:09:47 (none) auth.info sshd[2166]: Invalid user oracle from 221.186.210.230
May 22 23:09:50 (none) auth.info sshd[2170]: Invalid user oracle from 221.186.210.230
May 22 23:09:53 (none) auth.info sshd[2174]: Invalid user oracle from 221.186.210.230
May 22 23:09:56 (none) auth.info sshd[2178]: Invalid user oracle from 221.186.210.230
May 22 23:09:58 (none) auth.info sshd[2182]: Invalid user oracle from 221.186.210.230
May 22 23:10:01 (none) auth.info sshd[2186]: Invalid user apache from 221.186.210.230
May 22 23:10:03 (none) auth.info sshd[2190]: Invalid user apache from 221.186.210.230
May 22 23:10:07 (none) auth.info sshd[2194]: Invalid user apache from 221.186.210.230
May 22 23:10:10 (none) auth.info sshd[2198]: Invalid user apache from 221.186.210.230
May 22 23:10:12 (none) auth.info sshd[2202]: Invalid user apache from 221.186.210.230
May 22 23:10:15 (none) auth.info sshd[2206]: Invalid user apache from 221.186.210.230
May 22 23:10:17 (none) auth.info sshd[2210]: Invalid user joel from 221.186.210.230
May 22 23:10:20 (none) auth.info sshd[2214]: Invalid user joel from 221.186.210.230
May 22 23:10:23 (none) auth.info sshd[2218]: Invalid user joel from 221.186.210.230
May 22 23:10:25 (none) auth.info sshd[2222]: Invalid user joel from 221.186.210.230
May 22 23:10:28 (none) auth.info sshd[2226]: Invalid user joel from 221.186.210.230
May 22 23:10:43 (none) auth.info sshd[2250]: Invalid user john from 221.186.210.230
May 22 23:10:46 (none) auth.info sshd[2254]: Invalid user john from 221.186.210.230
May 22 23:10:48 (none) auth.info sshd[2258]: Invalid user john from 221.186.210.230
May 22 23:10:51 (none) auth.info sshd[2262]: Invalid user john from 221.186.210.230
May 22 23:10:54 (none) auth.info sshd[2266]: Invalid user pamela from 221.186.210.230
May 22 23:10:57 (none) auth.info sshd[2270]: Invalid user pamela from 221.186.210.230
May 22 23:10:59 (none) auth.info sshd[2274]: Invalid user pamela from 221.186.210.230
May 22 23:11:02 (none) auth.info sshd[2278]: Invalid user pamela from 221.186.210.230
May 22 23:11:05 (none) auth.info sshd[2282]: Invalid user frank from 221.186.210.230
May 22 23:11:07 (none) auth.info sshd[2286]: Invalid user frank from 221.186.210.230
May 22 23:11:10 (none) auth.info sshd[2290]: Invalid user frank from 221.186.210.230
May 22 23:11:12 (none) auth.info sshd[2294]: Invalid user frank from 221.186.210.230



So port-knocking is pointless is it?
 
Nah. Their argument was that it's not so helpful compared to the tried and true methods (though I personally feel that it's as reliable as any of those due to it's sheer simplicity -- there's not much room for things to go wrong.) Well, other than your log files filling up, nothing so bad is happening. They still haven't gotten in or anything. The problem with port knocking is it seems to require the whole system to be closed to the world with a port knock required to get in to anything. How would you reasonably run a web server or something on there when you have to tell anyone trying to get in validly to do a port knock for even just that (and then they only get in for a limited time btw -- it defaults to 30 minutes before it closes again on the things I saw.) If you think about it, it kind of defeats the purpose since you have to give the "password" (eg the knock sequence) to a lot of people instead of the just one or two who need ssh access.

Might not hurt to run DenyHosts on that system. Such persistant attempts deserve a good banning in my opinion.
 
Nazo said:
Nah. Their argument was that it's not so helpful compared to the tried and true methods (though I personally feel that it's as reliable as any of those due to it's sheer simplicity -- there's not much room for things to go wrong.) Well, other than your log files filling up, nothing so bad is happening. They still haven't gotten in or anything. The problem with port knocking is it seems to require the whole system to be closed to the world with a port knock required to get in to anything. How would you reasonably run a web server or something on there when you have to tell anyone trying to get in validly to do a port knock for even just that (and then they only get in for a limited time btw -- it defaults to 30 minutes before it closes again on the things I saw.) If you think about it, it kind of defeats the purpose since you have to give the "password" (eg the knock sequence) to a lot of people instead of the just one or two who need ssh access.

Might not hurt to run DenyHosts on that system. Such persistant attempts deserve a good banning in my opinion.

funny you should say that, I am looking into that right now... hoping it wont use too much RAM, just trying to find ARM-compiled modules
 
Geez, ARM? Well, DenyHosts is just a python script. I don't know, not horribly efficient if it even HAS an ARM binary anywhere (maybe some pocketpc related stuff? But, that would be windows ce, so that wouldn't help you. I don't know, I've never even looked.) Sorry, I forgot you were using a pretty specialized setup there. Anyway, tell me how to find out the memory usage and I'll check. I've decided to go ahead with DenyHosts as it seems to be working for me -- at least, if i can figure out how to keep it from adding a deny from all except localhost to the hosts.deny... Then again, I have a SMP system with 512MiB of memory (I don't know exactly how a 500MHz P3 compares to a 133MHz ARM since ARM does more per cycle on properly optimized things than P3.)
 
Well python on ARM isn't standard-layout (and is missing some core stuff) so cant use that.

I just added


sshd: UNKNOWN

to my /etc/hosts.deny


and sorted it (well stopped logging)
 
Back
Top