Squid Redirect Url

script in Perl per il controllo della rispondenza dell’url in ingresso

in questo post ho descritto la funzione di redirect, lo script proposto è utilizzato al fine di controllare che le richieste al Reverse Proxy siano coerenti con il servizio pubblicato

#!/usr/bin/perl
use strict;

$|=1;
## read from standard input
while (<>) {
my @X = split;
my $url = $X[0];

## ###### Dichiarazione output $url proveniente da SQUID per TEST ############
## my $filename = “/squid/Redirect/test.txt”;
## open FILE, “>>$filename”;
## print FILE $url;
## print FILE “n”;
## close FILE;
## ###### FINE  Dichiarazione output $url proveniente da SQUID per TEST ############

## eccezione per l’accesso in http di pagine con nome 9001 e 9002 .jnlp
if ($url =~ m#^http://[^/]*(/)Portale/900[12].jnlp#i) {
print “$urln”;
}

## Controllo formale che l’url abbia un contesto sia HTTP che HTTPS
if ($url =~ m#^https?://[^/]*(/)?$#i) {
print “302:http://www.subdom.dom.it/index.php?id=893n&#8221;;
}

## Controllo formale che l’url sia in HTTPS con l’url puntule altrimenti esco
if ($url !~ m#https://www.subdom.dom.it/Portale(/.*)#i) {
print “302:http://www.subdom.dom.it/index.php?id=893n&#8221;;
}

## controllo che la chiamata sia in https se arriva in http redirigo in https
if ($url =~ m#^http:/(/.*)?#i) {
print “302:https://www.subdom.dom.itn&#8221;;

}

else {

print “$urln”;

}

}

NOTA   ($url =~ m#^http:/(/.*)?#i)  è il confronto in Perl   con al relativa regex di confronto per la coerenza dell’URL in ingresso.

La parte di scrittura in un file test.txt della variabile $url è utile per identificare puntualmente quello che viene gestito dallo script.

Modifica prompt di sistema in OPENBSD

Per variare il prompt presentato dal sistema è sufficiente modificare il file .profile nella HOMEDIR dell’utente, impostando la variabile PS1.

esempio:

  • PS1=”descrizione@h[w]”
  • export PS1

il prompt appare come sotto, dove [/etc] è la directory corrente

descrizione@NomeHost[/etc]

le opzioni possibili sono:

a
esegue un BEEP.
d
Displays the date in "Weekday Month Date" format.
h
Visualizza il nome host abbreviato. 
H
Visualizza il nome host compreso di  dominio.
w
Visualizza la directory corrente.
n
Visualizza il prompt su una nuova linea.
s
Visualizza il nome della Shell corrente.
t
Visualizza l'ora corrente nel formato 24 ore HH:MM:SS
T
Visualizza l'ora corrente nel formato 12 ore HH:MM:SS
@
Visualizza l'ora corrente nel formato 12 ore am/pm
u
Visualizza lo username.
!
Visualizza il numero di comandi in .bash_history
#
Visualizza il numero di comandi eseguiti nella sessione corrente.


Configurazione di OPENBSD (5.6) in ambiente Chroot

chrootLa “funzionalità” di chroot letteralmente Change-Root è tipica dei sistemi Linux e può essere implementata per l’esecuzione di svariati servizi, dove questi sono eseguiti in un contesto differente rispetto al reale.

Viene ad essere modificate la root relativa al servizio in esecuzione simulando quella reale.

In questo modo se un servizio dovesse presentare alcune vulnerabilità, anche sfruttandole e quindi ottenendo l’accesso al sistema, ci si ritroverebbe in un ambiente diverso a quello che realmente permette l’esecuzione del servizio stesso.

Più semplicemente potremmo eseguire diversi servizi su un’unica installazione di base, isolandoli l’uno dall’altro.

Tuttavia l’adozione della funzione di chroot non è da considerarsi da sola come risolutiva di bug di sicurezza,(https://securityblog.redhat.com/2013/03/27/is-chroot-a-security-feature/)   sono sempre necessari tutti vari accorgimenti al fine di rendere un sistema “sicuro”. L’installazione di patch di sicurezza, l’adozione di software compilati con le opzioni realmente necessarie, l’impostazione puntuale dei premessi sulle varie directory, sono solo alcuni accorgimenti utili.

In questo caso sono illustrati i passi necessari al fine di realizzare una struttura chroot a partire da una cartella /chroot su un sistema OPENBSD, questo ambiente è poi utilizzato per la compilazione e la configurazione di  servizi quali SQUID, BIND, etc.

Si presume che il sistema operativo “base”, ossia una installazione di Openbsd sia già operativa e configurata,

A questo punto, utilizzando  una nuova partizione, è necessario tramite le opzioni proprie del sistema operativo, crearla, formattarla ed effettuare il mount sul percorso /chroot da ora in poi questo diventa il nuovo percorso di “/” per la successiva installazione su cui andrà compilato SQUID.

Nel dichiarare il mount in /etc/fstab è necessario specificare che questo dovrà avvenire senza le opzioni  nodev e nosuid

  • 814fb7ccfd84e045.l /chroot ffs rw 1 2

Nella definizione del sistema operativo all’interno di /chroot dovranno essere ri-creati i vari device (in questo caso fittizi) utilizzati per il corretto funzionamento.

L’opzione di default relativa al mount non consente l’utilizzo di questi device nodes così come non consente l’impostazione del SUID SUID (Set owner User ID up on execution) bit dei vari files.

Effettuato il Mount con i parametri richiesti, bisogna scompattare l’intero contenuto dei vari files .tgz presenti nel CD di installazione

  • cd /chroot

estrazione di tutti i pakages dal cd del Sistema Operativo

  • tar -xzf /media/5.6/i386/base56.tgz  
  • tar -xzf /media/5.6/i386/etc56.tgz
  • tar -xzf /media/5.6/i386/comp56.tgz
  • tar -xzf /media/5.6/i386/xbase56.tgz
  • tar -xzf /media/5.6/i386/xshare56.tgz
  • tar -xzf /media/5.6/i386/xetc56.tgz
  • tar -xzf /media/5.6/i386/xfont56.tgz
  • tar -xzf /media/5.6/i386/xserv56.tgz

A questo punto sono state ricreate in /chroot tutte le cartelle presenti in “/”,bin,etc,var…… etc.

Come accennato prima, relativamente ai device, è necessario che vengano ricreati, eseguendo il comando MAKEDEV all.

  • cd dev
  • ./MAKEDEV all
  • cd

Per rendere l’ambiente chroot autonomo nella risoluzione DNS bisogna copiare in /etc ( /chroot/etc ) il file resolv.conf presente nella “/” del Sistema operativo principale

  •  cp /etc/resolv.conf etc/

L’ultimo passo per terminare la configurazione dell’ambiente è la creazione tramite ldconfig del file  /var/run/ld.so.hints  che a partire dai percorsi passati come parametro al comando crea i riferimenti per la librerie utilizzate dai vari servizi.

  • chroot /chroot ldconfig /usr/lib /usr/local/lib /usr/X11R6/lib

La configurazione è terminata per accedere al nuovo ambiente “chroot-ato” è sufficiente eseguire

  • chroot /chroot su -l

La  shell, e quindi l’ambiente a cui si accede è di fatto un ambiente “al di sotto” dell’ambiente che ha eseguito il boot, quindi se dovessimo, come potrebbe essere necessario fare, creare un utente, il comando useradd creerebbe uno user in questo contesto e l’ambiente “padre” non ne vedrebbe l’esistenza. Anche nell’elencare le permission sui files, queste se viste dalla root presenterebbero come owner il solo ID.

Al fine di evitare confusioni è utile modificare il prompt del sistema in modo che informi con esattezza dell’ambiente su cui si sta operando

Configurazione di OPENBSD (.5.6) in ambiente Chroot

chrootLa “funzionalità” di chroot letteralmente Change-Root è tipica dei sistemi Linux e può essere implementata per l’esecuzione di svariati servizi, dove questi sono eseguiti in un contesto differente rispetto al reale.

Viene ad essere modificate la root relativa al servizio in esecuzione simulando quella reale.

In questo modo se un servizio dovesse presentare alcune vulnerabilità, anche sfruttandole e quindi ottenendo l’accesso al sistema, ci si ritroverebbe in un ambiente diverso a quello che realmente permette l’esecuzione del servizio stesso.

Più semplicemente potremmo eseguire diversi servizi su un’unica installazione di base, isolandoli l’uno dall’altro.

Tuttavia l’adozione della funzione di chroot non è da considerarsi da sola come risolutiva di bug di sicurezza,(https://securityblog.redhat.com/2013/03/27/is-chroot-a-security-feature/)   sono sempre necessari tutti vari accorgimenti al fine di rendere un sistema “sicuro”. L’installazione di patch di sicurezza, l’adozione di software compilati con le opzioni realmente necessarie, l’impostazione puntuale dei premessi sulle varie directory, sono solo alcuni accorgimenti utili.

In questo caso sono illustrati i passi necessari al fine di realizzare una struttura chroot a partire da una cartella /chroot su un sistema OPENBSD, questo ambiente è poi utilizzato per la compilazione e la configurazione di  servizi quali SQUID, BIND, etc.

Si presume che il sistema operativo “base”, ossia una installazione di Openbsd sia già operativa e configurata,

A questo punto, utilizzando  una nuova partizione, è necessario tramite le opzioni proprie del sistema operativo, crearla, formattarla ed effettuare il mount sul percorso /chroot da ora in poi questo diventa il nuovo percorso di “/” per la successiva installazione su cui andrà compilato SQUID.

Nel dichiarare il mount in /etc/fstab è necessario specificare che questo dovrà avvenire senza le opzioni  nodev e nosuid

  • 814fb7ccfd84e045.l /chroot ffs rw 1 2

Nella definizione del sistema operativo all’interno di /chroot dovranno essere ri-creati i vari device (in questo caso fittizi) utilizzati per il corretto funzionamento.

L’opzione di default relativa al mount non consente l’utilizzo di questi device nodes così come non consente l’impostazione del SUID SUID (Set owner User ID up on execution) bit dei vari files.

Effettuato il Mount con i parametri richiesti, bisogna scompattare l’intero contenuto dei vari files .tgz presenti nel CD di installazione

  • cd /chroot

estrazione di tutti i pakages dal cd del Sistema Operativo

  • tar -xzf /media/5.6/i386/base56.tgz  
  • tar -xzf /media/5.6/i386/etc56.tgz
  • tar -xzf /media/5.6/i386/comp56.tgz
  • tar -xzf /media/5.6/i386/xbase56.tgz
  • tar -xzf /media/5.6/i386/xshare56.tgz
  • tar -xzf /media/5.6/i386/xetc56.tgz
  • tar -xzf /media/5.6/i386/xfont56.tgz
  • tar -xzf /media/5.6/i386/xserv56.tgz

A questo punto sono state ricreate in /chroot tutte le cartelle presenti in “/”,bin,etc,var…… etc.

Come accennato prima, relativamente ai device, è necessario che vengano ricreati, eseguendo il comando MAKEDEV all.

  • cd dev
  • ./MAKEDEV all
  • cd

Per rendere l’ambiente chroot autonomo nella risoluzione DNS bisogna copiare in /etc ( /chroot/etc ) il file resolv.conf presente nella “/” del Sistema operativo principale

  •  cp /etc/resolv.conf etc/

L’ultimo passo per terminare la configurazione dell’ambiente è la creazione tramite ldconfig del file  /var/run/ld.so.hints  che a partire dai percorsi passati come parametro al comando crea i riferimenti per la librerie utilizzate dai vari servizi.

  • chroot /chroot ldconfig /usr/lib /usr/local/lib /usr/X11R6/lib

La configurazione è terminata per accedere al nuovo ambiente “chroot-ato” è sufficiente eseguire

  • chroot /chroot su -l

La  shell, e quindi l’ambiente a cui si accede è di fatto un ambiente “al di sotto” dell’ambiente che ha eseguito il boot, quindi se dovessimo, come potrebbe essere necessario fare, creare un utente, il comando useradd creerebbe uno user in questo contesto e l’ambiente “padre” non ne vedrebbe l’esistenza. Anche nell’elencare le permission sui files, queste se viste dalla root presenterebbero come owner il solo ID.

Al fine di evitare confusioni è utile modificare il prompt del sistema in modo che informi con esattezza dell’ambiente su cui si sta operando