---

Jeg har instaleret TightVNC server og client.
Jeg kan godt connecte fra maskinen selv både med TightVNC client på
port 590x og HTTP på port 580x, det virker ganske fornuftigt, men
så snart jeg vil connecte fra den anden maskine, så strejker den.
Da det virker fra maskinen selv, så må det alså være fordi den ikke
lytter efter connect fra andre maskiner, men lige meget hvilken af
man siderne jeg kikker i, så kan jeg ikke finde noget om hvordan
jeg får den til andet.

Det skulle lige være at Xvnc, og at det forslås at køre køre gennem
en SSH tunel. Men da jeg kun skal bruge det inden for mit LAN, så
må det næsten være letter at tage sikkerheden på routeren, end at
begynde at finde udaf hvordan en SSH tunel virker,,, eller det er
måske ikke så tosset af få op og køre? Jeg synes ikke udmilbart at
finde noget om SSH tuneler (på dansk) og google.com kan ikke hjælpe
der,,,

--
Med venlig hilsen

Ivar Madsen

---

Ivar Madsen skrev Lørdag den 11. januar 2003 22:07 i
dk.edb.system.unix:

> Jeg har instaleret TightVNC server og client.
> Jeg kan godt connecte fra maskinen selv både med TightVNC client
> på port 590x og HTTP på port 580x, det virker ganske fornuftigt,
> men så snart jeg vil connecte fra den anden maskine, så strejker
> den.

Det er det samme med SSH, jeg kan godt køre en "ssh localhost" men
ikke en "ssh [LAN IP'en]" fra en anden maskine på LAN'et.

/etc/ssh/sshd_config har en
listenAddress 0.0.0.0

der skulle få den til at lytte efter alle connect fra alle IP'er,
eller har jeg misforstået det?

--
Med venlig hilsen

Ivar Madsen

---

On Sun, 12 Jan 2003 00:30:16 +0100, Ivar Madsen wrote:

> Det er det samme med SSH, jeg kan godt køre en "ssh localhost" men
> ikke en "ssh [LAN IP'en]" fra en anden maskine på LAN'et.

Hvad siger den hvis du prøver med "ssh -v server", og hvad siger
logfilerne?


Mvh.

--
"Hmm, der er ikke særligt mange folk med Adam Sjøgren
elver-ører i denne her film!" asjo@koldfront.dk

---

Adam Sjøgren skrev Søndag den 12. januar 2003 00:58 i
dk.edb.system.unix:

>> Det er det samme med SSH, jeg kan godt køre en "ssh localhost"
>> men ikke en "ssh [LAN IP'en]" fra en anden maskine på LAN'et.
> Hvad siger den hvis du prøver med "ssh -v server",

|[root@milli ssh]# ssh -v server
|OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
|debug1: Reading configuration data /etc/ssh/ssh_config
|debug1: Applying options for *
|debug1: Rhosts Authentication disabled, originating port will not
|be trusted.
|debug1: ssh_connect: needpriv 0
|ssh: server: Name or service not known
|[root@milli ssh]#


> og hvad siger logfilerne?

/var/log/ har ikke nogen log for hverken ssh eller vnc kan de ligge
et andet sted?

Min host.deny er tom, kun kommentar, og hosts.allow
ALL:192.168.0.0/255.255.255.0
Og det skulle vel betyde at alle IP'er fra 192.168.0.0 til
192.168.0.255 har adgang?



--
Med venlig hilsen

Ivar Madsen

---

---

Adam Sjøgren skrev Søndag den 12. januar 2003 01:39 i
dk.edb.system.unix:


>> |[root@milli ssh]# ssh -v server
> Prøve gerne hvor du udskifter "server" med navnet på din
> server.
> Ellers prøver din ssh bare at forbinde sig til en
> ikke-eksisterende maskine og det er der jo ikke meget sjov i.

Jeg er ikke regtigt helt klar over hvad navnet på min server er i
denne forbindelse, men i konsolen skriver den brugerID@milli så jeg
formoder at det er milli det er, og det ser vist ikke ud til at det
gør nogen forskæld?

[ivar@milli ivar]$ ssh -v milli
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
ssh: milli: Name or service not known
[ivar@milli ivar]$

Så derfor prøvede jeg så med localhost også, er det godtnok?

ssh -v localhost
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/ivar/.ssh/identity type -1
debug1: identity file /home/ivar/.ssh/id_rsa type -1
debug1: identity file /home/ivar/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 127/256
debug1: bits set: 1604/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/ivar/.ssh/known_hosts:1
debug1: bits set: 1609/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /home/ivar/.ssh/identity
debug1: try privkey: /home/ivar/.ssh/id_rsa
debug1: try privkey: /home/ivar/.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is password
ivar@localhost's password:
debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: x11-req
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Sun Jan 12 01:33:13 2003
[ivar@milli ivar]$ debug1: channel request 0: window-change
[ivar@milli ivar]$ debug1: channel request 0: window-change
[ivar@milli ivar]$ debug1: channel request 0: window-change
[ivar@milli ivar]$ debug1: channel request 0: window-change
[ivar@milli ivar]$ debug1: channel request 0: window-change
[ivar@milli ivar]$ debug1: channel request 0: window-change
[ivar@milli ivar]$ debug1: channel request 0: window-change
[ivar@milli ivar]$ debug1: channel request 0: window-change
[ivar@milli ivar]$



>> /var/log/ har ikke nogen log for hverken ssh eller vnc kan de
>> ligge et andet sted?
> sshd skriver som regel i auth.log.

Den skriver noget når jeg laver en ssh localhost, men ikke noget
hvis jeg gør det fra en anden maskine, og så forøvigt hvis jeg fra
en anden maskine laver en
telnet 192.168.0.103 22
så kan den heller ikke connecte. Det er derfor jeg mener at det er
som den ikke lytter på indkommende connect,,,


--
Med venlig hilsen

Ivar Madsen

---

On Sun, 12 Jan 2003 01:32:38 +0100, Ivar Madsen wrote:

>> Hvad siger den hvis du prøver med "ssh -v server",

> |[root@milli ssh]# ssh -v server

Prøv gerne hvor du udskifter "server" med navnet på din server.

Ellers prøver din ssh bare at forbinde sig til en ikke-eksisterende
maskine og det er der jo ikke meget sjov i.

> /var/log/ har ikke nogen log for hverken ssh eller vnc kan de ligge
> et andet sted?

sshd skriver som regel i auth.log.


Mvh.

--
"Hmm, der er ikke særligt mange folk med Adam Sjøgren
elver-ører i denne her film!" asjo@koldfront.dk

---

On Sun, 12 Jan 2003 01:53:54 +0100, Ivar Madsen wrote:

> Jeg er ikke regtigt helt klar over hvad navnet på min server er i
> denne forbindelse

Ok. Start med at lære konceptet "hostnavn" og "domæne".

> Så derfor prøvede jeg så med localhost også, er det godtnok?

Det er irrelevant, det du skal finde ud af er hvorfor din
arbejdsmaskine ikke kan ssh'e til din server. Altså skal du have flere
informationer om hvad der sker *når du prøver dette*. Ikke når du
prøver alt muligt andet.

> Den skriver noget når jeg laver en ssh localhost, men ikke noget
> hvis jeg gør det fra en anden maskine, og så forøvigt hvis jeg fra
> en anden maskine laver en telnet 192.168.0.103 22 så kan den heller
> ikke connecte. Det er derfor jeg mener at det er som den ikke lytter
> på indkommende connect,,,

Siden du tilsyneladende ikke vil prøve at køre "ssh -v" fra din
arbejdsmaskine til din server er det svært at vide om det er derfor,
eller om der er en anden grund.


Mvh.

--
"Hmm, der er ikke særligt mange folk med Adam Sjøgren
elver-ører i denne her film!" asjo@koldfront.dk

---

Adam Sjøgren wrote:


>> Jeg er ikke regtigt helt klar over hvad navnet på min server er i
>> denne forbindelse
> Ok. Start med at lære konceptet "hostnavn" og "domæne".

Vil forsøge at finde noget om det,,,

>> Så derfor prøvede jeg så med localhost også, er det godtnok?
> Det er irrelevant, det du skal finde ud af er hvorfor din
> arbejdsmaskine ikke kan ssh'e til din server.

Som jeg ser det, så er der mere præcist, hvorfor min server ikke vil
acceptere connect fra andre maskiner end den selv.

> Altså skal du have flere
> informationer om hvad der sker *når du prøver dette*. Ikke når du
> prøver alt muligt andet.

|[ivar@localhost .ssh]$ ssh -v 192.168.0.103
|OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
|debug1: Reading configuration data /home/ivar/.ssh/config
|debug1: Reading configuration data /etc/ssh/ssh_config
|debug1: Applying options for *
|debug1: Rhosts Authentication disabled, originating port will not be
|trusted.
|debug1: ssh_connect: needpriv 0
|debug1: Connecting to 192.168.0.103 [192.168.0.103] port 22.
|ssh: connect to address 192.168.0.103 port 22: Connection timed out
|[ivar@localhost .ssh]$

Det er det samme hvis jeg laver en telnet 192.168.0.103 22, hvis jeg gør det
fra serveren selv, så svare den, hvis jeg gør det fra den anden maskine, så
lader den som den ikke er der, med timeout til følge.

>> Den skriver noget når jeg laver en ssh localhost, men ikke noget
>> hvis jeg gør det fra en anden maskine, og så forøvigt hvis jeg fra
>> en anden maskine laver en telnet 192.168.0.103 22 så kan den heller
>> ikke connecte. Det er derfor jeg mener at det er som den ikke lytter
>> på indkommende connect,,,
> Siden du tilsyneladende ikke vil prøve at køre "ssh -v" fra din
> arbejdsmaskine til din server er det svært at vide om det er derfor,
> eller om der er en anden grund.

Jeg vil sku meget gerne gøre som du forslår, det kræver bare at jeg forstår
det som du har ment det

--
Med venlig hilsen

Ivar Madsen

---

Ivar Madsen <news-@milli.dk> wrote:

>Det er det samme hvis jeg laver en telnet 192.168.0.103 22, hvis jeg gør det
>fra serveren selv, så svare den, hvis jeg gør det fra den anden maskine, så
>lader den som den ikke er der, med timeout til følge.

Saa du har altsaa kort og godt ikke nogen form for adgang til
serveren fra den anden maskine?

Du har ikke lukket dit lokalnet ude ved at opsaette
firewall-regler? Proev at se, hvad 'iptables -L -v' siger.

Jeg kan se andetsteds, at du ikke har mellemrum efter 'ALL:' i
hosts.allow, men jeg aner ikke, om mellemrummet er paakraevet.


--
Allan

---

Allan Olesen wrote:


>>Det er det samme hvis jeg laver en telnet 192.168.0.103 22, hvis jeg gør
>>det fra serveren selv, så svare den, hvis jeg gør det fra den anden
>>maskine, så lader den som den ikke er der, med timeout til følge.
> Saa du har altsaa kort og godt ikke nogen form for adgang til
> serveren fra den anden maskine?

Ikke på de pæorte der bruges til VNC (580x og 590x) og SSH (22), samt SMTP
(25), men mail (110) og den port jeg satte min newsserver til, de virker
uden problemmer.

SMTP ved jeg ikke lige om det erporten der ikke svares på, eller om det er
postfix der ikke vil relaye,,,

> Du har ikke lukket dit lokalnet ude ved at opsaette
> firewall-regler?

JEG har ikke, men om et eller andet har gjort det uden jeg er opmærksom på
det kan jeg ikke sige,,,

> Proev at se, hvad 'iptables -L -v' siger.

Jeg vil så ASAP kravle under bordet, så jeg kan komme over på serveren og
chekke.

> Jeg kan se andetsteds, at du ikke har mellemrum efter 'ALL:' i
> hosts.allow, men jeg aner ikke, om mellemrummet er paakraevet.

Når jeg kommer op fra gulvet, så vil jeg sætte et ind, bare for at udelukke
en fejl der,,,

--
Med venlig hilsen

Ivar Madsen

---

Allan Olesen skrev Søndag den 12. januar 2003 10:26 i dk.edb.system.unix:

Jeg har sat linielængden til et par hunedere, i dette indlæg,
da det letter læsninen af outputtet fra iptables,,,

> Du har ikke lukket dit lokalnet ude ved at opsaette
> firewall-regler? Proev at se, hvad 'iptables -L -v' siger.
> Jeg kan se andetsteds, at du ikke har mellemrum efter 'ALL:' i
> hosts.allow, men jeg aner ikke, om mellemrummet er paakraevet.

Mellemrummet var der.

BTW nu vi snarker iptables, er det en simpel parameter jeg
skal sætte på det kald, når jeg vil have port x åben for
IP y + z +æ + ø + å og ikke andet?
Og så have SSH og VNC åben for intavallet startende
med x sluttende med y (mit LAN IP range)?



,----[ /home/ivar/iptablesoutputLv ]
| Chain INPUT (policy DROP 0 packets, 0 bytes)
| pkts bytes target prot opt in out source destination
| 2951K 16G ACCEPT all -- lo any anywhere anywhere
| 24187 3862K eth0_in all -- eth0 any anywhere anywhere
| 0 0 common all -- any any anywhere anywhere
| 0 0 LOG all -- any any anywhere anywhere LOG level info prefix `Shorewall:INPUT:REJECT:'
| 0 0 reject all -- any any anywhere anywhere
|
| Chain FORWARD (policy DROP 0 packets, 0 bytes)
| pkts bytes target prot opt in out source destination
| 0 0 eth0_fwd all -- eth0 any anywhere anywhere
| 0 0 common all -- any any anywhere anywhere
| 0 0 LOG all -- any any anywhere anywhere LOG level info prefix `Shorewall:FORWARD:REJECT:'
| 0 0 reject all -- any any anywhere anywhere
|
| Chain OUTPUT (policy DROP 0 packets, 0 bytes)
| pkts bytes target prot opt in out source destination
| 2951K 16G ACCEPT all -- any lo anywhere anywhere
| 0 0 ACCEPT icmp -- any any anywhere anywhere state NEW,RELATED,ESTABLISHED
| 23480 1968K fw2net all -- any eth0 anywhere anywhere
| 0 0 common all -- any any anywhere anywhere
| 0 0 LOG all -- any any anywhere anywhere LOG level info prefix `Shorewall:OUTPUT:REJECT:'
| 0 0 reject all -- any any anywhere anywhere
|
| Chain all2all (0 references)
| pkts bytes target prot opt in out source destination
| 0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
| 0 0 newnotsyn tcp -- any any anywhere anywhere state NEW tcp flags:!SYN,RST,ACK/SYN
| 0 0 common all -- any any anywhere anywhere
| 0 0 LOG all -- any any anywhere anywhere LOG level info prefix `Shorewall:all2all:REJECT:'
| 0 0 reject all -- any any anywhere anywhere
|
| Chain common (5 references)
| pkts bytes target prot opt in out source destination
| 0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-request
| 0 0 icmpdef icmp -- any any anywhere anywhere
| 0 0 DROP tcp -- any any anywhere anywhere state INVALID
| 0 0 REJECT udp -- any any anywhere anywhere udp dpts:netbios-ns:netbios-ssn reject-with icmp-port-unreachable
| 0 0 REJECT udp -- any any anywhere anywhere udp dpt:microsoft-ds reject-with icmp-port-unreachable
| 0 0 reject tcp -- any any anywhere anywhere tcp dpt:135
| 0 0 DROP udp -- any any anywhere anywhere udp dpt:1900
| 0 0 DROP all -- any any anywhere 255.255.255.255
| 3 96 DROP all -- any any anywhere BASE-ADDRESS.MCAST.NET/4
| 0 0 reject tcp -- any any anywhere anywhere tcp dpt:auth
| 5741 842K DROP all -- any any anywhere 192.168.0.255
|
| Chain dynamic (2 references)
| pkts bytes target prot opt in out source destination
|
| Chain eth0_fwd (1 references)
| pkts bytes target prot opt in out source destination
| 0 0 dynamic all -- any any anywhere anywhere
|
| Chain eth0_in (1 references)
| pkts bytes target prot opt in out source destination
| 24187 3862K dynamic all -- any any anywhere anywhere
| 0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-request
| 24187 3862K net2fw all -- any any anywhere anywhere
|
| Chain fw2net (1 references)
| pkts bytes target prot opt in out source destination
| 18711 1489K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
| 0 0 newnotsyn tcp -- any any anywhere anywhere state NEW tcp flags:!SYN,RST,ACK/SYN
| 4769 479K ACCEPT all -- any any anywhere anywhere
|
| Chain icmpdef (1 references)
| pkts bytes target prot opt in out source destination
|
| Chain net2all (1 references)
| pkts bytes target prot opt in out source destination
| 0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
| 0 0 newnotsyn tcp -- any any anywhere anywhere state NEW tcp flags:!SYN,RST,ACK/SYN
| 5949 854K common all -- any any anywhere anywhere
| 205 12026 LOG all -- any any anywhere anywhere LOG level info prefix `Shorewall:net2all:DROP:'
| 205 12026 DROP all -- any any anywhere anywhere
|
| Chain net2fw (1 references)
| pkts bytes target prot opt in out source destination
| 16964 2934K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
| 37 2038 newnotsyn tcp -- any any anywhere anywhere state NEW tcp flags:!SYN,RST,ACK/SYN
| 18 1080 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:smtp
| 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:pop2
| 975 58500 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:pop3
| 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:imap
| 244 11892 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:[censur NNTPserverPort]
| 5949 854K net2all all -- any any anywhere anywhere
|
| Chain newnotsyn (4 references)
| pkts bytes target prot opt in out source destination
| 37 2038 DROP all -- any any anywhere anywhere
|
| Chain reject (6 references)
| pkts bytes target prot opt in out source destination
| 0 0 REJECT tcp -- any any anywhere anywhere reject-with tcp-reset
| 0 0 REJECT all -- any any anywhere anywhere reject-with icmp-port-unreachable
|
| Chain shorewall (0 references)
| pkts bytes target prot opt in out source destination
`----



--
Med venlig hilsen

Ivar Madsen

---

Ivar Madsen skrev Søndag den 12. januar 2003 11:18 i dk.edb.system.unix:

> ,----[ /home/ivar/iptablesoutputLv ]

Som jeg læser den, så er der ikke åbnet for de nødvendige porte, jeg er
på vej ud af døren men har lige skimmet man iptables, og blever alså
ikke lige klog på hvordan jeg sætter regler op, og er bange for at
begynder jeg at ekspermintere, så laver jeg noget forfækeligt lort.
webmin ser ikke ud til at kunne håndtere iptables, eller har jeg overset
det? Der kan nok laves knap så meget lort den vej


--
Med venlig hilsen

Ivar Madsen

---

Ivar Madsen <news-23-08-02@milli.dk> wrote:

>men har lige skimmet man iptables, og blever alså
>ikke lige klog på hvordan jeg sætter regler op, og er bange for at
>begynder jeg at ekspermintere,

Det forstaar jeg godt. Det var daeleme en lang udskrift. Jeg
gaetter paa, at din iptables-opsaetning kan rettes fra et eller
andet smart Mandrake-konfigurationsvaerktoej, hvor man saetter et
passende antal krydser. Reglerne ligner i hvert fald ikke noget,
et normalt menneske har opsat i haanden.

Fra dit andet indlaeg:
>BTW nu vi snarker iptables, er det en simpel parameter jeg
>skal sætte på det kald, når jeg vil have port x åben for
> IP y + z +æ + ø + å og ikke andet?
>Og så have SSH og VNC åben for intavallet startende
>med x sluttende med y (mit LAN IP range)?

Du kan i princippet bare lave en kommando for hver kombination af
ip-adresse og port, du vil tillade.

Paa min maskine foregaar al filtrering i en tabel ved navn
'block'. Kommandoen for at tillade tcp-trafik fra maskinen
62.242.225.162 til port 22 paa min maskine ser eksempelvis
saaledes ud:

> iptables -A block -m state --protocol tcp -s 62.242.225.162 --state NEW --destination-port 22 -j ACCEPT

Det kraever, at oevrige firewall-regler er sat op til stateful
filtering, men det er dine vist ogsaa.

I dine regler skal 'block' udskiftes med 'net2fw', saa vidt jeg
lige kan gennemskue.

Hvis du vil give adgang til et helt ip-range, kan du tilfoeje en
skraastreg efter ip-adressen og angive en netmaske eller det
antal bits, som er faelles. Dvs. for at give adgang til
192.168.0.0-192.168.255.255, kan du angive ipadressen som
'192.168.0.0/16' eller '192.168.0.0/255.255.0.0'.

Normalt ville jeg dog sortere paa interfaces og ikke paa
ip-ranges, men det kraever, at man har separate netkort til
lokalnettet.




--
Allan

---

Allan Olesen skrev Søndag den 12. januar 2003 17:42 i dk.edb.system.unix:


>>men har lige skimmet man iptables, og blever alså
>>ikke lige klog på hvordan jeg sætter regler op, og er bange for at
>>begynder jeg at ekspermintere,
> Det forstaar jeg godt. Det var daeleme en lang udskrift. Jeg
> gaetter paa, at din iptables-opsaetning kan rettes fra et eller
> andet smart Mandrake-konfigurationsvaerktoej, hvor man saetter et
> passende antal krydser. Reglerne ligner i hvert fald ikke noget,
> et normalt menneske har opsat i haanden.

Det er der sikkert nok, jeg kender det bare ikke,,, Hved ved hvad
der findes til det på Mandrake 9.0?

> Fra dit andet indlaeg:
>>BTW nu vi snarker iptables, er det en simpel parameter jeg
>>skal sætte på det kald, når jeg vil have port x åben for
>> IP y + z +æ + ø + å og ikke andet?
>>Og så have SSH og VNC åben for intavallet startende
>>med x sluttende med y (mit LAN IP range)?
>
> Du kan i princippet bare lave en kommando for hver kombination af
> ip-adresse og port, du vil tillade.
>
> Paa min maskine foregaar al filtrering i en tabel ved navn
> 'block'. Kommandoen for at tillade tcp-trafik fra maskinen
> 62.242.225.162 til port 22 paa min maskine ser eksempelvis
> saaledes ud:
>
>> iptables -A block -m state --protocol tcp -s 62.242.225.162 --state NEW --destination-port 22 -j ACCEPT

dvs.

iptables -A net2fw -m state --protocol tcp -s 192.168.0.100 --state NEW --destination-port 22 -j ACCEPT

Den kommer ikke med nogen fejlmeddelse, men når jeg så køre
iptables -L -v bagefter, så kan jeg ikke se noget om port 22,
eller IP 192.168.0.100

> Det kraever, at oevrige firewall-regler er sat op til stateful
> filtering, men det er dine vist ogsaa.

Her er jeg så helt blank, men det er måske fordi de ikke er det, at
overstående parameter på iptables ikke hjælper?

> I dine regler skal 'block' udskiftes med 'net2fw', saa vidt jeg
> lige kan gennemskue.

Hvad er forskællen?

> Hvis du vil give adgang til et helt ip-range, kan du tilfoeje en
> skraastreg efter ip-adressen og angive en netmaske eller det
> antal bits, som er faelles. Dvs. for at give adgang til
> 192.168.0.0-192.168.255.255, kan du angive ipadressen som
> '192.168.0.0/16' eller '192.168.0.0/255.255.0.0'.

OK, når jeg får chek på at sætte det op, så vil jeg kikke på det.
Lige nu har fjernstyringen højere priotet end beskyttelse af newsserveren,,,

> Normalt ville jeg dog sortere paa interfaces og ikke paa
> ip-ranges, men det kraever, at man har separate netkort til
> lokalnettet.

Det har jeg ikke. Og det andet jeg med IP range er ikke til SSH / VNC,,,


--
Med venlig hilsen

Ivar Madsen

---

Den Sun, 12 Jan 2003 22:01:13 +0100 skrev Ivar Madsen:
>Allan Olesen skrev Søndag den 12. januar 2003 17:42 i dk.edb.system.unix:
>
>> iptables -A block -m state --protocol tcp -s 62.242.225.162 --state NEW --destination-port 22 -j ACCEPT
>
>dvs.
>
>iptables -A net2fw -m state --protocol tcp -s 192.168.0.100 --state NEW --destination-port 22 -j ACCEPT
>
>Den kommer ikke med nogen fejlmeddelse, men når jeg så køre
>iptables -L -v bagefter, så kan jeg ikke se noget om port 22,
>eller IP 192.168.0.100

Prøv at tilføje -n, ellers kigger den i /etc/hosts og /etc/services
og skifter tallene ud med navne.

>> Det kraever, at oevrige firewall-regler er sat op til stateful
>> filtering, men det er dine vist ogsaa.
>
>Her er jeg så helt blank, men det er måske fordi de ikke er det, at
>overstående parameter på iptables ikke hjælper?

Nej, stateful inspection er det du angiver med -m state.

>> I dine regler skal 'block' udskiftes med 'net2fw', saa vidt jeg
>> lige kan gennemskue.
>
>Hvad er forskællen?

Hvilket program der har oprettet reglerne. Begge dele er "bruger"-
defineret.

Mvh
Kent
--
What was your username?
<Clicketyclick> - B.O.F.H.

---

Ivar Madsen skrev Søndag den 12. januar 2003 22:01 i dk.edb.system.unix:


> iptables -A net2fw -m state --protocol tcp -s 192.168.0.100 --state
> NEW --destination-port 22 -j ACCEPT

den har jeg kørt, og så har jeg kørt den samme med min WAN IP.

Ind i webmin og prøve med "Linux Firewall" Den siger så


|Webmin has detected 2 IPtables firewall rules currently in use, which
|are not recorded in the save file /etc/sysconfig/iptables. These rules
|were probably setup from a script, which this module does not know how
|to read and edit.

|If you want to use this module to manage your IPtables firewall, click
|the button below to convert the existing rules to a save file, and
|then disable your existing firewall script.


Mon ikke at det er de to jeg lige har sendt?

prøver klikke, men "disable your existing firewall script" Hmm,,, Den er
jeg ikke helt med på,,, Men hvis det er de to gange addKomandoer jeg
har sendt, så behøvces jeg vel ikke at gøre noget ved dem nu?

BTW jeg kom så ind og kunne adere firewallrools, og nu virker det som
det skal, har lige fra arbejdsmaskinen lavet en
ssh milli.dk knode
og den bad o m et PW og så startede den KNode op

Her er Debian's APT-GET alså Mandrake's UPRMI overlegent så det gør
noget. Jeg er næsten sikker på, at installere man OpenSSH på en Debian
med APT-GET så havde jeg fået fortalt under install, at jeg selv skal
åbne for iptables på porten, som jeg vil have det.?

--
Med venlig hilsen

Ivar Madsen

---

Ivar Madsen <news-23-08-02@milli.dk> wrote:

>Her er Debian's APT-GET alså Mandrake's UPRMI overlegent så det gør
>noget. Jeg er næsten sikker på, at installere man OpenSSH på en Debian
>med APT-GET så havde jeg fået fortalt under install, at jeg selv skal
>åbne for iptables på porten, som jeg vil have det.?

Nej.

For det foerste installerer man aldrig OpenSSH paa en Debian,
fordi det er med i minimums-installationen allerede.

For det andet har jeg endnu aldrig set en installation med
apt-get, der mindede mig om at give adgang til programmets port.


--
Allan

---

Allan Olesen skrev Onsdag den 15. januar 2003 23:07 i
dk.edb.system.unix:


>>Her er Debian's APT-GET alså Mandrake's UPRMI overlegent så det gør
>>noget. Jeg er næsten sikker på, at installere man OpenSSH på en Debian
>>med APT-GET så havde jeg fået fortalt under install, at jeg selv skal
>>åbne for iptables på porten, som jeg vil have det.?
> Nej.
> For det foerste installerer man aldrig OpenSSH paa en Debian,
> fordi det er med i minimums-installationen allerede.

OK.

> For det andet har jeg endnu aldrig set en installation med
> apt-get, der mindede mig om at give adgang til programmets port.

Det jeg mener er at det forkommer mig at Debian's agp-get har mulighed
for under install at give brugeren info, og stille denne spørgsmål,
samt tage svarene til følge og instalere afhænigt af disse svar, den
mulighed er der ikke med urpmi,,,

--
Med venlig hilsen

Ivar Madsen

---

Ivar Madsen <news-23-08-02@milli.dk> wrote:

>Det jeg mener er at det forkommer mig at Debian's agp-get har mulighed
>for under install at give brugeren info, og stille denne spørgsmål,
>samt tage svarene til følge og instalere afhænigt af disse svar,

Korrekt. Jeg har bare aldrig set det benyttet til aabning af
programmets port i iptables.

Det ville ogsaa vaere en umulig opgave, eftersom der ikke findes
nogen standardiseret iptables-konfiguration under Debian. Dermed
vil det vaere svaert for et installationsscript at vide, i
hvilken tabel reglen skal placeres.




--
Allan