Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
port 69 en port 53
23-03-2015, 15:44 door Anoniem, 18 reacties
Hallo,
Moet je port 69 UDP (TFTP) altijd dicht hebben?
En moet je port 53 (DNS) ook altijd dicht hebben?
Het gaat om een webserver, waar een Nmap scan bij deze poorten de melding open|filtered gaf.
Groet
Herman
Moet je port 69 UDP (TFTP) altijd dicht hebben?
En moet je port 53 (DNS) ook altijd dicht hebben?
Het gaat om een webserver, waar een Nmap scan bij deze poorten de melding open|filtered gaf.
Groet
Herman
Reacties (18)
In het kort: Een (pure) webserver hoeft in principe alleen http (wellicht https, al naargelang de opzet) open te hebben staan. Andere poorten moeten niet dicht en moeten niet open, dat ligt er maar net aan wat je met die machine wil, en wat er verder nog aan packet filters en dergelijke voor het lokale netwerk actief zijn. Het is het gebrek aan context die deze vraag een vaag antwoord oplevert.
Maar als je zonodig met deze speeltjes wil spelen: Tijd om je eens wat verder in te lezen. Je bent al begonnen met nmap, dus nu even doorpakken en ook leren wat al die diensten doen en wat de terugmelding precies betekent.
Maar als je zonodig met deze speeltjes wil spelen: Tijd om je eens wat verder in te lezen. Je bent al begonnen met nmap, dus nu even doorpakken en ook leren wat al die diensten doen en wat de terugmelding precies betekent.
Als poort 53 dicht zit kun je nooit het internet op, tenzij je met IP adressen gaat werken of DNS opvragen via poort 443 doet (Dat kan met sommige DNSCrypt versies).
Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
Ligt er compleet aan of je wilt dat de diensten achter de genoemde poorten bereikbaar moeten zijn vanaf buiten.
In het kort,
heb je een DNS server draaiende?
en doe je iets met TFTP (vanaf buiten)?
Als hierop het antwoord nee is, zie ik de meerwaarde niet om ze (naar binnen/inbound) open te laten. Default zo veel mogelijk sluiten uiteraard.
In het kort,
heb je een DNS server draaiende?
en doe je iets met TFTP (vanaf buiten)?
Als hierop het antwoord nee is, zie ik de meerwaarde niet om ze (naar binnen/inbound) open te laten. Default zo veel mogelijk sluiten uiteraard.
Door Anoniem: Als poort 53 dicht zit kun je nooit het internet op, tenzij je met IP adressen gaat werken of DNS opvragen via poort 443 doet (Dat kan met sommige DNSCrypt versies).
Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
Als je de OP leest zul je begrijpen dat het om inbound ports gaat...
Echter, wanneer je thuis "aan het spelen bent" en meer dan een webserver draait zul je meer poorten open zetten.. DNS echter NOOIT !
Dus inbound 53 dichtzetten !
En vanuit internet wil je ook nooit TFTP access geven dus deze poort ook dicht !
24-03-2015, 08:41 door
sjonniev
Alle inkomende poorten moeten dicht zijn, behalve de poorten die open moeten staan voor je toepassing.
24-03-2015, 08:44 door
Korund
Door NedFox:
Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
DNS werkt met UDP, een stateless datagramprotocol. Dat wil zeggen dat er geen tweewegsverbinding wordt opgezet. Het DNS-request wordt door de client naar poort 53 van de server gestuurd, het antwoord komt van de server naar poort 53 van de client. UDP-poort 53 wil je dus zowel uitgaand als inkomend open hebben staan.Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
http://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport
Door Carborundum:
http://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport
Door NedFox:
Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
DNS werkt met UDP, een stateless datagramprotocol. Dat wil zeggen dat er geen tweewegsverbinding wordt opgezet. Het DNS-request wordt door de client naar poort 53 van de server gestuurd, het antwoord komt van de server naar poort 53 van de client. UDP-poort 53 wil je dus zowel uitgaand als inkomend open hebben staan.Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
http://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport
Sorry maar hier klopt helemaal niks van!
Niet alleen wordt normaal gesproken als source port bij uitgaande requests nooit poort 53 gebruikt (dus je request gaat
bijvoorbeeld van port 34722 naar port 53 van de DNS resolver en je reply gaat terug van 53 naar 34722 in dat geval), ook
wordt er tegenwoordig door firewalls vrijwel nooit meer met statische filter configuraties gewerkt. Als er een reuqest de
deur uit gaat wordt er tijdelijk een rule aangemaakt die het antwoord doorlaat en die na een paar seconden weer verwijderd
wordt. Dus zelfs voor de antwoorden op de requests hoef je geen poorten open te zetten.
Als je inkomend port 53 open zet dan weet je zeker dat je een hoop ellende krijgt. Net als met 161 (SNMP). De
vervelende jongetjes die internet tegenwoordig terroriseren zullen je systeem gebruiken als uitvalsbasis voor DDOS
aanvallen.
En als je zelf geen DNS server draait voor een internet domein dan is het ook nergens voor nodig.
Door Carborundum:
http://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport
Door NedFox:
Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
DNS werkt met UDP, een stateless datagramprotocol. Dat wil zeggen dat er geen tweewegsverbinding wordt opgezet. Het DNS-request wordt door de client naar poort 53 van de server gestuurd, het antwoord komt van de server naar poort 53 van de client. UDP-poort 53 wil je dus zowel uitgaand als inkomend open hebben staan.Normaal wil je poort 53 open hebben. Op zijn minst uitgaand.
http://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport
Ik geloof niet dat je helemaal snapt hoe het werkt.
Uitgaande dns requests gaan van een dynamische poort naar de server , die server luistert op port 53 udp.
De uitgaande dynamische poort van jouw computer is elke keer een andere poort. Bij XP is dat een poort tussen de 1024 en 5000. bij latere OS'sen is dat een veel hogere poort.
Het is dus totaal nonsense om poort 53 udp open te zetten op een systeem dat dns requests maakt.
Dit is dus echt alleen nodig als je een DNS server draait.
Ik heb hier maar 4 poorten open en ondervind geen problemen, waarom zou je dan alles open laten als 25,110, 80 en 443 het enige is wat je als gewone gebruiker nodig hebt.
Door Anoniem: Ik heb hier maar 4 poorten open en ondervind geen problemen, waarom zou je dan alles open laten als 25,110, 80 en 443 het enige is wat je als gewone gebruiker nodig hebt.
Deze heb je inkomend niet nodig,
en ik zou 25 zowiezo niet meer gebruiken, eerder 587(TLS) of 993(SSL)(ik weet niet zeker of ik nu POP/IMAP/SMTP door elkaar haal), maar iig geen 25/110 maar iets met encryptie, en dus andere poorten ;).
en inkomend zou ik ze al helemaal niet open zetten, nergens voor nodig voor de gewone gebruiker.. alleen handig als je een eigen mail- of webserver hebt.
Door Anoniem: Ik heb hier maar 4 poorten open en ondervind geen problemen, waarom zou je dan alles open laten als 25,110, 80 en 443 het enige is wat je als gewone gebruiker nodig hebt.
Inkomend heb je als gebruiker helemaal geen open poorten nodig.
Je moet alleen de antwoorden van je verzonden verkeer binnen krijgen.
Ik hoop ik dat je geen tcp/25 en tcp/110 meer gebruikt.
(Maar tcp/587 en tcp/993)
27-03-2015, 07:17 door
Erik van Straten
Of de TS zijn eigen server of die van derden aan het scannen is, weet ik niet. Maar, doordat ik er zelf een keer tegenaan gelopen ben, weet ik wel dat DNS ook TCP poort 53 nodig kan hebben (naast UDP poort 53).
Scan je buiten om via een remote shell/doos of scan je alleen lokaal op je interne netwerkje ? :)
30-03-2015, 12:19 door
Ramon.C
lokale netwerkscan? Dan is het normaal dat poort 53 open staat, van buitenaf zou dit niet moeten! Voor p 69 geldt hetzelfde.
Als je een "poort scan" doet, kijk je "vanaf buiten" naar poorten die "naar binnen" open staan.
Voor een normale gebruiker betekent dat : je hebt NIETS nodig van buiten naar binnen. Je routertje mag/moet dus géén regels bevatten die verkeer naar binnen toe laat.
Dit heet "forwarden" of "NAT" in de meeste routers. En heeft NIKS te maken met verkeer dat naar buiten toegestaan is.
Als je een SERVER host, bv webserver, mail, dan moet je specifiek verkeer toelaten. Laat alleen verkeer toe dat nodig is, bv 80 en 443 voor je webserver.
ProTip: Als je niet weet wat NAT, Forwarding, TCP of UDP is, host dan in godesnaam niks want je bent binnen de kortse keren aan de beurt voor een fijne hack.
Voor een normale gebruiker betekent dat : je hebt NIETS nodig van buiten naar binnen. Je routertje mag/moet dus géén regels bevatten die verkeer naar binnen toe laat.
Dit heet "forwarden" of "NAT" in de meeste routers. En heeft NIKS te maken met verkeer dat naar buiten toegestaan is.
Als je een SERVER host, bv webserver, mail, dan moet je specifiek verkeer toelaten. Laat alleen verkeer toe dat nodig is, bv 80 en 443 voor je webserver.
ProTip: Als je niet weet wat NAT, Forwarding, TCP of UDP is, host dan in godesnaam niks want je bent binnen de kortse keren aan de beurt voor een fijne hack.
Zo leuk dat iedereen hier een antwoord klaar heeft, maar niemand eigenlijk weet hoe het werkt, of de tijd neemt om te kijken wat er echt aan de hand is.
Nmap zal bij een UDP scan altijd open/filtered weergeven omdat hij niet weet wat het resultaat is. Dat is inherent aan services die via UDP werken. Bij TCP krijg je bij een open port een SYN+ACK terug als hij open is, niks als hij gefilterd of niet bereikbaar is en een RST als hij gesloten is.
UDP doet daar niet aan, en zal dus alleen reageren als de service een valide request binnen krijgt. In het geval van DNS dus bijvoorbeeld een DNS query. De enige manier om te kijken of een UDP port open is, is dus door de goede payload ernaartoe te sturen. Met Nmap kan je dat doen met behulp van scripts. Bijvoorbeeld "dns-service-discovery" of "tftp-enum", in jouw geval.
Stuur je de juiste payload niet, dan is de poort of open maar reageert niet, of gefilterd en reageert niet. Met andere woorden: "open|filtered".
Het gaat om een webserver, waar een Nmap scan bij deze poorten de melding open|filtered gaf.
Nmap zal bij een UDP scan altijd open/filtered weergeven omdat hij niet weet wat het resultaat is. Dat is inherent aan services die via UDP werken. Bij TCP krijg je bij een open port een SYN+ACK terug als hij open is, niks als hij gefilterd of niet bereikbaar is en een RST als hij gesloten is.
UDP doet daar niet aan, en zal dus alleen reageren als de service een valide request binnen krijgt. In het geval van DNS dus bijvoorbeeld een DNS query. De enige manier om te kijken of een UDP port open is, is dus door de goede payload ernaartoe te sturen. Met Nmap kan je dat doen met behulp van scripts. Bijvoorbeeld "dns-service-discovery" of "tftp-enum", in jouw geval.
Stuur je de juiste payload niet, dan is de poort of open maar reageert niet, of gefilterd en reageert niet. Met andere woorden: "open|filtered".
Door Anoniem: Zo leuk dat iedereen hier een antwoord klaar heeft, maar niemand eigenlijk weet hoe het werkt, of de tijd neemt om te kijken wat er echt aan de hand is.
Hallelujah! Het resultaat van 15 jaar onkunde aan de zijde van opleidingen - en de situatie dat eenoog koning is in het land der blinden: ik word zo moe van al die jochies die met 10 jaar copy&paste "ervaring" denken dat ze volleerd developer zijn, maar feitelijk niet eens het niveau van script-kiddies ontstijgen. Ik had vier jaar geleden een sollicitant die 75 euro per uur wilde, maar het verschil tussen udp en tcp niet eens wist!
Hier dito, al die domme antwoorden, te bizar voor woorden!
08-04-2015, 17:56 door
[Account Verwijderd]
-
Bijgewerkt: 08-04-2015, 17:57
[Verwijderd]
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
