Protocol 61: Anybody got packets? - Internet Security

Protocol 61: Anybody got packets?
Jason is writing us saying that his firewall is dropping 600-700 packets per second with protocol 61 (not port 61). He hasn't been able to capture full packets but is working on it. This looks very much like a corrupt packet, maybe as a result of a DoS upstream, or a broken attack tools. If anybody sees something similar, please let us know (and we really like full packets) The source IP addresses are 2.2.128.1 and 5.5.128.1 (again, odd addresses... ) Here are some anonymized firewall logs from Jason: 2013-04-12 00:00:00 firewall %ASA-3-106010: Deny inbound protocol 61 src outside:2.2.128.1 dst outside:xxx.xxx.xx6.1 2013-04-12 00:00:00 firewall %ASA-3-106010: Deny inbound protocol 61 src outside:5.5.128.1 dst outside:xxx.xxx.xx6.1 2013-04-12 00:00:00 firewall %ASA-3-106010: Deny inbound protocol 61 src outside:2.2.128.1 dst outside:xxx.xxx.xx8.1 2013-04-12 00:00:00 firewall %ASA-3-106010: Deny inbound protocol 61 src outside:5.5.128.1 dst outside:xxx.xxx.xx8.1 ------ Johannes B. Ullrich, Ph.D. SANS Technology Institute Twitter I will be teaching next: Intrusion Detection In-Depth - SANS Boston Summer 2019	Johannes 3574 Posts ISC Handler
Subscribe	Apr 13th 2013 6 years ago
Whois Details on IP address 2.2.128.1 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2.2.128.0 - 2.2.128.255' inetnum: 2.2.128.0 - 2.2.128.255 netname: IP2000-ADSL-BAS descr: BSREN651 Rennes Bloc 2 country: FR admin-c: WITR1-RIPE tech-c: WITR1-RIPE status: ASSIGNED PA remarks: for hacking, spamming or security problems send mail to remarks: abuse@orange.fr mnt-by: FT-BRX source: RIPE # Filtered % Information related to '2.2.0.0/16AS3215' route: 2.2.0.0/16 descr: France Telecom Orange origin: AS3215 mnt-by: RAIN-TRANSPAC mnt-by: FT-BRX source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.55 (WHOIS3)	Anonymous
Quote	Apr 13th 2013 6 years ago
I have exactly the same, now for the 3rd or 4th time. Pretty unclear what this should be my guess after discussion with our upstram ISP's NOC was that there is something broken. The packets seem not to be spoofed and typically it lasts a week or so. PCAP is available.	Jens 42 Posts
Quote	Apr 13th 2013 6 years ago
Protocol 61 isn't defined by RFC or other such standards convention. It is intended to be used for internal (i.e. private) application conversations and functionality. The probes would seem to suggest testing for responsiveness of private applications that are published beyond the firewall boundary. If this is the case, the probe behavior would seem to be particularly relevant to those entities who develop custom applications.	VB33 6 Posts
Quote	Apr 14th 2013 6 years ago

Jason is writing us saying that his firewall is dropping 600-700 packets per second with protocol 61 (not port 61). He hasn't been able to capture full packets but is working on it.

This looks very much like a corrupt packet, maybe as a result of a DoS upstream, or a broken attack tools. If anybody sees something similar, please let us know (and we really like full packets)

The source IP addresses are 2.2.128.1 and 5.5.128.1 (again, odd addresses... )

Here are some anonymized firewall logs from Jason:

	2013-04-12 00:00:00 firewall %ASA-3-106010: Deny inbound protocol 61 src outside:2.2.128.1 dst outside:xxx.xxx.xx6.1
	2013-04-12 00:00:00 firewall %ASA-3-106010: Deny inbound protocol 61 src outside:5.5.128.1 dst outside:xxx.xxx.xx6.1
	2013-04-12 00:00:00 firewall %ASA-3-106010: Deny inbound protocol 61 src outside:2.2.128.1 dst outside:xxx.xxx.xx8.1
	2013-04-12 00:00:00 firewall %ASA-3-106010: Deny inbound protocol 61 src outside:5.5.128.1 dst outside:xxx.xxx.xx8.1

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

I will be teaching next: Intrusion Detection In-Depth - SANS Boston Summer 2019

Johannes

3574 Posts
ISC Handler

Whois

Details on IP address 2.2.128.1

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '2.2.128.0 - 2.2.128.255'

inetnum: 2.2.128.0 - 2.2.128.255
netname: IP2000-ADSL-BAS
descr: BSREN651 Rennes Bloc 2
country: FR
admin-c: WITR1-RIPE
tech-c: WITR1-RIPE
status: ASSIGNED PA
remarks: for hacking, spamming or security problems send mail to
remarks: abuse@orange.fr
mnt-by: FT-BRX
source: RIPE # Filtered

% Information related to '2.2.0.0/16AS3215'

route: 2.2.0.0/16
descr: France Telecom Orange
origin: AS3215
mnt-by: RAIN-TRANSPAC
mnt-by: FT-BRX
source: RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.55 (WHOIS3)

Anonymous

I have exactly the same, now for the 3rd or 4th time. Pretty unclear what this should be my guess after discussion with our upstram ISP's NOC was that there is something broken.
The packets seem not to be spoofed and typically it lasts a week or so. PCAP is available.

Jens

42 Posts

Protocol 61 isn't defined by RFC or other such standards convention. It is intended to be used for internal (i.e. private) application conversations and functionality. The probes would seem to suggest testing for responsiveness of private applications that are published beyond the firewall boundary. If this is the case, the probe behavior would seem to be particularly relevant to those entities who develop custom applications.

VB33

6 Posts