Monday, November 28, 2011

Open Security Self-Test initiative

Hi folks!

I'd like to establish  Open Security Self-Test initiative:

It' will allow any user to make security audit of his gadget (laptop, tablet, smartphone) on free of charge and self-service basis.

Desc: Free wifi APs located in public places connected to special designed security audit server.
  • All users nearby will be able connect to this AP (all communication gonna be encrypted, password for connection will be included into AP's SSID )
  • After connection to AP, user's workstation security scan will be started and all user's trafic to Internet (or Internet emulation sandbox) will be monitored by NIDS.
  • In couple of minutes user will get  report about any security threats found on his workstation and short recommendations how to solve the problems including the links to updates/patches and free/trial anti-viruses.
  • All security audits will be done by open-source solutions (some commercial tools could be involved if  vendors will allow such usage)
  • Whole solution will work on free of charge basis.

Architecture:


Updated: 


Proposed architecture could use Cloud tendency: in this case  Security Audit Servers will be located in the Cloud and being connected by VPN to distributed across the world WiFi APs. APs will use modified firmware (OpenWrt) and tunnel all the traffic from connected users' gadgets to the Cloud.
It will definitely reduce the operation costs and give a great scalability, flexibility and reliability for whole solution.



1. Access Point (AP)

2. Security Audit Server/s  including:

  • Captive portal 
  • Firewall
  • Vulnerabilities  scanner/s
  • Network Intrusion Detection System (NIDS)
  • Internet connection or Internet emulation

Current implementation:

Nginx+ Bind+iptables+snort+ nmap +OpenVAS+tcpdump+Scripts


Usage:

1. User  connects to public AP by his laptop, tablet or smartphone. PSK for connection included in broadcasted AP's SSID. Connection encrypted.
User get IP form DHCP and all connection attempt forwarded to Captive portal

2. Users establish connection via https with Open Security Self-Test web server.
Read end-user agreement, Accept it and start the security audit:

3. Vulnerabilities scan runs against user's device:

4.  During vulnerabilities scan and mostly after it user computer get connected to Internet (or Internet emulation). All traffic between user's device and Internet intercepted and monitored by NIDS.

5. Finally, user will get brief (with option to download full) description of security problems found and recommendations how to fix it. Recommendations will include links to vendors' patches, updates and free and trial antivirus software.


During security audit process user will see progress bar and will be able surf Internet.



Current stage: Alfa-testing.  Scheduled for  first implementation on late February, Montreal, QC.

Solution could be implemented on a stand-alone basis in public places or as a part of current free-WiFi access infrastructure. Showing advertisement to a users during the scan will allow using some commercial security audit solution or ,even, make project profitable.


Friday, November 18, 2011

canary in a coal mine

Simple couple of string on high critical servers that could save your ass .

add to root or your user  .bash_profile following string:

echo $SSH_CONNECTION | sed 's/\(.*\) \(.*\) \(.*\) \(.*\)/ Remote root ssh login detected from  \1:\2 to '"`hostname`"' IP \3 Port \4/' | mail -s "Remote root ssh login warning" your@email.com

Instead of email you can put your phone_number@your_operator.sms.gateway - and get sms like this:

Remote root ssh login detected from  10.1.1.148:65308 to my.server.com IP 141.1.1.107 Port 22

almost  immediately after root user login.

Stay informed!

Monday, November 7, 2011

ssh - Knockin' on Heaven's Door

Using both: port knocking technology and trusted networks for secure ssh access:

The key feature of this method is using ssh daemon listening on 2 diff ports:
--sshd_config--

# What ports, IPs and protocols we listen for
Port 22
Port 3054

and iptables.

1. "Normal" ssh port (22) will be available only from trusted subnets
2.  "New"ssh port (3054) will be available on demand (well known port knocking technology )

How-to:

1. Create new chain:

iptables -N SSH

2.  add it as action to our 2 ssh ports and 1 knocking port

iptables -A INPUT -p tcp -m tcp --dport 22 --syn  -j SSH
iptables -A INPUT -p tcp -m tcp --dport 3054 --syn  -j SSH
iptables -A INPUT -p tcp -m tcp --dport 3055 --syn  -j SSH

3. add rules to our SSH chain
--- add rule for trusted subnet:
iptables -A SSH  -s 184.144.0.0/13 -p tcp -m tcp --dport 22 -j ACCEPT -m comment --comment "Trusted subnet"

---add rule for knock port using recent iptables module:  add packet source to "recent" :
iptables -A SSH -p tcp -m tcp --dport 3055 --syn -m recent --set     --name ssh --rsource -j REJECT --reject-with tcp-reset

--- allow to connect to "new" ssh port within 30 second interval from the IP used to knock
iptables -A SSH -p tcp -m tcp --dport 3054 --syn -m recent --rcheck --seconds 30 --name ssh --rsource -j ACCEPT

That's it. To knock knock simple use: telnet "IP" 3055 and after that you have 30 second to connect.



It will allow you to use ssh and ssh-based tools as usual from trusted location, always be able to connect to server from any location around the world and reduce amount of alerts getting form your HIDS.

PS. Not forget about turning on SSH public key based authentication  and switching PasswordAuthentication to "no".


inspired by  http://execbit.ru/2011/05/18/portknoking/