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/


Wednesday, October 12, 2011

Advanced Persistent Threat (APT)

These chinese guys are really Persistent:


--------------------- SSHD Begin ------------------------ 

Illegal users from:
   67.228.251.6 (67.228.251.6-static.reverse.softlayer.com): 60 times
   
211.151.62.218: 10490 times


But not really Advanced:   for all password guessing attempt they must've got:

-----Permission denied (publickey). ---  

:-)





Thursday, September 22, 2011

careless developers

One more simple and lazy Google (tm) hacking:
try to google:

inurl:"info.php" filetype:php allow_url_fopen https
or
inurl:"info.php" filetype:php intitle:"phpinfo()"
Found:
about 282,000 results (0.22 seconds)

So, today we have quarter of a million careless developers :-)

Have a nice day, folks :-)




Monday, June 27, 2011

Insecure security


Dear credit cards users:
Next time when you gonna pay by credit card take a look on security camera behind the salesman. Today almost all point of sale equipped with a surveillance cameras. The best place to  install it - up at the wall right behind the salesman. But, this camera could not only capture your face for security purpose , but located at the best position and view angles to take a snapshot of both side of your credit card when salesman  or you rotate it looking for appropriate side to insert it in pos-terminal.





Hey, U , security guys, have you hide CVV code on your credit card? Or flashing it everywhere when take your card out of pocket?
Yes, current standart security camera resolution not enough for good snapshot, but time flies. 


PS. It's almost social engineering thing - we used to see surveillance cameras in any shop and never think about it as a possible security threat.





Monday, June 13, 2011

Security overseas

I thought that even people who faraway from infosec knows that WEP encryption for personal access point is bad idea.... But not for the biggest Canada telecom: Bell.
All Bell's new DSL-modem (with AP) shipping to the customer WEP enabled! More over it's not just shipping from stock- all AP already came preconfigured for the customer!



 The second surprise was: Canadian banks have no slightest idea about such simple thing of m-banking as sms notifications! So, in country where cash is used really rarely  there is absolutely  no way to stay informed by sms about you credit/debit card transactions! 
Sure thing, all bank have self-care web portals or , even, an iPhone apps, but , guess what? - no two-factors  authentication for end customer at all! No sms notification of login attempts to your online account too.

Sunday, January 2, 2011

Google secure search

Hi folks

You must've knew that Google support search over ssl.
So, do not forget to turn it on in your browser. It's a snap:
1. Change your default home page to https://www.google.com/
2. For Chrome browser  add to search engines list new entry (Preference/Basic):
-name: secure_google or whatever you like
-keywords: whatever you like
-url: https://encrypted.google.com/search?q=%s  - sure thing you can add more parameters to this search string if your want.
3.Make this search engine your default search engine.

That's all. Stay secure.