Sunday, December 22, 2013

How to Protect your servers from bruteforceattacks

Note : all blogs post will be moved to http://blog.cybergen.in/protect-your-server-by-securing-ssh/

Attackers try acessing servers all the time this is done generally by BruteForce where they would try random combination of passwords till they get access to your server .This is not generally done at a stretch but distributed over a period of time to prevent suspiscion.

in linux distributions you can find this log in /var/log/secure

Dec 22 08:43:25 your_server sshd[7207]: Failed password for root from (attackers ip) port 2867 ssh2
Dec 22 08:43:25 your_server sshd[7208]: Disconnecting: Too many authentication failures for root
Dec 22 08:43:27 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:27 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:27 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:28 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:28 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:28 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2

you can see this log if in your /etc/ssh/sshd_config
LogLevel is set to INFO

other options for Log Level

LogLevel
      Gives the verbosity level that is used when logging messages from
      sshd.  The possible values are: QUIET, FATAL, ERROR, INFO, VER-
      BOSE, DEBUG, DEBUG1, DEBUG2 and DEBUG3.  The default is INFO.
      DEBUG and DEBUG1 are equivalent.  DEBUG2 and DEBUG3 each specify
      higher levels of debugging output.  Logging with a DEBUG level
      violates the privacy of users and is not recommended.

Solutions


  1. Check existing firewall rules and remove rules for machines that do not need SSH open to the internet - This is particularly important when decommissioning machines. Compromises often occur when an IP address is re-used and a firewall rule for SSH still exists for the old machine. If the new machine has an out-of-the-box configuration that includes weak username/password combinations, it is likely to get compromised before long.
  2. Use a single, secure host for SSH access into your network - Instead of opening multiple firewall holes for every host that someone might need SSH access to, require users to SSH to one particular host, from which they can then SSH to other hosts which are not directly exposed to the internet. The exposed host can have more hardening measures applied, which may not be necessary on the others.
  3. Run SSH on a non-default port - Since nearly all 'random' attacks are targeted at the default port 22, changing the listening port for sshd is an effective way of avoiding them. In OpenSSH, this can be done by editing the line "Port 22" in /etc/ssh/sshd_config. It is probably wise to avoid obvious alternate ports such as 222 and 2222, as scans for these ports are sometimes seen. Any connecting clients will need to specify the new port.
  4. Disallow root logins via SSH - This should be the default setting anyway. Older versions that allow root logins by default should be updated. If you require root access via SSH, don't enable root logins, instead you should log in as a user that can 'su' to root.
  5. Allow only SSH protocol version 2 - Again this should be the default.  SSHv1 is insecure and may make brute force attacks easier.  The relevant line in /etc/ssh/sshd_config should read "Protocol 2".
  6. Avoid using easily guessable names for accounts - Unless the attackers can obtain usernames from another source (e.g. a website), they are just guessing them. Avoid usernames such as manager, admin, sysadmin, webmaster, guest, test, temp, as these are seen in brute force attempts. Users' first names are also used, so initial and lastname is a better choice.
  7. Apply a password policy - Setting length and complexity requirements will greatly decrease the chances of a successful brute force attack.
  8. Use key-based authentication - It is possible to disable password-based authentication altogether and use key-based authentication. This can have its own security issues. If your machine with the SSH keys is compromised, the attacker can log on to remote systems using your keys. So, if you use SSH keys, you should protect the private key with a passphrase which must be typed when the key is used. However, it might not be possible to force users to set a passphrase for their keys.
  9. Block brute force attacks - Although sshd itself provides no effective way to limit brute force attacks, it is possible to use methods that use log files and firewall rules to impose a ban on IP addresses that attempt too many connections. An example is Fail2ban.




Thursday, October 4, 2012

expanding your network using armitage

ohk here i'm showing youhow to expand a compromised network and how to do some post compromising actions


Sunday, September 30, 2012

how to backdoor a windows7 using armitage


how to backdoor a windows7 using armitage

I think if a user knows how and by what method his system can be compromised he can protect himself better by preventing others fom exploiting him/her.  



hacking into a windows system physically using backtrack


Hacking into windows system once you have a physical access to the machine.
this will work on any windows system with windows7 ultimate and older.

Note: that where ever I've used '  single quotes the content within it is meant to be typed on the interface

Perquisites : 

  1. A system with a windows OS.
  2. A backtrack 4 or above Live Distribution in a bootable media.
Boot BackTrack live distribution on the system once loaded up enter the following commands

# cat /etc/fstab

if the output is just about two lines it means that your drive isn't loaded up yet
and you'll have to load them up by yourself

#vi /etc/fstab

in the vi editor add the lines to what ever is existing there do not modify the existing lines
if the below line is already present skip this step

' /dev/sda2 /media/hdd ntfs 0 0 '

and save the file (to save it hit escape and type ' wq ' )

the next line to create a directory for the media

' #mkdir media/hdd '

to mount the drive 

' #mount dev/sda2 '

now to enter into the password menu

' #chntpw -i /media/hdd/Windows/System32/config/sam '

From here on its a interactive text menu so guess things from here will be easy

to exit the menu type ' ! '

you 'll get a quote what to do ? [1] -> 

enter ' q '

and confirm your changes by typing ' y '

to exit

type the below to rebot

' #reboot '