On 9 Jun 2000, at 11:28, Julien Calvet wrote:

yes you can ... You must use IP-route2 package to make NAT.

Hi, to me it sounded like Julien wanted to know if *sombody* (not allowed to) can connect to the private lan through his router. And that AFAIK is not possible without getting access to the router. This leads me to a question I wanted to post for quiet a while: I have a PC connected to the internet and my server doing NAT to allow access from my lan to the internet. My lan, like Juliens, uses private addresses 192.168.xxx.xxx. As sayd above, AFAIK it is not possible for someone to access my lan as the private addresses are not routed in the internet. So someone needed to compromise my router, log in (with e.g. telnet) and than has access to my lan. If that happened, all he has to access my lan with, are the programms installed on the router. Is that right? thanks mike

Hi, actually the routing PC runs NetBSD, there is no telnet, ftp, compilers etc., the system is in a state, where the disk is kind of write protected, only to special files (like logfiles) data can be added, existing data can not be modyfied or erased. The system can only be changed to single user mode by rebooting form the console (or tty) and only in single user mode the write protection is deactivated. The routing PC performs IPfiltering too. This router PC is in one subnet with the server, that runs SuSE 6.3 that performs IPfiltering and NAT, all the workstations are in a second subnet. I think it will be really hard to break into the router, and even when it is done, it should be not possible to get any tools to break inte the server! By using two different systems, a possible intruder had to know both. The thing I am concerned about is the mentioned possibility to follow a route to the workstation, as these are currently Win98 PCs and I do not think it even was possible to get them secure. thanks mike On 9 Jun 2000, at 13:49, Florian Gnägi wrote:

Hi

It is certainly true that your workstation is not accessible from the outside easily. However, everytime you open a connection with HTTP, FTP or whatever your gateway opens a port which will open a route to your inner workstation. I'm not an expert in this, but I guess with a little luck, a nasty tool and a unsecure workstation one *could* get on the workstation without cracking the gateway in the first place.

Althouth this seems really paranoid you can read in every security paper to better use proxies on your gateway than network address translation. Then you have to crack the gateway befor possibly getting in the inner network.

If someone cracked your gateway he has only the tools available on the machine. You can prohib users from using / in commands (so they can't download a tool and use it since they just can't lauch it with ./mytool.sh). There is a kernel patch which can make your system really secure with read only logfiles and alike (the can only be written by the kernel itself), however for maintanance you have to reboot in a less secure kernel since even root can't do anything with this patch.

I think for most cases it is enough secure to have no compiler installed, no user accounts, every damn port closed which is not necessary used, bann every clear text protocol (telnet, ftp) and rsync your logfiles from an inner machine every once in a while (and read them ;-)

Maybe a real expert can confirm or deny the first paragraph?

enjoy the weekend -florian

On Fri, 9 Jun 2000 Thomas Michael Wanka yelled into the voidness of cybercpace:

...

On 9 Jun 2000, at 11:28, Julien Calvet wrote:

...

yes you can ... You must use IP-route2 package to make NAT.

Hi,

to me it sounded like Julien wanted to know if *sombody* (not allowed to) can connect to the private lan through his router. And that AFAIK is not possible without getting access to the router.

This leads me to a question I wanted to post for quiet a while:

I have a PC connected to the internet and my server doing NAT to allow access from my lan to the internet. My lan, like Juliens, uses private addresses 192.168.xxx.xxx. As sayd above, AFAIK it is not possible for someone to access my lan as the private addresses are not routed in the internet. So someone needed to compromise my router, log in (with e.g. telnet) and than has access to my lan. If that happened, all he has to access my lan with, are the programms installed on the router. Is that right?

thanks

mike

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

Hi, I have not tested that, but AFAIK as soon as I get a packet with an invalid address (192.168.xxx.xxx) on the external interface from outside, the packet should be dropped or rejected, I will test this. Your suggested filtering is allready done! thanks mike On 9 Jun 2000, at 8:12, Chad Whitten wrote:

Some could spoof your invalid ip (rewrite their packets to have a source address of 192.168.xxx.xxx and gain access or you could allow access using port forwarding to prevent spoofing

* Gerhard Sittig wrote on Fri, Jun 09, 2000 at 15:39 +0200:

On Fri, Jun 09, 2000 at 13:33 +0200, Thomas Michael Wanka wrote:

...

Juliens, uses private addresses 192.168.xxx.xxx. As sayd above, AFAIK it is not possible for someone to access my lan as the private addresses are not routed in the internet.

This ^^^^^^^^^^^^^^ is better put as "should not get routed ..." -- it's not a requirement but common practise. Don't count on "RFC1918 won't show up from outside" and "won't find a way" [...]

You're right. Once a while we did some "traceroutes" with RFC1918 source addresses with different ISP. Usually the generated ICMP should get dropped, since it's addressed to a RFC1918 IP, but often you make some hops ... I was surprised, since I couldn't imagine how a router should know which way that packet has to be routed... Sometimes it seems that ISP use such addresses in their networks too without filtering well. Traceing _to_ a RFC1918 works until the first router drops that private address, generating a network unreachble or so, but sometimes the first 3 or 4 routers just forward such packets. Yeah, of course, there're a lot of misconfigured routers out there!

Don't count on source routed packets being dropped just because *you* have always done so.

I think it's a good idea to drop source routed packets always. But again this is common practise only, so don't relay on that. At all, I would never trust the ISP in any way; maybe they have a misconfigured router, or an hacked machine or whatever. And you can't know how experienced the engineers are. To put it in a sentence:

Don't imply anything, express all constraints yourself.

- etc pp

Activating the rp_filter seems to be a nice idea too.

It may sound a little stupid, but security is about being paranoid. :)

Yepp, my opinion too! It's alway nice to have multiple security things running. If one fails (or get misconfigured or forgotten or whatever), it wasn't the last one... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

* Thomas Michael Wanka wrote on Sat, Jun 10, 2000 at 00:09 +0200:

the routing PC is configured not to forward 192.168.xxx.xxx packets sent from the internet.

I know what kind of "experts" work at my ISP! (btw. it seems that here in Austria as well as in the Netherlands CableTV providers have the worst personnel compared to other ISPs, is that true for other countries?)

Well, I heard of this problem from other sides too...

So from what I understood, the only possibility left for an intruder was to "hook" himself to an established connection of one of the workstations to the internet. if so, how could he do this, and what possible actions can I take?

Well, you mean TCP Connection hijacking? This is one of the possiblities. This works in a way like this: Your WS sends a TCP stream to a server. This stream gets masqueraded and the backway de-masqueraded, which doesn't matter here. On any of the routers in between an attacker could catch the packets, and send responses back. To the original target host a RST packet may be sent, which doesn't matter. Suddenly there's a connection from your internal machine to the intruder. Let's assume it's an FTP data transfer, she could send you the wrong data, maybe a trojan or whatever. Other protocols may be even more dangerous. It's not a simple thing to prevent such hijacking. At least it's neccesary that the other side supports your solution. You may use IPSec or a secure protocol like SSL/TLS or SSH, or validate the data on application level, i.e. PGP/GPG encrypted/signed mails. But for most tasks this wouldn't work, since most servers won't offer such methods. Useing proxies you can protect your network from hijacked connections, since the connection goes only to the proxy, but usually the proxy has no chance to reject (or even detect) such forged data. Useing squid as FTP Proxy helps nothing here, since you still could get a virus or similar. For most protocols there are simply no proxies aviable with some filter options of course (how you would detect illegal IRC messages? and so on), so you have to be careful... At least it's not possible to connect to a trojan inside your network, but the trojan could connect to some bad host. If the trojan is a clever one, it would be possible to insert control data into harmless looking protocols: ping ICMP packets as payload, or HTTP look-a-like connections, or any other. So you cannot talk about "secure". And I don't think that there's something that helps a lot without disabling the services (you could deny all ICMPs, you could deny all HTTP and other traffic, but then you won't need a router...) Just my opionion. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.