This document describes a system that uses a portable remote security device and wiki software to help network administrators monitor for and respond to malicious bots within protected sub-LAN networks. The remote security device can monitor network traffic, filter malicious packets, and intercept and forward suspicious traffic to aid in identifying compromised hosts. The central network manager controls the device using commands written on a wiki page, allowing them to remotely monitor sub-LANs and work with local managers to quickly identify and remove malicious bots.

1. Capturing Malicious Bots
Using a Beneficial Bot and
Wiki
Takashi Yamanoue, Kentaro Oda,
Koichi Shimozono
Kagoshima University

2. Contents
• Introduction
• Implementation
• Usage Example
• Related Research
• Concluding Remarks

3. Introduction
• A bot
– runs automated tasks over the Internet.
– usually a malicious application
– controlled by a malicious herder
• Herder
– the master of the bot

4. Introduction
• Many resent viruses
• are used for recruiting a host into a botnet
– Botnet
• is a collection of malicious bots.
– Malicious bots - in a campus LAN
• Leak private information of students,
research secrets
• spam other people
• attack other web sites via DDos.

5. Introduction
• A campus with malicious
bots
– may be considered to be
engaging in criminal activity.

6. Introduction
• The manager of the campus LAN
– has to be careful about malicious bots and
remove the bot quickly when found

7. Introduction
• A fire-wall
and a Network Address Translation (NAT)
– enhance network security of a LAN.

8. Introduction
• NAT or fire-wall
– defend the LAN against
intrusion of a malicious bot.
– like a house protected
by a door with a key.
– Only permitted IP packets may pass through
the fire-wall or the NAT
– much like only people who have the key may
pass through the door of the house.

9. Introduction

10. Introduction
• When a host in the sub-LAN is
compromized by a malicous bot
– it is hard to identify the compromized host
from the outside of the LAN, much like it is
hard to find a robber who is hidden in the
house or the building.
– DHCP and IPv6 with privacy address
extension (RFC 3041) also make it difficult
– the IP address is changed dynamically.

11. Introduction

12. Introduction
• A campus’s LAN
– a central network infrastructure + sub-LANs.
• Some sub-LANs
– may be protected by a fire-wall or a NAT.
Sub-
The Internet
LAN
Sub-
LAN
Sub-
Central Network Infrastructure LAN

13. Introduction
• Network managers sometimes have to
find out bots which are hidden in such
protected sub-LANs.

14. Introduction
• One way to realize this is to prohibit use
of a fire-wall or a NAT for a sub-LAN.

15. Introduction
• It is easy to define the rule, but unrealistic
because broadband routers with fire-wall
or NAT function are so common.
Laws are made to be
broken

16. Introduction
• When malicious communication between
a bot in a protected sub-LAN and another
?
host on the outside is discovered by the
manager of the central network
infrastructure (or the central manager),
? ?
?

17. Introduction
• the central manager usually directs the
manager of the sub-LAN to disconnect
the sub-LAN from the central network
infrastructure immediately.
? ?
?

18. Introduction
• The sub-manager inspects all PCs in the
sub-LAN using anti-virus software.
? ?
?

19. Introduction
• Cannot always find the bot because
– anti-virus software can not find 0-day attacks,
– the central manager can not observe the
malicious communication in the sub-LAN.
? ?
?

20. Introduction
• Sometimes, the central manager would
like to monitor sub-LANs in order to find
the compromized host. The compromized
host should be found as quickly as
possible.

21. Introduction
• The central manager can monitor the
sub-LAN by re-configuring the LAN.
?

22. Introduction
• However such re-configuration without
care may cause serious trouble. Ex.
Loop
– Such re-configuration usually takes a long
time.

23. Introduction
• The manager should
have an easy and fast
way to monitor and
control sub-LANs.

24. Introduction
• We have made a network security
controlling system which uses
– a remote security device and
– a web site with wiki software.
(PukiWiki)

25. Introduction
• The device can be deployed fast and
easily because it is portable.

26. Introduction
• The central manager can monitor and
control the sub-LAN behind a fire-wall or
a NAT easily from a web site with
common wiki software, using the remote
security device.

27. Introduction

28. Introduction
• The remote security device is a kind of
bot which is controlled by the central
manager.

29. Introduction
• The device can do the following:
– Monitor traffic between hosts in the sub-LAN
and outside hosts.
– Filter out malicious packets of the traffic.

30. Introduction
– Intercept DNS query packets from the
suspicious host and return the IP address of
the fake host which pretends the herder’s
host.
– Pretend the herder’s host such like returning
the fake syn-ack packet to the syn packet
from the suspicious host.

31. Introduction
Fire-Wall
IDS
The Internet
Organization’s
Central Network The Wiki Site
Infrastructure Portable Remote
Security Device
NAT or Router
Original
Connection This Security Controlling System
Virus Infected Host
Sub-LAN
Auxiliary Switch
Auxiliary Wi-fi AP

32. Implementation
Portable
Remote
Security Device

33. Implementation

34. • Filter/Controller
– If the packet matches up to a “select pattern”,
• pass through the packet (from one DAQ to
another DAQ) and
• send the information of the frame of the packet to
the wiki access engine with the status.
– If the packet matches up to a “drop pattern”,
• do not pass through the packet and send the
information of the frame of the packet to the wiki
access engin with the status.

35. – If the packet matches up to a “forward pattern”,
• replace the destination IP address and destination
port with the IP address and port of a pseudo
application of a pseudo host, and pass the replaced
packet to another DAQ.
• Send the information of the frame of the original
packet to the wiki access engine with the status.

36. – Sends a packet to one of the bridges from
one of the DAQs. The sending packet is one
of the following.
• The pseudo syn-ack packet to a syn packet of
dropped packets.
• The pseudo DNS answer packet to a DNS query
packet.

37. Implementation

38. Usage Example
Booting and Setting

39. Usage Example
Booting and Setting

40. Usage Example
Booting and Setting

41. Usage Example
Booting and Setting

42. Usage Example
Monitoring and
Controlling
Click here, and here

43. Usage Example
Monitoring and
Controlling

44. Usage Example
Monitoring and
Controlling

45. Usage Example
Commands and Results
• get ip=<IP address>
• get startsWith <String constant>
– Ex. “PING”, “PONG”, “NIC” , “USER” for IRC.
• lan2wan drop ip=<IP address>
• wan2lan drop ip=<IP address>

46. Usage Example
Commands and Results
• lan2wan return-syn-ack ip=<IP address>
• lan2wan forward ip=<IP address 1>
to <IP address2>:<Port>
• lan2wan dns-intercept ip=<IP address 1>
to <IP address 2>

47. Usage Example
Commands and Results

48. Usage Example
Responding Infection
• The central manager identifies the
suspicious sub-LAN by using an IDS or a
firewall or managed security monitoring
service.
? ?
?

49. Usage Example
Responding Infection
• The central manager asks the sub-
manager of the sub-LAN to disconnect
the NAT or router of the sub-LAN from
the central network infrastructure.
? ?
?

50. Usage Example
Responding Infection
• The central manager writes commands
on the wiki page to capture and filter out
the suspicious packets. The manager
configures the remote security device to
connect the device to the wiki page.

51. Usage Example
Responding Infection
• The central manager sends the portable
sensor device to the sub-manager
– after the sub-manager agrees with the need
for identifying the suspicious host.
• The sub-manager connects the remote
security device to the sub-LAN and starts
it.
?

52. Usage Example
Responding Infection
• The remote security device reads the
commands on the wiki page periodically.
• When the device detects suspicious
packets, the device drop the packets and
writes information of the packets with the
MAC address of the suspicious host in
the sub-LAN on the wiki page.
?

53. Usage Example
Responding Infection
• The central manager confirms the
information of the suspicious packets on
the wiki page, and if the manager judges
the packets to be malicious,
• the central manager asks the sub-
manager to disconnect the host from that
sub-LAN.

54. Usage Example
Responding Infection
• If the central manager feels more deep
analysis on the traffic, the manager can
prepare a telnet server and s/he can write
commands for forwarding the packets
from the suspicious host to the telnet
server on the wiki page.

55. Usage Example
Responding Infection
• When a suspicious packet is forwarded to
the telnet server, the central manager can
see the contents of the packet and can
response to the packet on the telnet
server.

56. Usage Example
Responding Infection
• When the sub-manager cannot identify
the suspicious host, the central manager
writes the command, which transfers
packets from the host to a notification
web server, on the wiki page.
?

57. Usage Example
Responding Infection
• The notification web server
– notifies the user of the suspicious host that
the host is suspicious and asks the user of
the host to call the sub-manager.
• The sub-manager
– disconnects the suspicious host,

58. Usage Example
Responding Infection

59. Related research
• Security Monitoring System
• Snort
• Observing MAC address at the WAN side
• Unix device with two NICs
• KASEYA and UNIFAS

60. Concluding Remarks
• Bot for Bot
• An Easy way of incident response
• Wiki
• Not so stable now for real using
– Hope to have your support, assistant, ..
– https://github.com/takashiyamanoue/TrafficC
ontroller
• Should not turn into dark side.

61. • Masato Masuya, Takashi Yamanoue,
Shinichiro Kubota
"An Experience of Monitoring University
Network Security Using a Commercial
Service and DIY Monitoring" ,
Proceedings of the 34nd annual ACM
SIGUCCS conference on User services,
pp.225-230, Edmonton, Alberta, Canada.
5-8 Nov. 2006.