Bitcoin connections connecting from weird ports?

[Chick]

I looked in /var/log/syslog and found these IPTable lines.

Code:

iptables denied: IN=eth0 OUT= MAC=XXX SRC=XXX DST=XXX LEN=393 TOS=0x00 PREC=0x00 TTL=41 ID=29239 PROTO=ICMP TYPE=3 CODE=1 [SRC=173.255.204.204 DST=84.137.1.104 LEN=365 TOS=0x00 PREC=0x00 TTL=48 ID=49502 DF PROTO=TCP SPT=8333 DPT=51347 WINDOW=792 RES=0x00 ACK PSH URGP=0 ]
iptables denied: IN=eth0 OUT= MAC=XXX SRC=XXX DST=XXX LEN=393 TOS=0x00 PREC=0x00 TTL=41 ID=29240 PROTO=ICMP TYPE=3 CODE=1 [SRC=173.255.204.204 DST=84.137.1.104 LEN=365 TOS=0x00 PREC=0x00 TTL=48 ID=49503 DF PROTO=TCP SPT=8333 DPT=51347 WINDOW=792 RES=0x00 ACK PSH URGP=0 ]
iptables denied: IN=eth0 OUT= MAC=XXX SRC=XXX DST=XXX LEN=40 TOS=0x00 PREC=0x00 TTL=98 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0
iptables denied: IN=eth0 OUT= MAC=XXX SRC=XXX DST=XXX LEN=435 TOS=0x00 PREC=0x00 TTL=41 ID=0 DF PROTO=UDP SPT=5060 DPT=5060 LEN=415
iptables denied: IN=eth0 OUT= MAC=XXX SRC=XXX DST=XXX LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=22132 PROTO=TCP SPT=80 DPT=21921 WINDOW=16384 RES=0x00 ACK SYN URGP=0
iptables denied: IN=eth0 OUT= MAC=XXX SRC=XXX DST=XXX LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=23617 PROTO=TCP SPT=80 DPT=21921 WINDOW=16384 RES=0x00 ACK SYN URGP=0
iptables denied: IN=eth0 OUT= MAC=XXX SRC=XXX DST=XXX LEN=40 TOS=0x00 PREC=0x00 TTL=98 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0

How could this be happening? These connections must have came from other Bitcoin nodes because this is an dedicated IP and bitcoind is the only thing running on the system. However, doesn't Bitcoin only use ports 8333 and 8332? Why are other nodes connecting to other ports on my system?

Here is my `bitcoin.conf`:

Code:

rpctimeout=30
rpcallowip=XXX
rpcallowip=XXX
rpcport=8332

# OpenSSL Settings
rpcssl=1
rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH
rpcsslcertificatechainfile=server.cert
rpcsslprivatekeyfile=server.pem

# Firewall

noupnp=1

[CERN]

The first two lines are ICMP "destination unreachable" messages, which are usually sent to you by a router to inform your computer that something you've sent out was unable to find the destination.  This is completely normal, and it's A Good Thing, part of how networking works.

You should probably allow ICMP destination unreachable messages through (research iptables limits to throttle them to something like 10 / minute), else you'll find that some internet applications (web browsers, etc) will just stall for long stints of time while waiting for a reply to some outbound request to certain things

The third and last lines are to TCP port 1433 which, IIRC (I feel confident) belongs to Microsoft SQL Server.  This would likely be hackers/script kiddies/etc on your network or on the internet attempting to scan your computer to see if you have Microsoft SQL Server running so that they can try to brute force a password or exploit some vulnerability to take over your system.  This is completely normal - any computer connected to the internet will have people trying to connect to random ports.

Actually, every failed connection attempt in that log (sans the two ICMP type 3 packets) probably falls into the latter case.  It doesn't matter what services you run; as long as your computer is connected to the internet, you will be receiving connection attempts to just about every common service port in existence, perhaps even thousands a day (as is the case with one of my servers)

That is why iptables implements state management, etc.    My suggestion for you is to use DROP instead of REJECT when building your ruleset

[Chick]

The first two lines are ICMP "destination unreachable" messages, which are usually sent to you by a router to inform your computer that something you've sent out was unable to find the destination.  This is completely normal, and it's A Good Thing, part of how networking works.

You should probably allow ICMP destination unreachable messages through (research iptables limits to throttle them to something like 10 / minute), else you'll find that some internet applications (web browsers, etc) will just stall for long stints of time while waiting for a reply to some outbound request to certain things

The third and last lines are to TCP port 1433 which, IIRC (I feel confident) belongs to Microsoft SQL Server.  This would likely be hackers/script kiddies/etc on your network or on the internet attempting to scan your computer to see if you have Microsoft SQL Server running so that they can try to brute force a password or exploit some vulnerability to take over your system.  This is completely normal - any computer connected to the internet will have people trying to connect to random ports.

Actually, every failed connection attempt in that log (sans the two ICMP type 3 packets) probably falls into the latter case.  It doesn't matter what services you run; as long as your computer is connected to the internet, you will be receiving connection attempts to just about every common service port in existence, perhaps even thousands a day (as is the case with one of my servers)

That is why iptables implements state management, etc.    My suggestion for you is to use DROP instead of REJECT when building your ruleset

Thanks for the helpful information!

I have INPUT dropped, OUTPUT allowed, and FORWARD rejected.

If I enable UPnP, will Bitcoin use other ports as well?