On Wed, Nov 28, 2007 at 03:37:02PM +0545, Rajesh Pandey wrote: > hi abhijeet > I am responding in regards to your first query only > these might be some added steps for defining the acls in squid for allowing > your clients. > Hope I might not make your query more complicated. If so please discard this > message.
Rajesh bro, You've enlightened me. Seriously. :-) I think what Abhijeet is missing here is a manual/FAQ - http://wiki.squid-cache.org/SquidFaq/SquidAcl. I quickly skimmed through the documentation of squid and found these information related to ACLs for OP. # Common acl rules in squid.conf's lingo - # allow localsubnet:any->net:80 acl lan src 192.168.0.1/24 http_access allow lan # deny net:any<->local:any everyone acl all src 0/0 http_access deny all # allow another subnet, block rest acl anotherlan src 10.1.1.1/24 http_access allow anotherlan http_access deny all # allow partial safe ports as per Rajesh bro's recommendation, block rest. # remember this will only block client->internet:the_ports_below. acl safeports port 289 488 591 777 554 6770-7170 http_access deny !safeports # be explicit where necessary ;) acl sshport port 22 http_access deny sshport # allow localhost acl localhost src 127.0.0.1/255.255.255.255 http_access allow localhost # set it transparent http_port "squids_port" transparent I still think it's wise to have iptables/pf that allows/denies/rejects/logs/drops connection at one step above in the topology hierarchy. What happens if someone spoofs their IP address matching to local lan? (say 192.168.0.54 or something). In that case, they will be able to use the proxy. But if iptables/pf is in place, it will catch the bugger. I do not think squid can detect it (Also possible vai /etc/hosts.deny, using tcp wrapper). Although squid might do the job for you but it's important to realise that it's not a firewall but a caching proxy server -with- firewall extension and it's best use is served using it that way. On the other hand, OP's question seems to be related to dos attack via lots of invalid SSH sessions from the internet. In that case - * sshban * blackhole the connection * use tcp wrapper There maybe more ways like contacting the ISP/backbone and making them block the entire class A range. There is no perfect solution for dos (even worse for ddos) but I've heard lot of seniors talk about it in the past and they seem to indicate the solution along the lines of what I have mentioned above. Phew.. Abhijeet, take this as an small suggestion from a programmer :- Its not a healthy practise to manage security of the network this way. If you are a sys-admin, and you do not have time to setup proper administrative tasks, you should not be a doing sys-admin task at all. Don't take it wrongly. It's suppose to be constructive suggestion from a friend. Some day, a sophisticated script kitty might cripple your network. The sooner you realise this, the better you'll be equipped to deal with the situation. fstab question is answered I presume. Goodluck. -- Cheers, Bikal. GPG: 0x5DAE3BE5 "Rule 6: There is no Rule 6." - Rob Pike
pgpdCtV5LoqZI.pgp
Description: PGP signature
