how easy is it to disguise your IP address so to say that the intruder wasn't really at 82.79.116.77 or would it be more a case of 82.79.116.77 already being hacked and using that box as a mask to attack mine?

Yeah, don't be hung up on the culprit being physically in Romania.

For future security, you should examine your true business needs and come up with a comprehensive security policy. This is a big part of my job--preventing just this sort of thing.

One of the basic suggestions I can offer is to consider using a VPN and disallowing all remote access that is not authenticated/tunneled by the VPN. You can have greater control with shared keys, or at least extra-tough passwords for the VPN users (different from their system passwords). It can be done pretty economically.

IMO, it's more likely the latter then the former. I also wouldn't expect that box to be the first link back to the original machine either.

Off the top of my head, I cannot thing of a way to spoof an IP when connecting directly to a service like ssh. However, I'm neither a hacker/cracker, nor a trained computer forensic tech.

Here are some of the ways...

1. Buy an account on a server in that country. Server space is cheap in most countries. Security is lax.
2. Use an anonymizing or tunneling service. Hacker groups have them for use by their members.
3. Gain access to a zombie or network of zombies. It's not that hard.
4. Crack another account, and use that to bounce your attacks from.

I was ops manager for an ISP in the past, and now do a lot of security work. You might be shocked at how easy it is for someone with ill intent to launch a semi-anonymous attack. The new legions of zombied Windows XP workstations are going to be a huge problem for everyone soon. Right now they're mostly used to send phishing spam, but I expect they will be used for much more soon.

I see DDoSes in Microsoft's future. :(

On X.3.5, setting these two config options causes ssh to fail. What version of ssh and/or sshd are you using?

Trevor eventhough the command execution is blunt and crude which could point to a person in a hurry or suffers from poor unix commands the fact that they contolled it via a potential hacked box in Romania (I am not hung up on the Romanian thing - but it did come from there) shows that they have some nouse on cracking.

Well, you would think that would be true, and I really wish it were. Unfortunately, due to Microsoft's incompetent "secure" programming, Windows boxes are easily susceptible to viruses and worms that open large gaping back doors that any script kiddie who can download a couple of programs can exploit. Basically, there are literally millions of pre-compromised boxes sitting on the Internet available for just anyone to take over and do anything they want with.

So, if a disgruntled employee at your workplace shoulder surfs you to get the root password, and wants to get revenge for some past tussle with you, he could easily just find some compromised Windows box to bounce off of before hitting your XServe. This would make him think nobody can trace him.

Trevor

aubreyapple, I have PermitRootLogin no set in my /etc/sshd_config file in OS X 10.3.5 without any failure of ssh or sshd. I am using the versions of ssh and sshd that ship with OS X. I don't use the AllowUsers directive, though, perhaps that is the problem in 10.3.5?

Trevor

OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090704f

OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090704f is my installation. Wierd.

I am two security updates behind, so maybe it is in there. I do not have 2004-09-07 or the next one. Too many people reporting the latest ones
break things, I guess.

You might find out why if you put sshd into debug mode via the -d option.
Note that you will have to restart sshd after each connection when it is in this mode.

Ok, first of all, the version of ssh I had was:
OpenSSH_3.6.1p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

Updated the security updates and now my version agrees.

However, ssh out still fails with PermitRootLogin no. I do not see that
sshd is involved with this failure.

Oddly enough, ssh inbound is ok with this line in the file. It is ssh outboud which fails and sshd does not run when ssh is working outbound.

And is the PermitRootLogin no set in your ssh_config or your sshd_config?

Actually, perhaps this needs to be in a new thread...

Trevor

I am blind... aha sshd_config not ssh_config. That works and has the desired effect.

Nah, it doesn't sound like your IT guys to me. I'd go over there with a box of donuts sometime and see what they think of your situation. IT guys like this kind of thing. And they like donuts.

;)

Anyway, I am concerned about your new security policy.
So what this means is if they stumble across one of your account names, you have allowed them to create a DoS attack on that account. You may end up with more phone calls than you want from any user with a guess-able name. You can easily tell what usernames they are using by grepping them out of the logs. If you think your account names are safe, fine. Just be aware of this type of risk.

And as MervTormel once said... :)

.

God I miss Merv!

Anyway, I still don't think it's an inside job. Are the IT guys good enough to fake their IP? Granted I have only been on Unix since OS X came out, but I am far from that good. I doubt someone that competent would wipe your hard drive with such poor grammar. They'd screw with you a bit first. If I this was personal and I knew a whole lot more than someone I didn't like, I'd let 'em know. :cool:

Unless you're busy pissing off more than just the IT people at your office. :rolleyes:

I like to think I'm pissing no one off - but I have had a couple of bad things happen recently;

got the svchost.exe worm on a Win2000 box Domino web enabled,
then a root kit installed on a RHEL WS 3 which aslo had SSH open, couldn'tget the logs on that one,

the 3 incidents happnened on separate LANS but connected by a national WAN.

all this in one month and nothing prior in 5 years.

Yeah, CAlverez made note of larger scale incidents. What's a RHEL WS 3?

RHEL WS 3

Red Hat Enterprise Linux Workstation

(used as a accucobol based financial transaction server)