My arch system got cracked!

pyther · 2010-03-29 11:10:36

I'm interested if I read this thread correctly you stated you use denyhosts. Did they get on the first few login attempts? If so what was the password on the account?

print · 2010-03-30 02:42:59

@pyther yes, they did. I believe I had left it as test:test *slaps forehead.* The brute force attack was done using IP x and 10 seconds after test account login was successful, IP y logged in.

Leonid.I · 2010-03-30 15:49:44

.:B:. wrote:

Block attackers after X failed attempts
Fail2ban is already wikified; so is Denyhosts, a similar application. If you want to use iptables, I think it can be done with the 'recent' module.
Only open port on request
A fifth security measure would be setting up port knocking, but every layer adds complexity (and I find port knocking adds a lot of complexity).

Agreed, xt_recent can do dynamic blocking and port knocking. At least, I have been using this setup for a couple of months. Unfortunately, in 2.6.32.10 (xt_recent.ko) it is broken, because after an upgrade my firewall is totally locked down, and the --rcheck directive, which checks whether a given host already sent you a packet, does not work (always returns false). I don't know about complexity -- it's just 5 more lines in iptables.rules.

Regarding fail2ban, knockd and similar software, I think it violates the idea of minimalism

@print, just to get an idea, how complex was the password for the test user?

Last edited by Leonid.I (2010-03-30 15:51:30)

.:B:. · 2010-03-30 16:50:34

I agree. As I said, every extra layer is extra complexity. And that only makes the whole setup more prone to error, and harder to debug.

jimburnettva · 2010-03-30 17:40:03

MD5 can be spoofed.

print wrote:

@gazj If I'd discovered it later I'd be inclined to agree with you. However, I have two up-to-date systems here and I compared the md5sums ofthe /bin and /usr/bin binaries on the compromised machine with the uncompromised machine and they are all the same. Plus I caught them after 20 minutes, and they were just running some stupid port scanning crap out of /var/tmp. They wouldn't have been able to escalate privileges that quickly and the permissions on my user directories are all locked down.
@wonder I updated it to note that they hackers were coming from a computer in Romania, not that they were necessarily in Romania. But I wouldn't put it past you . . .

stryder · 2010-03-31 00:44:53

print wrote:

I believe I had left it as test:test *slaps forehead.*

The topic should have said "My username:password got cracked". Obviously test:test is high on the list and denyhost didn't have a chance to kick in.

Leonid.I · 2010-03-31 15:16:34

stryder wrote:

print wrote:
I believe I had left it as test:test *slaps forehead.*
The topic should have said "My username:password got cracked". Obviously test:test is high on the list and denyhost didn't have a chance to kick in.

Ahhh. so the password was test! I missed that.

I wonder though how good their dictionaries are, for instance would "Te:St;" be easily broken?

Rorschach · 2010-04-05 13:50:01

wow people here really use denyhost and failed2ban? What's the reason for this except making it easier for people to DoS your machine?

As already said: just use a secure password!

If you use denyhost for the only reason I can understand (prevent spamming of logfiles with skiddies doing some bf...) just filter those out with your own scripts before lessing the logfiles...

Oh and when I'm remembering correctly denyhost itself had some serious security-problems in the past... it's the same as using userland-firewalls on windows.. you're raising more securityholes with such things then you prevent.

pyther · 2010-04-05 13:55:19

I fail to see how using fail2ban or denyhost is bad. How does it make it easier to DoS machine?

Rorschach · 2010-04-05 14:12:52

You have an additional software-layer, using cpu-time and memory, processing incoming packets.

pyther · 2010-04-05 14:17:02

Really it's just checking a log file

http://denyhosts.sourceforge.net/faq.html#1_5 wrote:

When run for the first time, DenyHosts will create a work directory. The work directory will ultimately store the data collected and the files are in a human readable format, for each editing, if necessary.
DenyHosts then processes the sshd server log (typically, this is /var/log/secure, /var/log/auth.log, etc) and determines which hosts have unsuccessfully attempted to gain access to the ssh server. Additionally, it notes the user and whether or not that user is root, otherwise valid (eg. has a system account) or invalid (eg. does not have a system account).

Rorschach · 2010-04-05 14:28:12

Oh you are right, I always thought that those tools would do packetinspection and never gave a deeper look at them!

As I have read now denyhost, checks the log every 30secs by default... Thus you have a 30sec timeframe to bruteforce per IP. Which means even with a small botnet of 70000 bots and everyone can do 10 attempts per second you have 21 million attempts to guess the correct password.

Next to that you can try to get the log such full that denyhost can't process it before a new denyhost-process is running thus resulting in a "memory-leak" like scenarion.

You should also be aware of logfile-injection and a short google revealed that denyhost was vuln to it: http://www.ossec.net/main/attacking-log … #denyhosts .

Also if my initial statement that they increase the risk of DoS is wrong, I'm still having the opinion that those tools don't help and make more worse than good.

Last edited by Rorschach (2010-04-05 14:29:49)

OrangeRoot1000 · 2010-04-05 14:39:31

Fail2ban and the like are scripts to insert into your iptables chains/rules. F2B will NOT make large logs in fact they shorten them. Bots like to hit machines at thousands of times a second. If a certain IP hits a box 3x in less than X secs. It will be marked and banned for a 15 minute time period. Usually this takes all the fun out of trying to do anything to a box.

My understanding of a DDoS is not having packets hit a box. A proper IPTables can DROP a packet and the originator never even knows that the packet found anything. It's the *poof* factor. A DDoS is when a packet or series of them "SUCCESSFULY" enter the network in question and get some kind of activity out of the kernel, CPU, hard disk, apps. With that activity it gets SOOOO overwhelming that it can slow down processes running or even bring the box down. NMAP can sniff all day at my ports in rapid succession that's NOT a DDoS.

deny.hosts is like /etc/groups or polkit or consolekit... its just a list telling who has permission to enter the network.

VampirePenguin

Rorschach · 2010-04-05 14:52:34

@OrangeRoot1000: "If a certain IP hits a box 3x in less than X secs. It will be marked and banned for a 15 minute time period. Usually this takes all the fun out of trying to do anything to a box."
In theory but in practise you have all the time until denyhost and fail2ban check the log and not just the X secs.

A DoS is simply: making the cpu use so much cpu-time or memory to make the system unresponsive. If this cpu-times is eaten by iptables because it has a huge blacklist of hosts to check against every package destination or a userland-processes like apache or the ssh-server doesn't matter.

A great deny.host-file has to be checked for every newly opened tcp-connection and udp-stream. This eats time and cpu.

The more layers you add in front of you service, the more layers are there which can create cpu-time and eat memory and make you machine unresponsive.

Last edited by Rorschach (2010-04-05 14:52:51)

OrangeRoot1000 · 2010-04-05 14:57:26

F2B and SSHGuard are instantaneous... No waits. Always UP... and still NOT inside the network. My IPTables set up even under "attac" is .1% CPU .1% memory... nothing to bother with and a very healthy level.

VP

OrangeRoot1000 · 2010-04-05 23:07:10

@ print

Unless the 32 bit ssh/sshd configs are different the only "bug" was you my friend. There is NO allowusers line in either file by default in the 64 bit and when I was running 32 DEbian, Slack, Arch, SourceMage, Sabayon, etc etc.. it was never there either. The sys admin MUST add it to the file. The proper syntax is
AllowUser blah blah blah

If you try to place on mulitple lines the sshd will generate syntax errors with the file.

I have little faith in in using "off" ports. Nmap knows all unless you have it hid by port knocking. Though using anything above the 2000 UID is outside of root permissions and into userland permissions.

If they got in your box for 2 minutes or for the past two years. The fact is the WHOLE OS is compromised, and depending on how vital your data is and if it was encrypted or open during the cracking is compromised also. The "suggestion" to reinstall would be much heeded...

Consider this I will tell you what IS standard in a sshd_config file. Root Logins = yes, UsePam = Yes... Think about it. PAM is meant for fine granular access denial and control of a box. They cracked it with PAM running. I wouldn't trust anything on it if it was a production machine.

I personally like to use passphrases -- ie there are 26 characters to each place value so using a 50 character passphrase is 26^50 that must at a minimum be used in computing power to "crack" that phrase. I do think that Arch lacks in one area that sad to say even Ubuntu is ahead in. The /etc/shadow files are still in MD5... major poor choice. Easy Peasey is a minimum SHA256 for sudo, and all other passwords. I change all mine to SHA512 on installs. It is possible with a kernel modification to have Blowfish as standard. OpenBSD uses Blowfish as standard for its files.

I like keys IF they can't be accessed by others physical prescence, AND if for some funky reason your "reliable" system backups you're supposed to be making don't get scrambled and render the keys useless. I have for example a tar.lzma file with scrypt that has a long, long, long passphrase just incase I need it. I still used bcrypt also which is a quick oneliner like scrypt, self contained and portable. bcrypt is 448 bit blowfish, scrypt I have not been able to find the bit value but their salts are in major conventions and trials said to be 100x greater than bcrypt.

I could give some wonderful stories over the past 6 months about encryption and data failures. Let's say I just lost 250GB of files. Was it important to me, yes. Will the world end, no. But if it was a business it is well known that a complete failure of computer systems that result in total loss of company assests. The companies usually are out of biz in less than a year.

Okay.... laters. Good luck.

VampirePenguin

Arch Linux

#26 2010-03-29 11:10:36

Re: My arch system got cracked!

#27 2010-03-30 02:42:59

Re: My arch system got cracked!

#28 2010-03-30 15:49:44

Re: My arch system got cracked!

#29 2010-03-30 16:50:34

Re: My arch system got cracked!

#30 2010-03-30 17:40:03

Re: My arch system got cracked!

#31 2010-03-31 00:44:53

Re: My arch system got cracked!

#32 2010-03-31 15:16:34

Re: My arch system got cracked!

#33 2010-04-05 13:50:01

Re: My arch system got cracked!

#34 2010-04-05 13:55:19

Re: My arch system got cracked!

#35 2010-04-05 14:12:52

Re: My arch system got cracked!

#36 2010-04-05 14:17:02

Re: My arch system got cracked!

#37 2010-04-05 14:28:12

Re: My arch system got cracked!

#38 2010-04-05 14:39:31

Re: My arch system got cracked!

#39 2010-04-05 14:52:34

Re: My arch system got cracked!

#40 2010-04-05 14:57:26

Re: My arch system got cracked!

#41 2010-04-05 23:07:10

Re: My arch system got cracked!

Board footer