tcpwrapper voor uitgaande verkeer

[Verwijderd]

Ik wil op mijn debian box kunnen bijhouden welke uitgaande connecties er gemaakt wordt door welke user account, op welke tijdstip en naar welke host. Eigenlijk dus functionaliteit dat voor inkomend verkeer geleverd kan worden door een tcpwrapper.

Waarschijnlijk kan dit dit op soort gelijke manier als de wrapper voor een inkomende wrapper, 1 script (evetueel 1 per te gebruiken programma), die aangeroepen wordt als een user gaat ssh-en, telnetten, ftp-en enz. . Probleem is de rechten, het script moet in een logfile schrijven, dus heeft root/admin rechten nodig, maar het ftp/telnet/ssh dat daarna met het script gestart wordt, mag niet met root rechten gestart worden. Heeft iemand een idee hoe dit aan te pakken is?

[Seth4Chaos]

is het niet een mogenlijkheid om je firewall de uitgaande pakketjes te laten analyseren.
als een nieuwe connectie wordt opgebouwd heeft TCP (en UDP) iets andere flaggetjes uit staan dan established connections.
als je nou alles dat naar buiten gaat en niet established is logged dmv. iptables heb je volgens mij redelijk wat jij wilt.

[Guru Evi]

met iptables heb je idd een logfunctie: google & search ;-)

[Verwijderd]

is er niets wat ik kan gebruiken in combinatie met ipchains?

[Verwijderd]

Kijk's naar ipac-ng

[Maarten @klet.st]

Verwijderd schreef op 08 August 2003 @ 15:43:
is er niets wat ik kan gebruiken in combinatie met ipchains?

Als je echt wilt zien wat er uitgaat kun je snort gebruiken, die kan ook alle verbindingen (in meer of mindere mate) loggen/capturen. Zie hiervoor ook the honeypot project. Op zich gaan ze er daar vanuit dat snort op een aparte machine staat (in bidge mode), maar op dezelfde machine kan in principe ook.

[Seth4Chaos]

Verwijderd schreef op 08 August 2003 @ 15:43:
is er niets wat ik kan gebruiken in combinatie met ipchains?

mmm heb ff een snelle blik geworpen op de man-page van ipchains maar dat zit er volgens mij niet in (tcp-flags checks).

maar waarom stap je niet over op een 2.4.x kernel met iptables?

[Verwijderd]

Ik blijf nog ff bij 2.2.x totdat 2.6.x uitkomt en 2.4.x een beetje stabieler is. Ik zoek eigenlijk een oplossing die niet afhankelijk is van iptables, zodat ik hem ook op andere *n?x varianten kan toepassen.

Maar ik zal het weekend ff kijken naar ipac-ng en snort

[Verwijderd]

Verwijderd schreef op 08 August 2003 @ 21:37:
Ik blijf nog ff bij 2.2.x totdat 2.6.x uitkomt en 2.4.x een beetje stabieler is. Ik zoek eigenlijk een oplossing die niet afhankelijk is van iptables, zodat ik hem ook op andere *n?x varianten kan toepassen.

Maar ik zal het weekend ff kijken naar ipac-ng en snort

Ik ben net zelf druk bezig geweest met ipac-ng (zie: http://members.home.nl/mvanrijnen/mrtg onderaan staan de statistieken per protocol, moet nog totaal tellers neer gaan zetten), maar ben nog niks tegen gekomen om de remote hosts etc. te tellen/onderscheiden.

Wel kan je met ipac-ng per IP nr (moet je wel opgeven) je data per protocol weergeven. Ik gebruik zelf iptables nu, maar ik dacht dat ipac-ng ook ipchains ondersteunde.

[Oezie Woezie]

[rml][ Linux] Netwerk traffic analyze[/rml]

[Verwijderd]

Eerst zou ik graag willen weten waar de users zich bevinden. Bevinden deze zich op dezelfde machine als de packetfilter zijn er de volgende mogelijkheden:

- lnx netfilter / obsd pf / fbsd ipfw: filteren op uid en dan allowen/denyen + loggen
- anders: pech, dan zul je toch naar wrappers om applicaties moeten gaan kijken (wat vrij makkelijk weer te omzeilen is door de user)

Bevinden de users zich op machines achter de firewall, dan kun je de volgende dingen doen:

- filteren op ip adres. Hiermee loop je het risico dat mensen ip en mac adressen kunnen gaan spoofen om door je systeem heen te komen, en je vangt er geen meerdere gebruikers per ip adres mee op.
- filteren op ip adres en indent poort: Zelfde risico als hierboven, afgezien van het feit dat je op een onbetrouwbare manier remotely het userid achterhaald.
- gebruik maken van vpn tunnels van de users naar de firewall. Dit zou je weer wel enigzinds veilig kunnen maken dmv unieke certificaten / id's per user. Nadeel is weer wel dat het overhead geeft op het interne netwerk, niet triviaal is om op te zetten en lastig is om je users aan te leren.

[ Voor 3% gewijzigd door Verwijderd op 09-08-2003 16:32 ]