brute force Archives - ☩ Walking in Light with Christ - Faith, Computing, Diary ☩ Walking in Light with Christ

Posts Tagged ‘brute force’

Maximal protection against SSH attacks. If your server has to stay with open SSH (Secure Shell) port open to the world

Thursday, April 7th, 2011

Brute Force Attack SSH screen, Script kiddie attacking
If you’re a a remote Linux many other Unix based OSes, you have defitenily faced the security threat of many failed ssh logins or as it’s better known a brute force attack

During such attacks your /var/log/messages or /var/log/auth gets filled in with various failed password logs like for example:

Feb 3 20:25:50 linux sshd[32098]: Failed password for invalid user oracle from 95.154.249.193 port 51490 ssh2 Feb 3 20:28:30 linux sshd[32135]: Failed password for invalid user oracle1 from 95.154.249.193 port 42778 ssh2 Feb 3 20:28:55 linux sshd[32141]: Failed password for invalid user test1 from 95.154.249.193 port 51072 ssh2 Feb 3 20:30:15 linux sshd[32163]: Failed password for invalid user test from 95.154.249.193 port 47481 ssh2 Feb 3 20:33:20 linux sshd[32211]: Failed password for invalid user testuser from 95.154.249.193 port 51731 ssh2 Feb 3 20:35:32 linux sshd[32249]: Failed password for invalid user user from 95.154.249.193 port 38966 ssh2 Feb 3 20:35:59 linux sshd[32256]: Failed password for invalid user user1 from 95.154.249.193 port 55850 ssh2 Feb 3 20:36:25 linux sshd[32268]: Failed password for invalid user user3 from 95.154.249.193 port 36610 ssh2 Feb 3 20:36:52 linux sshd[32274]: Failed password for invalid user user4 from 95.154.249.193 port 45514 ssh2 Feb 3 20:37:19 linux sshd[32279]: Failed password for invalid user user5 from 95.154.249.193 port 54262 ssh2 Feb 3 20:37:45 linux sshd[32285]: Failed password for invalid user user2 from 95.154.249.193 port 34755 ssh2 Feb 3 20:38:11 linux sshd[32292]: Failed password for invalid user info from 95.154.249.193 port 43146 ssh2 Feb 3 20:40:50 linux sshd[32340]: Failed password for invalid user peter from 95.154.249.193 port 46411 ssh2 Feb 3 20:43:02 linux sshd[32372]: Failed password for invalid user amanda from 95.154.249.193 port 59414 ssh2 Feb 3 20:43:28 linux sshd[32378]: Failed password for invalid user postgres from 95.154.249.193 port 39228 ssh2 Feb 3 20:43:55 linux sshd[32384]: Failed password for invalid user ftpuser from 95.154.249.193 port 47118 ssh2 Feb 3 20:44:22 linux sshd[32391]: Failed password for invalid user fax from 95.154.249.193 port 54939 ssh2 Feb 3 20:44:48 linux sshd[32397]: Failed password for invalid user cyrus from 95.154.249.193 port 34567 ssh2 Feb 3 20:45:14 linux sshd[32405]: Failed password for invalid user toto from 95.154.249.193 port 42350 ssh2 Feb 3 20:45:42 linux sshd[32410]: Failed password for invalid user sophie from 95.154.249.193 port 50063 ssh2 Feb 3 20:46:08 linux sshd[32415]: Failed password for invalid user yves from 95.154.249.193 port 59818 ssh2 Feb 3 20:46:34 linux sshd[32424]: Failed password for invalid user trac from 95.154.249.193 port 39509 ssh2 Feb 3 20:47:00 linux sshd[32432]: Failed password for invalid user webmaster from 95.154.249.193 port 47424 ssh2 Feb 3 20:47:27 linux sshd[32437]: Failed password for invalid user postfix from 95.154.249.193 port 55615 ssh2 Feb 3 20:47:54 linux sshd[32442]: Failed password for www-data from 95.154.249.193 port 35554 ssh2 Feb 3 20:48:19 linux sshd[32448]: Failed password for invalid user temp from 95.154.249.193 port 43896 ssh2 Feb 3 20:48:46 linux sshd[32453]: Failed password for invalid user service from 95.154.249.193 port 52092 ssh2 Feb 3 20:49:13 linux sshd[32458]: Failed password for invalid user tomcat from 95.154.249.193 port 60261 ssh2 Feb 3 20:49:40 linux sshd[32464]: Failed password for invalid user upload from 95.154.249.193 port 40236 ssh2 Feb 3 20:50:06 linux sshd[32469]: Failed password for invalid user debian from 95.154.249.193 port 48295 ssh2 Feb 3 20:50:32 linux sshd[32479]: Failed password for invalid user apache from 95.154.249.193 port 56437 ssh2 Feb 3 20:51:00 linux sshd[32492]: Failed password for invalid user rds from 95.154.249.193 port 45540 ssh2 Feb 3 20:51:26 linux sshd[32501]: Failed password for invalid user exploit from 95.154.249.193 port 53751 ssh2 Feb 3 20:51:51 linux sshd[32506]: Failed password for invalid user exploit from 95.154.249.193 port 33543 ssh2 Feb 3 20:52:18 linux sshd[32512]: Failed password for invalid user postgres from 95.154.249.193 port 41350 ssh2 Feb 3 21:02:04 linux sshd[32652]: Failed password for invalid user shell from 95.154.249.193 port 54454 ssh2 Feb 3 21:02:30 linux sshd[32657]: Failed password for invalid user radio from 95.154.249.193 port 35462 ssh2 Feb 3 21:02:57 linux sshd[32663]: Failed password for invalid user anonymous from 95.154.249.193 port 44290 ssh2 Feb 3 21:03:23 linux sshd[32668]: Failed password for invalid user mark from 95.154.249.193 port 53285 ssh2 Feb 3 21:03:50 linux sshd[32673]: Failed password for invalid user majordomo from 95.154.249.193 port 34082 ssh2 Feb 3 21:04:43 linux sshd[32684]: Failed password for irc from 95.154.249.193 port 50918 ssh2 Feb 3 21:05:36 linux sshd[32695]: Failed password for root from 95.154.249.193 port 38577 ssh2 Feb 3 21:06:30 linux sshd[32705]: Failed password for bin from 95.154.249.193 port 53564 ssh2 Feb 3 21:06:56 linux sshd[32714]: Failed password for invalid user dev from 95.154.249.193 port 34568 ssh2 Feb 3 21:07:23 linux sshd[32720]: Failed password for root from 95.154.249.193 port 43799 ssh2 Feb 3 21:09:10 linux sshd[32755]: Failed password for invalid user bob from 95.154.249.193 port 50026 ssh2 Feb 3 21:09:36 linux sshd[32761]: Failed password for invalid user r00t from 95.154.249.193 port 58129 ssh2 Feb 3 21:11:50 linux sshd[537]: Failed password for root from 95.154.249.193 port 58358 ssh2

This brute force dictionary attacks often succeed where there is a user with a weak a password, or some old forgotten test user account.
Just recently on one of the servers I administrate I have catched a malicious attacker originating from Romania, who was able to break with my system test account with the weak password tset .

Thanksfully the script kiddie was unable to get root access to my system, so what he did is he just started another ssh brute force scanner to crawl the net and look for some other vulnerable hosts.

As you read in my recent example being immune against SSH brute force attacks is a very essential security step, the administrator needs to take on a newly installed server.

The easiest way to get read of the brute force attacks without using some external brute force filtering software like fail2ban can be done by:

1. By using an iptables filtering rule to filter every IP which has failed in logging in more than 5 times

To use this brute force prevention method you need to use the following iptables rules:
linux-host:~# /sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state -state NEW -m recent -set linux-host:~# /sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state -state NEW -m recent -update -seconds 60 -hitcount 5 -j DROP

This iptables rules will filter out the SSH port to an every IP address with more than 5 invalid attempts to login to port 22

2. Getting rid of brute force attacks through use of hosts.deny blacklists

sshbl – The SSH blacklist, updated every few minutes, contains IP addresses of hosts which tried to bruteforce into any of currently 19 hosts (all running OpenBSD, FreeBSD or some Linux) using the SSH protocol. The hosts are located in Germany, the United States, United Kingdom, France, England, Ukraine, China, Australia, Czech Republic and setup to report and log those attempts to a central database. Very similar to all the spam blacklists out there.

To use sshbl you will have to set up in your root crontab the following line:

*/60 * * * * /usr/bin/wget -qO /etc/hosts.deny http://www.sshbl.org/lists/hosts.deny

To set it up from console issue:

linux-host:~# echo '*/60 * * * * /usr/bin/wget -qO /etc/hosts.deny http://www.sshbl.org/lists/hosts.deny' | crontab -u root -

These crontab will download and substitute your system default hosts with the one regularly updated on sshbl.org , thus next time a brute force attacker which has been a reported attacker will be filtered out as your Linux or Unix system finds out the IP matches an ip in /etc/hosts.deny

The /etc/hosts.deny filtering rules are written in a way that only publicly known brute forcer IPs will only be filtered for the SSH service, therefore other system services like Apache or a radio, tv streaming server will be still accessible for the brute forcer IP.

It’s a good practice actually to use both of the methods 😉
Thanks to Static (Multics) a close friend of mine for inspiring this article.

Tags: amanda, apache, brute force, example feb, Failed, fax, ftpuser, hosts, info, invalid user, Linux, log, log messages, logins, logs, majordomo, malicious attacker, mark, maximal protection, oracle, password, peter, port, postgres, protection, root, Secure, secure shell, security, security threat, Shell, sophie, ssh, ssh secure shell, system, temp, test, test1, testuser, threat, tomcat, toto, trac, unix, upload, user1, user2, user3, user5, var, webmaster
Posted in Linux, System Administration | 6 Comments »

How to suspend Cpanel user through ssh / Cpanel shell command to suspend users

Friday, August 5th, 2011

One of the servers running Cpanel has been suspended today and the Data Center decided to completely bring down our server and gave us access to it only through rescue mode running linux livecd.

Thus I had no way to access the Cpanel web interface to suspend the “hacker” who by the way was running a number of instances of this old Romanian script kiddies brute force ssh scanner called sshscan .

Thanksfully Cpanel is equipped with a number of handy scripts for emergency situations in /scripts directory. These shell management scripts are awesome for situations like this one, where no web access is not avaiable.

To suspend the abuser / (abusive user ) I had to issue the command:

root@rescue [/]# /scripts/suspendacct abuse_user Changing Shell to /bin/false...chsh: Unknown user context is not authorized to change the shell of abuse_user Done Locking Password...Locking password for user abuse_user. passwd: Success Done Suspending mysql users warn [suspendmysqlusers] abuse_user has no databases. Notification => reports@santrex.net via EMAIL [level => 3] Account previously suspended (password was locked). /bin/df: `/proc/sys/fs/binfmt_misc': No such file or directory Using Universal Quota Support (quota=0) Suspended document root /home/abuse_user/public_html Suspended document root /home/abuse_user/public_html/updateverificationonline.com Using Universal Quota Support (quota=0) Updating ftp passwords for abuse_user Ftp password files updated. Ftp vhost passwords synced abuse_user's account has been suspended

That’s all now the user is suspended, so hopefully the DC will bring the server online in few minutes.

Tags: brute force, center, data, document root, emergency, emergency situations, few minutes, file, Ftp, ftp passwords, hacker, handy scripts, home abuse, instances, level, level 3, livecd, management scripts, mysql users, notification, number, password, password files, quot, Quota, quota support, rescue, rescue mode, root, santrex, scanner, script, script kiddies, Shell, shell command, ssh, Success, Universal, web access, web interface
Posted in System Administration, Various, Web and CMS | 1 Comment »

How to install and configure Jabber Server (Ejabberd) on Debian Lenny GNU / Linux

Wednesday, December 28th, 2011

Ejabberd server erlang logo hedgehog

I've recently installed a jabber server on one Debian Lenny server and hence decided to describe my installations steps hoping this would help ppl who would like to run their own jabber server on Debian . After some research of the jabber server softwares available, I decided to install Ejabberd

The reasons I choose Ejabberd is has rich documentation, good community around the project and the project in general looks like one of the best free software jabber servers available presently. Besides that ejabberd doesn't need Apache or MySQL and only depends on erlang programming language.

Here is the exact steps I followed to have installed and configured a running XMPP jabber server.

1. Install Ejabberd with apt

The installation of Ejabberd is standard, e.g.:

debian:~# apt-get --yes install ejabberd

Now as ejabberd is installed, some minor configuration is necessery before the server can be launched:

2. Edit /etc/ejabberd/ejabberd.cfg

Inside I changed the default settings for:

a) Uncomment%%override_acls.. Changed:

%%%% Remove the Access Control Lists before new ones are added.%%%%override_acls.

%% %% Remove the Access Control Lists before new ones are added. %% override_acls.

b) Admin User from:

%% Admin user {acl, admin, {user, "", "example.com"}}.

%% Admin user {acl, admin, {user, "admin", "jabber.myserver-host.com"}}.

c) default %% Hostname of example.com to my real hostname:

%% Hostname {hosts, ["jabber.myserver-host.com"]}.

The rest of the configurations in /etc/ejabberd/ejabberd.cfg can stay like it is, though it is interesting to read it carefully before continuing as, there are some config timings which might prevent the XMPP server from user brute force attacks as well as few other goodies like for example (ICQ, MSN , Yahoo etc.) protocol transports.

3. Add iptables ACCEPT traffic (allow) rules for ports which are used by Ejabberd

The minimum ACCEPT rules to add are:

/sbin/iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT /sbin/iptables -A INPUT -p udp -m udp --dport 5222 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m tcp --dport 5223 -j ACCEPT /sbin/iptables -A INPUT -p udp -m udp --dport 5223 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT /sbin/iptables -A INPUT -p udp -m udp --dport 5269 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m tcp --dport 5280 -j ACCEPT /sbin/iptables -A INPUT -p udp -m udp --dport 5280 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m tcp --dport 4369 -j ACCEPT /sbin/iptables -A INPUT -p udp -m udp --dport 4369 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m tcp --dport 53873 -j ACCEPT

Of course if there is some specific file which stores iptables rules or some custom firewall these rules has to be added / modified to fit appropriate place or chain.

4. Restart ejabberd via init.d script

debian:~# /etc/init.d/ejabberd restart Restarting jabber server: ejabberd is not running. Starting ejabberd.

5. Create ejabberd necessery new user accounts

debian:~# /usr/sbin/ejabberdctl register admin jabber.myserver-host.com mypasswd1 debian:~# /usr/sbin/ejabberdctl register hipo jabber.myserver-host.com mypasswd2 debian:~# /usr/sbin/ejabberdctl register newuser jabber.myserver-host.com mypasswd3 debian:~# /usr/sbin/ejabberdctl register newuser1 jabber.myserver-host.com mypasswd4 ... etc.

ejabberdctl ejabberd server client (frontend) has multiple other options and the manual is a good reading.

One helpful use of ejabberdctl is:

debian:~# /usr/sbin/ejabberdctl status Node ejabberd@debian is started. Status: started ejabberd is running

ejabberctl can be used also to delete some existent users, for example to delete the newuser1 just added above:

debian:~# /usr/sbin/ejabberdctl unregister newuser jabber.myserver-host.com

6. Post install web configurations

ejabberd server offers a web interface listening on port 5280, to access the web interface right after it is installed I used URL: http://jabber.myserver-host.com:5280/admin/

To login to http://jabber.myserver-host.com:5280/admin/ you will need to use the admin username previously added in this case:
admin@jabber.myserver-host.com mypasswd1

Anyways in the web interface there is not much of configuration options available for change.

7. Set dns SRV records

I'm using Godaddy 's DNS for my domain so here is a screenshot on the SRV records that needs to be configured on Godaddy:

GoDaddy DNS SRV records screenshot

In the screenshto Target is the Fually qualified domain hostname for the jabber server.

Setting the SRV records for the domain using Godaddy's DNS could take from 24 to 48 hours to propagate the changes among all the global DNS records so be patient.

If instead you use own custom BIND DNS server the records that needs to be added to the respective domain zone file are:

_xmpp-client._tcp 900 IN SRV 5 0 5222 jabber.myserver-host.com. _xmpp-server._tcp 900 IN SRV 5 0 5269 jabber.myserver-host.com. _jabber._tcp 900 IN SRV 5 0 5269 jabber.myserver-host.com.

8. Testing if the SRV dns records for domain are correct

debian:~$ nslookup > set type=SRV > jabber.myserver-host.com ... > myserver-host.com
If all is fine above nslookup request should return the requested domain SRV records.
You might be wondering what is the purpose of setting DNS SRV records at all, well if your jabber server has to communicate with the other jabber servers on the internet using the DNS SRV record is the way your server will found the other ones and vice versa.

DNS records can also be checked with dig for example

$ dig SRV _xmpp-server._tcp.mydomain.net

[…]

;; QUESTION SECTION:
;_xmpp-server._tcp.mydomain.net. IN SRV

;; ANSWER SECTION:
_xmpp-server._tcp.mydomain.net. 259200 IN SRV 5 0 5269 jabber.mydomain.net.

;; ADDITIONAL SECTION:
jabber.mydomain.net. 259200 IN A 11.22.33.44

;; Query time: 109 msec
;; SERVER: 212.27.40.241#53(212.27.40.241)
;; WHEN: Sat Aug 14 14:14:22 2010
;; MSG SIZE rcvd: 111

9. Debugging issues with ejabberd

Ejabberd log files are located in /var/log/ejabberd , you will have to check the logs in case of any issues with the jabber XMPP server. Here is the three files which log messages from ejabberd:

debian:~$ ls -1 /var/log/ejabberd/ ejabberd.log erl_crash.dump sasl.log

I will not get into details on the logs as the best way to find out about them is to read them 😉

10. Testing ejabberd server with Pidgin

To test if my Jabber server works properly I used Pidgin universal chat client . However there are plenty of other multiplatform jabber clients out there e.g.: Psi , Spark , Gajim etc.

Here is a screenshot of my (Accounts -> Manage Accounts -> Add) XMPP protocol configuration

Pidgin account configuration XMPP on debian Linux

Tags: admin, apache, best free software, brute force, cfg, com, configure, custom, default hostname, default settings, DNS, doesn, dport, ejabberd, ejabberdctl, exact steps, file, GNU, goodies, hostname, hosts, init, INPUT, Install, installation, Jabber, Linux, Lists, mypasswd, necessery, override, ports, ppl, programming language, Protocol, quot, quot quot, rich documentation, server, servers, software, tcp, transports, uncomment, User, xmpp
Posted in Linux, System Administration, Various | 8 Comments »

How to prevent SSH and FTP bruteforce attacks with iptables on Linux

Friday, December 30th, 2011

Earlier I've blogged about how to prevent brute force attacks with fail2ban, denohosts and blockhosts , however there is easier way to secure against basic brute force attacks by not installing or configuring any external programs.
The way I'm talking about uses simple iptables rules to filter out brute force attacks.

Here is a small script to stop ssh and FTP invaders which try to initiate more than 3 consequential connections in 5 minutes time to port 22 or port 23:

SERVER_MAIN_IP='AAA.BBB.CCC.DDD';/sbin/iptables -N SSH_WHITELIST /sbin/iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshbr --set /sbin/iptables -A INPUT -p tcp --dport 22 --syn -j SSH_WHITELIST /sbin/iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshbr \ --update --rttl --hitcount 3 --seconds 300 -j REJECT --reject-with tcp-reset /sbin/iptables -A SSH_WHITELIST -s $SERVER_MAIN_IP -p tcp --dport 22 --syn -m recent --rttl --remove

The only thinIf the rules are matched iptables filter rules will be added to the iptables CHAIN SSH_WHITELIST
In case if you want to add some more truested IPs add some more iptables rules, like:

ALLOW_IP='BBB.CCC.DDD.EEE'; /sbin/iptables -A SSH_WHITELIST -s $ALLOW_IP -p tcp --dport 22 --syn -m recent --rttl --remove

Each filtered IP that matches the rules will be filtered for 5 minutes, if 5 minutes is enough, the 300 value has to be increased.

Tags: ALLOW, BBB, blogged, brute force, CCC, ddd, dport, EEE, filter rules, INPUT, ips, iptables, Linux, Main, name, nbsp, port, port 22, port 23, removeEach, sbin, server, ssh, sshbr, SYN, time, value, way, whitelist
Posted in Computer Security, Linux, System Administration | 2 Comments »

rkhunter, chkrootkit and unhide three Linux handy tools to find out if a Linux server is compromised

Wednesday, August 17th, 2011

Check Linux server for rootkit using rkhunter, chrkootkit unhide

I’ve been hired, just recently by a company to make them a quick security audit analysis as they complain of having severe Denial of Service problems against an online e-store.

As a mean of securing the local network of the company, the old Linux server had to be replaced with a freshly installed one, which I had to configure to run smooth firewall and create DMZ zone.
The company System Administrator has installed Debian Linux and brought up sshd to allow me to futher take the lead and secure the server
After few hours, I’ve noticed unusual activities. For example processes like:

./a 207 as well as processes like ./ssh 212

debian:~# ps axu|grep -i ./ssh|wc -l 216

On the server and after checking in /etc/shadow I found that users like admin, test had a password string assigned , interestingly even system users like postgresql and man was enabled and ready for login and had a password hash assigned in /etc/shadow

I’ve seen the ./ssh shit before and I know pretty well this is a famous romanian script kiddies tools which circulates in the wild for at least 5 years already.

A quick look up in the usual places, where script kiddies store their files, like: /var/tmp, /tmp, /proc, /sys and /var/run has helped me find the ssh brute forcer the kiddie has issues on the machine in my case it was located in /var/run/2012 inside I found of course the usual sk bad stuff:

root@debian:/var/run/2012# ls1 3 5 a data.conf find internet.txt pass_file screen ssh stricat.txt vuln.txt 2 4 64.37.find.22 atack derbedeu.txt full mfu.txt ronet13.txt ss start tefac.txt x

As well as an archive in /var/run/2012.tgz which was obviously quickly extracted and the brute force ssh tool was started to lookup for some more targets.

As I like keeping script kiddie stuff to expose and share with people, to help them get a better understanding what they can expect on their servers I made a copy of the 2012.tgz brute forcer tool, download the romanian ssh brute forcer shit is here if somebody wants to take a look, though I suggest to be very careful with it as some files might contain rootkits and other unwanted tool.
If someone wants to give it a try be sure not to launch it as root.

Anyways, after finding the abuser I quickly removed all the active users, which were not supposed to be existent on the newly installed system from /etc/shadow changed the server root password, give a reinstall the openssh-server and openssh-client (as I was not if they had not been substituted with some rootkited version), e.g.:

debian:~# apt-get install --reinstall openssh-client openssh-server

Consequentially I killed all the active ./ssh and ./a processes to assure the script kiddie ssh brute forcer is no longer running on the server as well killed all connections to the ssh server manually with kill cmd to the unknown IPs.

Finally to make sure, the server is not rootkited or not backdoored I run some tests with chkrootkit, rkhunter and unhide :

On Debian the 3 tools are available as packages, so this saved me time and I proceeded installing like so:

debian:~# apt-get install rkhunter unhide chkrootkit ...

In few seconds the tools were installed so I used them to check if the server is irreversably damaged or root kitted by the kiddie.

1. unhide

First I used unhide to make sure there are no hidden backdoor processes listening on the server:

for i in $(echo proc sys brute); do unhide $i; done Unhide 20100201 http://www.security-projects.com/?Unhide [*]Searching for Hidden processes through /proc scanning Unhide 20100201 http://www.security-projects.com/?Unhide [*]Searching for Hidden processes through kill(..,0) scanning [*]Searching for Hidden processes through comparison of results of system calls [*]Searching for Hidden processes through getpriority() scanning [*]Searching for Hidden processes through getpgid() scanning [*]Searching for Hidden processes through getsid() scanning [*]Searching for Hidden processes through sched_getaffinity() scanning [*]Searching for Hidden processes through sched_getparam() scanning [*]Searching for Hidden processes through sched_getscheduler() scanning [*]Searching for Hidden processes through sched_rr_get_interval() scanning [*]Searching for Hidden processes through sysinfo() scanning HIDDEN Processes Found: 1 Unhide 20100201 http://www.security-projects.com/?Unhide [*]Starting scanning using brute force against PIDS with fork() [*]Starting scanning using brute force against PIDS with Threads

The above command checks with unhide in /proc and /sys for hidden processes as well as next uses brute option to try to brute force all PIDs on the server attempting to locate listening backdoors processes.

There are 2 more unhide binaries that can be used to check for hidden backdoors, unhide-posix and unhide-tcp

For some reason unhide-posix sys detected the /usr/sbin/rsyslogd -c4 process as some kind of hidden process, which is most probably a false positive, though I can’t be one hundred sure until I try to scan completely the server remotely after mounting the filesystem via ssh and scan it with clamav chkrootkit and rkhunter and even maybe with drweb .

I assume the HIDDEN Processes Found: 1 bells the alarm, however even though I did profound look up on the server with lsof, netstat and fuser cmds I cannot find nothing suspicious any more.

2. chkrootkit scan

Next I used chkrootkit to check if some common rootkit is not installed on the server:

debian:~# chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `crontab'... not infected Checking `date'... not infected ...

The chkrootkit output displayed thanksfully failed to detect that the system is rootkitted.

3. rkhunter

Finally, tested with rkhunter to assure chkrootkit to expand the range of rootkits the system is scanned for:

debian:~# rkhunter --check [ Rootkit Hunter version 1.3.6 ]

Checking system commands…

Performing ‘strings’ command checks
Checking ‘strings’ command [ OK ]

Performing ‘shared libraries’ checks
Checking for preloading variables [ None found ]
Checking for preloaded libraries [ None found ]
Checking LD_LIBRARY_PATH variable [ Not found ]
…

After a long screen of consequential rootkit tests, each of which requires the user to press enter rkhunter was unable to detect any rootkits installed on host as well.

Finally to make sure for one more time there are no some backdoors left or some unwanted users still connected to the server I used netstat:

debian:~# netstat -tanp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 7269/sshd tcp 0 0 192.168.0.1:22 83.228.93.76:54913 ESTABLISHED 24545/1 tcp 0 0 192.168.0.1:22 83.228.93.76:50240 ESTABLISHED 7059/0 tcp6 0 0 :::22 :::* LISTEN 7269/sshd

As the output shows, I coulnd’t find anything suspiciou, still I can’t be 100% percent sure the system is clean and there is no something left from the cracker, probably the Debian server will be re-installed as it doesn’t matter since it’s newly installed Debian machine.

What is amazing is that the server was compromised immediately after it was installed. This means that either the very easy default root password the admin who installed the server was cracked, or his whole network has been compromised by the script kiddie.
Tomorrow will have to investigate further to assure the security breach is closed hopefully once and for all.

Tags: administrator, atack, axu, bad stuff, brute force, brute forcer, chkrootkit, configure, Denial, denial of service, e store, forcer, handy tools, hash, kill, lead, linux server, local network, login, mfu, password, password string, postgresql, rkhunter, Romanian, root, script kiddie, script kiddies, security audit, Service, shadow, ssh, system users, test, tgz, tmp, tool, xas
Posted in Linux, System Administration | 5 Comments »

Howto remote access Windows PC which is behind Vivacom ADSL (Commtrend SmartAX MT882 router) modem with VNC server

Wednesday, May 11th, 2011

I had been assigned the not easy task to make a Windows XP Pro which is located behind an ADSL modem to be remotely accessible via VNC

The Windows is connected to the Bulgarian Vivacom Intrnet provider through their ADSL service and hence there is an ADSL router modem which is configured to disallow all inbuond connections by default.

The Windows Pro PC where the VNC server was needed to be accessible did not have a real IP address (e.g. was assigned a virtual IP address by the ADSL modem.

The exact ADSL model used to connect the computer via a lan cable to the internet was Huawei SmartAX MT882

As the device is owned by Vivacom (the ex BTK tele communication company) I did not have any admin user and pass credentials for the ADSL modem to configure the ADSL router to do a port NAT forwarding of port 5800 and 5900 used by the VNC software I installed on the PC (TightVNC)

Nevertheless the missing user and password I decided to check in google if I can find some default passwords that Vivacom ADSL modems are configured to work with

After a few minutes spend in Google I already had found few passwords which were said to work fine with the Vivacom ADSL router.
Here are the passwords I found for the Vivacom ADSL Internet modems:

ZTE ZXDSL 832 username: root password:GSrootaccess

ZTE ZXDSL 831
username:root
password:GSrootaccess

ZTE
username:root
password:831access

Huawei SmartAX MT882
username:root
password:MT882rootaccess

ZTE ZXDSL-531b
username: root
password:warmWLspot

I tried some old school brute force techniques 😉 by trying all the passwords via the ADSL web interface located on http://192.168.1.1 (I was not sure which model the Vivacom ADSL modem is as on the router there was nothing written concerning the modem type but only the Vivacom logo was present.

After a bit of time I already knew that the ADSL modem model, user and pass was:

Huawei SmartAX MT882 ------------------------------- user: root pass: MT882rootaccess

My next step was to configure port forwarding for the SmartAX MT882 ADSL in order to achieve from modem’s web administrator I had to follow the menus:

Advanced Setup -> Virtual Servers

Next in the NAT — Virtual Servers section I pressed the Add button to create new automatic redirection (port forwarding) rule.

Configuring ADSL SmartAX MT882 TightVNC NAT port redirection screenTightVNC requires also NAT port redirection rule for port 5900 in order to be able to connect to the VNC server behind the dsl, so analogically I added a Virtual Server NAT rule for port 5900.

Note that the private IP address of the Windows host was assigned by the ADSL router to the ip 192.168.1.3

Further on I expected the adsl port forwarding created rule would now allow me to connect to the VNC server on the pc located behind the dsl firewall, but I was wrong… even though all seemed to be configured just fine in the ADSL router still the port unmbers 5800 and 5900 were showing up as closed during nmap scan as well as a simple telnet connection to port 5800 and 5900 failed to get established.

My logical assumption was that some configured Firewall on the Windows PC is blocking port connections to 5800 and 5900 thus I decided to check the default Windows Firewall settings as a first possible cause for the vnc ports being blocked.

I did that via the Windows menus:

Start -> Settings -> Control Panel -> Windows Firewall

However weirly enought it seemed the Windows Firewall was disabled e.g. the Off (not recommended) option was set for the firewall.

A bunch of other lookup over all the running system and services on the windows hosts I have found the PC is protected by NOD32 Antivirus – Personal Firewall

The default behaviour of NOD32’s Persnal firewall was extremely restrictive and I found it’s causing a port filter of the 5800 and 5900 vnc connection ports.

To solve the filtering nod32 did I had to open NOD32 and navigate to the following menus:

Setup -> Personal Firewall -> Configure rules and Zones

In the Zone and rule setup menu config window I had to further press on:
New button to add new personal firewall rule.

In the New rule: menu I filled in the following info:
In the General tab:

Name: vnc Direction: Both Action: Allow

In the tab Local

I pressed over the Add Port

Number: 5800

in the Remote tab once again I had to fill in:
Number: 5800

Then to confirm settings just pressed OK

Next on I added in the same manner an allow rule for port 5900.

After this settings I restarted the NOD32 firewall to make sure the new settings takes place by pressing over the Personal firewall button Disable filtering: allow all traffic and right after enabling the firewall once again.

Now remote tightvnc connections to the Windows XP Pro pc works like a charm once again, Thanks God 😉

Tags: admin user, adsl modem, adsl modems, adsl router, adsl service, brute force, BTK, Button, Commtrend, company, configure, connection, default, default passwords, disallow, google, GSrootaccessZTE, http 192 168 1 1, Huawei, internet modems, lan cable, menu, model user, modem model, modem type, NOD, password, router, router modem, software, tab, tele communication, TightVNC, username, Virtual, virtual ip address, Vivacom, vnc software, web interface, windows xp pro, ZTE
Posted in System Administration, Various | 1 Comment »

☩ Walking in Light with Christ – Faith, Computing, Diary

Posts Tagged ‘brute force’

How to suspend Cpanel user through ssh / Cpanel shell command to suspend users

Howto remote access Windows PC which is behind Vivacom ADSL (Commtrend SmartAX MT882 router) modem with VNC server

Daily Bible quote

GET ARTICLE UPDATES

Useful blog? Help it:

Links to Other Places

Recent Posts

Ads

Categories

About Myself

Recent Comments

Top Post Views

blogtopsites