A New Change

Well, I’ve noticed over the last while that blog is suffering from some major attrition from real life. Information and network security is so fast moving and requires a lot of technical depth and time spent on it that I don’t have the time to continually post things here. In fact the trend of recent posts has not been security focused but more of a general IT focus.

The time has come for a change where I will include anything IRL or !IRL for my own amusement.

Reset VSOM admin password

What do you do when a retarded engineer sets a VSOM admin password and leaves the company? Call TAC and get the below super secret (not really) script . The below will reset the admin password to admin.

# /usr/BWhttpd/vsom_be/db/resetAdminUser.sh

 

The Most Redundant Error In The World

Whilst trying to upgrade from Cisco VSM 7.0 to 7.2 via the VSMC yesterday I received this error code.

File upload failed..{“status”:{“errorType”:”SUCCESS”}}

Well done Cisco, well done. You have created the most redundant error code in the history of your shitty output.

As a note for anyone who comes across this, you only see this error whilst trying to upgrade via Chrome, the upgrade works perfectly from IE.

NAT Timeout Variations

Just a quick note on the varying state of NAT timeouts as used by different vendors.

RFC1122 states the below regarding TCP keep-alives as programmatically designed:

Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. This interval MUST be configurable and MUST default to no less than two hours.

RFC5382 states the below about NAT keeping RFC1122 in mind:

If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the “established connection idle-timeout” MUST NOT be less than 2 hours 4 minutes. The value of the “transitory connection idle-timeout” MUST NOT be less than 4 minutes.

 

Keeping this in mind there is a huge difference between vendor implementations as a default value. NOTE that this is just using a quick browse of the net for specific references, so some may be old/updated etc.

  • RFC: 7440 sec (2 hours 4 mins)
  • Cisco IOS: 86400 sec (24 hours)
  • Cisco ASA: 10800 sec (3 hours)
  • A10 (Carrier Grade): 300 sec (5 mins)
  • Brocade ServerIron ADX: 120 sec (2 mins)
  • Netgear FVS318: 600 sec (10 mins)
  • Netgear FVS336Gv2: 1200 sec (20 mins)
  • D-Link DIR-615: 7800 sec (2 hours 10 mins)
  • DD-WRT: 3600 (1 hour)

Fixing ISPConfig3 MySQL Backup

I have been playing with ISPConfig3 for the last few months. Apart from being highly surprised by such a complete free offering, the MySQL backup has never worked for me. Web backup would work but the sql.gz would show 0 or a very small number bytes resulting in no backup.

After playing with the script in /usr/local/ispconfig/server/cron_daily.php I found that the script sanitizes input from /usr/local/ispconfig/server/lib/mysql_clientdb.conf before passing the details over to mysqldump.

The script sanitizes input with the PHP function escapeshellcmd: http://php.net/manual/en/function.escapeshellcmd.php

From the manual, the function will escape all input with #&;`|*?~<>^()[]{}$\\x0A\xFF and unpaired ‘ and “. This means that if we have any of these characters in our username or password the script will sanitize the input before throwing it to commandline which essentially breaks our backup process.

This sanitization is fine if your expecting input from an end user, but this is our root password using a string stored in a text file. Apart from some type of remote rewrite of the file and waiting for cron_daily.php to be executed hoping for a break on the commandline, I’m pretty sure this file is ok to edit.

The line is at 892 of /usr/local/ispconfig/server/cron_daily.php and reads

$command = "mysqldump -h '".escapeshellcmd($clientdb_host)."' -u '".escapeshellcmd($clientdb_user)."' -p'".escapeshellcmd($clientdb_password)."' -c --add-drop-table --create-options --quick --result-file='".$db_backup_dir.'/'.$db_backup_file."' '".$db_name."'";

For me it was my password that was causing problems for the function in which the mysqldump would fail resulting in a gz file of nothing.

Once the file was edited to the below everything started working again as expected.

$command = "mysqldump -h '".escapeshellcmd($clientdb_host)."' -u '".escapeshellcmd($clientdb_user)."' -p'".$clientdb_password."' -c --add-drop-table --create-options --quick --result-file='".$db_backup_dir.'/'.$db_backup_file."' '".$db_name."'";

I hope this helps!

CallManager 9 + VirtualBox + Ubuntu 12.04 + GNS3 + SIP

Following on from similar post I did a few years back about CCM7 in VirtualBox with a SIP trunk to a 2621XM, I’ve recreated the process for CCM9 with a few differences.

The final environment looks like the below:

  • Cisco SRP527W ADSL2+ Router
  • Ethernet to Ubuntu 11.04 running as the VirtualBox Host
  • Call Manager 9 Virtual Machine Guest
  • Ubuntu 12.04 Guest
  • GNS3 inside the 12.04 Guest
  • 2621XM running as CUBE inside GNS3
  • SIP trunk between Call Manager 9 and the 2621XM
  • SIP trunk between external provider and the 2621XM (my provider is Internode)

I won’t detail the SRP or VirtualBox Host config – it’s far too simple. The only note to add is to turn SIP ALG on on the SRP and forward 5060-5062 to the IP of your GNS3 router.

Continue Reading…

SSH Bruteforce IP Offenders List and Common Usernames – April 2013

This is the computed list of SSH bruteforce IP’s and commonly used usernames for April 2013.

Top 50 SSH bruteforce offenders IP’s.

Failed Attempt Count IP
479633 223.4.147.158
389495 198.15.109.24
354877 114.34.18.25
324632 118.98.96.81
277040 61.144.14.118
118890 92.103.184.178
113896 208.68.36.23
110541 61.19.69.45
102587 120.29.222.26
98027 216.6.91.170
87315 219.143.116.40
71213 200.26.134.122
68007 38.122.110.18
65463 133.50.136.67
65187 121.156.105.62
57918 210.51.10.62
55575 10.40.54.5
52888 110.234.180.88
51473 61.28.196.62
46058 223.4.211.22
45495 183.136.159.163
45363 61.28.196.190
41791 1.55.242.92
40654 223.4.233.77
39423 61.155.62.178
39360 61.28.193.1
39296 211.90.87.22
38516 119.97.180.135
35799 221.122.98.22
35077 109.87.208.17
31106 78.129.222.102
29505 74.63.254.79
28676 65.111.174.19
28623 116.229.239.189
28092 81.25.28.146
26782 223.4.148.150
26493 218.69.248.24
25853 210.149.189.6
25241 223.4.27.22
25231 221.204.252.149
25089 125.69.90.148
23951 69.167.161.58
22912 202.108.62.199
22433 61.147.79.98
22372 111.42.0.25
22068 218.104.48.105
21988 120.138.27.197
21914 14.63.213.49
21882 60.220.225.21
20780 195.98.38.52

Top 50 SSH bruteforce usernames.

Failed Attempt Count Username
2407233 root
45971 oracle
40375 test
26522 admin
22642 bin
20586 user
18782 nagios
17370 guest
13292 postgres
11193 www
11088 mysql
10281 a
10228 webroot
10061 web
9143 testuser
8946 tester
8708 apache
8611 ftpuser
8442 testing
8095 webmaster
7379 info
7112 tomcat
6826 webadmin
6309 student
6255 ftp
6254 ts
5947 backup
5688 svn
5314 test1
5127 support
4743 temp
4378 teamspeak
4335 toor
4149 test2
4046 www-data
3944 git
3907 webuser
3852 userftp
3637 news
3626 cron
3594 alex
3581 amanda
3535 ts3
3397 ftptest
3378 students
3360 test3
3283 mail
3243 games
3132 test123
3093 test4

Download the top 50 offenders IP list: april2013top50ips

Download the top 50 usernames list: april2013top50users

SSH Bruteforce IP Offenders List and Common Usernames

I maintain a radius server that proxies requests from publicly accessible SSH servers which, unfortunately must run on port 22.

There are over 140 SSH servers that proxy all requests through this server and due to the logging which is configured I am able to capture all failed attempts including username password and IP address. I frequently scan these logs to find the top offending IP addresses and common usernames so I can add them to a blacklist for the radius server to drop straight away.

There are many public projects that compile sources of such information, however these logs are easy for me to divulge for others to incorporate into similar lists.

I will throw some old stats of interest and work on this to become a monthly release.

October 2012
Failed Attacks: 19,969,074

November 2012
Failed Attacks: 11,335,220

December 2012
Failed Attacks: 5,277,817 <- I guess everyone went quite over the holiday period?

January 2013
Failed Attacks: 6,786,138

February 2013
Failed Attacks: 17,375,929

March 2013
Failed Attacks: 16,437,020

April 2013
Failed Attacks: 5,542,223

May 2013
Failed Attacks To Date: 3,347,659