Greetings, Yet another strange pattern of traffic is being halted at the shorewall firewall, but I have no idea what this is. IANA shows the ports unassigned, and a net search yields only some of the same questions - what is this port? There are two machines as SOURCE, on the same class C network, adjacent, even, sending one connect attempt to TCP port 32230 every five minutes. I''m probably just going to add a drop rule without logging, but was curious if anyone knew what this traffic was attempting to connect to? An Nmap scan of my network shows no open ports anywhere near 32230. Obviously, the DST= address is changed to a ficticious one. I left the SRC= address unchanged. John Stroud Someday I''ll make a real sig. ----------------------------- May 16 16:54:56 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUTMAC=00:10:a4:8e:6d:df:00:a0:c5:44:55:75:08:00 SRC=216.177.89.29 DST=46.331.328.18 LEN=50 TOS=0x00 PREC=0x00 TTL=113 ID=18662 PROTO=UDP SPT=4690 DPT=32230 LEN=30 May 16 16:54:58 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUTMAC=00:10:a4:8e:6d:df:00:a0:c5:44:55:75:08:00 SRC=216.177.89.29 DST=46.331.328.18 LEN=50 TOS=0x00 PREC=0x00 TTL=113 ID=22609 PROTO=UDP SPT=1642 DPT=32230 LEN=30 May 16 16:59:56 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUTMAC=00:10:a4:8e:6d:df:00:a0:c5:44:55:75:08:00 SRC=216.177.89.30 DST=46.331.328.18 LEN=50 TOS=0x00 PREC=0x00 TTL=113 ID=6909 PROTO=UDP SPT=4365 DPT=32230 LEN=30 May 16 16:59:58 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUTMAC=00:10:a4:8e:6d:df:00:a0:c5:44:55:75:08:00 SRC=216.177.89.30 DST=46.331.328.18 LEN=50 TOS=0x00 PREC=0x00 TTL=113 ID=7394 PROTO=UDP SPT=4478 DPT=32230 LEN=30 Tracking #: 382A3F9313FD9448A05B302AE226F72F38F8735E
On 16 May 2002, John Stroud wrote:> > Yet another strange pattern of traffic is being halted at the shorewall > firewall, but I have no idea what this is. IANA shows the ports > unassigned, and a net search yields only some of the same questions - > what is this port?Probably the latest trojan -- it''s not yet listed at Simovitz though. Another problem I used to have when I had a semi-dynamic IP was game servers. My IP would be listed on a website somewhere as having a game server and I would get 1000s of UDP packets to the same port.> > There are two machines as SOURCE, on the same class C network, adjacent, > even, sending one connect attempt to TCP port 32230 every five minutes. >Sure looks like UDP 32230 to me.> I''m probably just going to add a drop rule without logging,I think I''d blacklist the class C but your choice.> but was curious if anyone knew what this traffic was attempting to > connect to? An Nmap scan of my network shows no open ports anywhere > near 32230. > > Obviously, the DST= address is changed to a ficticious one.But we all know what the real address is (give or take) -- I don''t know why people go to the effort of sanitizing things like this when SMTP headers tell all in 99% of cases. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Thu, 2002-05-16 at 17:53, Tom Eastep wrote:> On 16 May 2002, John Stroud wrote: > > > > Yet another strange pattern of traffic is being halted at the shorewall > > firewall, but I have no idea what this is. IANA shows the ports > > unassigned, and a net search yields only some of the same questions - > > what is this port? > > Probably the latest trojan -- it''s not yet listed at Simovitz though. > Another problem I used to have when I had a semi-dynamic IP was game > servers. My IP would be listed on a website somewhere as having a game > server and I would get 1000s of UDP packets to the same port. > > > > > There are two machines as SOURCE, on the same class C network, adjacent, > > even, sending one connect attempt to TCP port 32230 every five minutes. > > > > Sure looks like UDP 32230 to me.Oops, absolutely right. Brain needs more caffeine. UDP it is, but still no info. I find reports on various security sites that show it appearing near the end of 2001, yet very little info. So maybe gaming is the answer.> > > I''m probably just going to add a drop rule without logging, > > I think I''d blacklist the class C but your choice.Excellent idea. Easiest way to drop....> > > but was curious if anyone knew what this traffic was attempting to > > connect to? An Nmap scan of my network shows no open ports anywhere > > near 32230. > > > > Obviously, the DST= address is changed to a ficticious one. > > But we all know what the real address is (give or take) -- I don''t know > why people go to the effort of sanitizing things like this when SMTP > headers tell all in 99% of cases.Because this list is duplicated elsewhere, without the headers. Overly paranoid, but then that doesn''t mean someone isn''t out to get me. <g> Thanks again! John Stroud> > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@shorewall.net > http://www.shorewall.net/mailman/listinfo/shorewall-usersTracking #: AE27DBC1AE49A84A8D18E2C9B322CDBF2A9239EB
John Stroud
2002-May-17 01:51 UTC
[Shorewall-users] Yet another question, more on topic...
OK, when it rains, it pours....Another question rears itself in the form of.. I have a simple two-interface network, eth0 on the internet, masq/nat on the internal. Everything pretty much works fine, and has been for some time. However, something new I''m seeing is a certain ISP''s SMTP server is unable to connect with mine. The SMTP server is also the shorewall box (I know, I know)... 99% of the email gets through - just their packets are dropped in the net2all chain, despite an explicit (and working) rule to: ACCEPT net loc:internalnataddress tcp smtp - mailserverpublicipaddress Also, I have the machine natted statically, but since the DST= the internal address, I assume that''s working. I know the nat rules apply before the port forwards, but removing the port forward changes nothing. The packets still log as: May 16 16:09:04 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUT=eth1 SRC=216.254.0.211 DST=192.168.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=43374 DF PROTO=TCP SPT=33420 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 Again, this host/net provied the only drops I see for DPT=25. Looking through the archives, I wondered if this could be related to the tcp_ecn thing. Thoughts? John Stroud Someday I''ll make a real sig Tracking #: 194A5273B3332744894535DD462FB989EFD40E7C
On 16 May 2002, John Stroud wrote:> OK, when it rains, it pours....Another question rears itself in the form > of.. > > However, something new I''m seeing is a certain ISP''s SMTP server is > unable to connect with mine. The SMTP server is also the shorewall box > (I know, I know)... 99% of the email gets through - just their packets > are dropped in the net2all chain, despite an explicit (and working) rule > to: > ACCEPT net loc:internalnataddress tcp smtp - mailserverpublicipaddress >If you run your SMTP server on the Shorewall box then why are you port forwarding? I''m clearly missing something...> Also, I have the machine natted statically, but since the DST= the > internal address, I assume that''s working.If 192.168.0.2 is the SMTP server''s IP (again, I''m confused about your statement above), and <the external SMTP IP> is associated with that address in /etc/shorewall/nat then yes.> I know the nat rules apply before the port forwards, but removing the > port forward changes nothing. The packets still log as: > > May 16 16:09:04 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUT=eth1 > SRC=216.254.0.211 DST=192.168.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=50 > ID=43374 DF PROTO=TCP SPT=33420 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 >Since the packet was dropped in ''net2all'' (filter table), NAT/de-MASQ/ has been applied.> Again, this host/net provied the only drops I see for DPT=25. > > Looking through the archives, I wondered if this could be related to the > tcp_ecn thing. Thoughts? >If ECN was dropping it, then you wouldn''t be seeing the ''Shorewall'' log messages. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
I have several hits from this pair of IPs as well and my friend was getting thousands of them per day. All of our hits were on different ports. Arin lists it as being a block of ips on the westcoast belonging to Exodus. We did some poking around and discovered that they appear to be part of the internet Gamespy system for finding gaming partners for hundreds of different games on the web. Each time we were hit by these messages was shortly after having done something on gamespy. I have no idea why their servers are so unruley but .. Steve ----- Original Message ----- From: "John Stroud" <bear@amberorder.com> To: "Shorewall List" <shorewall-users@shorewall.net> Sent: Thursday, May 16, 2002 8:17 PM Subject: [Shorewall-users] Port 32230 anyone?> Greetings, > > Yet another strange pattern of traffic is being halted at the shorewall > firewall, but I have no idea what this is. IANA shows the ports > unassigned, and a net search yields only some of the same questions - > what is this port? > > There are two machines as SOURCE, on the same class C network, adjacent, > even, sending one connect attempt to TCP port 32230 every five minutes. > > I''m probably just going to add a drop rule without logging, but was > curious if anyone knew what this traffic was attempting to connect to? > An Nmap scan of my network shows no open ports anywhere near 32230. > > Obviously, the DST= address is changed to a ficticious one. I left the > SRC= address unchanged. > > John Stroud > Someday I''ll make a real sig. > > ----------------------------- > > May 16 16:54:56 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUT> MAC=00:10:a4:8e:6d:df:00:a0:c5:44:55:75:08:00 SRC=216.177.89.29 > DST=46.331.328.18 LEN=50 TOS=0x00 PREC=0x00 TTL=113 ID=18662 PROTO=UDP > SPT=4690 DPT=32230 LEN=30 > > May 16 16:54:58 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUT> MAC=00:10:a4:8e:6d:df:00:a0:c5:44:55:75:08:00 SRC=216.177.89.29 > DST=46.331.328.18 LEN=50 TOS=0x00 PREC=0x00 TTL=113 ID=22609 PROTO=UDP > SPT=1642 DPT=32230 LEN=30 > > May 16 16:59:56 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUT> MAC=00:10:a4:8e:6d:df:00:a0:c5:44:55:75:08:00 SRC=216.177.89.30 > DST=46.331.328.18 LEN=50 TOS=0x00 PREC=0x00 TTL=113 ID=6909 PROTO=UDP > SPT=4365 DPT=32230 LEN=30 > > May 16 16:59:58 cave kernel: Shorewall:net2all:DROP:IN=eth0 OUT> MAC=00:10:a4:8e:6d:df:00:a0:c5:44:55:75:08:00 SRC=216.177.89.30 > DST=46.331.328.18 LEN=50 TOS=0x00 PREC=0x00 TTL=113 ID=7394 PROTO=UDP > SPT=4478 DPT=32230 LEN=30 > > > > Tracking #: 382A3F9313FD9448A05B302AE226F72F38F8735E > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@shorewall.net > http://www.shorewall.net/mailman/listinfo/shorewall-users