Slashdot Mirror
The Enemy Within: Firewalls and Backdoors
hrbrmstr writes "SecurityFocus is running an article on firewalls and backdoors on their InFocus site. They provide info on firewall types, backdoor classifications, some examples of real backdoors and tips on mitigating their use on your network." Some good topics explained for the beginner, and it's a nice refresher for the veteran admin as well.
I wonder which layer model (iso, dod, other?) they took. Looks like iso/osi to me and if that's the case
>Packet filters [1]
> * Operates at Layer 3
> * Also known as Port-based firewalls
> * Each packet is compared to against a list of rules (source/destination address, source/destination port, protocol)
based on tcp/udp port numbers? that would be layer 4, right? Imho Layer 3 applies to ip-address only.
>Application-level gateways [2]
>
> * Operates at Layer 5
> * Application-specific
> * Example: Web (http) proxy
I thought the application layer is layer 7?
someone?
cheers
Sascha
look what certain backdoors can do to you.
My life in the land of the rising sun.
I spent two years in a highschool cisco class, and in the 2 months before we started playing quake, I learned about network models. Basically, network operations can be divided into multiple layers, with each performing different functions. The layout of these devices seems to be based on one of these models, though I don't remember which. The stateful packet inspection you refer to would probably be part of the first device mentioned in the article, packet filters, which just operate on the network layer, not the other two.
Of course, somewhat intellegent packet filtering at the router beats the hell out of those "home firewall" programs that make pop ups every time you run a new program.
Allowing ALL ougoing and RELATED incoming traffic is hardly secure setup. Every fscking worm/backdoor is allowed to call home, replicate itself or even participate in DDOS network. I also doubt that netgear cares about actual packet payload (layers 4-7). I guess that they're using dynamic packet filter.
One thing which is handy for backdoor is SSH tunneling. A nice exaple can be found here Just replace port 110 with anything else and off you go
Rus
Cheap UK and US VPS
So he wouldn't have to buy a switch.
Several of the games did not like the firewall. There was *some* connectivity but not total cooperation between the PS2 and the firewall.
Several of the games want huge chunks of ports opened up. Uh uh. Not gonna do that. So I added the third nic as a DMZ (smoothwall calls it "Orange Zone") so that the PS2 has unhindered access to the web.
There are three nics,
red=nic to modem (dhcp)
orange= nic to PS2 - 192.168.2.1
green=nic to my lan - 192.168.1.1
The red zone is the nic that goes to the cable modem, it gets it's IP from RR's DHCP.
The orange zone nic is hard coded to 192.168.2.1 (by me) and the PS2 is 192.168.2.2 There are no port restrictions on it, it's raw and naked on the net, as it wants to be..
Since it's a PS2 it doesn't matter.
Smoothwall provides DHCP for the green zone so whatever I plug in to it works. Nice. People bring me PC's all the time to work on.
Another nice thing smoothwall does is take care of dynamic DNS for me, I have a freebee domain from dyndns.org so I can FTP to a private box on my lan from remote sites (while working) and I have accounts setup for my friends so they can ftp in too.
I hard coded one of my boxes to a specific IP then port forward from port XXXX to port 21 at my internal IP of 192.168.1.205. Only my friends and I know it's there and can access it. Very handy.
Veyr often I get somewhere and remember that I forgot something important! Bada bing! I can connect up to the house and get it... Smoothwall is VERY handy for my needs. I have no complaints about it...
1) Use both inbound and OUTBOUND ACL lists on routers, firewalls and other access control devices. Go with the highest level of restriction you can get away with, and log everyhing to a central point.
2) For services you must offer to internal users (www access etc), use good proxies and authenticate every connection.
3) Ensure all services/software products are up to date with security patches. This INCLUDES user workstations.
4) Keep track of security-related sites and lists, such as bugtraq, packetstorm etc.
5) IDS' inside your perimeter to detect anything you're missing. After all, no-one (and by extention, no-one's ACLs) is perfect.
6) Ensure you pay close attention to any remote-access you offer. Modem banks, VPN endpoints etc. Preferably these should also be access-controlled via ACL's of some sort.
7) Ensure you configure your software properly. Seems stupid, I know. But a perfectly secure (from a bugs point of view) mail server is suddenly a problem if you've forgotten to disable mail relay.
8) Ensure you have the right topology. There's no point in spending hundreds of man hours securing services, auditing router ACLs etc etc if theres fifteen different ingress/egress points to your network. The less, err, gresses you have, the more you can concentrate your efforts and thus use your time effectively.
Caveats: I may have missed one or two points in the above summary of practice, but hey - it's a friday arvo and I want to get my work finished so im not here late.
Also note that while the above list sounds relatively easy to implement, IT ISN'T. Be prepared for a lot of work if you want to do it right.
Janie took my gun...
I hard coded one of my boxes to a specific IP then port forward from port XXXX to port 21 at my internal IP of 192.168.1.205. Only my friends and I know it's there and can access it. Very handy.
.exe so you can easily grab it when you need it, and drop it in the trash when you're finished.
Nice, but I strongly suggest you use SSH instead, particularly since you're on a cable connection.
You can download a windows client called putty. It's a small, standalone
455fe10422ca29c4933f95052b792ab2
I've never used Smoothwall, instead doing all of that by hand (setting up a firewall, DHCP; haven't bothered with dyndns though, since I used to have static IPs and now that I don't I haven't found a need to connect to my home PCs yet). The way I would've setup your topology would have been to set a given IP to the PS2's mac rather than just getting a random IP, and then setup appropriate firewall rules for that IP. The rest of the internal network would have its own separate rules.
Then again, I didn't want to add more NICs than was reasonably necessary (as another poster pointed out, you could've done all of this with a single NIC, but two NICs is the sweet spot IMHO). Maybe Smoothwall makes it more difficult to do this (can't assign specific IPs by MAC, perhaps? or can't assign specific rules to a given IP?) and so the third NIC route was the easiest method, or maybe you just wanted to play around. I don't know. Whatever works.
And just for kicks, my own setup looks something like this:
Like you, I didn't want to have to putz around with opening ports for a gaming console, but I took a slightly different approach. I pay Comcast another couple $ per month for a second dynamic IP, and have the XBox directly online (no NAT or firewall to get in the way).
Well, I'm not "the linux community", but I'd like to see your MacOS 9 box serve up files for twenty thousand students and staff with decent performance and mantain an uptime greater than single digits.
Well, I have a confession to make, then, also, just so you don't feel bad:
Remember what I said about the PPPOE and ICS and a star config with one NIC on the gateway, and all that?
I actually ran that for a while when I was living with my parents, before moving out. It was dog-slow when they'd be on their box though, sometimes, because ICS isn't exactly very efficient, and bouncing it in and out across the same segment didn't help. Plus, they couldn't turn off their box, or I'd be screwed. Not to mention that I had to get a third-party PPPOE adapter to get it working, because the stupid spyware-laden CD that the ISP wanted us to use wouldn't work with ICS anyway. I moved out (got a promotion, moved out of state) before I put in a real router, but I bought a router and another switch before even getting DSL at my new place. Then when I moved back in (got laid off) I gave them the router and changed the layout of the network.
I wrote all that in case anyone out there is thinking of doing something similar. It's doable, but you're much better off either making a gateway or buying a cheap one (which also uses less power, is silent, isn't as likely to have parts fail, and has firmware pre-loaded) unless you're absolutely without funds. Did I mention that ZoneAlarm wouldn't work with ICS back then, either?
Get off my launchpad!
You're very confused. This behaviour is absolutely nothing to do with stateful packet inspection. *ALL* routers will behave like this if you enable routing of all outbound traffic - even really cheap and simple NAT firewalls (not really even a firewall). Allowing all outbound traffic means that any trojans you get though e-mail/floppy/open HTTP port etc etc mean that the trojans can phone home and start sending out personal information or attacking other systems. Hardly secure...
The particular Netgear firewall you mentionned (FM114P/FR114P) is one I've used at home. It's probably the least stable and most annoying piece of hardware I've ever used. If you read the forums on dslreports.com you'll see that most users are plagued with problems ranging from random lock ups (mine needs rebooting every couple of days) to it's inability to handle long URLs (causes lock ups) and it's susceptability to the common ping of death attack, which means anyone on the internet can lock up your router with a simple ping command. I've had most of these problems myself, and if you combine them with the poor performance (especially if WEP is enabled) and power supply problems, you end up with a pretty poor product where the only redeeming factor is it's price. I think Netgear have resolved a few of these issues with the latest firmware, but they should have got it to this stage BEFORE releasing it, not a year or two afterwards! Why it takes 12 minutes to copy a 100mb file across the network - when both machines are in line of sight with the router and have full signal strength is beyond me! That's only 135k/sec which is almost exactly 1Mbit - and it's supposed to be an 11Mbit network - not exactly fast!
Nick...
You're very confused. This behaviour is absolutely nothing to do with stateful packet inspection. *ALL* routers will behave like this if you enable routing of all outbound traffic
The last time I looked at a cheap firewall/router that did not have stateful packet inspection, I seem to recall that it had most ports closed. That if you wanted to run some wacky program on some wacky port (your new game, for instance) that you would have to fire up the web browser, go to the admin form, and open the port. And then that port would be open. All the time.
So, I'm confused. Am I wrong about how the non-stateful firewall works?
Allowing all outbound traffic means that any trojans you get though e-mail/floppy/open HTTP port etc etc mean that the trojans can phone home
Dude, check my comment about "Of course, that cuts both ways". I know they can phone home. (But I think most trojans phone home through the HTTP port, so most firewalls will let them do it.)
The particular Netgear firewall you mentionned (FM114P/FR114P) is [...] probably the least stable and most annoying piece of hardware I've ever used.
I'm sorry to hear that. I've had good luck with my Netgear. In fact I haven't had any trouble with any Netgear stuff I have bought (and I can't say the same about Linksys).
I haven't tested that particular model, however.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I suspect you haven't actually tried to implement a PIX yet. The Cisco PIX (at least, the low-end 506 we have) *does* support what you're talking about - although what you're talking about isn't really a transparent (also known as *bridged*) firewall.
m l
Setup the PIX. Use static maps for the IP addresses, so your webservers etc are behind the pix but using the public IP's. When an internal machine tries to connect to the IP address of your website (say 210.20.38.129), the request is forwarded to your default router (border router usually, unless you're on a larger network). The router gets the request, goes "hey, im responsible for that IP. It should go *HERE*" and fowards it back to the webserver *through* the PIX. At no point does the PIX attempt to map the IP address of 210.20.38.129 to the MAC addy of your webserver for the internal connection. Only after the connection has bounced off the border router does the PIX go "hey, incoming *external* request for 210.20.28.129. I've got a static route for that. I'll send it to $webserver". And your connection works.
Now, if you use a domain name for the request (as most people do when using a web browser), your internal requests will first bounce off your internal DNS. And that's where the problem is. Your internal DNS is configured to point www.myinternalwebserver.com to 192.168.0.129 (or whatever the machine's internal interface is) instead of the public IP address. If it was pointed at the public address, your machine would get said address returned to it after doing the DNS lookup and follow the steps in the paragraph above. Namely, the req bounces off the border router.
As a side note, transparent firewalls are synonyms for bridged firewalls. I.e. it's impossible to actually gain network connectivity to the firewall because for all intents and purposes, it's setup to act as an intercept on a peice of cat5, not as two interfaces seperating two network segments. Think of it as tapping a Cat5 cable and trying to ping the tap itself. Not going to happen, as neither the bridged firewall system (or the tap, per example) have interfaces with an IP address.
There's a guide floating around the net on how to implement bridged/transparent firewalls using OpenBSD if you're interested. It can be found at http://ezine.daemonnews.org/200207/transpfobsd.ht
Janie took my gun...
There is no requirement for a Checkpoint/1 or Cisco PIX firewall, for example, to use private addresses on the inside, and translate them into public addresses on the way out. It's just a question of how you configure the system.
On the one hand, you could have your public addresses "on the inside of the firewall", with one address being the firewall's "inside" interface and the default route out to the internet for your servers - allowing for the network and broadcast addresss, that leaves 29 usable addresses for systems inside your firewall. You would probably use a private address for the outside interface, but you'd sort that out with your ISP. No address translation required. Like your sonicwall, perhaps?
On the other hand, you could configure your public addresses as a pool on the firewall, and have it translate them into private addresses on the way in (and public addresses on the way out). And you could have a 1:1 or a 1:Many mapping. But you don't HAVE TO do any of this.
On the third hand, you could split the 32 addresses, use Network Address Translation for some of them, and route the rest transparently through the firewall.
In any of these cases, you can also apply whatever rules you want to each of the addresses.
Or am I misunderstanding your question?
Paul "Say no to feeping creaturism"
Bridged firewalls support VPNs, in that they'll pass VPN traffic. however, as they have no IP addresses, you can make them endpoints for the VPN tunnel. What you'd have to do is setup a 2nd host inside the bridged firewall, and use that. Keep in mind however that anyone who can authenticate to your VPN is treated as an internal user. So, if you have business parter type companies connecting, its best to keep a close eye on VPN traffic coming OUT of your VPN endpoint and into your internal network.
Janie took my gun...
Umm...innodb hasn't always been Open Source...the backdoor was discovered after the source was opened...
Freedom's just another word for nothing left to lose