Tag Archive for 'Open Source'

Slackware 11.0 Release Candidate 5

Slackware 11.0 Release Candidate 5 is here. Lots of updates to existing packages. Not many packages were upgraded. Patrick is giving the scouts honor that this will be the last RC before 11.0 final.

Head on over to the Slackware Blog to have a look at the full changelog entry. Hopefully we will see Slackware 11.0 released sometime next week or maybe even by the end of the week since we’ve seen such a long RC cycle. I don’t think we’ve seen anything greater than RC2 since Slackware 9.0 or so. It’s been a while since we’ve seen this many release candidates.

Popularity: 6% [?]

Slackware 11.0 Release Candidate 4

Slackware 11.0 Release Candidate 4 is out! This release sees kernel 2.4.33.3 included as the default. Soon after RC4 was made, Patrick made another small update to the ChangeLog:

Sun Sep 3 19:59:47 CDT 2006
a/udev-097-i486-8.tgz: Fixed a missing ‘[’ in rc.udev. Thanks to
guilherme for pointing out the error, and to J., who found the missing
‘[’. (It had fallen off my desk and ended up under a table)
kernels/System.map: Forgot to gzip a bunch of these. Thanks, Steve’o.

This should definitely be the last RC before Slackware 11.0 final is released. In the past two or three Slackware releases (10.0, 10.1, and 10.2), we’ve only seen 2 or 3 release candidates. I suppose there’s a chance we’ll see RC5 this time, but I’m thinking this RC4 will be the last. Probably see Slackware 11.0 final within a week and a half or so.

Popularity: 4% [?]

Slackware 11.0 Release Candidate 3

Slackware 11.0 Release Candidate 3 is here!! The 2.6 kernel was moved from /testing/ to /extra/. What’s that mean? Not much really, other than it’s considered to be more stable since it’s now in /extra/.

Head on over to the Slackware Blog for more details.

Popularity: 5% [?]

More SSH Brute Force Protection

Stopping SSH Brute Force Attacks resulted in some really great comments and suggestions from readers.

So, this is a follow up to the last SSH brute force post. I didn’t realize there was such a wide selection of applications for dealing with this, but there is! The two best looking options in my opinion are Fail2ban and DenyHosts.

I’ve actually started using DenyHosts on two machines now, and it’s working very well. I chose to go with DenyHosts for a very simple reason. Community stats. I love stats.

Anyway, if you’re looking for something to protect against ssh brute force attacks, go with Fail2ban or DenyHosts, they’re still being actively developed. I can’t say the same for Breakinguard, as it appears to have been abandoned about 1 year ago. And like I said, DenyHosts does it’s job extremely well, I couldn’t ask for anything more.

If you’re looking for another solution, try using cryptographic keys instead of passwords. A tutorial on configuring SSH to look for keys instead of passwords can be found here. This was suggested by commenter pwyll.

Oh, and this is the 700th post. yay!

Popularity: 7% [?]

Stopping SSH Brute Force Attacks

A few weeks ago at work, I noticed a bunch of failed login attempts to one of our Linux servers. After doing some investigation, I found that no intrusion had actually been made, which is excellent. Lines similar to this were filling my /var/log/messages log file:

Aug 20 23:31:26 elixer sshd[22526]: Failed password for invalid user alias from 66.166.22.186 port 26217 ssh2

Notice they’re trying to login with the username “alias”, which doesn’t exist on that system. In fact, all the usernames attempted don’t exist, which makes me feel a little safer. Still, I don’t like seeing my boxes actively attacked. So, to stay on top of these breakin attempts, I installed Breakinguard.

Breakinguard basically watches your log file for any failed login attempts. You can set a pre-defined number of attempts that can be executed before breakinguard will block the IP.

The Package itself does a ‘tail -f’ of your syslog, and when it identifies a matching line within your logs, it logs this ‘attempt’. If more than the pre-defined number of attempts from the same IP address are received it triggers the iptables (or any other block method defined) block and also emails you notification.

I’ve never been able to get the configure script to work for me, simply because the perl module installation always fails. So, to get around that I simply installed these perl modules manually and commented out these lines in the configure script:

$PERL -MCPAN -e "install File::Tail"
$PERL -MCPAN -e "install IO::Socket"

Those two lines execute perl and try to install the File::Tail module and the IO::Socket module. After manually installing the perl modules below and commenting out the lines above in the configure script, the configure script should run and do it’s thing without error.

File::Tail
IO::Socket


After the configuration script has run, you should have a couple new files, /etc/breakinguard.conf and /etc/rc.d/breakinguard. Now, the /etc/breakinguard.conf file stores the breakinguard configuration. This is where you tell breakinguard which log file to monitor and how many incorrect login attempts are defined as a breakin.

I’m not going to bother going through all the options in breakinguard.conf, simply because they’re all explained pretty well within the conf file.

The other “new file”, /etc/rc.d/breakinguard is the script used to launch breakinguard. Run “/etc/rc.d/breakinguard start” to start breakinguard.

Once breakinguard is running, it will monitor whichever log file you specified in /etc/breakinguard.conf (/var/log/messages in my case). When it sees a failed login attempt, it will be noted. Now, when an IP fails a certain number of logins, iptables will be called to block all traffic from the IP.

Below is an example email that’s generated by Breakinguard when it blocks an IP:

BreakinGuard has blocked an IP based on suspicious activity
Please review this server.

Detail:
Hostname: elixer.hostname
IP Blocked: 202.82.16.180
Last log entry that caused the block:
Aug 22 06:17:05 elixer sshd[25591]: Failed password for invalid user alias from 202.82.16.180 port 45340 ssh2

Popularity: 7% [?]

Slackware 11 Feeling Official

Slackware 11.0.0 is really feeling “official” now for me. Yesterday, Patrick made an update to the -current ChangeLog stating he had bumped the /etc/slackware-version number up to 11.0.0. I had been waiting for him to bump that version number up. Now that he’s done so, I know Slackware 11.0 will be out soon. I am excited.

Popularity: 3% [?]



cheap xbox 360 games - buy from zavvi
cheap xbox 360 games - zavvi

mobile phones - Web Design - Loans - Renegade motorhomes - Remortgage - Mortgages
Mobile Phone - Bike Insurance - Landlords Insurance - Search Engine Marketing - Mobile Phone