hi friends, i have a problem at the time of entering the machine remotly with ssh ex.: :~# ssh [email protected] it appears the following error :~# ssh_exchange_identification: Connection closed by remote host I approached the machine to see what happened physically, and it surprised to me that it could not either enter from the same machine, what it makes me think that they did to crack to /etc/shadow and /etc/passwd files. the problem is how entering to the machine because i not have the root user or another one ... please i need help because this machine is a production server, with to much email account's and resellers, etc .... ahhh.. the email accounts don't work, the reseller account either... thank i dont know resolve the problem .... the machine is a Gnu/Linux Debian 4.0 with all updates and ispconfig 2.2.14 like only resource...
Boot into single user mode, which automatically puts you in as root, then set your password with the passwd command.
you can always use a live cd and then mount / chroot to your linux partition but keep close a live cd (always helpful)
ok, but the problem is that two users only exist the root and ispconfig that they can modify this files, then can i to control the ispconfig user so that it does not have east permission???,
The ISPConfig user (admispconfig) can not modify /etc/passwd and I dont think that your server has been hacked through ISPConfig. You should use a rescue cd to start the server, mount the harddisk and have a look at /etc/passwd and /etc/shadow and check if the yare correupted, also check the syslog and auth.log what caused your SSH connection to fail. There are may other possible reasons, e.g. a full harddisk partition that has the same symptoms that you described.
it already fixes the problem, in any case what they did it was to modify the shadow, password, gshadow and group files, for that reason I think that it can have been through ispconfig server, because no other user has the possibility of modifying these files. The other errors that appeared they were by the same problem, i solved the problem entering in single mode, and replacing the archives modified with those of backups old files, but now it appears in the name of session, to initiate the session in ssh for example, a messages as : I have no name!@machinename:~$ I did not solve this problem yet ... well my friend i will continue analyzing this and other problems and i'm writing them ... thank you for all the answers ... greetings albertux
That is some coincidence... I had EXACTLY THE SAME HAPPEN 15TH OCTOBER... I am now sitting and installing fedora core 6 and installing Pleask.. sorry but I need to feel safer.. I set up a catchall email on one of the webs, after the catchall was set NONE of my passwords worked.. could not ssh into it.. would not accept root user single mode... nothing nada... 120 km drive, get the box .. install FC6 .. Too much of a coincidence? Could there be a problem with ispconfig security here?
There is no known problem with ISPConfig security. If you claim that there is a security problem, you should proove this and provide a bit more info. Did you had a look at the logfiles and /etc/passwd and /etc/shadow? And by the way, you forgot how many ISPConfig installations are out there. If 2 installations of several ten thousand have the same issue, it is statistical just a coincidence.
really i dont know, it is the first time than happens somethings to much great and burden, other times I had problems with mambo server for the bugs of security but never with the characteristics to put in danger all the system, and still i believe that it was throungth ispconfig, because of the rest of my Gnu/Linux Debian Etch it's update completely and similar errors have not been reported in the community... Specially i create and guarantee the ispconfig server because, to part of this event, never it had had some other problem before, therefore i will continue using it ... although it is much coincidence really grettings P.D. Fedora Core it gives but insecurity me that any other package
It might be a bug in ISPConfig but I really doubt that it was a hack. Teveo1 said that he has changed a thing himself and was not able to login afterwards. So if he dont call himself a hacker, then its most likely not caused by a hack. It is much more likely that e.g. the /etc/passwd file was corrupted or something similar. But as he was not able to provide any additional information nor ask for help, we can not find the cause for the problem.
i am not claiming, i am asking.. that is a difference i have used the system for 2 yrs with no big problems, however i did get the same problem just 2-3 days after "albertux" and that is at a minimum strange. i am checking the password files now.. it may be these but the only service being used on this box was ispconfig and by changing one users password (through ispconfig) and same time setting up a catchall for him.. this incident occured.. my /etc/passwd have rw r r attributes my /etc/shadow only have r for root... what should it have ? same attributes as /etc/passwd ??
The attributes are fine, the question is more the content. Run the following commands to check the syntax: pwck grpck and check if the root account looks fine. To check if your system has been hacked, install and run "rkhunter". Also have a look at /home/admispconfig/ispconfig/ispconfig.log if it contains any errors and which actions are recorded there, as the problem occured. The ISPConfig interface is not run with root priveliges, so a hack trough the interface will not allow to run anything with root permissions easily. And everything that is run throgh the daemon part is recorded in the logfile.
thanks. i am trying the commands.. no success, pwck only reports "user pcap: directory /var/arpwatch does not exist" .. corrction running on /etc/passwd reports all users like this.. user web14_max: directory 7 does not exist user root: directory 7 does not exist
Thats uncritical. And the server you run this is still the same with ISPConfig installed that denied you the login? What is recorded in your auth.log or syslog as you tried to login?
yep, the problem it's that the files : passwd shadow group gshadow they corrupt nothing else, i did, was to initiate the machine in single mode and paste the backups files of the files in the etc directory ... and the problem "i have no name" it was solved when I put the necessary permissions to him ... nothing else. you are right that can be a worm or something but as i can find, it or as I can review more meticulously, since in logs he does not appear nothing... you know, could have been a negligence of openssl 0.9.7, that has shown security problems, but strange it it is that I have everything updated from the beginning of the operation of ispconfig. now it can be a tiny bug or worm, because it does not let to me update the version from the panel in the port 81 of ispconfig server, it I can only do from the console untar the file and installing again... some idea ????
Do you have still the corrupted files or can you tell me any details about the corruption? ISPConfig can never be updated from the contropanel, because the controlpanel does not run as root user. To uopdate ISPConfig, you must login as root user on the shell, unpack the installer files and run the setup script.
from what I see.. everyone now is group 7.. eg.. ... :7:::: in the end in the shadow file for all my users i did not find much relief on google either... your conclusion is right i guess, there is a problem with some of these files.. i dont have any backup of the old shadow/passwd so i have to fix what i have the files are all fine and readable.. the box is at my desk (a noisy bastard!! ) but it does not start much services due to it not finding users, i ran it with rescue mode earlier and transferred all my important data (webs, databases etc ) The FC5 -> FC6 went fine but of course the main problem was not solved. i will check the logs now..
ahhh ok thanks, ... you know, , I analyzed my version of openssl, and he is 0.9.8c, that it does not have security holes, but can be reason why I have read, that has modified me the archives before updating openssl and day 16 activated all ... greeting and thanl you for your aid
