Netwerk beveiliging

[Verwijderd]

Bedrijfssituatie:
Aantal werkstations: 400
Prive computers: 400
Servers: ook een aantal
en natuurlijk een firewall


In ons bedrijf krijgen we regelmatig mailtjes van (automatische firewalls) e.d. dat wij proberen te " hacken" etc.
Dit komt omdat wij met 1 ip adres naar buiten gaan. (intern dns)
Wij kunnen dus nooit zien wie dat is geweest (intern)


Kunnen we dit loggen op de 1 of andere manier?

Ik heb geen idee...

Misschien een wazig verhaal, maar ik zou het niet anders kunnen omschrijven

[Verwijderd]

vertel eerst eens welke firewaal je hebt.
en hoe jullie nat hebben geconfigureerd en eventueel een dhcp scope.

[Verwijderd]

Betere beschrijving van de e-mails m.b.t. het "Hacken" is natuurlijk wel handig...

Domain en protocol policy is ook wel van beland ;-) (toegestane uitgaande protocollen e.d.)

[Verwijderd]

Ja maak ff een screenshotje van je rulebase op de firewall.

[oZy]

zal wel gewoon een NT TCP scan zijn die opzoek is naar computers op het netwerk.. kreeg ik ook wel eens een mailtje over dat ik aan het "hacken" was.

[Verwijderd]

Firewall: Cisco PIX 525

Screenshot Rules: (we hebben ze net veranderd)

http://www.africanviolet.com/pix/translation_rules.jpg

mailtje:

Onderwerp: CERT-NL#blaat: DShield Fightback regarding 194.171.135.3 (fwd)


Waarde KIM Site Security Contact,

CERT-NL ontving een ge-automatiseerde DShield-melding over probes die
vanaf IP-adres 194.171.135.3 gedaan zouden zijn. DShield heeft inmiddels
al 718 'records' over deze doos. Het lijkt erop dat betreffend systeem
besmet is met ongerief. Zouden jullie dit kunnen onderzoeken en indien
nodig passende maatregelen kunnen nemen ? Graag ook terugmelding onder
nummertje CERT-NL#blaat zodat we dit geval in onze administratie kunnen
afsluiten.

Met vriendelijke groeten,

Xander Jansen
CERT-NL

---------- Forwarded message ----------
Date: Tue, 22 Apr 2003 06:03:01 -0500
From: [e-mail]
To: [e-mail]
Subject: DShield Fightback regarding 194.171.135.3


Hi.

A user of DShield.org, the Distributed Intrusion Detection System,
submitted a log excerpt which indicates a probe from one of your users.
Please notify the user and take appropriate actions to avoid further problems.

Details:

Source IP: 194.171.135.3 (port: 3566)
Target IP: 134.243.99.113(port: 137)
Protocol: 17 (Flags: )
Time: 2003-04-22 08:25:39 (GMT)


Original Log as submitted:

2003-04-22 08:25:39 GMT 194.171.135.003 3566 -> 134.243.099.113 137 17

Need more logs/evidence? See: http://www.dshield.org/ip...171.135.003&v=10000741779

A total of 718 records in dshield's database implicate
this IP address. These records show attacks against 718 unique
targets. This report includes one sample of these records.

This report was submitted to Dshield.org by [e-mail]

For more information about DShield see http://www.dshield.org
Please let us know if you would not like any further notices from DShield.org
or if you would prefer a different format.

You have permission to share this information to facilitate a solution
of this problem.

Thanks.

[e-mail]
http://www.dshield.org/fightback.html

IMPORTANT: If you require further assistance, please reply and add the word
'URGENT' to the subject. Please include this full email in your reply.

[ Voor 4% gewijzigd door Verwijderd op 23-04-2003 09:59 ]

[Koffie]

Move PNS > NT

[Verwijderd]

Volgende protocol wordt naar buiten gebruikt voor het "Hacken".

The Service Location Protocol (SLP) [50] uses multicast, softstate and simple filter expressions to advertize and query the location, type and attributes of services

Op firewall zorgen dat dit protocol niet naar buiten toe wordt gebruikt. Hier zijn tal van oplossingen voor.

[Verwijderd]

ja maar dat is niet de bedoeling, want je kunt ook over port 80 hacken en die is niet te blocken.
In dit geval gaat het niet perse over hoe je hacken kunt voorkomen, maar hoe kun je nou die translation rule loggen?

[Verwijderd]

Heb het in post hierboven niet over poorten blokeren, maar het protocol.

[Verwijderd]

Logging mogelijkheden liggen aan de software die de NAT regelt. Wat je kunt doen is een sniffer gebruiken en filteren op SLP verkeer dat naar 'buiten' is geadresseerd, dan heb je de herkomst van het verkeer. Dan nog het aanpassen van de configuratie van de software dat deze SLP pakketten verstuurd zodat deze niet meer naar buiten worden verzonden en opgelost... in THEORIE natuurlijk :-)

Maar ken je NAT software niet.

[egeltje]

Hmmm... wat me opvalt is dat al die 'hacks' naar hetzelfde segment gaan. 134.243.0.0/16 is geregistreerd door cas.org.
Het lijkt er op of iemand van binnen een netbiso sessie probeert te starten naar een van die machines.

Gaat er iemand huilen als je dat niet toestaat?
Het is trouwens sowieso good-practice om niet standaard alles van binnen naar buiten open te zetten...

[Brahiewahiewa]

Wat denk je er van om op je firewall gewoon port 137 (en 135 en 138 en 139) naar buiten toe dicht te zetten? Als je in die logs van dshield kijkt, zie je dat er iemand bij jullie gewoon ordinair zit te port scannen.
Als er iemand een business reason heeft om een NetBIOS over internet te moeten doen, gaat-ie zich vanzelf wel bij jou melden. Maar geloof me: geen enkel zinnig mens biedt bewust informatie aan op internet via NetBIOS, dus die business reason kan er niet zijn.

[Verwijderd]

Verwijderd schreef op 23 April 2003 @ 10:15:
Logging mogelijkheden liggen aan de software die de NAT regelt. Wat je kunt doen is een sniffer gebruiken en filteren op SLP verkeer dat naar 'buiten' is geadresseerd, dan heb je de herkomst van het verkeer. Dan nog het aanpassen van de configuratie van de software dat deze SLP pakketten verstuurd zodat deze niet meer naar buiten worden verzonden en opgelost... in THEORIE natuurlijk :-)
Maar ken je NAT software niet.

een sniffer heb ik best wel een krachtige machine voor nodig en is vrij onderhoudsgevoelig (of iemand moet een goede sniffer weten?, wij gebruiken nu: Iris Network Traffic analyzer). is er niet iets hardwarematig?

want de firewall biedt ook niet echt logging mogelijkheden

en ik wil ook niet alles van binnen naar buiten dichtzetten omdat sommige mensen moeten inloggen e.d. op porten naar bijv. de bibliotheek in (TU)delft.

btw: wat is SLP verkeer?

[ Voor 33% gewijzigd door Verwijderd op 23-04-2003 10:50 ]

[Verwijderd]

Service Location Protocol (SLP) verkeer

http://www.ietf.org/html.charters/svrloc-charter.html

http://www.networkcomputi...2ws22.html?ls=NCJS_1112bt

Als het sniffen al zwaar aan de machine vreet, wat denk je dat het loggen van alle NAT's teweeg brengt.

Volgens mij moet je een beetje security-by-default gaan hanteren, en poorten dicht gaan zetten. Hebben mensen deze poorten nodig dan krijg je het wel te horen.

Probeer wanneer mogelijk eens een firewall die het filteren op protocollen toestaat en blokeer het SLP protocol, volgens mij zijn je problemen dan opgelost (maar 1 oplossing).

Zoals altijd zijn er legio oplossingen te bedenken voor dit soort problemen, ga per oplossing na wat de invloed ervan is op zowel de technische aspecten van het netwerk als ook de organisatorische aspecten.

Suc6

[egeltje]

Verwijderd schreef op 23 April 2003 @ 10:43:
[...]

en ik wil ook niet alles van binnen naar buiten dichtzetten omdat sommige mensen moeten inloggen e.d. op porten naar bijv. de bibliotheek in (TU)delft.

Dat (alles dichtzetten) moet je ook niet doen.
Je moet alleen open zetten wat mensen _echt_ nodig hebben (poort 21, poort 80, poort 443 bijvoorbeeld). Als ze naar de bieb in Delft moeten en het gaat niet over standaard poorten, kun je een rule aanmaken dat verkeer over die poorten naar die servers toestaat.
Je wilt toch ook niet dat als er op een van je machines backorifice ofzo geinstalleerd is, een verbinding met jouw interne netwerk mogelijk is? Dan kun je je PIX net zo goed meteen bij het vuil zetten.

Goed firewall beheer betekent werken en bij blijven...