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

I just recently found the following IPTABLES rules, and let me just say they rock. What the following does is allows 2 tcp connects to port 22 in a variable time window. After which, it will reject all further connect attempts until the window has expired ( in my example, 5 minute window ). This has effectively prevented any brute force attempts on my server from bots, although a dedicated cracker may take the time to discover my personal window and code around it. Anyway, here are the rules:

Code:
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name sshattack --rsource
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j LOG --log-prefix "SSH Drop: "
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j REJECT --reject-with tcp-reset

Again, I don't know how helpful this is the OP, but I know I find it extremely useful and I'm sure others will too.
 
Looks to be the same thing as DenyHosts basically. Even also runs in Python.

Well, one of the things I like most about DenyHosts is it has an option which, once enabled, allows DenyHosts to download a list from their official server of bans (with a configurable criteria for how many times the IP had been banned so you don't get the little ones.)
 
XOR != OR said:
I just recently found the following IPTABLES rules, and let me just say they rock. What the following does is allows 2 tcp connects to port 22 in a variable time window. After which, it will reject all further connect attempts until the window has expired ( in my example, 5 minute window ). This has effectively prevented any brute force attempts on my server from bots, although a dedicated cracker may take the time to discover my personal window and code around it. Anyway, here are the rules:

Code:
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name sshattack --rsource
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j LOG --log-prefix "SSH Drop: "
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j REJECT --reject-with tcp-reset

Again, I don't know how helpful this is the OP, but I know I find it extremely useful and I'm sure others will too.

very nice IP-rules there, might use that on my main desktop when I get that setup for SSH
 
Nazo said:
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.)

yup ARM-processor for the ultimate "security by Obsurity". Even if they did manage to get in they couldn't run any of their custom programs (bar BASH-scripts & python-scripts that dont access x86 binarys/libarys). I also do not have the chaintool installed - it can be but takes 4hours just to compile a tiny bit of it.

I love my slug
 
eeyrjmr said:
very nice IP-rules there, might use that on my main desktop when I get that setup for SSH
Code:
 --------------------- iptables firewall Begin ------------------------ 

 
 Dropped 1412 packets on interface eth0
   From 65.19.155.219 - 1412 packets to tcp(22) 
 
 ---------------------- iptables firewall End -------------------------
From my logwatch. Posted here to highlight the effectiveness of these rules. This is a comcast connection, btw. Nothing business about it.
 
eeyrjmr said:
yup ARM-processor for the ultimate "security by Obsurity". Even if they did manage to get in they couldn't run any of their custom programs (bar BASH-scripts & python-scripts that dont access x86 binarys/libarys). I also do not have the chaintool installed - it can be but takes 4hours just to compile a tiny bit of it.
I love my slug
You know, with the right software an ARM binary can be compiled even on an x86. Aren't there some PocketPCs that can run linux though? You could even look for a good PocketPC with a faster processor (my 400MHz is a really old one, but, I think they haven't gotten too much better in the three to four years or so it has been since that thing was new -- too much speed translates into too much power consumption, which is kind of the point of ARM since it has so little power consumption normally, but, if you clocked it at 1GHz or something it might be another matter.) Only catch is the hacker has to actually figure out you have an ARM processor and then get the right tools. Normally they wouldn't go to such lengths, but, who knows, a professional might actually consider it a fun challenge. Lol. Well, us mere humans can't stop a pro, but, we can keep out all the dimwitted script kiddiez.


XOR != OR, I'm not sure I want to do that myself, but, I am curious. I've never tried adding my own custom rules to IPTABLES. I just use shorewall and let it add it's rules on startup. To something more of a newbie, how does one go about adding a rule like that, and is there any clean way to have it added on startup, or must you just toss your own init.d script or something in there (eg I'd rather it were added by something of a more official-like program like shorewall, which is less likely to screw up than me.)

BTW, has anyone tried DenyHosts? Anyone have the patience to take a crack at trying to figure out why it keeps adding a deny all except 127.0.0.1 to my hosts.deny? I'm thinking it probably picked that up when I first installed it or something, so there must be a file somewhere that stores what to keep which contains this rule, but, I haven't the foggiest idea where it's keeping this (it's not in the normal installation directory, /usr/share/denyhosts/, or any of its subdirectories.) I wanted to take advantage of denyhosts because of that whole download a blacklist from a central server thing, but, it's useless when it keeps adding a rule to ban everything external...

EDIT: Wait, could it be mandrake security (msec) doing it? Either way, I don't see anything obvious, so I'm not sure how to disable this rather troublesome setting...


I'm glad to see this thread is helping more than myself though. If I can get that one thing working, I'll probably be set well enough to suit my purposes thanks to the suggestion of using a keyfile since that's so hard to crack (not impossible, but, any hacker with brains will spend more time trying to crach my apache or something instead.)
 
Nazo said:
XOR != OR, I'm not sure I want to do that myself, but, I am curious. I've never tried adding my own custom rules to IPTABLES. I just use shorewall and let it add it's rules on startup. To something more of a newbie, how does one go about adding a rule like that, and is there any clean way to have it added on startup, or must you just toss your own init.d script or something in there (eg I'd rather it were added by something of a more official-like program like shorewall, which is less likely to screw up than me.)
Depends on how and where shorewall does it. You can save the current ruleset in iptables with the iptables-save command. The output looks much like the above ( more or less ), and can be piped into the iptables-restore command to reset your firewall.

I imagine shorewall uses this method. So the trick would be finding the file that shorewall is saving the firewall rule set to and adding the above commands before anything else ( or after your secure interfaces, if they set it up that way ). Once that's done, it'll restore automatically.

One thing I'd be worried about using this approach; Automation tools. I don't know how shorewall works, and there may be iptable automation tools that would rewrite the script everytime it's modified.
 
Shorewall rewrites the rules on startup. This is to allow for changes to its own settings so you can easily just change a rule then restart it. Actually, that's all shorewall is in the end, just a complex set of scripts to take an easy set of configurations and write them into IPTABLES rules. And there are GUIs and such which like to screw up my set of shorewall rules (in particular, the firewall drake will wipe out custom things not set within itself, so I make a backup of my rule file every now and then to be on the safe side in case I should forget and use that thing by accident.)

Anyway, sounds like I'd probably have to toss in my own little script or something. Truth is, I don't like the idea of having to use a window for it though. Still, if nothing else, you've told anyone else who reads this thread how to do it. ^_^
 
eeyrjmr said:
However I now get log content :rolleyes:

Who cares?

If you use logrotate like a sensible administrator it all gets wiped away anyways.
 
doh said:
Who cares?

If you use logrotate like a sensible administrator it all gets wiped away anyways.
Look a little more carefully. He has a bit of a specialized setup and that's causing problems for a reason.
 
Nazo said:
Look a little more carefully. He has a bit of a specialized setup and that's causing problems for a reason.

If he's got limited space available he shouldn't use logging, or he should be sending his logs to a remote host.

The sysklogd parameter would be -r [host] (i think). I'd verify but I'm on a flakey access point that's dropped my connection four times in the time I've been responding to this thread today.
 
I think the point is that when you have a specialized setup like that, it makes more sense to fix the problem itself than to find ways to try to go around it. Even with such methods, there's still a lot of wasted cpu power and memory, neither of which the box has in abundance. Even an ARM CPU can only do so much once you have to start doing a lot of if-the-else type stuff.


BTW, should anyone be curious, I found out that it was definitely Mandriva security causing the deny all except localhost entry to continuously reappear in the hosts.deny. Turns out you have to set the option "Authorize all services controlled by tcp_wrappers" to ALL. I love the IDEA of Mandriva with its checks for permissions and such, but, I have to admit that it definitely has a bad fault in that it has a lot of options that are completely unintuitive. It sounds more like that has to do with validity checking, not denying connections from certain hosts...
 
doh said:
Who cares?

If you use logrotate like a sensible administrator it all gets wiped away anyways.

Who cares? I care!!!
1) this is a mini file server I like to spin the harddrive down. Un-nessacary logging stops the disk from spinning down

2) every single attempt to enter my system causes SSH to report to the sys logger, which in turn diverted CPU time (of which I ONLY have 266MHZ!!!) to writing to disk,

3) in writing to disk it is moving the head away from where I want it to be, ie MY DATA!

4) I do not want my log filled with this BS,
File-size isn't the problem (root system is 10gig in size with 300meg used, with /opt having 140gig). Plus anyway in saying "If you use logrotate like a sensible administrator " I can only deduce that you do not know they rotatelog is not compatible with busybox provided syslogd :rolleyes:



corr you were soo helpful to my situation
:rolleyes:


anyway the UNKNOWN rule in hosts.deny sorted that out now so all I get is a single entry as they scan my system THAT I can cope with
 
Heh, basically what I was saying. With specialized setups like that, the solution isn't to just let the logs flood but cycle them faster, but, to prevent the flood to begin with.


Uhm, anyone have any idea why my connection is STILL refused when attempting to ssh remotely even after I finally got rid of the deny from all but localhost statement? It's actually getting a connection refusal, not just a timeout (eg not dropped as per the firewall's default actions on a closed port.) I'm using the exact same settings I'm using at home in PuTTY with the only difference being that I connect to my DNS address instead of the name of the local computer. I even tried ssh (cygwin) though I haven't exactly figured out how to get the PuTTY exported key file to actually work (it's the right one, and it's supposed to be for ssh, but, well, when I try it on the lan it doesn't accept, so I'm guessing that "supposed to" isn't good enough.) It too said connection refused. Never even gets so far as sending the key file as nearly as I can tell. I don't even think the remote server gets my login username. I think the connection is just instantly refused on the port without even checking to see if it could be a valid connection or not...

I wondered why I still didn't have any messages of people trying to get into the ssh server. I figure if nothing else the occasional rare port scan may find the open port and then them attempt it. Even if they would get banned by DenyHosts (hopefully) it would show me in the logs that someone had tried it...
 
You've been staring at consoles too long when you think you can delete posts by typing del. d-: That is what you were trying to do I presume?

EDIT: I see, they removed the ability to delete one's own posts. Wonder why they did that
 
EDIT: And the ultimate irony, I accidentally hit the wrong button and double post, then find I can't delete it.. Sorry.
 
eeyrjmr said:
Who cares? I care!!!
1) this is a mini file server I like to spin the harddrive down. Un-nessacary logging stops the disk from spinning down
Why don't you just have a central syslog server, and simply send all messages to it? If its that big of a deal to you that is.
 
Xipher said:
Why don't you just have a central syslog server, and simply send all messages to it? If its that big of a deal to you that is.

:rolleyes: because I am a poor engineer and this little box cost £50 and is extreamly powerful (be it limited). THIS is only for home file-serving, ftp-ing, torrenting as well as (via a USB sound-card) a MP3-player (once I have finished the python-script).

This is the only server, so what "other" server that both you and "doh" now mention would I send the log to?

its all well and good coming up with nice solutions when you have lots-o nice powerful network servers, but sometimes, just sometimes to "one solution fits all" approach does not work and you have to "think outside the box" but hey that's why I am an engineer.

My solution works perfectly for my implementation and that is all that matters thanks
 
Just a possible suggestion. The thing is I don't actually see why you would want the drive too spin down. That means when something wants to access it needs to spin it back up, adding to the latency in waiting for the file to be served. I can understand it from a power saving standpoint, but not from a performance standpoint. You could also add a small secondary drive strictly for log files.
 
Xipher said:
Just a possible suggestion. The thing is I don't actually see why you would want the drive too spin down. That means when something wants to access it needs to spin it back up, adding to the latency in waiting for the file to be served. I can understand it from a power saving standpoint, but not from a performance standpoint. You could also add a small secondary drive strictly for log files.

The drive spin-down is more for when it is not in use much (ie most of the day) but the drive spinning down is minor (it is a very quiet drive).

As mentioned its not the space that is the issue, it is the leaching of the CPU-time to actually do the logging that is the issue. SCript-kiddies tend to bombard say around 100-tries.

Now at the moment the ARM isn't being pushed that bad (on CPU-time), BUT when I finally finish my script (to hopefully line up with my new phone next month) anything that take CPU-time away from decoding MP3 files is a no-no

before you ask, it can be done a mate has one playing MP3's but it is controlled via a web-interface on his laptop (via MPD), I am just taking it a step further. The NSLU2 is more then capable of it, I just do not want SSHd as well as SysLogd responding (and thus taking CPU-time) when it shouldn't have to.

my Arcam amp should ride through the odd log-entry, BUT even that wouldn't cope with a 5min sustained attack causing the decoding of the MP3 to be jerky and sound shite
 
Well, I would suggest then having the bad login attempts blocked before they even reach the device, because if they get that far, the kernel is going to get context switched on, and no mater what take some CPU time away. Even if you set it too block, every single attempt will require the kernel to be switched on to handle it.
 
Xipher said:
Well, I would suggest then having the bad login attempts blocked before they even reach the device, because if they get that far, the kernel is going to get context switched on, and no mater what take some CPU time away. Even if you set it too block, every single attempt will require the kernel to be switched on to handle it.

That is fine, Disk IO take alot more CPU time (USB-disk) then all those "ignored" attempts
IF it comes to it I will just setup a CRON-job to only allow SSH at certain times, killing of the possibilty when I want music

Oh and 1st stage of the script - creating a PICKLE file of the album collection to send to the phone (when I get) can then use it to choose track,album,... and then send back a command to play that (via madplay)


Code:
#! /usr/bin/env python

import os,sys,string, fnmatch
import eyeD3

def all_files(root,patterns='*'):
	patterns = patterns.split(';')
	for path,subdirs,files in os.walk(root):
		files.sort()
		#print path
		for name in files:
			for pattern in patterns:
				if fnmatch.fnmatch(name,pattern):
					yield os.path.join(path,name)
					break


#FILE = 'M:\\ZEN\\F.A.C.T\\01 - Meet My Modem.mp3'
#DIR = 'M:\\ZEN'
FILE = '/opt/DATA/mp3/ZEN/F.A.C.T/01 - Meet My Modem.mp3'
DIR = '/opt/DATA/mp3/ZEN/' 
Collection = {}
##############################################
# Testing for MP3 ID-info
##############################################
tag = eyeD3.Tag()
tag.link(FILE)
#print tag.getArtist()
#print tag.getAlbum()
#print tag.getTitle()
#print tag.getTrackNum()[0]

##############################################
# Testing for directory walking
############################################
print "\n\n"
for FILE in all_files(DIR,'*.mp3'):
	#print FILE
	tag.link(FILE)
	if not tag.getAlbum() in Collection:
		Collection[tag.getAlbum()] = {tag.getTrackNum()[0]:[tag.getTitle(),FILE]}
	else:
		Collection[tag.getAlbum()][tag.getTrackNum()[0]] = [tag.getTitle(),FILE]


#print Collection
print len(Collection.keys()),"\n\n"
#print Collection.keys()
print Collection[u'Lamb']



outputs
Code:
//LKGD718D2/opt/DATA/misc# ./mp3.py



50


{1: [u'Lusty', '/opt/DATA/mp3/ZEN/Lamb/01-Lusty.mp3'], 2: [u'God Bless', '/opt/DATA/mp3/ZEN/Lamb/02-God Bless.mp3'], 3: [u'Cotton Wool', '/opt/DATA/mp3/ZEN/Lamb/03-Cotton Wool.mp3'], 4: [u'Trans Fatty Acid', '/opt/DATA/mp3/ZEN/Lamb/04-Trans Fatty Acid.mp3'], 5: [u'Zero', '/opt/DATA/mp3/ZEN/Lamb/05-Zero.mp3'], 6: [u'Merge', '/opt/DATA/mp3/ZEN/Lamb/06-Merge.mp3'], 7: [u'Gold', '/opt/DATA/mp3/ZEN/Lamb/07-Gold.mp3'], 8: [u'Closer', '/opt/DATA/mp3/ZEN/Lamb/08-Closer.mp3'], 9: [u'Gorecki', '/opt/DATA/mp3/ZEN/Lamb/09-Gorecki.mp3'], 10: [u'Feela', '/opt/DATA/mp3/ZEN/Lamb/10-Feela.mp3']}
 
You know, get properly optimized software and MP3 playback should be pretty darned negligable on an ARM processor. MP3 happens to be one of those things that love the RISC-style (what was the official name of this? Vector processing?) nature of the ARM processor: http://en.wikipedia.org/wiki/ARM_architecture#NEON - Check it out. 10MHz. Even if it doesn't have NEON, a properly optimized program should decode MP3s with practically no visible effect on processing time. Considering that libmad was developed on x86 systems probably specifically for x86 systems with focus first and foremost on a really really high decoding accuracy (remember, their "selling" point is that it decodes with 24-bit precision, which is more accurate even dithered down to 16-bit than to simply decode in 16-bit to begin with. Sounds like something that eats more ram and CPU power than you need for your purposes to me. Especially since you are talking over the phone, which is 8-bit precision with a very decreased frequency range...) Just something to think about anyway. I don't know if any player is properly optimized for ARM -- I know the PocketPC player I use takes a lot more cycles than it should, but, then I'm not sure how much of that is the GUI and Windows. Even though it's an OLD Windows CE (3.0) it still wastes a surprising number of those 400 million cycles per second (my poor nearly dead battery can't take it!) I do think MAD isn't the decoder you want though.


BTW, anyone willing to take a crack at why my SSHd is denying non-lan connections? I'm still trying to figure that one out. What's really odd here is that when I check my logs, I can't actually find an entry at that time saying ANYTHING about denied or dropped connections...
 
Nazo said:
You know, get properly optimized software and MP3 playback should be pretty darned negligable on an ARM processor. MP3 happens to be one of those things that love the RISC-style (what was the official name of this? Vector processing?) nature of the ARM processor: http://en.wikipedia.org/wiki/ARM_architecture#NEON - Check it out. 10MHz. Even if it doesn't have NEON, a properly optimized program should decode MP3s with practically no visible effect on processing time. Considering that libmad was developed on x86 systems probably specifically for x86 systems with focus first and foremost on a really really high decoding accuracy (remember, their "selling" point is that it decodes with 24-bit precision, which is more accurate even dithered down to 16-bit than to simply decode in 16-bit to begin with. Sounds like something that eats more ram and CPU power than you need for your purposes to me. Especially since you are talking over the phone, which is 8-bit precision with a very decreased frequency range...) Just something to think about anyway. I don't know if any player is properly optimized for ARM -- I know the PocketPC player I use takes a lot more cycles than it should, but, then I'm not sure how much of that is the GUI and Windows. Even though it's an OLD Windows CE (3.0) it still wastes a surprising number of those 400 million cycles per second (my poor nearly dead battery can't take it!) I do think MAD isn't the decoder you want though.


BTW, anyone willing to take a crack at why my SSHd is denying non-lan connections? I'm still trying to figure that one out. What's really odd here is that when I check my logs, I can't actually find an entry at that time saying ANYTHING about denied or dropped connections...

probably becuase RISC come with a floating point unit and ARM do not (I plan to use a integer-based decoder, I have heard the quality pretty good from the NLSU2).

Anyway back to the topic at hand

What is in your syslog when you try to connect
what if you disable denyhost and try
what if you disable denyhost and mv the /etc/hosts.deny to say /etc/host.deny.orig and try to log in
 
eeyrjmr said:
What is in your syslog when you try to connect
what if you disable denyhost and try
what if you disable denyhost and mv the /etc/hosts.deny to say /etc/host.deny.orig and try to log in
Like I said, I can't find any entry in the log for that time...

I'll try disabling denyhosts I suppose. I don't like it, and I don't believe it's the problem (supposed to stop you after something like 10 failed attempts -- I don't recall right off the top of my head my exact setting.) The biggest problem here is I can only test how it works away from home while actually away from home, so I end up testing once a weekday, and I can't change anything until I get back, what with there being no ssh connection possible to do anything through...

BTW, I made 100% sure that the port is opened in the firewall. Well, that is, I presume that sshd is TCP, right? It doesn't use any other ports, maybe a non-configurable base + 1 like FTP or something?

EDIT: I see mention of ssh and UDP together. I'm going to enable that through the firewall as well next time. Now that I use my head a bit, I remember that the firewall is applied to eth0, so the LAN bypasses the firewall entirely... Sorry, I may have had a rather dumb moment here.

EDIT2: Then again, I see people saying ssh does NOT use UDP... Well, the TCP port IS open in the firewall (I used a portscan site and ports other than the ssh port showed up as stealthed, but, the ssh port showed up as open.) Here's a question. Does the ssh CLIENT need incoming ports? I'm behind a firewall here that I can't control...
 
There is a option for openssh to change to log-level (default INFO I think, VERBOSE might be of more use).

I say disable DEnyHost (temporarily) just so it stops filling yr hosts.deny (for now, can re-enable in a bit). BUT definitly move your hosts.deny file (so its an empty file) to see if the reason why you cannot log-on is because of the content of hosts.deny.

all denyhost does (I believe) is populates that file (I tried to again set it up on my NSLU2 but the setup of PYTHON I have has a broken "SMPT" support).

so to re-iterate
1) change ssh logging
2) stop DenyHost
3) use an empty hosts.deny file

Then try to log in. IF you can then try again with the hosts.deny (I suspect this is the fail point)
 
That's the problem with the lack of entries. Log level was set too low. Darn, I knew about it, but, 100% forgot it. Darn, you'd think it would have at least left an entry for denies though. And yes, denyhosts just adds to hosts.deny. I can simply erase the hosts.deny because I had nothing in it without denyhosts and denyhosts will just repopulate it from the server if I do.

I can't test any of this until tomorrow though. BTW, could it matter at all that I'm using a nonstandard port? Also, FTP's data connection is the host port + 1, could ssh have anything like that that I need to be letting through? As far as I know it's just the one TCP port, but, I'm grasping at straws here.
 
I can't believe that no one here has mentioned keypair authentication. If you disable password login, disable root login, and use 2048bit keys to login, it is a minimal security risk to open sshd to the outside world.

Here's a good guide on how to get public key authentication up and running:
http://sial.org/howto/openssh/publickey-auth/

Additionally iptables can be configured to resist brute force sshd attacks:
Code:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --update --seconds 60 --hitcount 4 -j DROP

The above two lines will allow 3 tries to connect to port 22 per minute then drop subsequent connections.
 
Keyfiles were already mentioned. I currently use a 2048-bit RSA key (I originally started with DSA because I heard it was harder to crack the same number of bits versus a RSA, but, I later read that there's a bit of a vulnerability in it that could give them your whole key, so I'm back to RSA.) I've turned off the plaintext password login, though I don't decrypt or whatever the key file, so it requires you to authenticate it to use it (I think this is actually handled client side isn't it?) Once I figured out how to do that much, I actually have felt pretty confident about the whole thing since that large keyfile isn't something easily made up and no dictionary attack is possible I would hope (even if they got the keyfile, hopefully it would take a really long time to decrypt since I'm using a proper password with mixed characters and numbers, albiet not a particularly long one -- hey, I have to remember it too.)

The IPTABLES rule does sound like something that could be useful. At least, when you want to start more cleanly dropping due to a large volume of attacks. By the way, I see all these mentiones of using IPTABLES for that sort of thing, but, as nearly as I can tell I already have sshd configured to do this sort of thing. Ok, it's not as clean as IPTABLES doing it since it still involves processing power and the connections would be rejected instead of dropped, but, the point is that it should be able to do that as well.

Anyway, at this point, I'm less worried about lack of security, more worried about what is apparently too much security considering that I can only get in from the LAN right now.
 
canis said:
Additionally iptables can be configured to resist brute force sshd attacks:
Code:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --update --seconds 60 --hitcount 4 -j DROP

The above two lines will allow 3 tries to connect to port 22 per minute then drop subsequent connections.
Beat you to it, canis. :D And you are far nicer than I am, I give people 2 logins in half an hour. I have since moved to DROPing bad packets from there on.
 
Alright. Denyhosts disabled, blank hosts.deny file, DEFINITELY opened firewall port (I verified more times than I should have via things like the shields up tester and in each case adjacent ports were marked as stealthed but the port I have sshd on was marked at opened (they show blocked if the connection is simply refused.)

I'm wondering if it's something on this end instead? Rather than blaming the firewall, the server, or denyhosts, maybe there's something wrong on this end? Does the ssh client need incoming ports or something maybe?

EDIT: I know what it is... My stupid school is probably blocking unusual ports, such as what I'm using for sshd, and, now what I'm using for httpd... (I can't get to my web server either when before I could.) Bah, this screws up everything. I wonder if there isn't some way I can test to see which client ports are allowed through... I can't test them all one by one (or even two by two -- ssh + httpd) since by the time I figured it out I wouldn't need it anymore...
 
Nazo said:
Alright. Denyhosts disabled, blank hosts.deny file, DEFINITELY opened firewall port (I verified more times than I should have via things like the shields up tester and in each case adjacent ports were marked as stealthed but the port I have sshd on was marked at opened (they show blocked if the connection is simply refused.)

I'm wondering if it's something on this end instead? Rather than blaming the firewall, the server, or denyhosts, maybe there's something wrong on this end? Does the ssh client need incoming ports or something maybe?

EDIT: I know what it is... My stupid school is probably blocking unusual ports, such as what I'm using for sshd, and, now what I'm using for httpd... (I can't get to my web server either when before I could.) Bah, this screws up everything. I wonder if there isn't some way I can test to see which client ports are allowed through... I can't test them all one by one (or even two by two -- ssh + httpd) since by the time I figured it out I wouldn't need it anymore...


Ha fell into the trap I did. I was using port 13507 for access from work and then all of a sudden it stopped working. Changed and it to stopped working (then knockd no longer viable).

I had to go back to port 22 (and now all the script-kiddies are flodding my log)

turns out I still get some log-floods so I have started using "BlockHost" I prefer this over Denyhost (cant get denyhost woking anyway) becuase it only runs when a failed login occurs unlike Denyhost that acts like a daemon
 
Well, I found a useful tool that may have answered my question for me:

nmap -R -p1-65535 xxx.xxx.xxx

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2006-04-26
11:30 Central Daylight Time
Interesting ports on xxx.xxx.xxx.xxx:
(The 65522 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
20/tcp filtered ftp-data
21/tcp filtered ftp
22/tcp filtered ssh
23/tcp filtered telnet
53/tcp filtered domain
80/tcp filtered http
119/tcp filtered nntp
389/tcp filtered ldap
443/tcp filtered https
1723/tcp filtered pptp
8080/tcp filtered http-proxy
8100/tcp filtered unknown
8200/tcp filtered unknown
(I didn't filter the address and IP because I don't trust you people, but, because I don't trust google... Lol, the smart hackers know to use google to find their targets more easily. Heck, even the e-mail spammers do. You don't really have to be a smart hacker to realize you can google around and find some interesting stuff in various forums.)

You'll note that it explicitely says all other ports are marked as closed. Filtered, according to the documentation means it received no response while closed means it received the rejected response. Considering that I told it to scan ports 1-65535 and only those were filtered while the others rejected, those must be what the school's firewall is allowing through since it seems to be actively rejecting connections on ports like what I was using to get to my ssh server at home rather than simply filtering them. Well, I tried nmap on one site using one such port (I found some kind of chat server type thing using 8100) and it did say port open, so I consider that a good sign. Didn't really feel like downloading some random unknown chat thing and running it on here, so that's good enough for me to go on. Anyway, I guess I'll move my ssh server to one of those ports.

BTW, turns out the modem only responds to ICMP pings. Smart things like nmap will definitely see my system and consider it up just because the modem responds (even if the actual computer is down) but, less smart things like typing ping in a console use TCP ping as far as I know and they just sit there until they time out or you get tired of waiting and abort them. I'd still kill for the modem to not respond to anything at all and let my host system just handle stuff like pings (geez, they could have given us the option like they do with everything else) but, at least it is better than responding to the normal kind of ping.

EDIT: Oh yeah, and I double verified that my system was up, running, and running correctly by using the-cloak to connect to my web server, and it worked since it uses port 80 to the client.
 
LazyBastard said:
Port-knocking is not security through obscurity. Using OpenVMS is security through obscurity.
Usernames and passwords are security through obscurity, technically.

It's not that security through obscurity is bad. It's bad when it's trivial to obtain the data.
 
XOR != OR said:
Usernames and passwords are security through obscurity, technically.

It's not that security through obscurity is bad. It's bad when it's trivial to obtain the data.
Well, GOOD usernames and passwords... Come on, most of us use dumb usernames or passwords somewhere...

BTW, turns out the problem definitely was the school. I'm now using ssh and a tunneled VNC session to my server at home from a school computer. Lol, who knows, maybe I'll actually get something USEFUL done...
 
Nazo said:
Well, GOOD usernames and passwords... Come on, most of us use dumb usernames or passwords somewhere...

BTW, turns out the problem definitely was the school. I'm now using ssh and a tunneled VNC session to my server at home from a school computer. Lol, who knows, maybe I'll actually get something USEFUL done...


Well you could setup a CHROOT jail and then open a SSH to the world to see how long for it to get compromised
 
XOR != OR said:
Usernames and passwords are security through obscurity, technically.

It's not that security through obscurity is bad. It's bad when it's trivial to obtain the data.
Nah, usernames and passwords are faily common. I guess the ultimate security through obscurity would be to make your own OS. Then you can make one that doesn't use usernames or passwords. That is a much better example of STO (security through obscurity (look, I made a new TLA!)).
 
Back
Top