Category Archives: Linux

install PPTP VPN on Gentoo server

Leave a reply

First, Install the necessary components

emerge -av ppp pptpd iptables

Note: PPP should be supported by Linux Kernel. If your Kernel doesn’t support PPP, you need to re-compile it.

Modify /etc/ppp/options.pptpd

nano /etc/ppp/options.pptpd

unmark below section and use google DNS

ms-dns 8.8.8.8
ms-dns 8.8.8.4

create username, password for VPN access, modify /etc/ppp/chap-secrets


# Secrets for authentication using CHAP
# client  server  secret          IP addresses
username * password *

Then modify system settings for IP forward.

nano /etc/pptpd.conf

Unmark below sections:

localip 192.168.0.1
remoteip 192.168.0.234-238,192.168.0.245

Then add ip forward rules, modify /etc/sysctl.conf and add

net.ipv4.ip_forward = 1

Save and execute

sysctl -p

Add iptable rules

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j MASQUERADE
/etc/init.d/iptables save

Start iptable and pptp

/etc/init.d/iptables start
/etc/init.d/pptpd start

Start the service when system start

rc-update add iptables default
rc-update add pptpd default

Preventing Brute Force Attacks With BlockHosts On Debian Etch

1 Reply

cd
wget http://www.aczoom.com/tools/blockhosts/BlockHosts-2.1.0.tar.gz
tar xvfz BlockHosts-2.1.0.tar.gz
cd cd BlockHosts-2.1.0
python setup.py install –force
nano /etc/blockhosts.cfg

修改

[…]
HOSTS_BLOCKFILE = "/etc/hosts.allow"
[…]
HOST_BLOCKLINE = ["ALL: ", " : deny"]
[…]
LOGFILES = [ "/var/log/auth.log", "/var/log/proftpd/proftpd.log", ]
[…]
COUNT_THRESHOLD = 3
[…]
AGE_THRESHOLD = 12
[…]
MAIL = True
[…]
NOTIFY_ADDRESS = ‘[email protected]’
[…]
SMTP_SERVER = "localhost"
SENDER_ADDRESS = ‘BlockHosts <[email protected]>’
[…]
IPBLOCK = "iptables" […]

In HOSTS_BLOCKFILE we can specify either /etc/hosts.allow or /etc/hosts.deny. It doesn’t matter which one we choose. I’m using /etc/hosts.allow here. In the LOGFILES line we specify the log files that BlockHosts should look at. OpenSSH is logging failed login attempts to /var/log/auth.log, ProFTPd to /var/log/proftpd/proftpd.log. COUNT_THRESHOLD specifies the number of failed login attempts from the same host after which BlockHosts should block that host. AGE_THRESHOLD is the numer of hours after which blocked hosts get unblocked. IPBLOCK specifies if you’d like to block hosts with iptables or iproute in addition to adding these hosts to /etc/hosts.allow (or /etc/hosts.deny).

Next we must modify /etc/hosts.allow. First back up your current /etc/hosts.allow:

cp /etc/hosts.allow /etc/hosts.allow_bak
nano /etc/hosts.allow

Continue reading →

TCP: Treason uncloaked! Peer..shrinks window..Repaired.”

Leave a reply
TCP: Treason uncloaked! Peer 203.168.193.2:55074/80 shrinks window … Repaired.
系统信息中出现大量这个问题，查了下资料
 
先在网上看到这样的一段解释:

The remote host decided to shrink the TCP window size without negotiating such with your Linux box. The message is of the informational level, meaning Linux doesn’t like what it is seeing but will cope with it and carry on.

大致意思是说:这是一段一般性提示信息,说明远程主机在未经Linux主机”同意”就收缩了TCP window size,虽然Linux主机不喜欢这类举动,但是仍将继续处理这类请求.

这是一种解释,也就是这类信息可能并非危险.

另外一段解释来自Debian的邮件列表,首先回复者引用了一段源代码说明错误的来源:

>>From /usr/src/linux/net/ipv4/tcp_timer.c:

        if (tp->snd_wnd == 0 && !sk->dead &&
            !((1<<sk->state)&(TCPF_SYN_SENT|TCPF_SYN_RECV))) {
                /* Receiver dastardly shrinks window. Our retransmits
                 * become zero probes, but we should not timeout this
                 * connection. If the socket is an orphan, time it out,
                 * we cannot allow such beasts to hang infinitely.
                 */
#ifdef TCP_DEBUG
                if (net_ratelimit())
                        printk(KERN_DEBUG “TCP: Treason uncloaked! Peer
%u.%u.%u.%u:%u/%u shrinks window %u:%u. Repaired.n”,
                               NIPQUAD(sk->daddr), htons(sk->dport), sk->num,
                               tp->snd_una, tp->snd_nxt);
#endif

具体的解释是:

So it appears that someone is running some sort of “tar-pit” system that is
designed to keep sockets in a bad state and run you out of kernel memory.

I suspect that this ties in with the spam blocking things we recently
discussed.  Maybe you should tell your ISP that they are to blame for such
actions being done to you and that they should “give you face” (I think that
was the term you used) by closing their open relays.

作者认为这可能和tar-pit攻击相关.并且建议联系ISP提供解决方案.

还有如下的解释:

The reason Linux is printing such messages is because your client guy is shrinking the TCP Window to 0, and the server has something to retransmit. There is something seriously wrong with your client’s stack. Which Stack/OS are you using on he client side, and which browser?

That could explain your browser showing some html tags as the server fails to send the whole page across and based on what browser you are using it is failing to parse it out.

意思是,这类错误也可能是客户端Stack错误引起的.

另一段同样引用了源代码的解释似乎直指了问题的本质:

> Treason uncloaked! Peer [IP address]:515/1022 shrinks window
> 3957222360:3957222379.  Repaired.

> Our researches so far indicate the problem may be a buggy TCP stack
> in the client, that is in the DP301P+. But we still do not know
> exactly what caused the problem, nor how to prevent it happening
> again.

That comes from the kernel tcp code below.  Looks like the DLink has
returned information yielding a transmit window smaller than it
previously did; specifically it returned a window of zero plus an ack
of up to byte 3957222360, thus indicating that it can accept nothing
after that byte.  Previously it had sent some ack+wnd values
indicating that it would accept up to byte 3957222379.

The Linux side is now supposed to send a packet every now and then
forever until the returned window is nonzero.  It does. 

However, the dlink is apparently not responding in a timely manner.
Any response would either open the window or update the rcv timestamp
such that the thing will retransmit forever.  It may be responding
very slowly, or just not responding at all.

The kernel prints the message after it expected but did not see a
response to the probe packet it sent to check for a nonzero window.
The kernel implements exponential backoff retransmissions until it
hasn’t seen any response in 2m, then it will bail and close the
connection.  This is reasonable.  It’s unclear from your report if the
connections are failing outright or just sometimes having to
retransmit a probe against a peer that shrank the window.

这段解释极为详尽.就此作结.

proftpd虚拟用户注意问题

1 Reply

proftpd配置文件中设置的最大连接数为500，结果发现事实上到了100就不能连接了。

今天发现原来是mysql的问题，mysql中max_connections设置的为100。导致proftpd用户登录时，与mysql连接进行验证失败。

修改my.conf ，将里面的max_connections设置为500就ok了