Benutzerspezifisches iptables oder SSH/AllowTCPForwarding

[Schlorfy]

hallo!

ich trenne die zugriffe auf meinen Server per SSH in 2 gruppen:

benutzer denen ich vertraue, die alle "internen" diesnte auf den verschiedenen ports nutzen
dürfen

und solche die nur SCP und vielleicht ein bisschen SSH in einer chroot umgebung
nutzern sollen...

es läuft alles so weit- nur können die benutzer denne ich nicht vertraue trotzdem nocht
per tunnel auf meine internen dienste zugreiffen (AllowTCPForwarding yes) was
sehr schlecht ist..

wie verbiete ich nun nur MANCHEN Usern das weiterleiten der TCP verbindung
über SSH?

lg

[Savar]

ich weiß nicht ob man das konkret machen kann, ansonsten starte doch 2 SSH Server auf zwei versch. Ports und mache den einen entsprechend dicht?

[cosmac]

In den Public-Key-Files (normal: $HOME/.ssh/authorized_keys)
der einzelnen Benutzer kann man Einschränkungen festlegen,
z.B. "no-port-forwarding". Voraussetzung ist natürlich, daß die
Anmeldung nur noch mit diesem Key erlaubt ist.

[chroiss]

wie wäre es mit einem match owner unter iptables

Code: Alles auswählen

$IPTABLES -A FORWARD -i $INTDEV -p tcp -s 192.168.10.10 --dport 22 -m owner --uid xyz -j DROP

gruss chroiss[/code]

[Schlorfy]

das sieht ja sehr gut aus- so etwas in der richtung will ich haben,
allerdings verstehe ich den befehl nochnicht so richtig- und
nachdem ich ihn einfach so eingegeben hatte- gabs nen fehler...

Code: Alles auswählen

# iptables -A FORWARD -i eth0 -p tcp -s 192.168.0.2 --dport 22 -m owner --uid 1007 -j DROP
iptables: Invalid argument

was macht der befehl?

er verwirft alle packete die über eth0 von der ip das servers kommen und auf port 22
gehen und dem user 1007 gehören?!?!????

mir wärs ja am liebsten wenn alle packete verworfen würden die dieser User so sendet-
ausser den Filetransfer aus seinem Gesichertem CHroot gefängniss- dann
hätte ich ein tolles sicheres "ftp"... )[/code]

[chroiss]

sry. das war nur n beispiel.

kenn deine firewall regeln nicht ..
ich gehe jetzt mal davon aus das ihm nur ssh verboten werden soll ?!
so hab ich das jetzt mal verstanden.

wie verbiete ich nun nur MANCHEN Usern das weiterleiten der TCP verbindung
über SSH?

Code: Alles auswählen

iptables -t filter  -A OUTPUT -p tcp --match owner --uid-owner 1007  --dport 22 -j DROP

Übrigens muss beim owner match ein

Code: Alles auswählen

modprobe ipt_owner  

erfolgen.

Hier würde dem User mit der ID 1007 ssh verboten was von der Maschine rausgeht.
Man kann den "owner match " leider nur auf die OUTPUT Kette anwenden, so wie ich gerade erfahren habe.
Wahrscheinlich wird dir das jetzt nicht mehr allzu viel bringen und ich hab mich hier ganz schön verhaspelt - wollte es aber wenigstens noch richtig stellen.

Dein Problem ist mir ehrlich gesagt aber immer noch nicht ganz klar , wer was von wo nicht dürfen sol...

Chroiss

[nepos]

Naja, auf alles andere als die OUTPUT-Chain wuerde das auch keinen Sinn machen. Denn woher sollte iptables wissen, von welchem User das von aussen kommende Paket ist?

[Schlorfy]

sorry- hab meine frege vielleicht etwas 2-deutig formuliert:

also: ich habe einen User auf meinem Server dem ich nciht so richtig vertraue...
..aber schon ein bisschen ;o)

immerhin so weit das er in einer gesicherten CHroot SSH benutzen darf... und am besten
sonst NICHTS!

ich hab bei meinem SSH server aber /AllowTCPForwarding auf Yes, das heisst, mein iptables
müsste zwar den "normalen SSH tranfer" für diesen benutzer zulassen (ganz wichtig)
aber alle anderen dienste für ihn sperren: (welche er ja mit TCPForwarding ganz
einfach durch meine verhanden Firewall tunneln kann) .. es müsste also irgend was in der
richtung:

iptables -t filter -A OUTPUT -p tcp --match owner --uid-owner 1007 --dport (alle bis auf 22) -j DROP


noch ein paar verständnissfragen: OÄUTPUT richtet sich ja an alle packete
die von einem localen prozess stammen, heisst das also, das es alle packete von dem
bestimmten User verwirft, welche an dienste gerichtet sind die sich direkt auf dem rechner
befinden den man grade benutzt- und dienste die vielleicht im Lan in direkter umgebung dieses
rechners laufen? das wäre nämlich ideal-- nur müsste SCP/SSH dannach noch fehlerfrei
funktionren... ja vwüre die OUTPUT Kette denn überhaupt einflüss auf die SSH funktionalität
habe? immerhin handelt es sich dort nicht um einen dienst welcher local von dem User angesprochen
wird ... sozusagen....... ::?: ?:

danke schonmal

[nepos]

Hm, du willst also, dass der User "ichtraudirnedsoganz" zwar per SSH auf den Server kommen soll, aber er keinerlei andere Anwendungen via SSH tunneln darf?
Soweit ich das aus der Doku ersehe, kannst du a) AllowTcpForwarding nur fuer alle User aktivieren/deaktivieren und b) wird in der Doku eh darauf hingewiesen, dass die User mit Shell-Zugang eigene Forwarder installieren koennten.

Mit iptables hast du da glaube ich keine Chance, da die Tunnels ueber die bestehende SSH-Verbindung laufen und du daher nicht auf irgendwelche Ports und co filtern kannst.

[Schlorfy]

b) ich müsste ihn doch daran hindern können eigene Forwarder zu nutzen,
wenn ich ihm in der Chroot umgebung die schreibrechnte nehme?



was wird wohl minimal in der Chroot umgebung notwendig sein um
eine eigenen tunnelingsoftwar zu installieren?


.... also ist es wohl nciht möglich das mit iptables zu sperren?

aber Chroiss variante hat auf mich einen vielversprechenden eindruck
gemacht.... werd damit mal etwas herumprobieren..

einfach alle packete auf dienste von diesem User verwerfen...
der SSH tunnel sollte keinen einfluss haben- da die tcp/ip aktivitäten
von dem user AUF dem rechner nichtmehr verschlüsselt sind- diese
packete sind in jedem falle einzusehen....

gruss

[Schlorfy]

Hi Leute!

hab jetzt mal einfach Chroiss tip:

Code: Alles auswählen

iptables -t filter  -A OUTPUT -p tcp --match owner --uid-owner 1009  --dport 1:65535 -j DROP
[

eingetipp... das klappt ja prima- der user kann sich noch per SSh anmelden und in meiner
Chroot umgebung rumdocktern aber keinen einzigen Dienst mehr benutzen...
ob SCP noch funktioniert wird sich zeigen... (sollte es sollte es nicht? welche ports müsste ich dafür
wieder frei machen???)


ausserdem hab ich noch die frage ob es mit dieser regel immernoch möglich ist, andere diesnte in dem ungeschützem LAN die sich nciht auf dem SSH server befinden anzusprechen... ich denke auch
das es mit keiner anderen Forwarding software jetzt noch möglich sein sollte über SSH auf einen
diesnt zuzugreifen....

wäre nett wenn wenn noch jemand was zu den o.g. fragen schreiben würde..
oder vielleicht hat ja noch jemand ein paar tips für die benutzerspezifische sicherung eines SSH
servers für mich...

danke jedenfalls erstmal!!!!

ich komme meinen Plänen einen halbwegs sicheren server über SSH zu basteln näher-- ;o))

[herrchen]

das klappt ja prima- der user kann sich noch per SSh anmelden und in meiner Chroot umgebung rumdocktern aber keinen einzigen Dienst mehr benutzen...

hmm, du kannst jetzt von aussen keinen tunnel mehr aufbauen?

/EDIT:
vergiss' es, war ein missverständnis.

herrchen

[chroiss]

@nepos

[ stimmt natürlich mitn OUTPUT, manchmal Brett vorm Kopp ! ]

iptables -t filter -A OUTPUT -p tcp --match owner --uid-owner 1007 --dport (alle bis auf 22) -j DROP

das wäre exakt , das hier

Code: Alles auswählen

iptables -t filter  -A OUTPUT -p tcp --match owner --uid-owner 1007  ! --dport 22 -j DROP 

das "!" invertiert den port 22 . das heisst alles was nicht port 22 ist , wird gedropt.

gruss chroiss

[Schlorfy]

@ Herrchen:

Doch kann ich!
da sich die regel nur auf den user bezieht, und nicht auf die externe schnittstelle-
mit der der SSH tunnel aufgebaut wird --
klappt prima- probiert es aus !

würde mich jetzt interessieren wie ich nach der "sperrung" dann auch noch
nach und nach ein paar ports wieder frei gebe...
wenn ich dannach:

Code: Alles auswählen

iptables -t filter  -A OUTPUT -p tcp --match owner --uid-owner 1007  ! --dport 80 -j DROP 

würde dann die regel für z.B. port 80 wieder überschrieben und ich könnte ihn
wieder forwarden?

gruss

[chroiss]

Code:

iptables -t filter -A OUTPUT -p tcp --match owner --uid-owner 1007 ! --dport 80 -j DROP

das würde so nicht gehen , da du ja schon vorher alles ausser 22 gesperrt hast; somit natürlich auch Port 80.

wenn du die regel mit dem port 22 so stehen lassen willst und dem user nur ab und zu zugriff aufs web erlauben möchtest ( ist übrigens ein erheblicher aufwand , wie ich finde ) könnte es so aussehen

Code: Alles auswählen

iptables -t filter -I OUTPUT -p udp --match owner --uid-owner 1007 --dport 53 -j ACCEPT
iptables -t filter -I OUTPUT -p tcp --match owner --uid-owner 1007 --dport 80 -j ACCEPT 
iptables -t filter -A OUTPUT -p tcp --match owner --uid-owner 1007  ! --dport 22 -j DROP 

wichtig ist nur das der ACCEPT Eintrag vor dem DROP eintrag aufgeführt ist.

gruss chroiss

[Schlorfy]

@chroiss

danke nochmal- das funktioniert gut-

aber nach einiger benutzung bin ich dann zu dem schluss gekommen, das du wohl recht hast,
-erstmal alles komplett dich zu machen, und dann so wie du beschreiben hast, die einzelnen ports für betimmte
user freigeben-

ich bin wirklich begeister von der userspezifikation in iptables..
iptables, war mir früher immer zu abstrakt- aber jetzt könnt ich nichtmehr ohne!

liebe Grüsse