Access-list maken d.m.v. controle op porten (sniffing)

[Verwijderd]

Ik ben bezig met een nieuwe access-list te ontwikkelen voor het bedrijf waarvoor ik werk.
Op dit moment mag alles van binnen naar buiten toe, maar is er wel een controle op wat er van buiten naar binnen toe komt.

Qua veilig lijkt het me belangrijk dat ook interne programma's die onbewust of zonder het te weten mee draaien, geknepen worden.
Ik heb een server geinstalleerd met WireShark en deze aangesloten op een hub, helemaal aan het begin van het netwerk.
Alles wat communiceert komt zo langs deze server, en ik verbaas me eigenlijk nog over wat er allemaal voor 'vreemde' porten voorbij komen schuiven.

Ik begin in te zien dat het erop lijkt dat alle programma's die met internet communiceren, intern, dus nog in het netwerk, naar buiten gaan op een port, zoals bijvoorbeeld 3464 en bij de tegenpartij aankomen op port 80.
Het idee wat ik had dat port 80 extern ook port 80 is dus hiermee weg.

Het is eigenlijk nog lastig om door de bomen het bos te zien, want intern draaien er zo veel verschillende porten dat ik begin te twijfelen om deze inderdaad af te knijpen en intern ook een access-list te plaatsen.
Wat kan ik het beste doen keuzes te maken om toch intern er ook een access-list op te plaatsen?

[Bl@ckbird]

Maak eerst eens een inventarisatie van applicaties die overal geïnstalleerd staan.
Bepaal of ze internet access nodig hebben. (Ook voor bijvoorbeeld updates.)
En zoek hier de TCP/UDP poortnummers bij. (Via websites.)
Sysinternals heeft een tooltje waarmee je kan kijken welke TCP /UDP poorten er worden gebruikt.

Vervolgens blok je alles, behalve voor "legale" applicaties, die je wil toestaan op je netwerk.

Kijk ook of je router / firewall syslog ondersteund.
( De router moet log gegevens spugen naar een syslog server. )

Met andere tooltjes kan syslog gegevens analyseren.

Edit:
Idd. een goede dedicated statefull firewall of een statefull firewall in een router kan je hiermee helpen.
Als aanvulling op een firewall kan je evt. ook kijken naar een IPS. ( Evt. geïntegreerd in de router / firewall.)

[ Voor 16% gewijzigd door Bl@ckbird op 31-03-2009 09:22 ]

[Verwijderd]

Heb je ook een tip wat betreft de hoeveelheid 'vreemde' poorten die naar buiten communiceren?

Ik heb stapels pakketjes die op poorten in de 3000 naar buiten gaan en bij de tegenpartij aankomen op 80, de naam van sommige is bijvoorbeeld:
edm-adm-notify
svnet (3413)
networklens (3409)

En ga zo maar door.

Googlen heeft weinig nut, want dan zie ik lijsten met een bevestiging dat inderdaad dat protocol op die poort draait. Maargoed dat zegt dus helemaal niets over wat het doet en of het erg is om het dicht te knijpen.

[jvanhambelgium]

ACL's zijn zo 1990 ;-) en zijn eigenlijk niet echt veel waard anno 2009 vanuit security viewpoint.

Stomme vraag maar hebben jullie eigenlijk een firewall binnen dit bedrijf of een ander "policy enforcement point" zoals een proxy-server ofzo ?

Je moet ook eens kijken om een security policy uit te schrijven waarin je duidelijk gaat oplijsten wat mag en niet mag/kan.

Ik ben er zeker van dat je de legitieme traffic serieus kan terugbrengen. Je hebt uiteraard de klassiekers zoals windows-updates (tenzij je met 1 centrale WSUS-server werkt?) en AV-updates.

[TrailBlazer]

Uitgaande verbindingen zullen in 99% van de gevallen op een random source poort boven de 1024 hebben. Als beide kanten altijd poort 80 zou gebruiken voor een sessie is het voor beide kanten niet meer uit te bepalen zijn welk pakket bij welke sessie hoort als je meerdere sessies naar 1 server hebt.
Als ik een pagina hier op tweakers open dan worden alle plaatjes parallel gedownload van tweakimg.net. Elke sessie die mijn pc opzet naar tweakimg pakt dan een willekeurige poort boven die 1024.
Er zijn programma's die luisteren op een poort boven de 1024 (MySQL 3306 is een bekende) mocht je PC dan toevallig poort 3306 kiezen als de random source port dan zal Wireshark dit vertalen naar MySQL. Als 1 van de 2 poortnummer onder de 1024 is dan kan je er van uit gaan dat dat de poort is die je vanaf het internet moet permitten.
Overigens een goede firewall is statefull. Dit houdt in dat de FW bijhoudt welke sessies en van binnen naar buiten zijn opgezet en dan het verkeer wat bij die sessie hoort netjes doorlaat als het terugkomt.

edit ik zal me maar eens heel goed gaan inlezen in networking als je dit soort basic dingen niet weet en je het wel moet opleveren.

[ Voor 6% gewijzigd door TrailBlazer op 31-03-2009 09:10 ]

[DigiK-oz]

Applicaties die "naar buiten gaan" pakken vrijwel altijd gewoon de eerste vrije poort, te beginnen bij 1025 dacht ik. En dat zegt dus niks over het soort verkeer. De destination port is degene waarop jij in eerste instantie wilt filteren. Monitor maar eens een specifiek systeem, en ga daar wat op webbrowsen (eventueel met meerdere browsers tegelijk), dan zie je wat ik bedoel.

Applicaties die een port openen om data te ontvangen (status "listening" van de port) kun je weer wel redelijk bepalen waar ze voor dienen a.d.h.v. het portnummer (dan heb je dus wel wat aan de lijsten die je all over the net vindt, en waarvan jij er een paar noemt hierboven).

Wat ben ik weer traag, en dan is Trailblazer ook nog eens duidelijker

[ Voor 6% gewijzigd door DigiK-oz op 31-03-2009 09:14 ]

[Vicarious]

Verwijderd schreef op dinsdag 31 maart 2009 @ 08:52:
Heb je ook een tip wat betreft de hoeveelheid 'vreemde' poorten die naar buiten communiceren?

Ik heb stapels pakketjes die op poorten in de 3000 naar buiten gaan en bij de tegenpartij aankomen op 80, de naam van sommige is bijvoorbeeld:
edm-adm-notify
svnet (3413)
networklens (3409)

En ga zo maar door.

Googlen heeft weinig nut, want dan zie ik lijsten met een bevestiging dat inderdaad dat protocol op die poort draait. Maargoed dat zegt dus helemaal niets over wat het doet en of het erg is om het dicht te knijpen.

Je moet dan ook alleen filteren op destination port. Een computer maakt altijd verbinding via een hoger poortnummer als source poort, anders zou hij maar 1 http-verbinding tegelijk kunnen openen. Hoe houdt de computer anders immers de verschillende sessies uit elkaar als ze allemaal vanaf hetzelfde poortnummer verbinden?

[Kabouterplop01]

ACL's zijn zo 1990 ;-) en zijn eigenlijk niet echt veel waard anno 2009 vanuit security viewpoint.

Offtopic: Waar doel je op? Ik vind je opmerking hoogst interessant namelijk. Als je alles MOET controleren dan ontkom je denk ik niet aan wat ACL's. (Als je vindt dat dit een heel andere discussie wordt..; het is iig niet mijn intentie om te kapen)

[TrailBlazer]

ACL (als in de klassieke Access list op een Cisco) moet je naar mijn mening enkel gebruiken om dingen als routingupdates te filteren en om op je VTY te zetten bijv. De statefullness van een ACl is gewoon drie keer nul. Wil je een firewall functionaliteit hebben koop er dan ook gewoon een.

[jvanhambelgium]

TrailBlazer schreef op dinsdag 31 maart 2009 @ 20:53:
ACL (als in de klassieke Access list op een Cisco) moet je naar mijn mening enkel gebruiken om dingen als routingupdates te filteren en om op je VTY te zetten bijv. De statefullness van een ACl is gewoon drie keer nul. Wil je een firewall functionaliteit hebben koop er dan ook gewoon een.

I second that ;-)
Dus ja, wat RFC1918 filtertjes is best schattig op een router, maar ook niet gaan overdrijven ;-)
Alsook wat klassieke anti-spoof rules (eigen ip-ranges etc)

Met "reflexive ACL's" ben je al iets meer "statefull" , en wil je nog intelligenter uitpakken zit je al in de CBAC (firewall feature set)

Uiteraard als je een zeer klein bedrijfje ben en de middelen zijn krap moet je wat inventief zijn hé, ik deed dat vroeger ook toen Cisco 2500 modelletjes nog hot waren ;-)

[ Voor 3% gewijzigd door jvanhambelgium op 31-03-2009 21:14 ]

[jvanhambelgium]

Kabouterplop01 schreef op dinsdag 31 maart 2009 @ 20:30:
[...]


Offtopic: Waar doel je op? Ik vind je opmerking hoogst interessant namelijk. Als je alles MOET controleren dan ontkom je denk ik niet aan wat ACL's. (Als je vindt dat dit een heel andere discussie wordt..; het is iig niet mijn intentie om te kapen)

Als je alles moet controleren ?? Bedoel je dan eerder gewoon een "permit ip any any log-input" of zoiets ?
Gewoon om alles te loggen ?? Gaat de router niet altijd prettig vinden natuurlijk...
Dan zou ik eerder opteren om inderdaad met een "bridged" linux bak alles te onderscheppen en daar zijn weer mooie tooltjes voor om alle traffiek in kaart te brengen en als je "de baseline" hebt beginnen definieren wat kan en niet kan.

Als je device wat flinker is kan je Netflow overwegen ook ...

[Verwijderd]

Ik zou beginnen met niks doorlaten en alleen de poorten openzetten dmv source -> destination adres voor programma's waarvan licenties zijn aangeschaft.
Deze change tijdig aankondigen en op input van gebruikers wachten. (pietje uit amsterdam die een bijv. een verbinding nodig heeft met een sqlserver bij ticker in amersfoort). en ALLES documenteren.
Je zou nu alvast kunnen beginnen met het filteren van verbindingen waarvan je zeker bent dat deze opgezet moeten/mogen worden.

[Kabouterplop01]

Als je alles moet controleren ?? Bedoel je dan eerder gewoon een "permit ip any any log-input" of zoiets ?

Als je device wat flinker is kan je Netflow overwegen ook ...

ik bedoel eerder op ISP nivo alles controleren.... Alle verkeersstromen; je frontend je dmz en je backend. dat is zeker geen permit ip any any log.. (Dat is geen controleren, maar nakijken. Hier doel ik op controleren als in sturen op) Anyway ik snap je standpunt nu, ook al geef je antwoord met een vraag!

Ontopic
Maar eens als je echt dpi en statefull inspection wil dan wellicht de juiste instrumenten daarvoor kopen

[jvanhambelgium]

Kabouterplop01 schreef op woensdag 01 april 2009 @ 15:55:
[...]


ik bedoel eerder op ISP nivo alles controleren.... Alle verkeersstromen; je frontend je dmz en je backend. dat is zeker geen permit ip any any log.. (Dat is geen controleren, maar nakijken. Hier doel ik op controleren als in sturen op) Anyway ik snap je standpunt nu, ook al geef je antwoord met een vraag!

Ontopic
Maar eens als je echt dpi en statefull inspection wil dan wellicht de juiste instrumenten daarvoor kopen

Op ISP niveau is het dikwijls Netflow dat gebruikt kan worden om "inzicht" te krijgen wat er over de kabel loopt.
Goede ondersteuning op de grote / middelgrote dozen.

http://www.arbornetworks.com/ hebben ook cool spul om dit dingen in kaart te brengen en bescherming te bieden tegen bepaalde dingen...

[Verwijderd]

Vergeet ik toch bijna m'n eigen topic.

Jammer weer zo'n sneer als:

edit ik zal me maar eens heel goed gaan inlezen in networking als je dit soort basic dingen niet weet en je het wel moet opleveren.

Was inderdaad niet bekend met het feit dat elke aanvraag naar een website op een eigen poort gebeurt.
Routeerd de router dit wel gewoon goed? We maken gebruik van een Cisco ASA-5510, de mogelijkheden zijn gigantisch.
Ik neem dus aan dat als ik (even een voorbeeld) alles dichtzet, behalve poort 80, ik geen problemen ondervind met website die normaal vanaf de source (werktstation in dit geval) worden aangeroepen op bijvoorbeeld 3413?
Er kunnen dus gewoon nog websites bezocht worden, en de router gaat hier zelf goed mee om door bijvoorbeeld een label aan elk pakketje te hangen?

Heb een access-list gemaakt doormiddel van alle belangrijke informatie op te zoeken.
Zo hebben we een IPSEC verbinding met een externe computer. Ik heb dus een access-list samen gesteld met porten als, ISAKMP 500 (UDP). HTTPS 443 (TCP) en bijvoorbeeld alle porten gebruikt door VoiP.
Zo heb ik een flinke lijst met porten die ik sowiesie openstel om van binnen naar buiten te communceren.


Ik denk dat ik er voor de rest wel uit ben. In feite moet ik toch echt zelf ondervinden wat ik over het hoofd hebt gezien.
Op de opmerking na van jvanhambelgium, was er eigenlijk weinig nieuws en extra informatie m.b.t. access-lists ik lees me dus nu wat in over CBAC.
Thanks.

[TrailBlazer]

Verwijderd schreef op vrijdag 10 april 2009 @ 11:30:
Vergeet ik toch bijna m'n eigen topic.

Jammer weer zo'n sneer als:

[...]

Hoezo sneer. Ik zeg gewoon waar het op staat. Dit is basic TCP/IP kennis die je gewoon als moet hebben wil je hier mee aan de gang gaan. Volgens mij leg ik daarboven keurig voor je uit hoe TCP werkt alleen dat laat je gewoon even weg

[Flyduck]

Verwijderd schreef op vrijdag 10 april 2009 @ 11:30:

Ik neem dus aan dat als ik (even een voorbeeld) alles dichtzet, behalve poort 80, ik geen problemen ondervind met website die normaal vanaf de source (werktstation in dit geval) worden aangeroepen op bijvoorbeeld 3413?
Er kunnen dus gewoon nog websites bezocht worden, en de router gaat hier zelf goed mee om door bijvoorbeeld een label aan elk pakketje te hangen?

Heb een access-list gemaakt doormiddel van alle belangrijke informatie op te zoeken.
Zo hebben we een IPSEC verbinding met een externe computer. Ik heb dus een access-list samen gesteld met porten als, ISAKMP 500 (UDP). HTTPS 443 (TCP) en bijvoorbeeld alle porten gebruikt door VoiP.
Zo heb ik een flinke lijst met porten die ik sowiesie openstel om van binnen naar buiten te communceren.


Ik denk dat ik er voor de rest wel uit ben. In feite moet ik toch echt zelf ondervinden wat ik over het hoofd hebt gezien.
Op de opmerking na van jvanhambelgium, was er eigenlijk weinig nieuws en extra informatie m.b.t. access-lists ik lees me dus nu wat in over CBAC.
Thanks.

Je moet als je het goed wil doen natuurlijk wel protocol inspection gebruiken. Verder moet je maar eens inlezen wat het verschil is tussen source en destination poorten.
Je geeft aan dat je vanaf je interne netwerk een ipsec verbinding naar buiten gaat opzetten door de asa heen? Waarom terminate je de tunnel niet gewoon op de ASA? IPSEC gebruikt trouwens ook protocol 50.
CBAC is overigens voor IOS routers en niet voor de ASA.

[Vicarious]

Flyduck schreef op vrijdag 10 april 2009 @ 12:03:
[...]
Je geeft aan dat je vanaf je interne netwerk een ipsec verbinding naar buiten gaat opzetten door de asa heen? Waarom terminate je de tunnel niet gewoon op de ASA? IPSEC gebruikt trouwens ook protocol 50.

Wellicht wil hij gewoon met een Cisco client naar buiten connecten naar verschillende andere netwerken met een concentrator/pix/asa?

[Verwijderd]

Flyduck schreef op vrijdag 10 april 2009 @ 12:03:
[...]


Je moet als je het goed wil doen natuurlijk wel protocol inspection gebruiken. Verder moet je maar eens inlezen wat het verschil is tussen source en destination poorten.
Je geeft aan dat je vanaf je interne netwerk een ipsec verbinding naar buiten gaat opzetten door de asa heen? Waarom terminate je de tunnel niet gewoon op de ASA? IPSEC gebruikt trouwens ook protocol 50.
CBAC is overigens voor IOS routers en niet voor de ASA.

De tunnel terminaten op de ASA..?
Er zit een policy op de server intern, en een policy op een andere server, extern.
Beide communiceren met elkaar via IPSEC, vandaar dus die local policy op beide servers.