Rebooting
in [Suse]
|
From: Dennis Golden on 17 Jul 2010 09:28 On Fri, 16 Jul 2010 22:01:46 -0500, Moe Trin wrote: > On Fri, 16 Jul 2010, in the Usenet newsgroup alt.os.linux.suse, in > article <20100716133254(a)usenet.waxborg.local>, Vahis wrote: > >>houghi <houghi(a)houghi.org.invalid> wrote: > >>> David Bolt wrote: > >>>> My router blocks that. I only allow ssh from a very select few IP >>>> addresses, so haven't had to worry too much about break-in >>>> attempts[0]. > >>> I also do not worry about SSH break in attempts. SSH is secure. I just >>> use BlockHosts to keep my logfiles clean. > > Is anyone maintaining that Self-Denial-Of-Service tool? Last I looked > it hadn't been revised since 2008. But then the other similar log > readers ('blocksshd' last revised 2008, 'DenyHosts' last revised 2006 > and 'fail2ban' last revised 09/2009) aren't any better. You guys might look into OSSEC HIDS. It is actively maintained. >>Same here. > > Hope you are using 'sane' expire times. A system with several hundred > individual host block rules - either in the firewall or libwrap - isn't > going to be the fastest thing in town. A ten minute block is usually > more than enough to discourage 'bots and skript kiddieZ. OSSEC does this automatically. <snip> > Old guy -- Dennis Golden Golden Consulting Services Change 'invalid' to 'com' to reply by email.
From: Moe Trin on 17 Jul 2010 17:03 On Sat, 17 Jul 2010, in the Usenet newsgroup alt.os.linux.suse, in article <slrni42sva.4c8.houghi(a)penne.houghi>, houghi wrote: >Moe Trin wrote: >> Is anyone maintaining that Self-Denial-Of-Service tool? Last I >> looked it hadn't been revised since 2008. >Those tools are (to me) NOT about security, but about keeping my >logfiles clean. Your system - your rules >> Hope you are using 'sane' expire times. A system with several >> hundred individual host block rules - either in the firewall or >> libwrap - isn't going to be the fastest thing in town. >I never had "several hundred" block rules. At most I had about 20 >and that includes the ones I put there. Never had an issue with >speed as well. Most "attacks" come from zombie hosts - often on "residential" network providers. All of these log reader tools can be set to permanently block an attacking address (it's the default configuration on most of the tools as written), and that does indeed add up. >> a simple port knocking technique acts as an _additional_ block >> (still need the "regular" authentication scheme _after_ the port >> knock tells the server to unblock the firewall for "this" address >> for a minute). >Way to much work for me Not only trivial, but a number of scripts to handle this exist on the web. >and it still is (for me) security through obscurity. Yeah - everyone sees the phrase "port knocking" and seems to stop reading at that point - ignoring that it's not used as a _substitute_ for proper identification. It's an additional hoop you have to jump through to get connected - no less. >Either ssh is safe and you can use it, or it isn't safe and you can't >use it. Hope your daemon is up to date and that you're not using a proxie. >Also it isn't a situation of 'OR/OR' it can be 'AND/AND'. So you can >do the following: It helps to think about it - most people don't >1) Allow always from certain fixed IP adresses Always >2) Block always other IP ranges (Russia, China, USA. Places where > you will NEVER go to) Main problem with that is that IP addresses are not allocated/assigned in a convenient manner. [planck ~/IP.ADDR/stats]$ zgrep RU [ALR]* | cut -d' ' -f2 | cut -d'.' -f1 | sort -nu | column 2 78 82 86 90 94 188 212 46 79 83 87 91 95 193 213 62 80 84 88 92 109 194 217 77 81 85 89 93 178 195 [planck ~/IP.ADDR/stats]$ First octet of networks registered in Russia. China is even worse: [planck ~/IP.ADDR/stats]$ zgrep CN [ALR]* | cut -d' ' -f2 | cut -d'.' -f1 | sort -nu | column 1 61 114 119 124 162 180 202 219 27 110 115 120 125 166 182 203 220 58 111 116 121 134 167 183 210 221 59 112 117 122 159 168 192 211 222 60 113 118 123 161 175 198 218 223 [planck ~/IP.ADDR/stats]$ and that's ignoring Hong Kong, Macau and Taiwan. Then there is the point that the country of registration is not a reliable indication of the actual location of the host. >5) Run sshd on a different port(1) >(1)Some people I know MUST do this as their provider blocks everything >below 1024. Others must run it on 443 as their work-enviroment blocks >it. You can run http and ssh both on port 80. Run into the opposite problem - and it's also a problem with port knocking. Many of the businesses I deal with block outgoing to ports other than a few "well known" ones. (But then, we also block access to "residential" address ranges - foiling the idiots who try to work around our firewalls.) Old guy
From: Moe Trin on 17 Jul 2010 17:04 On Sat, 17 Jul 2010, in the Usenet newsgroup alt.os.linux.suse, in article <Sdi0o.36718$Ls1.21241(a)newsfe11.iad>, Dennis Golden wrote: >Moe Trin wrote: >> Is anyone maintaining that Self-Denial-Of-Service tool? Last I >> looked it hadn't been revised since 2008. But then the other >> similar log readers ('blocksshd' last revised 2008, 'DenyHosts' >> last revised 2006 and 'fail2ban' last revised 09/2009) aren't any >> better. >You guys might look into OSSEC HIDS. It is actively maintained. I looked at 1.6.1 (seemingly October 2008), and wasn't impressed. The documentation was pretty poor, and I'm really not into IDS that depend on finding specific filenames and strings. The old classic in this is things like rkhunter and chkrootkit (and OSSEC operated the same way) looking for a specific file/directory (/tmp/.../r or /tmp/.../a for the 55808 worm) - never thinking that the malware author might do something highly technical like changing the file/directory name (to /tmp/.../R or /tmp/.../b) or similar. Old guy
From: Dennis Golden on 18 Jul 2010 09:48
On Sat, 17 Jul 2010 16:04:00 -0500, Moe Trin wrote: > On Sat, 17 Jul 2010, in the Usenet newsgroup alt.os.linux.suse, in > article <Sdi0o.36718$Ls1.21241(a)newsfe11.iad>, Dennis Golden wrote: > >>Moe Trin wrote: > >>> Is anyone maintaining that Self-Denial-Of-Service tool? Last I looked >>> it hadn't been revised since 2008. But then the other similar log >>> readers ('blocksshd' last revised 2008, 'DenyHosts' last revised 2006 >>> and 'fail2ban' last revised 09/2009) aren't any better. > >>You guys might look into OSSEC HIDS. It is actively maintained. > > I looked at 1.6.1 (seemingly October 2008), and wasn't impressed. The > documentation was pretty poor, and I'm really not into IDS that depend > on finding specific filenames and strings. The old classic in this is > things like rkhunter and chkrootkit (and OSSEC operated the same way) > looking for a specific file/directory (/tmp/.../r or /tmp/.../a for the > 55808 worm) - never thinking that the malware author might do something > highly technical like changing the file/directory name (to /tmp/.../R or > /tmp/.../b) or similar. > I'm running 2.4.1 and out of the box it will kill an sshd brute force attack in no more that 7 tries. Dennis -- Dennis Golden Golden Consulting Services Change 'invalid' to 'com' to reply by email. |