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.
Kinda makes me wonder, though, how often articles like this spawn ideas in the minds of the "wrong people," leading to attacks or attempts to attack. Anyone else ever wonder that?
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
Pretty much all of Netgear's home routers have stateful packet inspection features. Some of them are quite inexpensive (how about US$80 for a model that even includes a print server!).
The great thing about stateful packet inspection is that you don't have to configure it. If you want to play some new game that does multiplayer play on the Internet through some wacky port, it will just work, and meanwhile if some random guy blasts packets at that port or any other they will bounce off. If you didn't ask for a packet, it gets turned away.
(If you ever serve as tech support for a friend or family member, be sure they buy a firewall/router with stateful packet inspection!)
Of course, that cuts both ways: any back-doors in your network will just work, also. Don't figure that just having a cool firewall/router with stateful packet inspection is a guarantee that you are secure. But it's a nice start, and it's what I recommend to anyone who has an always-on Internet connection.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I remember the time when we found out that the 3Com switch / router / whatever (i can't remember so clearly now, it's been such a traumatic shock that i am still trying to forget and having mild success), and we were basically like "WHAT?!?!" and then all passed out.
I remember this time I was all drunk and busy trolling slashdot and I got to this article that was related to what I do for a living, only it was related in the most remedial of fashions and I was like "right on, I can troll this motherfucker like it ain't nobody's business, fo shizzle mah nizzle, and I may even get mod points cuz of the bullshit I'm about to spew."
Anyway, I was reading this mofo and I came across some whack job herion addict post that said some stupid shit and I read it and reread it and reread it, and was like "well, I'd troll this sumbith, but the wanker can't even write coherently". So I read it again and was basically like "WHAT?!?!" and then I was all passed out.
You know you're on slashdot when sex position posts get modded Informative.
Smoothwall GPL 2.0 Beta 4 (mallard)
http://smoothwall.org/beta/
I put three nics in a Pentium 90 that I found on a trash heap. One nic goes to my RR cable modem, one nic goes to my switch and one nic is for my son's Playstation 2.
I can control every aspect of the firewall from any pc on the green nic. The firewall pc doesn't even have a keyboard or monitor.
I can VPN through it with ease and I have port forwarding from an oddball port number to port 21 for a private FTP so that RR won't find it.
It's really easy to use and so far I've had no problems.
Of course ALL the machine inside of it are Linux boxes and all of them are using iptables (w/shorewall) so everything is really secure..
For a super easy, very cheap and very fast firewall try floppyfirewall at http://zelow.no/floppyfw
No worries here...
no, it's at 127.0.0.1 ... it's super easy to break in, I've done it before, and the poor sap didn't even realize it. muhahahaha, i am such a l33t h4x0r
YOU SUCK BALLS!
Personally I don't see any use for software firewalls for the majority of home users. I have a Linksys router and it completely shields both of my computers from outside access unless I use port forwarding. This is much easier to configure and use than a software firewall, and if there is ever a port you need to open for whatever reason, just use port forwarding and it's done in 30 seconds.
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
Yes and no. If you rely solely on firewalls, yes, because firewalls just contain damage and prevent it spreading. You definitely still have to take care of the weak security on the affected machine(s). However, if you think of security as an ongoing effort (i.e. no "last step"), you'll see that monitoring your firewall may give you much quicker notification of abnormal activity.
Personally, I much prefer to be warned by port scans, etc., than to rely solely on hardening for protection from attacks. It's like having a fence around your house, with a gate in front, and having a burglar standing outside, rattling the front gate, yelling "hey, I'm about to try to break into your house!" He might get over the fence or through the gate, but you'd be awfully stupid, if you knew some burglers did that, not to at least have the wall and the gate.
Carrying the metaphor a little too far, of course, it's a heck of a lot easier to track the guy down and "remove the threat," if you know he's going to try something, and where he is, before he does tries it.
Get off my launchpad!
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...
1. What firewall software pretends to do (as opposed to what it actually accomplishes).
2. How to become a perfect target of DoS attack through paranoia (imitation of any intrusion-like activity will make the supposed origin unable to access you).
3. How to defend yourself when you have already lost, and are for all practical purposes as good as dead.
Contrary to the popular belief, there indeed is no God.
The concluding sentences contain the main learning point, as I see it: you need a way to identify all connections down to the source (user).
And you need to make sure that all those dumb users know you're watching them and that you will hold them accountable for breaches of security that they initiate.
Or is all that so obvious that no-one has felt the need to point it out?
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...