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/

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). ---  

:-)

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 :-)

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.

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.

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.

PKI authentication and legacy web application

One of the most secure ways of user authentication- is the PKI authentication. A lot of modern systems support this method and everything works nice and smoothly (almost everything - details in the my next post). But, as usually, in real big enterprise you have a dilemma: you need the strongest authentication but you have a lot of legacy systems (or it takes ages to get changes in authentication method from vendor).

The best way (IMHO) to resolve this problem is to use mutual ssl on certificates.

SSL will terminate on reverse proxy server in front of your Business Application Server inside the high secure network zone . So, here the scheme:

It looks really easy, isn't it?

How it works:

1. Each user has his own certificate and private key. It could be located on smart card, token or inside OS key storage.

2. User's browser must be configured to use this certificate for authentication (It's easy - just import it in browser or point it to OS key storage)

3. User must connect to revers proxy server (ssl termination point) for getting access to Business Application Server.

4. Revers proxy server checks validity of user's certificate and some certificate's fields (if you need to restrict access to only some users groups) like OU, CN or "extended key usage" and establish mutual ssl connection.

5. Revers proxy server offloads ssl and make direct connection over http (or non-mutual ssl connection) to your business application server.

6. Business application server authenticate user and authorised them by user/password pair.

The key point of this scheme is the Revers Proxy Server with ssl offloading feature (May be the better name for it - Secure Application Gateway).

How this servers looks like?

1. Open Source:

Any *nix + Apache web server with mod_proxy and mod_ssl + some changes in Apache config for certificate verification.

2. Load balancer or Web Application firewall from your favorite vendor. I have tested this on F5 BigIP and everything works perfectly.

Almost forget. You will get a lot of users' web request logging possibilities during  implementation of this scheme. So you can easily control users' activity within business application server.

That's all folks. Stay secure.