[linux/xinetd] toegang regelen op mac adres?

[GiLuX]

ik regel nu acces op mijn bak via xinetd tcp wrappers maar ik wil graag ipv op ip adres toegang verlenen op mac adres toegang verlenen.
kan dit met xinetd?
kan er niets over vinden dus het zal wel niet (just making sure...)

ga nl binnenkort op vakantie en neem mijn leptop mee en heb dan natuurlijk geen vast ip adres maar wil graag wel zo nu en dan op mijn bak in kunnen loggen.

[blaataaps]

iptables kan op mac-adres matchen dacht ik, maar hoe dacht je dat het macadres vanaf je laptop via internet bij je server kwam?

[Wilke]

Dat kan iptables inderdaad (mits de juiste opties aan staan in je kernel), xinetd zou dat nooit kunnen omdat die niet naar zo'n lowlevel network layer kan kijken.

Maar zoals blaataaps al suggereert denk ik dat je je eerst eens moet verdiepen in hoe Ethernet werkt, want wat je wilt kan dus niet, tenzij de machines op hetzelfde LAN zitten (of iig op een netwerk zonder ook maar 1 router tussen laptop en linux computer).

Aangezien de maximum lengte van een ethernet-kabel zonder repeater 250 meter is, kun je dan hooguit 250 meter op vakantie, en dat zal wel niet precies de bedoeling zijn denk ik

[blaataaps]

Cat 5 is toch 100 meter binnen de specs?

[Warbringer]

blaataaps schreef op 29 juli 2004 @ 12:32:
Cat 5 is toch 100 meter binnen de specs?

Ik dacht het wel ja

Geeft een nieuwe betekenis aan het begrip "een korte vakantie"

[GiLuX]

100 meter?

ik heb een directe sateliet uplink met vpn die uitkomt op de dmz die met een wifi verbinding op de juniper uitkomt die het allemaal als een netwerk ziet dus dat is niet zo'n probleem.

vakantie houdt trouwens voor mij in dat ik naar de keuken ga om nieuwe koffie te zetten.

anyway, i get the point

[Verwijderd]

In mijn ogen kan je het beste werken met ssh connectie, dat heeft encryptie en zo.
Wil je het nog veiliger doen, kan je bovendien ook nog werken public en private keys.

[Wilke]

Kan ook, maar ik dacht dat de theoretische maximum-kabellengte ('span') voor een compleet 10 MBit ethernet max. 250 meter is omdat als je daar voorbij gaat het te lang duurt voordat duidelijk is dat er een collision is op het medium en een zender dat dan mogelijk niet meer doorheeft. Dus zodra de computers aan de langste uiteinden dan toevallig tegelijk iets zenden, komen pakketjes mogelijk 'stuk' aan zonder dat de zendende systemen doorhebben dat er een collision is opgetreden.

Het kan prima zo zijn dat Cat-5 kabel de pakketjes al niet meer goed doorgeeft als een kabel langer is dan 100 meter (maar dan gewoon door signaalverlies/ruis/storing), dat weet ik zo niet hoor

Langer kan dus wel, maar dan moet je er een bridge of switch tussen zetten die de pakketjes opnieuw verstuurt.

_{Lekker offtopic allemaal, maar och}

[igmar]

Wilke schreef op 29 juli 2004 @ 12:43:
Langer kan dus wel, maar dan moet je er een bridge of switch tussen zetten die de pakketjes opnieuw verstuurt.

Gewoon IP Datagrams on Avian Carriers gebruiken, lange afstanden, makkelijk vreemde toegangscontroles gebruiken, en ook nog eens onopvallen. Wat wil de IT'er nog meer

[Gotiniens]

igmar schreef op 29 juli 2004 @ 15:00:
[...]


Gewoon IP Datagrams on Avian Carriers gebruiken, lange afstanden, makkelijk vreemde toegangscontroles gebruiken, en ook nog eens onopvallen. Wat wil de IT'er nog meer

een kooi voor de duifen

nu nog een on-topic reactie verzinnen, jullie zien zo wel een edit

hier trouwens wat meer uitleg over rfc1149: http://www.blug.linux.no/rfc1149/

[ Voor 10% gewijzigd door Gotiniens op 29-07-2004 15:30 ]

[Wilke]

igmar schreef op 29 juli 2004 @ 15:00:
Gewoon IP Datagrams on Avian Carriers gebruiken, lange afstanden, makkelijk vreemde toegangscontroles gebruiken, en ook nog eens onopvallen. Wat wil de IT'er nog meer

Ja, maar die functioneren dus ook als ethernet bridge (of zelfs als router? afhankelijk van hoe je dit implementeert misschien)

[Loesje]

Coax-kabel kon wel altijd 250 meter overbruggen. Wilke heeft al uitgelegd waarom dat het maximum is.

(Nog meer nutteloze informatie!)

[igmar]

Wilke schreef op 29 juli 2004 @ 15:54:
Ja, maar die functioneren dus ook als ethernet bridge (of zelfs als router? afhankelijk van hoe je dit implementeert misschien)

Gewoon de carrier een andere kant uitschoppen De roundtrip tijd is wel wat aan de hoge kant, maar goed, detail

[Verwijderd]

Ok, genoeg gein getrapt, we gaan eens wat oplossingen geven:

Oplossing 1
Als ik het goed begrijp wil je SSH ed. niet voor de hele wereld openzetten, maar heeft je client een dynamisch IP. Wat je zou kunnen is een dyndns-entry aanvragen voor je client dan die dan door middel van een daemon op je client elke keer updaten. Vervolgens kun je op hostname matchen in je sshd config als je die met tcp_wrapper support hebt gecompiled.

Oplossing 2
Je gaat gebruik maken van SSH certificaten met passphares en staat ook alleen mensen met SSH-sleutels toe om in te loggen. Dat maakt het geheel al een stuk veiliger.

Oplossing 3
Je hebt een daemon knockd die na een bepaalde combinatie van TCP/UDP/ICMP pakketten een poort voor je open zet. Een soort geheime klopcode dus die je zelf in kunt stellen voordat een daemon actief wordt. Originele oplossing en misschien in dit geval wel bruikbaar. Zie: http://www.zeroflux.org/knock/

Oh en MAC-adressen gaat zeker niet werken. Dat is OSI model laag 2 en TCP/UDP werkt op laag 3/4. Dus MAC-adresfiltering werkt alleen op lokaal netwerk.

[CyBeR]

Verwijderd schreef op 29 juli 2004 @ 22:37:
Ok, genoeg gein getrapt, we gaan eens wat oplossingen geven:

Oplossing 1
Als ik het goed begrijp wil je SSH ed. niet voor de hele wereld openzetten, maar heeft je client een dynamisch IP. Wat je zou kunnen is een dyndns-entry aanvragen voor je client dan die dan door middel van een daemon op je client elke keer updaten. Vervolgens kun je op hostname matchen in je sshd config als je die met tcp_wrapper support hebt gecompiled.

Nope, dat gaat niet. Daarvoor heb je reverse DNS nodig.

Oplossing 2
Je gaat gebruik maken van SSH certificaten met passphares en staat ook alleen mensen met SSH-sleutels toe om in te loggen. Dat maakt het geheel al een stuk veiliger.

Eensch, edoch is password auth niet bepaald heel erg onveilig bij SSH.

Oplossing 3
Je hebt een daemon knockd die na een bepaalde combinatie van TCP/UDP/ICMP pakketten een poort voor je open zet. Een soort geheime klopcode dus die je zelf in kunt stellen voordat een daemon actief wordt. Originele oplossing en misschien in dit geval wel bruikbaar. Zie: http://www.zeroflux.org/knock/

Interessant, maar mischien een tikje overdreven voor een dienst die van zichzelf al vrij secure is.

[Verwijderd]

CyBeR schreef op 29 juli 2004 @ 22:48:
[...]

Nope, dat gaat niet. Daarvoor heb je reverse DNS nodig.


[...]

Eensch, edoch is password auth niet bepaald heel erg onveilig bij SSH.


[...]


Interessant, maar mischien een tikje overdreven voor een dienst die van zichzelf al vrij secure is.

Hmm, reverse DNS even vergeten, daar kun je inderdaad dus wel eens gelijk in hebben.

Password auth via ssh is zo veilig als het password sterk is (even buffer overflows ed. in de ssh daemon buiten beschouwing gelaten). Alles valt of staat met goede wachtwoorden. Er worden de laatste tijd nogal veel bruteforce aanvallen op ssh uitgevoerd (zie SANS storm center voor meer info). SSh-sleutels maken dat soort brute force aanvallen zonder sleutel onmogelijk.

Op zich is in mijn eigen ssh met een sterk wachtwoord ook goed genoeg, maar aangezien de topicstarter met xinetd aan de gang gaat wil hij blijkbaar de range van geldige hosts beperken.

[ Voor 4% gewijzigd door Verwijderd op 29-07-2004 23:26 ]

[CyBeR]

De veiligheid van password auth ligt altijd bij de passwords zelf (er van uitgaande dat ze netjes encrypted over en weer worden gestuurd natuurlijk). Als jij je accountnaam als passwd gebruikt is dat.. niet handig. Als je een zooitje characters aan elkaar plakt kom je al een stuk verder.

Overigens, die bruteforce attacks vallen ook wel mee. Bovendien gaan die uit van users 'root', 'guest' en 'admin' zover ik kan zien. 'root' laat je natuurlijk niet direct inloggen, 'guest' is al helemaal uit den boze, en 'admin' bestaat natuurlijk niet. Echt brute force is het ook niet.. Ik zie per host hoogstens een 'failed password' staan..

edit:

Sterker nog, in mijn logs staan alleen 'test' en 'guest'.

[ Voor 13% gewijzigd door CyBeR op 29-07-2004 23:32 ]

[Verwijderd]

Mjah ik weet dat het niet al te geavanceerd is, maar ik las toch wat mailtjes op de Dshield mailing list dat mensen gehacked waren. Dus blijkbaar hebben ze toch succes ermee. Maar genoeg offtopic.