Week One — Setting Up Host & Firewall Logs - matthewlaujh/itpnyu-understandingnetworks GitHub Wiki
Set Up An Internet Host
During this semester we’ll do a number of exercises on the internet. To do these in a consistent way, we’ll all set up linux-based internet host with a public IP address. Since Linux is the most common operating system for internet-based applications, it will benefit us all to work on the same system.
A host is simply a computer system attached to the internet. It could be a single physical device running its own operating system, or it could be a virtual instance of an operating system, hosted along with many other instances on a computer elsewhere in the world. All hosts on the internet have IP addresses, either public or private. Having a public IP address means that the system can be reached from other computer systems on the internet directly. For class purposes, it will be most convenient if you use a hosting service. Several of the class examples reference Digital Ocean hosting, but you can use Heroku, Dreamhost, AWS, or any service you prefer.
Here are the properties your host should have:
A public IP address
Administrative control (ability to run sudo)
The ability to start up and shut down yourself (i.e. don’t use a shared host)
Secure shell (ssh) access
The ability to run for days or weeks at a time without interruption
There are instructions on setting up a virtual host on Digital Ocean on the ITP networks site. Make sure your host has a firewall in place, and note the IP address. You’ll use this throughout the semester for some of the other projects. Early on, we’ll all use our hosts to run some simple command line exercises and to pass some messages around the class.
Host set up!
Having taken Connected Devices last semester, I already have Digital Ocean set up and just created a new project and droplet for this class.
The first droplet I created for the assignment —
The second droplet I created for the assignment —
ifconfig:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 161.35.13.241 netmask 255.255.240.0 broadcast 161.35.15.255
inet6 fe80::9403:f7ff:fec1:131d prefixlen 64 scopeid 0x20<link>
ether 96:03:f7:c1:13:1d txqueuelen 1000 (Ethernet)
RX packets 14450 bytes 191016985 (191.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 13158 bytes 1404247 (1.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.116.0.3 netmask 255.255.240.0 broadcast 10.116.15.255
inet6 fe80::7cb9:68ff:fe77:649b prefixlen 64 scopeid 0x20<link>
ether 7e:b9:68:77:64:9b txqueuelen 1000 (Ethernet)
RX packets 12 bytes 916 (916.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 64 bytes 3316 (3.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 306 bytes 30261 (30.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 306 bytes 30261 (30.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Analyze Your Firewall Logs
Run your Linux host for several days, with a firewall in place and a public IP address. Make a table of all the IP addresses that attempt to connect to your host. Compile information about them. Here’s a video about firewall logs.
How many different attempts were there to connect to your server?
How different IP addresses attempted to connect to your server?
How many times did each IP address attempt to connect?
Where are they located? You can look them up on ipinfo.io and other geoIP services.
What organizations are they associated with, at all (whois and nslookup can help determine this)?
What service providers are providing their IP addresses?
Are there specific times of day that are most common for activity?
Are there IP addresses which return at regular times?
Write a summary of your work and findings on your blog.
Firewall logs!
Had some issues with the first server I created, I started it and went through the tutorials for it but it did not have a ufw.log file, so I had created one just by making the file, but it wasn't writing to it, but I looked it up and i could find some details through syslog, but it was a mess and had a mix of other stuff and UFW Audit and it was just hard to sift through and find the IP addresses that the ufw actually blocked link here for some results. So I decided to start a new droplet and follow the instructions from the start again, this time it worked, I must've forgotten to reboot the droplet, I feel like I did it the first time, but I might be wrong, I probably am wrong. But the second time now it has the ufw.log and it's a lot easier to work with. Unfortunately, it's Tuesday night now, so I won't leave it to run for too long before looking at results (sorry! should've checked earlier, I did the first server over the weekend and left it till today)
So in between the time it took for me to setup the server and firewall I got about 33 hits and in between the time it took for me to cook some dinner and type the first part of this blog it had an additional 139 hits within the last 30 minutes? But moving on — one look at the results and I saw this IP address pop up quite consistently "9.110.62.61" — did a wc -l on it and it tried to access it 26 times in just about an hour?
Tried to get the log to copy over to sheets but something seems to be wrong with the tabbing and I couldn't quite get it to be as neat as in the demo — Link to spreadsheet here. But also the details that I got were similar but it also looked different from the demo. Not quite sure what's going on here. But for the exercise I will look up ""9.110.62.61" for now.
Ok kinda interesting it says it's IBM and American Registry for Internet Numbers. That's interesting, are they trying to ping it cause it's a new server? Quick google search didn't really answer the question but I asked ChatGPT and Claude and they gave these answers:
Claude:
Routine network monitoring: Large corporations like IBM often perform regular network checks across the internet.
Security scanning: They might be running automated security scans, which sometimes include ping sweeps.
Misconfigured systems: An IBM system or network could be misconfigured, leading to unintended pings.
Research or testing: IBM might be conducting network research or testing that involves sending pings to various servers.
Compromised systems: In rare cases, a compromised system within IBM's network could be used for malicious scanning.
False positives: Your monitoring system might be misinterpreting normal traffic as pings.
Business-related: If you have any business relationship with IBM or use any of their cloud services, it could be related to that.
ChatGPT:
Automated Network Scanning: IBM might be scanning public IPs for vulnerabilities or doing research.
Cloud or Hosting Services: IBM offers cloud and enterprise services, and the traffic could be coming from one of their hosted services.
Legitimate Traffic: If your droplet is interacting with IBM systems or services, this could be valid traffic.
I want to dig further and I should but for now this is where I'm at. I will let the droplet run for a bit more and then check back tomorrow before class or might redo this part of the assignment again before next week just so I can try to find some malicious ones that should be fun. It's my bad for not checking the logs earlier, I should do it again.