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
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 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...