Hi again
Hi. Before all, I'd like to thank Steffen and Tobias for their answers.
Don't mention it.
Effectively, NAT ("generic" NAT ;)) isn't a security device, but it's quite clear that NAT by itself provices some kind of security. Not the security many people want, but a bit at least.
A little bit, I wouldn't overestimate it. IMHO, people are highly susceptible to a false sense of security in the scenario you describe.
Suppose the following intranet:
ISDN Router | Switch | | | A B C ...
This network is connected to the ISP (/Internet) via ISDN. The router receives a (dinamic) real IP whenever it re-connect to ISP account. The intranet objetive is providing Internet connectivity to the employers in a firm / etc.. :) I mean, no services are provided to the Internet community from the intranet (no daemons at border gateway). Finally, the ISDN router is performing PAT.
What border gateway? You're connecting the internal network to the Internet with a PAT router, that's it. Purely network level stuff, no application layer gateways involved.
A, B, C are machines belonging the intranet (therefore they have private range IP's). They are workstations, used to access the Internet.
1) Let's think about how to attack it. Supposing an attacker has got our (real) IP (one of the ISDN router; the other one is private). How could the hacker attack machine A (the same applies for B, C...)?
For a start, he could attack the router itself. Most of them offer administrative functions to the network, such as Telnet, HTTP or SNMP access. Most also probably have default passwords on these services, so it could be simple to just login to the box. A fair number of routers also provide other services, such as echo, finger, timestamp, etc.. Most of these can be abused in some form or other, if not to cause harm to the router's owner then to third parties (for example, you could spoof your IP address to the broadcast address of a victim network, send echo packets to the router and the victim network will be hit with all of the replies). You can play tricks with routing protocols, if the router is performing dynamic routing. There are many ways to compromise routers. You can also, of course, hijack active sessions, PAT shouldn't make this any more difficult by itself (though sequence numbers could pose a problem). UDP transactions are also a prime target, since PAT needs to make pretty broad assumptions concerning UDP, as the protocol is connectionless, yet PAT requires connections to work. So what PAT implementations normally do is that they establish a reverse translation rule for any UDP packets leaving the internal network that stays in place for a certain amount of time. You can push basically any UDP content through this virtual connection (provided you spoof the source IP address) and most probably each and every packet you send through will reset the timeout counter to zero. Then there's attacks using protocols that don't let themselves be PATed easily, such as FTP, Quake, Battle.Net, IRC, CuSeeMe, H.323, etc... Most PATs have special code to be able to handle these protocols. However, since they work at the network level, they typically don't posess the same level of knowledge as the real applications. And more often than not, these modules are concerned with getting the protocol to work at all, not to secure it. Don't count on them to enhance security, rather I'd expect them to actually reduce it. Wahey! Ain't PAT a great security device? ;-)
At first approach, let's suppose workstations users are well-security-educated people, I mean, people who doesn't run executables without checking them for virus, etc (so the chance a trojan attempt was successful is zero) (yes, hard to believe :)).
Um, yeah, let me know when you're back in the real world. I work for a security consulting firm and one of our most successful means of analysing networks when we pretend-play 'hackers' is a malicious script that we send to employees of the customer company. That and other social attacks work real great. Humans are so much easier to take advantage of than machines..
2) Let's suppose I want to install a packet filter (for example, a linux box router with ipchains).Let's name "fw" to this new machine. I'd put it between the router and the switch (right?) and both ports would have private IP's.
OK. Oh, the placement is correct, yes.
- 2.1) Which type of rules would you put for defeating attacks *from* the Internet? (taking into account that NAT itself stops "basically" many of these attacks). This is something I haven't got clear at all.
First of all, deny or reject everything. Then open up what you need. That's the secure approach.
- 2.2) Which type of rules would you put concerning the internal side?
This depends entirely on your situation. Many people like to be restrictive about what gets into their network, yet liberal about what goes out. Security people are careful about both.
I'll also appreciate any new ideas, reference to a good fw paper *based on this scenario*, etc.
Actually, your scenario is very common, however, I don't know of any document that gives you details exactly on how to do it right. And IMHO there can't be *one* paper about it, as there are too many variables in the mix. IMHO, you should get good overall knowledge on the subject -- after all, your setup is merely one variation of the general thing. You shouldn't, again IMHO, be trying to learn how to deal with your situation only, but rather how things work and are done generally and then apply that to your situation. This way, if your setup should change, which it probably will in the not too distant future, you'll be able to handle it. Otherwise, you'd have to start from scratch. Oh, all of the views in this email are mine and don't reflect anything about my employer. Regards -- Tobias Reckhard secunet Security Networks AG Tel : +49(6196)95888-42 Mergenthalerallee 77 Fax : +49(6196)95888-88 D-65760 Eschborn E-Mail: reckhard@secunet.de