What's new

Is this an attack on openvpn?

  • Thread starter Deleted member 27741
  • Start date
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

D

Deleted member 27741

Guest
Hi guys, I have been seeing a number of the following entries in my log from different ip addresses, what is it? If it is an attack, is there a way to block it?

Jul 17 08:49:25 openvpn[628]: TCP connection established with [AF_INET]190.138.168.93:54996
Jul 17 08:49:25 openvpn[628]: 190.138.168.93:54996 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1592 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jul 17 08:49:25 openvpn[628]: 190.138.168.93:54996 Connection reset, restarting [0]
Jul 17 08:49:25 openvpn[628]: 190.138.168.93:54996 SIGUSR1[soft,connection-reset] received, client-instance restarting
 
Random port scanner. Ignore it, or move OpenVPN to a non-standard port number.
 
im getting the same sort of crap from china ofc..
love the way it checks back again every 48 hours class..

Jul 15 07:45:02 pptpd[835]: CTRL: Client 183.60.48.25 control connection started
Jul 15 07:45:03 pptpd[835]: CTRL: EOF or bad error reading ctrl packet length.
Jul 15 07:45:03 pptpd[835]: CTRL: couldn't read packet header (exit)
Jul 15 07:45:03 pptpd[835]: CTRL: CTRL read failed
Jul 15 07:45:03 pptpd[835]: CTRL: Client 183.60.48.25 control connection finished
Jul 16 10:54:43 miniupnpd[696]: HTTP Connection from 192.168.0.30 closed unexpectedly
Jul 17 07:45:04 pptpd[2998]: CTRL: Client 183.60.48.25 control connection started
Jul 17 07:45:04 pptpd[2998]: CTRL: EOF or bad error reading ctrl packet length.
Jul 17 07:45:04 pptpd[2998]: CTRL: couldn't read packet header (exit)
Jul 17 07:45:04 pptpd[2998]: CTRL: CTRL read failed
Jul 17 07:45:04 pptpd[2998]: CTRL: Client 183.60.48.25 control connection finished
Jul 17 14:54:02 miniupnpd[696]: remove port mapping 3659 UDP because it has expired
 
Last edited:
im getting the same sort of crap from china ofc..
love the way it checks back again every 48 hours class..

Jul 15 07:45:02 pptpd[835]: CTRL: Client 183.60.48.25 control connection started
Jul 15 07:45:03 pptpd[835]: CTRL: EOF or bad error reading ctrl packet length.
Jul 15 07:45:03 pptpd[835]: CTRL: couldn't read packet header (exit)
Jul 15 07:45:03 pptpd[835]: CTRL: CTRL read failed
Jul 15 07:45:03 pptpd[835]: CTRL: Client 183.60.48.25 control connection finished
Jul 16 10:54:43 miniupnpd[696]: HTTP Connection from 192.168.0.30 closed unexpectedly
Jul 17 07:45:04 pptpd[2998]: CTRL: Client 183.60.48.25 control connection started
Jul 17 07:45:04 pptpd[2998]: CTRL: EOF or bad error reading ctrl packet length.
Jul 17 07:45:04 pptpd[2998]: CTRL: couldn't read packet header (exit)
Jul 17 07:45:04 pptpd[2998]: CTRL: CTRL read failed
Jul 17 07:45:04 pptpd[2998]: CTRL: Client 183.60.48.25 control connection finished
Jul 17 14:54:02 miniupnpd[696]: remove port mapping 3659 UDP because it has expired

I have a msg sent to my mobile phone for every successful PPTP or OpenVPN connection.

To be honest I know I shouldn't be using PPTP but I'll probably have a heart attack if the msg on my mobile does ultimately show a successful unauthorised connection from that address! :eek:
 
Im not going to go to details but i have just checked the ip out that's probing me every two days
and its well over a gigabit link and is directly connected to the chinese backbone

it isnt some random malware infested pc
its a multi gigabit full fat connection

that your typical chinese end user would never ever have
 
Haha... yeah, I get a bunch of pptp vpn login attempts from China IP addresses as well. I won't get worried until they try more login attempts in a day. This kind of "hacking" is just looking for low-hanging fruit. It's not like they are hitting me with 50,000 login attempts a day. :D

P.S. Holy cow, shonk!

Maybe some people still think they will be able to pull this one off-
http://arstechnica.com/security/201...e-been-pwned-thanks-to-easily-exploited-flaw/
 
Last edited by a moderator:
Im not going to go to details but i have just checked the ip out that's probing me every two days
and its well over a gigabit link and is directly connected to the chinese backbone

it isnt some random malware infested pc
its a multi gigabit full fat connection

that your typical chinese end user would never ever have

Can be a server that was compromised.
 
I have a msg sent to my mobile phone for every successful PPTP or OpenVPN connection.

To be honest I know I shouldn't be using PPTP but I'll probably have a heart attack if the msg on my mobile does ultimately show a successful unauthorised connection from that address! :eek:

With your level of expertise, you could easily block this through iptables, either filtering non-local IPs, or using a throttle rule.

Eventually, I will extend the SSH DoS protection to also cover PPTP and OpenVPN. For now, the focus is on the RT-AC87U launch this weekend. I will get new source code to merge in early next week, so this will have to wait until I'm done updating to the latest code from Asus.
 
im getting the same sort of crap from china ofc..
love the way it checks back again every 48 hours class..
Yeah, regular as clockwork. You can set your watch by it :D

TBH I don't mind China trying to scan me once every 2 days, but I do object to Shodan (USA) scanning me every few hours and selling the results to every Tom, Dick and Harry.

/jffs/scripts/firewall-start:

#!/bin/sh
logger -t $(basename $0) $1
iptables -I INPUT -s 183.60.48.25 -j logdrop
iptables -I INPUT -s 198.20.64.0/18 -j logdrop
 
Last edited:
Dumb question, I know, but is it blocking IP addresses (on the N66U) as easy as creating a file called firewall-start in /jffs/scripts and adding the text:

#!/bin/sh
logger -t $(basename $0) $1
iptables -I INPUT -s SOMEIPIWANTBLOCKED -j logdrop
iptables -I INPUT -s ANOTHERIPIWANTBLOCKED -j logdrop

Another goofy quesiton- is it possible to filter based on MAC address instead of IP? So, instead of allowing connection to pptp from a certain IP address instead allowing connection from a MAC address? This would be useful for road warriors who want a bit of extra security but don't know what IP they will use to connect. I guess OPENVPN with certs pretty much crushes that anyway... hehe.
 
Dumb question, I know, but is it blocking IP addresses (on the N66U) as easy as creating a file called firewall-start in /jffs/scripts and adding the text:

#!/bin/sh
logger -t $(basename $0) $1
iptables -I INPUT -s SOMEIPIWANTBLOCKED -j logdrop
iptables -I INPUT -s ANOTHERIPIWANTBLOCKED -j logdrop
Yes it is.

Another goofy quesiton- is it possible to filter based on MAC address instead of IP? So, instead of allowing connection to pptp from a certain IP address instead allowing connection from a MAC address? This would be useful for road warriors who want a bit of extra security but don't know what IP they will use to connect. I guess OPENVPN with certs pretty much crushes that anyway... hehe.
I don't see why not. You would probably have to replace this existing rule:

-A INPUT -i eth0 -p tcp -m tcp --dport 1723 -j ACCEPT

with something like this:

-A INPUT -i eth0 -p tcp -m tcp --dport 1723 -m mac --mac-source 00:AA:BB:CC:CD:EE -j ACCEPT
 
Last edited:
In case others are looking for a beginner's guide to iptable configuration, I found one. Note I only use the CLI.

https://fedoraproject.org/wiki/How_to_edit_iptables_rules


***************************************************************

I blocked all connections to port 1723 (pptp vpn) except connections from a specific mac address. The commands I used were the following while connected via ssh:

iptables -I INPUT 1 -p tcp -m tcp --dport 1723 -j DROP
iptables -I INPUT 1 -p tcp -m tcp --dport 1723 -m mac --mac-source 00:11:22:33:44:55 -j ACCEPT

These insert commands put the first rule at the top, then the second command puts the second rule above the first (necessary to be above the first rule or else it would already DROP all traffic on 1723 since the rules are followed until drop or accept is achieved).

So, remember drop first, accept later. The insert command inserts ABOVE the rule number given, so if you sequentially insert to rule 1, the last rule you insert will be the first. God, that is confusing, isn't it?

Of course, I had to save the iptables to a file with command (iptables are wiped on boot unless you rerun them every time the router starts):
iptables-save > /location/you/use/iptables.dump

I then appended this command to file /jffs/scripts/firewall-start:
iptables-restore < /location/you/use/iptables.dump

I also made the file /jffs/scripts/firewall-start executable:
chmod a+rx /jffs/scripts/firewall-start

Keep in mind there are a zillion ways to do this, probably most of them are better than my method, I am a iptables noob.

I will end with a very useful iptables command for your eyeballs (counting lines is a pain)-
iptables -vnL --line-numbers
 
Last edited by a moderator:
Hi 000111 (you seem to have lost a couple of bits there ;)),

Thanks for to update. Looks good. I would make an observation though.

iptables-restore by default will replace all the current rules with the ones in your dump file. This is all well and good provided that you never want to make any more changes to the router that modifies the packet filtering. Like changes to parental control, DOS protection, VPNs, etc.

I think it would be better if you just put your two iptables commands in the firewall-start script and left it at that.

Just my 2 cents.
 
You mean the now superfluous post I deleted? Heh, don't want thread bloat!

I am not sure I understand what you are getting at... I will further illustrate my lack of knowledge by saying I thought it would be pretty easy to modify the dump file- the first couple of input rules from the iptables.dump file are:

-A INPUT -i ppp10 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1723 -m mac --mac-source 11:22:33:44:55:66 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1723 -j DROP
-A INPUT -i tap21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -m state --state INVALID -j DROP

Looks pretty easy to change rules as I see fit here. I thought that would be easier than using iptables CLI commands?

Ah, I think I get it. Only the current rules will be sent from the other GUI stuff becuase the file is already made. If I make changes to the VPNs/firewall/etc from the router GUI those changes will not be translated to the iptables.dump file. Good point.
 
Last edited by a moderator:
You mean the now superfluous post I deleted? Heh, don't want thread bloat!
Sorry, just my sense of humour. Your name (000111) has six bits, whereas a byte has eight. So you're missing 2 bits. OK, it's not that funny. :eek:

If I make changes to the VPNs/firewall/etc from the router GUI those changes will not be translated to the iptables.dump file. Good point.
Exactly. Because the iptables rules are dynamically created depending on what options you choose, and any future changes Merlin/ASUS might make to the firmware, you cannot rely on the rules remaining the same.
 
Yeah, regular as clockwork. You can set your watch by it :D

TBH I don't mind China trying to scan me once every 2 days, but I do object to Shodan (USA) scanning me every few hours and selling the results to every Tom, Dick and Harry.


Umm i have to agree i blocked census1.shodan.io to census12.shodan.io yesterday its a joke how much they are port scanning my ip

Nov 13 18:14:15 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=71.6.165.200 DST=* <1>LEN=58 TOS=0x00 PREC=0x00 TTL=116 ID=33613 PROTO=UDP <1>SPT=40000 DPT=626 LEN=38
Nov 13 21:29:09 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=198.20.70.114 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=49192 PROTO=TCP <1>SPT=33302 DPT=2323 SEQ=1385412140 ACK=0 WINDOW=12705 RES=0x00 SYN URGP=0
Nov 13 23:41:11 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=66.240.192.138 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=60980 PROTO=TCP <1>SPT=4758 DPT=9200 SEQ=314821339 ACK=0 WINDOW=43311 RES=0x00 SYN URGP=0
Nov 14 00:39:06 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=71.6.135.131 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=25212 PROTO=TCP <1>SPT=50666 DPT=7777 SEQ=412604517 ACK=0 WINDOW=65259 RES=0x00 SYN URGP=0
Nov 14 01:00:25 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=66.240.192.138 DST=* <1>LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=41070 PROTO=UDP <1>SPT=40000 DPT=523 LEN=28
Nov 14 04:38:51 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=71.6.165.200 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=50302 PROTO=TCP <1>SPT=35358 DPT=21 SEQ=1640866139 ACK=0 WINDOW=62202 RES=0x00 SYN URGP=0
Nov 14 06:48:14 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=82.221.105.6 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=118 ID=18037 PROTO=TCP <1>SPT=3056 DPT=53 SEQ=3568202656 ACK=0 WINDOW=38098 RES=0x00 SYN URGP=0
Nov 14 07:34:15 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=66.240.192.138 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=50144 PROTO=TCP <1>SPT=15890 DPT=62078 SEQ=2463359718 ACK=0 WINDOW=53627 RES=0x00 SYN URGP=0
Nov 14 08:58:33 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=71.6.135.131 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=65407 PROTO=TCP <1>SPT=23527 DPT=3306 SEQ=3110752431 ACK=0 WINDOW=5219 RES=0x00 SYN URGP=0
Nov 14 10:14:36 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=66.240.192.138 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=15890 PROTO=TCP <1>SPT=18966 DPT=8333 SEQ=3320016347 ACK=0 WINDOW=44716 RES=0x00 SYN URGP=0
Nov 14 10:48:06 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=71.6.165.200 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=22384 PROTO=TCP <1>SPT=28891 DPT=2404 SEQ=3678474454 ACK=0 WINDOW=10885 RES=0x00 SYN URGP=0
Nov 14 13:31:58 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=198.20.69.98 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=41559 PROTO=TCP <1>SPT=40783 DPT=9944 SEQ=2590659721 ACK=0 WINDOW=22907 RES=0x00 SYN URGP=0
Nov 14 14:05:37 kernel: DROP <4>DROP IN=eth0 OUT= MAC=* <1>SRC=198.20.99.130 DST=* <1>LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=54321 PROTO=ICMP TYPE=8 CODE=0 ID=35722 SEQ=0


iptables -I INPUT -s 198.20.69.74 -j logdrop
iptables -I INPUT -s 198.20.69.98 -j logdrop
iptables -I INPUT -s 198.20.70.114 -j logdrop
iptables -I INPUT -s 198.20.99.130 -j logdrop
iptables -I INPUT -s 93.120.27.62 -j logdrop
iptables -I INPUT -s 66.240.236.119 -j logdrop
iptables -I INPUT -s 71.6.135.131 -j logdrop
iptables -I INPUT -s 66.240.192.138 -j logdrop
iptables -I INPUT -s 71.6.167.142 -j logdrop
iptables -I INPUT -s 82.221.105.6 -j logdrop
iptables -I INPUT -s 82.221.105.7 -j logdrop
iptables -I INPUT -s 71.6.165.200 -j logdrop
 
Last edited:
iptables -I INPUT -s 198.20.69.74 -j logdrop
iptables -I INPUT -s 198.20.69.98 -j logdrop
iptables -I INPUT -s 198.20.70.114 -j logdrop
iptables -I INPUT -s 198.20.99.130 -j logdrop
iptables -I INPUT -s 93.120.27.62 -j logdrop
iptables -I INPUT -s 66.240.236.119 -j logdrop
iptables -I INPUT -s 71.6.135.131 -j logdrop
iptables -I INPUT -s 66.240.192.138 -j logdrop
iptables -I INPUT -s 71.6.167.142 -j logdrop
iptables -I INPUT -s 82.221.105.6 -j logdrop
iptables -I INPUT -s 82.221.105.7 -j logdrop
iptables -I INPUT -s 71.6.165.200 -j logdrop
If I see lots of similar IPs, rather than drop them individually, I do an IP Whois on it to discover the subnet and drop the whole subnet.

For example this will drop everything between 198.20.64.1 and 198.20.127.254:

iptables -I INPUT -s 198.20.64.0/18 -j logdrop
 
in the past i was just blocking single ip's
but have started blocking subnets now due to them popping up more

i have rebooted the router and the script is started on boot
but ip's in the block list are still connecting to pptp

It worked fine with single ip's
There must be a mistake somewhere

Code:
#!/bin/sh

logger -t $(basename $0) $1

iptables -I INPUT -s 42.156.250.0/24 -j drop
iptables -I INPUT -s 59.174.191.0/24 -j drop
iptables -I INPUT -s 60.186.109.0/24 -j drop
iptables -I INPUT -s 66.240.192.0/24 -j drop
iptables -I INPUT -s 66.240.236.0/24 -j drop
iptables -I INPUT -s 71.6.135.0/24 -j drop
iptables -I INPUT -s 71.6.165.0/24 -j drop
iptables -I INPUT -s 71.6.167.0/24 -j drop
iptables -I INPUT -s 82.221.105.0/24 -j drop
iptables -I INPUT -s 93.120.27.0/24 -j drop
iptables -I INPUT -s 101.16.240.0/24 -j drop
iptables -I INPUT -s 112.94.222.0/24 -j drop
iptables -I INPUT -s 112.193.89.0/24 -j drop
iptables -I INPUT -s 119.4.27.0/24 -j drop
iptables -I INPUT -s 123.117.168.0/24 -j drop
iptables -I INPUT -s 123.158.49.0/24 -j drop
iptables -I INPUT -s 153.0.57.0/24 -j drop
iptables -I INPUT -s 183.60.48.0/24 -j drop
iptables -I INPUT -s 193.138.154.0/24 -j drop
iptables -I INPUT -s 198.20.69.0/24 -j drop
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top