On Fri, Sep 19, 2003 at 12:26:34AM +0000, Bob Crandell wrote: > Bummer. How do I let a person or company in that does not have a > static IP address? It depends what you mean by "in". If you mean in to the web proxy server service then you need some sort of authentication. I would say the best way to do this is with a password. Dan's Guardian should have password authentication. If that is not desired then you need to require customers to have a static ip, or use a vpn implementation (far worse). Otherwise you are faced with opening up large blocks of ip addresses your clients don't own, to a web proxy. This highly insecure and will result in spammers and crackers bouncing off your service, causing this site to be liable for damages to other companies through "Down Stream Liability".
> I can ssh in. DansGuardian and Webmin works. I was expecting you to > find 3 or 4 ports open. The fact that you didn't find any is a plus. Perhaps you are getting in from one of the trusted hosts. From those hosts, there isn't 3-4 ports open, everything that has a service is open. Ie, there is no firewall for those hosts, which I don't think is great, but as long as they really are trusted this is fine. If you have someone's home system running win??, exposed to the internet without a secure firewall, then this is NOT a trusted host. If you are putting these types of systems in the trusted host/net list then you need to have the firewall script properly rewritten so that it is a firewall on the inside and the outside. > There is dhcp on each of the NET# networks. The HOST#s are static. > The only time I have to edit the list is if uspops changes their > addressing scheme or if I want to add or remove a specific HOST. Hmm, uspops is a dialup service that many companies use. So if someone dials in to uspops, they get an IP address that is in one of your trusted networks? Then you have no firewall against them. > >> /usr/sbin/iptables -A INPUT -i eth0 -d $BROADCAST -j DROP > >Why is this here? It won't stop windows broadcasts. It just requires > >every packet to match against this rule. > It is to prevent this box from accepting broadcasts. Accepting, as in doing something with them? It doesn't do anything with them anyway. There needs to be an application or some layer that wants to do something with incoming packets before such is done. Windows has the netbeui protocol that sends and receives broadcasts often, so it is processing them. On linux, unless you are running samba, no one is looking for broadcasts, except for the dhcp server. > They are open to the internet. No, they are not. That's what my scan showed. They are open to everyone in your trusted net/host list, but so is every other application port. They are not to the internet in general. > There is something about this script doesn't let you "browse" for > them. "Browsing" for a service and connecting to it are the same. Your application can't tell the difference in almost all cases. > I like that. So you are saying that if I enabled telnet in inetd that > someone could get in because of (-j sort)? I don't like that. No, no one can get in to anything on your system, regardless of what applications you enable unless they are on the list. Here is basically what your firewall ways: Trusted Net/Host lists == everything open Everyone else == everything blocked > All I want available to the internet > are these 4 ports and only to those listed in NET? and HOST? Ok, so you want: Trusted Net/Host list == 4 ports open, everything else blocked Everyone else == everything blocked But perhaps you reall want: Bob's networks == 4 ports open, everything else blocked Trusted Net/Host list == web proxy open, everything else blocked Everyone else == port 80 open, everything blocked That last, if you are running a public website. The point is, you can distribute which networks have access to which ports. The clients probably don't need to see ssh for instance. > On page http://www.sns.ias.edu/~jns/security/iptables/rules.html he > has --sport on his INPUT rule and --dport on his OUTPUT rule This is true, however if you read the comment for these rules, it says it is for OUTBOUND. Notice that his policy for output is DROP. > >/usr/sbin/iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT > Does this include a port FROM the internet? When a packet comes from the internet to a machine for say ssh, this is what the ip/ports look like: source: 12.12.12.12:32423 (can be anything) destination: 64.65.66.67:22 (will be our ip:ssh) When we match on the input rule, we need to match on the non variables, specifically our ip and the service we want. In your case you are matching with our interface. Next, you match the destination service, 22. This is why you use --dport. --sport in the INPUT chain is for outbound service. The reason it doesn't seem that way is because that rule he is using is specifically for packets coming back from the remote machine when this one is doing an outbound connection. If you draw it out it will become clear. > Ok. I'll take this out. Or, thinking about your worm, would it be > better to leave these in and make the policy DROP? [snip] > If you think I'm going in the wrong direction with this, call me. Since you are tying together a number of networks, your firewall should be made much more secure. So yes the output policy should be drop. However if you do that now while users are on it, you're going to cut off a lot of people because the rest of the script is not setup right. In fact you are likely to cut yourself off if you are doing this remotely. I'll definitely call. Cory -- Cory Petkovsek Adapting Information Adaptable IT Consulting Technology to your (541) 914-8417 business [EMAIL PROTECTED] www.AdaptableIT.com _______________________________________________ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
