| 服务器配置：Squid配置详解 | |
| 来源: Linux论坛 日期： 2010.03.22 21:24 (共有条评论) 我要评论 | |
| 基本配置 安装完成后，接下来要对Squid的运行进行配置(不是前面安装时的配置)。所有项目都在squid.conf中完成。Squid自带的squid.conf包括非常详尽的说明，相当于一篇用户手册，对配置有任何疑问都可以参照解决。 在这个例子中，代理服务器同时也是网关，内部网络接口eth0的IP地址为192.168.0.1，外部网络接eth1的IP地址为202.103.x.x。下面是一个基本的代理所需要配置选项： http_port 192.168.0.1:3128 默认端口是3128，当然也可以是任何其它端口，只要不与其它服务发生冲突即可。为了安全起见，在前面加上IP地址，Squid就不会监听外部的网络接口。 下面的配置选项是服务器管理者的电子邮件，当错误发生时，该地址会显示在错误页面上，便于用户联系： cache_mgr start@soocol.com 以下这些参数告诉Squid缓存的文件系统、位置和缓存策略： cache_dir ufs /var/squid cache_mem 32MB cache_swap_low 90 cache_swap_high 95 在这里，Squid会将/var/squid目录作为保存缓存数据的目录，每次处理的缓存大小是32兆字节，当缓存空间使用达到95%时，新的内容将 取代旧的而不直接添加到目录中，直到空间又下降到90%才停止这一活动。 如果不想Squid缓存任何文件，如某些存储空间有限的专有系统，可以使用 null文件系统(这样不需要那些缓存策略)： cache_dir null /tmp 下面的几个关于缓存的策略配置中，较主要的是第一行，即用户的访问记录，可以通过分析它来了解所有用户访问的详尽地址： cache_access_log /var/squid/access.log cache_log /var/squid/cache.log cache_store_log /var/squid/store.log 下面这行配置是在较新版本中出现的参数，告诉Squid在错误页面中显示的服务器名称： visible_hostname No1.proxy 以下配置告诉Squid如何处理用户，对每个请求的IP地址作为单独地址处理： client_netmask 255.255.255.255 如果是普通代理服务器，以上的配置已经足够。但是很多Squid都被用来做透明代理。 所谓透明代理，就是客户端不知道有代理服务器的存在，当然也不需要进行任何与代理有关的设置，从而大大方便了系统管理员。相关的选项有以下几个： httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_user_host_header on 在Linux上，可以用iptables/ipchains直接将对Web端口80的请求直接转发到Squid端口3128，由Squid接手，而用户浏览器仍然认为它访问的是对方的80端口。例如以下这条命令： iptables -t nat -A PREROUTING -s 192.168.0.200/32 -p tcp --dport 80 -j REDIRECT 3128 page 就是将192.168.0.200的所有针对80端口的访问重定向到3128端口。 所有设置完成后，关键且重要的任务是访问控制。Squid支持的管理方式很多，使用起来也非常简单(这也是有人宁愿使用不做任何缓存的Squid，也 不愿意单独使用iptables的原因)。 Squid可以通过IP地址、主机名、MAC地址、用户/密码认证等识别用户，也可以通过域名、域后缀、文件类 型、IP地址、端口、URL匹配等控制用户的访问，还可以使用时间区间对用户进行管理，所以访问控制是Squid配置中的重点。 Squid用ACL (Access Control List，访问控制列表)对访问类型进行划分，用http_access deny 或allow进行控制。根据需求首先定义两组用户advance和normal，还有代表所有未指明的用户组all及不允许上网的baduser，配置代 码如下： acl advance 192.168.0.2-192.168.0.10/32 acl normal src 192.168.0.11-192.168.0.200/32 acl baduser src 192.168.0.100/32 acl baddst dst www.soocol.com acl all src 0.0.0.0/0 http_access deny baduser http_access allow advance http_access allow normal 可以看出，ACL的基本格式如下： acl 列表名称 控制方式 控制目标 比如acl all src 0.0.0.0/0，其名称是all，控制方式是src源IP地址，控制目标是0.0.0.0/0的IP地址，即所有未定义的用户。出于安全考虑，总是在最后禁止这个列表。 下面这个列表代表高级用户，包括IP地址从192.168.0.2到192.168.0.10的所有计算机： acl advance 192.168.0.2-192.168.0.20/32 下面这个baduser列表只包含一台计算机，其IP地址是192.168.0.100： acl baduser 192.168.0.100/32 ACL写完后，接下来要对它们分别进行管理，代码如下： http_access deny baduser http_access allow advance http_access allow normal 上面几行代码告诉Squid不允许baduser组访问Internet，但advance、normal组允许(此时还没有指定详细的权限)。由 于 Squid是按照顺序读取规则，会首先禁止baduser，然后允许normal。如果将两条规则顺序颠倒，由于baduser在normal范围中， Squid先允许了所有的normal，那么再禁止baduser就不会起作用。 特别要注意的是，Squid将使用allow-deny-allow-deny……这样的顺序套用规则。例如，当一个用户访问代理服务器时， Squid会顺序测试Squid中定义的所有规则列表，当所有规则都不匹配时，Squid会使用与最后一条相反的规则。 就像上面这个例子，假设有一个用户 的IP地址是192.168.0.201，他试图通过这台代理服务器访问Internet，会发生什么情况呢?我们会发现，他能够正常访问，因为 Squid找遍所有访问列表也没有和192.168.0.201有关的定义，便开始应用规则，而最后一条是deny，那么Squid默认的下一条处理规则 是allow，所以192.168.0.201反而能够访问Internet了，这显然不是我们希望的。所以在所有squid.conf中，最后一条规则 永远是http_access deny all，而all就是前面定义的“src 0.0.0.0”。 高级控制 前面说过，Squid的控制功能非常强大，只要理解Squid的行为方式，基本上就能够满足所有的控制要求。下面就一步一步来了解Squid是如何进行控制管理的。 通过IP地址来识别用户很不可靠，比IP地址更好的是网卡的MAC物理地址。要在Squid中使用MAC地址识别，必须在编译时加上“--enable-arp-acl”选项，然后可以通过以下的语句来识别用户： acl advance arp 00:01:02:1f:2c:3e 00:01:02:3c:1a:8b ... 它直接使用用户的MAC地址，而MAC地址一般是不易修改的，即使有普通用户将自己的IP地址改为高级用户也无法通过，所以这种方式比IP地址可靠得多。 假如不想让用户访问某个网站应该怎么做呢?可以分为两种情况：一种是不允许访问某个站点的某个主机，比如ok的主机是ok.sina.com.cn，而其它的新浪资源却是允许访问的，那么ACL可以这样写： acl sinapage dstdomain ok.sina.com.cn ... ... http_access deny ok ... ... page 另一种情况是整个网站都不许访问，那么只需要写出这个网站共有的域名即可，配置如下： acl qq dstdomain .tcccent.com.cn 注意tcccent前面的“.”，正是它指出以此域名结尾的所有主机都不可访问，否则就只有tcccent.com.cn这一台主机不能访问。 如果想禁止对某个IP地址的访问，如202.118.2.182，可以用dst来控制，代码如下： acl badaddr dst 202.118.2.182 当然，这个dst也可以是域名，由Squid查询DNS服务器将其转换为IP。 还有一种比较广泛的控制是文件类型。如果不希望普通用户通过代理服务器下载MP3、AVI等文件，完全可以对他们进行限制，代码如下： acl mmxfile urlpath_regex .mp3$ .avi$ .exe$ http_access deny mmxfile 看到regex，很多读者应该心领神会，因为这条语句使用了标准的规则表达式(又叫正则表达式)。它将匹配所有以.mp3、.avi等结尾的URL请求，还可以用-i参数忽略大小写，例如以下代码： acl mmxfile urlpath_regex -i .mp3$ 这样，无论是.mp3还是.MP3都会被拒绝。当然，-i参数适用于任何可能需要区分大小写的地方，如前面的域名控制。 如果想让普通用户只在上班时间可以上网，而且是每周的工作日，用Squid应当如何处理呢?看看下面的ACL定义： acl worktime time MTWHF 8:30-12:00 14:00-18:00 http_access deny !worktime 首先定义允许上网的时间是每周工作日(星期一至星期五)的上午和下午的固定时段，然后用http_access 定义所有不在这个时间段内的请求都是不允许的。 或者为了保证高级用户的带宽，希望每个用户的并发连接不能太多，以免影响他人，也可以通过Squid控制，代码如下： acl conncount maxconn 3 http_access deny conncount normal http_access allow normal 这样，普通用户在某个固定时刻只能同时发起三个连接，从第四个开始，连接将被拒绝。 总之，Squid的ACL配置非常灵活、强大，更多的控制方式可以参考squid.conf.default。 认证 用户/密码认证为Squid管理提供了更多便利，最常用的认证方式是NCSA。从Squid 2.5版本开始，NCSA认证包含在了basic中，而非以前单独的认证模块。下面来看看实现认证的具体操作。 首先在编译时配置选项应包括以下配置： --enable-auth="basic" --enable-basic-auth-helpers="NCSA" page “make install”以后，需要将“helpers/basic_auth/NCSA/ncsa_auth”拷贝到用户可执行目录中，如/usr/bin(如 果在该目录中找不到这个执行文件，在编译时请使用make all而不是make，或者直接在该目录中执行make)，然后需要借助Apache的密码管理程序htpasswd来生成用户名/密码对应的文件，就像 下面这行代码： htpasswd -c /var/squid/etc/password guest 在输入两遍guest用户的密码后，一个guest用户就生成了。如果以后需要添加用户，把上面的命令去掉-c参数再运行即可。 Squid 2.5在认证处理上有了较大的改变，这里就只讨论2.5版本的处理方法，2.4及以下版本请参考squid.conf.default。在2.5版的squid.conf中，包括以下几个相关选项： 该选项指出了认证方式(basic)、需要的程序(ncsa_auth)和对应的密码文件(password) auth_param basic program /usr/bin/ncsa_auth /var/squid/etc/password 指定认证程序的进程数 auth_param basic children 5 浏览器显示输入用户/密码对话框时的领域内容 auth_param basic realm My Proxy Caching Domain 基本的认证有效时间 auth_param basic credentialsttl 2 hours 普通用户需要通过认证才能访问Internet acl normal proxy_auth REQUIRED http_access allow normal 通过以上的配置即可完成认证工作。有的读者可能要问：认证只针对普通用户，而高级用户是直接上网的，该怎么处理呢?其实，这两种用户是可以共存的。 如 前所述，Squid是顺序处理http_access的，所以在http_access处理过程中，如果先处理normal用户，那么当前用户无论是否属 于高级用户，都会被要求进行认证;相反如果先处理高级用户，剩下的就只有需要认证的普通用户了。例如以下配置代码： ... http_access allow normal (需要认证) http_access allow advance (不需要认证) ... 不管是否为noauth用户，都要求进行用户名/密码验证。正确的方法是将二者位置交换，代码如下： ... http_access allow advance http_access allow normal ... 这时，高级用户不会受到任何影响。 总结 下面把整个squid.conf总结一下： 服务器配置 http_port 192.168.0.1:3128 cache_mgr start@soocol.com cache_dir null /tmp cache_access_log /var/squid/access.log cache_log /var/squid/cache.log cache_store_log /var/squid/store.log visible_hostname No1.proxy client_mask 255.255.255.255 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_user_host_header on 用户分类 acl advance arp 00:01:02:1f:2c:3e 00:01:02:3c:1a:8b ... acl normal proxy_auth REQUIED acl all src 0.0.0.0 行为分类 acl mmxfile urlpath_regex .mp3$ .avi$ .exe$ acl conncount maxconn 3 acl worktime time MTWHF 8:30-12:00 14:00-18:00 acl sinapage dstdomain ok.sina.com.cn acl qq dstdomain .tcccent.com.cn 处理 http_access allow advance http_access deny conncount normal http_access deny !worktime http_access deny mmxfile http_access deny sinapage http_access deny qq http_access allow normal 配置后的状况是，advance组可以不受任何限制地访问Internet，而normal组则只能在工作时间上网，而且不能下载多媒体文件，不能访问某些特定的站点，而且发送请求不能超过3个。 通过本文的介绍，它可以了解Squid的基本能力。当然，它的能力远不止此，可以建立强大的代理服务器阵列，可以帮助本地的Web服务器提高性能，可以提高本地网络的安全性等。要想发挥它的功效，还需要进一步控制。 |
2011年12月3日星期六
Squid配置详解
2011年12月2日星期五
2011年11月29日星期二
A short guide to SSH port forwarding
A short guide to SSH port forwarding
SSH port forwarding, or TCP/IP connection tunneling, is a process whereby a TCP/IP connection that would otherwise be insecure is tunneled through a secure SSH link, thus protecting the tunneled connection from network attacks. Port forwarding can be used to establish a form of a virtual private network (VPN).To illustrate how port forwarding works, let us use an example. Suppose you are the network administrator in a company that has two buildings. In Building #1, there are numerous workstations residing in the subnet 10.1.1.*. In Building #2, there are multiple servers residing in the subnet 10.2.2.*. The two buildings are separated by a busy street with parking spaces on each side, and the subnets in the two buildings are linked wirelessly through an antenna on the roof of each building. The workstations in Building #1 are running a legacy client application that uses an unencrypted TCP/IP session to communicate sensitive data with the servers in Building #2.
One day, someone in your company notices that an unmarked black van has remained parked on the street between the two buildings for several days. As your CEO realizes that sensitive data is being transmitted unencrypted between the two buildings, he becomes worried that the van parked outside might be collecting the company's confidential information. He orders you to solve the problem ASAP.
What you do is this:
On each of the client workstations in Building #1 (in the above example,
workstation 10.1.1.7 is shown), you install an SSH client. On the
machine in Building #2 that runs the server for your legacy
application, you install an SSH server. You configure the SSH client
with the following client-to-server port forwarding rule: for each
connection that comes on interface 127.0.0.1 and port 999, forward that
connection to the SSH server, and request the SSH server to forward
that connection to host 127.0.0.1 (relative to the server), port 123.Now, your application client doesn't connect to the server directly anymore. Rather, it connects to the SSH client, which encrypts all data before transmission. The SSH client forwards the encrypted data to the SSH server, which decrypts it and forwards it to your application server. Data sent by the server application is similarly encrypted by the SSH server and forwarded back to the client.
Previously, the data that was being radioed between the two buildings was sent in plaintext and could be captured by anyone parking on the street below. Now, the data is encrypted using the SSH protocol, and is virtually impossible to decipher. The next day after installing SSH, you observe that the black unmarked van is gone.
Now, let us comment on the above example. It corresponds with the following C2S (client-to-server) port forwarding rule in the SSH client:
- Listen interface: 127.0.0.1 (this ensures that only connections from the local client machine, or loopback connections, are accepted for forwarding)
- Listen port: 999
- Destination host: 127.0.0.1 (important: the target address is relative to the server, not the client, so 127.0.0.1 will work fine if the target application server is listening on all interfaces - 0.0.0.0)
- Destination port: 123
Next, you will note that the listening port has been set to 999. The listening port could be set to any figure between 1 and 65535 that is not already occupied by another application listening for connections on the same machine. In this case, the SSH client listening port has been set to 999, but it could just as well have been set to 123, the same port at which the application server is listening.
Now comes the most confusing part: the address of the destination host. It is important to understand that, in a client-to-server port forwarding rule, the target host address is relative to the SSH server, not the client. This is the address that the SSH server will connect to when a connection needs to be forwarded. In this case, the target host address is set to 127.0.0.1 to have the SSH server connect to the application server which is running on the same machine.
Finally, the destination port specifies the port on which the target TCP/IP server is listening - in this case, 123.
The port forwarding configuration shown in the above example is strict: it minimizes the exposure of unencrypted data by constraining the SSH client to reside on the same machine as the application client, and the SSH server to reside on the same machine as the application server.
On the other hand, if you are only concerned about eavesdropping between the SSH client and the server, and do not mind unencrypted data in the local subnets, you might configure your SSH port forwarding rules like this:
This corresponds with the following C2S (client-to-server) port forwarding rule in the SSH client:- Listen interface: 0.0.0.0 (this opens up the SSH client's forwarding socket to connections from other machines)
- Listen port: 123
- Destination host: 10.2.2.9 (the target application server is not on the same machine as the SSH server, so we need to enter its address as visible from the SSH server)
- Destination port: 123
Even though our examples above only discuss client-to-server port forwarding rules, the concept of server-to-client port forwarding is entirely symmetric. Only the roles are reversed: with S2C forwarding, the listening address is relative to the SSH server, and the destination host address is relative to the SSH client.
It is a common mistake to define both a C2S as well as an S2C rule for the same forwarded connection. This is not necessary and will not work. S2C rules are required only if you are forwarding other connections which are established in the direction from the server to the client. Such connections are normally independent from, and unrelated to, those established from client to server. Only one type of rule is necessary for each connection.
2011年11月27日星期日
使用免费的amazon EC2 服务部署SSH翻墙
使用免费的amazon EC2 服务部署SSH翻墙
原文：http://lianlay.com/?p=128在开始阅读本篇文章的时候我假定你已经成功注册了amazon ec2的服务，并且开启了一个免费的实例。
这方面在网上的现成的教程比较多，请同学们自行查找。
下面是如何利用这个免费的实例搭建一个ssh代理服务从而实现翻墙。
第一步: 登陆到你的ec2服务器修改sshd配置文件
cd /etc/ssh //进到ssh目录
cp sshd_config sshd_config.bak //备份一下一下源配置文件
sudo vi sshd_config //修改配置文件
找到AllowTcpForwarding 改为yes 允许TCP转发
AllowTcpForwarding yes //允许TCP转发
因为Amazon默认使用比较安全证书方式进行登陆, 但是如果大家自己aws的免费配额使用不完希望分配其他的同学使用,
那么再让那些同学密码进行登录是个比较省事儿的方法.
如果如果你想这么做的话，可以在里面修改成为密码登陆方式，但是你必须知道密码登陆方式没有密钥方式相对安全。
在配置文件里面找到PasswordAuthentication 项改为yes 就可以改为密码登录方式
PasswordAuthentication yes //LL就是采用的这种方式,可以省掉不少麻烦
保存退出sshd文件
执行下面这行代码重启sshd服务使之生效
sudo /etc/init.d/sshd restart
第二步: 建立一个专门用于链接ssh的账户组
sudo groupadd ec2ssh //建立ec2ssh用户组
sudo useradd -d /home/ec2ssh -m -g ec2ssh -s /bin/false ec2ssh //增加用户ec2ssh并且创建一个ec2ssh的目录并且属于组ec2ssh并且禁止shell
这里一定要禁掉shell以降低安全问题，以后给自己的同学和朋友建立账户的时候就可以了。
当然要记得给你新建的账户改密码
sudo passwd ec2ssh
第三步: 客户端配置
推荐下载一个客户端Tunnelier http://www.bitvise.com/
填入host和端口号: 就是你部署的ssh服务器地址
右面填入用户名
initial method 选择password 填入密码
再到option选项卡，勾掉Open Terminal 和 Open SFTP
在到service里面 enable proxy forwarding 设置interface和port
在这里设置的127.0.0.1:8888就是对应要设置到浏览器里面的值。
设置好后，点击界面最低端的login可以查看是否可以成功连接到服务器。
然后通过设置好的浏览器就可以上网了。
这里提一句请选择可以支持socks5的代理。Tunnelier 官方说对http代理支持的有问题。
这方面在网上的现成的教程也比较多，请同学们自行查找。
PS: 由于国情所致，从国内的部分网络到aws有时候会不稳定。
建议这种方式配合之前文章介绍的Goagent共同使用。
AWS Free Tier正好补足了GAE流量上的限制。GAE也弥补了AWS时而不稳定的缺陷。
查看GAE翻墙教程 http://lianlay.com/?p=123
一些注意事项
AWS Free Usage Tier (Per Month):
750 hours of Amazon EC2 Linux Micro Instance usage (613 MB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month* 750 hours of an Elastic Load Balancer plus 15 GB data processing* 10 GB of Amazon Elastic Block Storage, plus 1 million I/Os and 1 GB of snapshot storage* 5 GB of Amazon S3 standard storage, 20,000 Get Requests, and 2,000 Put Requests* 15 GB of bandwidth out aggregated across all AWS services* 25 Amazon SimpleDB Machine Hours and 1 GB of Storage** 100,000 Requests of Amazon Simple Queue Service* 100,000 Requests, 100,000 HTTP notifications and 1,000 email notifications for Amazon Simple Notification Service** 10 Amazon Cloudwatch metrics, 10 alarms, and 1,000,000 API requests** 对于Amazon EC2的free tier包括每月750小时的micro instance(linux) micro内存。24*31=744 正好是一个月。
Free Tier包含每月各15GB的上传下载
免费EBS容量为10GB 含1 GB 快照容量，1百万次I/Os
详细内容这里看 http://aws.amazon.com/free/
订阅：
博文 (Atom)