---

Jeg er i gang med at lave et projekt omkring hvordan man via tunneller kan
omgå firewalls indefra. Dvs. hvorledes man kan anvende FTP, telnet mmm.
selvom firewallen f.eks. kun tillader trafik ud på port 80.

Mod den simpleste form for firewall beskyttelse der blot lader trafikken
sive ud gennem f.eks. port 80 synes løsningen lige til: man kontakter en
ekstern tunnel på port 80, der så videreformidler en til den ønskede IP og
port.

Men hvad hvis firewallen laver en form for indholdscheck af de sendte
pakker? Ved f.eks. at kigge på om det nu også er HTML der sendes over
porten. Kan man da blot lave en slags "http marshalling" ved at smide nogen
html tags omkring pakkerne inde man sender dem ud, encode binært iht. RFCen
for HTTP og få den eksterne tunnel til at fjerne dette? Hvad er
sandsynligheden for at firewallen vil opdag dette, og hvordan vil den gøre
det?

Helt "galt" synes det så at være hvis firewallen checker om trafikken nu
også opfører sig som HTTP: HTTP er jo karaktiseret ved at klienten kun
sender én forespørgelse af begrænset størrelse, serveren svarer og socket
nedlukkes. Protokoller der anvender lange forbindelsestider og kræver flere
sendinger fra klienten – f.eks. telnet -, vil således ikke umiddelbart kunne
omgå firewalls der anvender denne form for "forbindelsescheck". Eller?

For at vise princippet bag tunnellen har jeg lagt en illustration op på
http://www.it.edu/~morton/Tunnel.ppt . Venstre side er intranettet, højre
Internettet.

Er der nogen der kender til hvordan indholdsscheck fungerer og
begrænsningerne i disse? Links, erfaringer o.l. ville altsammen være af
største interesse!

På forhånd tak for hjælpen.

-- Morton

---

Morton P. Christiansen <morton_c@worldonline.dk> wrote:
> Er der nogen der kender til hvordan indholdsscheck fungerer og
> begrænsningerne i disse? Links, erfaringer o.l. ville altsammen være af
> største interesse!

Covert channels er et rimeligt bredt emne og der har blandt andet
vaeret eksempler paa PC'ere der er blevet styret gennem skjulte beskeder
i ICMP pakker, email beskeder, osv. Jeg mener det var Whitfield Diffie
der postede en proof of concept trojan der patchede MS Outlook og MS
Messenger, og saaledes kunne kommunikeres med det installeret program
gennem email og instant messagess uden at brugeren kunne maerke det.

Covert channels over HTTP ville virke ved at klienten laver GET eller
POST requests til en server som enten blot optager disse, eller endda
svarer med nye kommandoer som klienten saa udfoerer.

Soeg lidt efter "covert channels" og "content inspection" paa Google,
saa faar du masser af hits, f.eks. dette:

http://www.cyberguard.com/PDF/Solutions_Whitepapers2.pdf

Hm, nu tror jeg egenligt at det var Spafford der postede en trojan, men
lige nu kan jeg ikke finde et godt link.

HTH.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Morton P. Christiansen wrote:

> Jeg er i gang med at lave et projekt omkring hvordan man via tunneller kan
> omgå firewalls indefra. Dvs. hvorledes man kan anvende FTP, telnet mmm.
> selvom firewallen f.eks. kun tillader trafik ud på port 80.


En tunnel kan oprettes hvis der er en form for kommunikation.

Formen på denne kommunikation er ligegyldig, så længe man kan ramme en
maskine på internet der kan bruges.

Hvis fx har tilladt http til én webserver på Internet vil ovenstående
være svært, hvis man da ikke har adgang til webserveren.


> Mod den simpleste form for firewall beskyttelse der blot lader trafikken
> sive ud gennem f.eks. port 80 synes løsningen lige til: man kontakter en
> ekstern tunnel på port 80, der så videreformidler en til den ønskede IP og
> port.


Ja.


> Men hvad hvis firewallen laver en form for indholdscheck af de sendte
> pakker? Ved f.eks. at kigge på om det nu også er HTML der sendes over


Dette kunne også inkludere brugervalidering af http klienterne.

> porten. Kan man da blot lave en slags "http marshalling" ved at smide nogen
> html tags omkring pakkerne inde man sender dem ud, encode binært iht. RFCen
> for HTTP og få den eksterne tunnel til at fjerne dette? Hvad er
> sandsynligheden for at firewallen vil opdag dette, og hvordan vil den gøre
> det?


Hvis du finder en metode for at opdage dette, vil det være trivielt at
finde en metode, så det ikke kan opdages.

En anden måde at bygge en tunnel, kunne være at requeste et gif billed
(denne request kan indholde oplysninger om hvordan den udadgående pakke
ser ud, svaret vil være et gif billed, denne indeholder oplysninger om
hvordan den indgående pakke ser ud).


> Helt "galt" synes det så at være hvis firewallen checker om trafikken nu
> også opfører sig som HTTP: HTTP er jo karaktiseret ved at klienten kun
> sender én forespørgelse af begrænset størrelse, serveren svarer og socket
> nedlukkes. Protokoller der anvender lange forbindelsestider og kræver flere


HTTP/1.1 understøtter pipeline'ning, således kan en socket godt bruges
til flere sessioner.

> sendinger fra klienten - f.eks. telnet -, vil således ikke umiddelbart kunne
> omgå firewalls der anvender denne form for "forbindelsescheck". Eller?


I telnet kan man samle sine "sendinger", det vil man som angriber godt
kunne leve med :)

[cut]

> Er der nogen der kender til hvordan indholdsscheck fungerer og
> begrænsningerne i disse? Links, erfaringer o.l. ville altsammen være af
> største interesse!


indholdsikkerhed går mere på hvilken typer data der flyder, ikke hvordan
det bliver toket af klient/server applikationerne.

---

Tak for rigtige gode pointer fra både dig og Alex.

>> Men hvad hvis firewallen laver en form for indholdscheck af de sendte
>> pakker? Ved f.eks. at kigge på om det nu også er HTML der sendes over
>Dette kunne også inkludere brugervalidering af http klienterne.
Hvad mener du konkret her?

Hvis en trojan ligger og laver forbindelser ud via en krypteret HTTP tunnel
virker det stor set umuligt at fange dette på firewall niveau, og snakken
kommer vist mere over på hvordan man forhindre at trojanen kommer ind og
bliver installeret korrekt til at starte med. Enig?

-- Morton

---

Tak for rigtige gode pointer fra både dig og Alex.

>> Men hvad hvis firewallen laver en form for indholdscheck af de sendte
>> pakker? Ved f.eks. at kigge på om det nu også er HTML der sendes over
>Dette kunne også inkludere brugervalidering af http klienterne.
Hvad mener du konkret her?

Hvis en trojan ligger og laver forbindelser ud via en krypteret HTTP tunnel
virker det stor set umuligt at fange dette på firewall niveau, og snakken
kommer vist mere over på hvordan man forhindre at trojanen kommer ind og
bliver installeret korrekt til at starte med. Enig?

-- Morton

---

"Morton P. Christiansen" wrote:
>
> Tak for rigtige gode pointer fra både dig og Alex.
>
> >> Men hvad hvis firewallen laver en form for indholdscheck af de sendte
> >> pakker? Ved f.eks. at kigge på om det nu også er HTML der sendes over
> >Dette kunne også inkludere brugervalidering af http klienterne.
> Hvad mener du konkret her?
>
> Hvis en trojan ligger og laver forbindelser ud via en krypteret HTTP tunnel
> virker det stor set umuligt at fange dette på firewall niveau, og snakken
> kommer vist mere over på hvordan man forhindre at trojanen kommer ind og
> bliver installeret korrekt til at starte med. Enig?

Enig, det er altid vigtigere at forhindre en trojan i at komme ind,
end det er at forhindre den i at komme ud.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

---

Morton P. Christiansen wrote:

>>Dette kunne også inkludere brugervalidering af http klienterne.
> Hvad mener du konkret her?


Hvis klienterne skal validere sig på firewallen, og trojen ikke er
implementeret til dette, kan den ikke komme. Hvis den er implementeret
til dette skal den fange passwordet af brugeren.


> Hvis en trojan ligger og laver forbindelser ud via en krypteret HTTP tunnel
> virker det stor set umuligt at fange dette på firewall niveau, og snakken


Dette er muligt at fange på firewall niveau!

> kommer vist mere over på hvordan man forhindre at trojanen kommer ind og
> bliver installeret korrekt til at starte med. Enig?


Forbyggelse er altid bedre (dvs. undgå trojen kommer ind).