Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Troublesome PIX Syslog entries *Please Help!*

Status
Not open for further replies.

chucksel

IS-IT--Management
Sep 13, 2002
38
US
Hi Fellows!

Hello, my PIX syslog is getting bombarded by these entries (several per minute). I have tried to ping and tracert this IP address with no success. I have no VPN users active so I do not suspect that they are connected and trying to use the network as a default gateway. My internal network is a 10.X.X.X /16 . It looks like this IP is trying to use ICMP to ping the outside address of 155.195.86.68 .

Any ideas on how to track this guy down?


Feb 06 2003 12:12:32: %PIX-3-305005: No translation group found for icmp src inside:192.209.110.62 dst outside:155.195.86.68 (type 0, code 0)

This Syslog server is a new setup but the PIX has been implemented for quite some time.

Thanks for the help!

chucksel@hotmail.com Chuck, MCSE
 
HI.

This is strange because the source is "inside".
ICMP type 0 is echo-reply.
These could be actual replies to echo-request, or some kind of attack.
For example some trojan horses running on client computers, are waiting for echo-reply message from the attackers host, to be activate and start a remote control session.
Such echo-reply messages will not have associated echo-request.

I would try this at the pix:
logging trap 4 (warnings)
ip audit name info1 info action alarm
ip audit name attack1 attack action alarm drop reset
ip audit interface outside info1
ip audit interface outside attack1
ip audit interface inside info1
ip audit interface inside attack1

Now you'll see in the logs any ICMP activity (any ICMP packet is considered as "info" by the pix ids engine), and you'll have more info to work with.

Bye
Yizhar Hurwitz
 
Ahhhhhhhhh. Of course! I will turn on auditing of IDS feature of the PIX, Good idea,

Thanks, Yizhar! Chuck, MCSE
 
Hi Yizhar,

Now that I have logged some IDS info, take a look-see.


Feb 07 2003 09:13:12: %PIX-4-400011: IDS:2001 ICMP unreachable from 129.250.10.90 to 10.100.5.28 on interface outside

M:\>ping -a 10.100.5.28

Pinging RUGGIERO [10.100.5.28] with 32 bytes of data:

Reply from 10.100.5.28: bytes=32 time<10ms TTL=128

I hunted down this wrkstn and it was running the latest definition/virus pattern of Trend's OfficeScan so I started a network security scan on it. I'll keep you posted.

Feb 07 2003 09:15:52: %PIX-4-400010: IDS:2000 ICMP echo reply from 192.209.110.46 to 155.195.86.68 on interface inside

Feb 07 2003 09:16:49: %PIX-4-400011: IDS:2001 ICMP unreachable from 67.105.62.10 to 10.100.2.2 on interface outside

Feb 07 2003 09:18:52: %PIX-4-400010: IDS:2000 ICMP echo reply from 192.209.110.46 to 155.195.86.68 on interface inside

Feb 07 2003 09:20:07: %PIX-4-400011: IDS:2001 ICMP unreachable from 10.100.2.10 to 67.17.215.132 on interface inside

Feb 07 2003 09:20:37: %PIX-4-400011: IDS:2001 ICMP unreachable from 67.X.242.254 to 10.100.2.8 on interface outside

(67.X.242.254 - this is my perimiter/internet router. 10.100.2.8 - this is my workstation)

Feb 07 2003 09:20:50: %PIX-4-400010: IDS:2000 ICMP echo reply from 192.209.110.62 to 155.195.86.68 on interface inside

(this one I am concerned about - happens frequently)

Feb 07 2003 09:20:53: %PIX-4-400010: IDS:2000 ICMP echo reply from 192.209.110.46 to 155.195.86.68 on interface inside

(notice that the last octet is slightly different from the above msg.... .46 versus .62)

Feb 07 2003 09:42:25: %PIX-4-400011: IDS:2001 ICMP unreachable from 64.14.67.246 to 10.100.5.54 on interface outside

(again, this .54 is an internal wrkstn)


I'll let you know what else I find.


Chuck, MCSE
 
HI.

Please provide more details about your network.
Any dial-up RAS connections (inbound or outbound)?
Any WAN links to other networks?

Take a look here:
Both addresses belong to RADIANZ which is interesting.
You might wish to contact the RADIANZ or Citibank - Washington DC QUOTRON-LAN47 network administrators to investigate further.

It seems like an attack which could mean that:
* A person in your organization has decided to be the greatest hacker in the world.
* A host in your network has been taken control of, and now is running a trojan horse or something for DOS attack of another organization.

How many internal hosts in your network?
Do you have RAS dial-in connections (inbound or outbound)?
Do you have WAN links to other organizations?

Getting your hands on that host could be dificult since the source ip is probably spoofed.
I'm not experiences with such cases, but I would try some of the following tools for investigation:
Use common sense - you probably have some ideas on where to look for the problem. Do you?
Check all servers first before going to workstations.
Visit the networking room at off-working hours. Simply look at the switch, and focus on ports that blink more then others... At those hours you can also try to simply disconnect some cables until you see that the activity is stopped.
Use a network monitoring device to get more info, for example MAC address of the host sending those packets.
An IDS oriented software/device can do it better.
If you have internal WAN routers, try to use &quot;ip accounting&quot; or some other logging method, and look for the 192.209.110.62 source ip. You can also create an access-list on those routers to block (or permit) ICMP destined to
155.195.86.68 and use the &quot;log&quot; parameter to catch that activity.

Take a look at the output of the pix command:
show conn
And look for suspicious port numbers, long duration or other abnormal activity.

> ... I have no VPN users active ...
Are you sure?
Carefuly check all remote connections and entry points to your network.

Anyway, keep us informed as you do - and good luck.

Bye
Yizhar Hurwitz
 
Another idea:

Ask/check the accounting department.
Is any host there connected to the RadianzNet extranet?
It could be getting those addresses from a VPN or dial-up session to that network, and a misconfiguration could cause it to route some traffic via the pix instead of the VPN connection.

Bye

Yizhar Hurwitz
 
Hello,

Well, I contacted all the vendors who provide data services to our company who have routers on our internal network and asked them if any of those IP addresses belonged to them. Guess what? Radianz is a data provider for a few of our vendors. After contacting each one, I found someone who could tell me it belonged to them. So......they opened up a trouble ticket to find out why the router is trying to send packets through my PIX. At least I am on my way to figuring this out. Chuck, MCSE
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top