Now I can not connect to the web through my browser or any other way
What error message do you get?
Did anything regarding your CP show up in the logs?
Are any new users added to the system authentication database?
Are there any (setuid) binaries in /tmp or /var/tmp (or any place where daemons/users have write access)?
Are there any unusual processes running?
Did you notify the hosting company (please do)?
when I go through my Security Log I can see a whole bunch of sshd and xinetd connection attempts couple of which are in fact successful
Xinetd is a superserver. It usually doesn't serve stuff for itself (on public interfaces) but acts like a broker for other services (first thing I regularly set up for myself is an IP ACL'ed OpenSSH on a high port). The question is what services those attempts where for, if those services where/are publicly accessable and what shows up in the logs (post, if any). Same for OpenSSH.
Please try to provide as much info as you can.
What should I do to protect my server and fix the connection problem? I am running RH Enterprise Linux 3.
Basically what you need to do is to define the purpose of the box (single purpose boxen are by nature relatively easier to harden and manage), minimise risks by deinstalling any daemon, system, config or helper apps (and dependancies) that are not linked directly to the purpose of the box, secure system and service access by using inert login shells for system service accounts, disallowing root (v)tty access, PAM access lists on unprivileged user accounts necessary for management, using separate (ie not using the system's auth db's) authentication databases for users that only need access to FTP (please consider ditching FTP in favour of SCP/SFTP) or POP/IMAP, remounting partitions like /usr read-only if you can, remounting /tmp, /var/tmp with noexec,nodev,nosuid flags (if available as separate partition, and might break some apps), denying access to management services by using TCP wrappers, daemon and Xinetd config option/user/IP ACL's and the firewall (not OR). This is not a full list, but it'll give you some idea what's involved. So. There you have it. Seems there's a lot to do, right? Maybe now is the time to first read up on securing your box: check out the
LQ FAQ: Security references, post #1.
But for now you should concentrate on regaining access to the box. If the box was hacked, it'll probably be used for stashing warez or IRC mischief. Anyway the bandwidth bill will be yours. What you want is to regain control as fast as possible, and if you fail doing that by yourself with help from us, asking the hosting company to set things straight is your only I said ONLY option. And DO NOT put off that decision for too long (24hrs from when you discovered the problem would be my max). Letting the hosting company set things straight probably will cost you money, but (and this may sound bad, but we all got lessons to learn, right) think of it as the price you pay as a newbie for thinking you can securely run Linux w/o putting in effort to harden a box.
Please note: when you ask the hosting company to fix things for you, make sure that if it can be proven the box was hacked you should (have the hosting company) transfer your database, system and app configs, authentication files, system and application logs, shell history files off the box (no binaries or stuff you can't read outside database dumps or login records) and re-install from scratch first. There is no alternative for that, and it is no point asking for any. We're always willing to help you with stuff, but please do not waste time on forensics if you haven't got loads and loads of time and at least some experience.
