So, I've been trying to get Fail2ban working with Postfix.
It has been a bit of a hassle and I'm still not sure if I've got it working properly.
First, when I edit jail.conf to enable the postfix configuration, Fail2ban stops working when I add a ports listing.
Second, I've got it running without errors but can see that Fail2ban isn't blocking incoming bruteforcing attempts on Postfix. I can see the attacks happening in the mail logs but can't see Fail2ban blocking them. The Postfix jail is showing when I run "fail2ban-client status".
I've a crapload of studying up to do, as I just found the man pages for fail2ban-client.
I need to configure for FTP and HTTP as well. SSH is already done.
UPDATE (1/15/2017) - I now have Fail2ban working with more than just SSH. I'm running it to monitor Apache and Xinetd, as well as MySQL and php-url-fopen attacks. But I'm stills struggling with getting it to track Postfix brute-forcing attempts.
This is an online log of my Slackware experiences. Be aware that I'm also using this blog to cover basic and intermediate security issues that may not pertain to Slackware. This is my way of consolidating blogs (I've several of them).
Showing posts with label Ubuntu. Show all posts
Showing posts with label Ubuntu. Show all posts
Thursday, January 12, 2017
Tuesday, November 24, 2015
IPTables and SSH - Resetting Brute Force Traffic, UPDATE
I showed how to determine IPs that were bruteforcing in my last blog entry, and how to block the majority of it (the posts are here and here).
I'm to the point where I should create a script that would determine any IP with a hit count of, for example, 1000, and block them. Or I can just use opensource products like fail2ban (remember, denyhosts isn't working because tcpwrapper support isn't compiled into inetd.conf on Ubuntu 14.04 LTS.). So, I've installed fail2ban and will watch to see how it blocks things with the default setting before making changes to the configuration. The cool thing about fail2ban is that it will watch and block more than just SSH activity.
Am I worrying too much about this? Some would say, YES! I'm doing this for learning purposes and also to get a better understanding of how such bruteforcing is evolving, but I don't really want to have to deal with a box that has been hacked, either. Every admin has the responsiblity of doing their utmost to ensure their machines aren't hacked...that means that the admin needs to be proactive in placing defenses to deter or slow down attacks.
UPDATE:
Already, I see the following in the fail2ban logs:
2015-11-24 22:33:10,453 fail2ban.actions: WARNING [ssh] Ban 195.154.46.203
2015-11-24 22:33:10,458 fail2ban.actions: WARNING [ssh] Ban 59.47.0.157
2015-11-24 22:33:10,462 fail2ban.actions: WARNING [ssh] Ban 43.229.53.49
2015-11-24 22:33:10,466 fail2ban.actions: WARNING [ssh] Ban 43.229.53.87
2015-11-24 22:43:11,085 fail2ban.actions: WARNING [ssh] Unban 195.154.46.203
2015-11-24 22:43:11,090 fail2ban.actions: WARNING [ssh] Unban 59.47.0.157
2015-11-24 22:43:11,094 fail2ban.actions: WARNING [ssh] Unban 43.229.53.49
2015-11-24 22:43:11,098 fail2ban.actions: WARNING [ssh] Unban 43.229.53.87
In checking my logs over the last week, I see some activity that's making it through the firewall. To be honest, I doubt I'll be able to filter ALL the bruteforcing using the rules I've currently in place. I did tweak them a bit, changing the 4th and 5th rules' threshold to 60 seconds (vs 30 seconds). It helped some but then I saw one particular IP blast through the firewall's ruleset like it was designed to go low and slow.
Here are the IPs that have been bruteforcing port 22 this week, as well as their hit counts:
Here are the IPs that have been bruteforcing port 22 this week, as well as their hit counts:
root@linode:~/ssh_brute_force_logs# sed 's/S.*=//' combined1 | uniq -c
2 183.60.48.25
2 162.13.76.111
2 183.60.48.25
2 113.108.21.16
1334 221.231.139.206
2 183.60.48.25
1 217.91.114.240
2 113.108.21.16
2 207.46.140.7
1 218.4.117.26
2 113.108.21.16
8 146.88.41.119
2 113.108.21.16
1 218.60.99.51
2 113.108.21.16
1 187.120.217.121
1 113.108.21.16
1 43.229.53.49
2 113.108.21.16
2 43.229.53.49
6 61.146.150.209
1 94.23.60.117
5 61.146.150.209
2 113.108.21.16
1 179.48.253.43
2 51.254.137.164
1 104.20.64.58
1 51.254.137.164
1 178.187.137.68
2 113.108.21.16
39 140.115.36.207
2 113.108.21.16
3 119.90.18.7
2 113.108.21.16
1 121.43.169.81
1 113.108.21.16
1 203.129.217.5
1 113.108.21.16
1 106.57.172.14
2 14.160.13.174
2 113.108.21.16
2 119.90.18.7
IP 221.231.139.206 was the most prevalent by far, with IP 140.115.36.207 coming in second.
I'm to the point where I should create a script that would determine any IP with a hit count of, for example, 1000, and block them. Or I can just use opensource products like fail2ban (remember, denyhosts isn't working because tcpwrapper support isn't compiled into inetd.conf on Ubuntu 14.04 LTS.). So, I've installed fail2ban and will watch to see how it blocks things with the default setting before making changes to the configuration. The cool thing about fail2ban is that it will watch and block more than just SSH activity.
Am I worrying too much about this? Some would say, YES! I'm doing this for learning purposes and also to get a better understanding of how such bruteforcing is evolving, but I don't really want to have to deal with a box that has been hacked, either. Every admin has the responsiblity of doing their utmost to ensure their machines aren't hacked...that means that the admin needs to be proactive in placing defenses to deter or slow down attacks.
UPDATE:
Already, I see the following in the fail2ban logs:
2015-11-24 22:33:10,453 fail2ban.actions: WARNING [ssh] Ban 195.154.46.203
2015-11-24 22:33:10,458 fail2ban.actions: WARNING [ssh] Ban 59.47.0.157
2015-11-24 22:33:10,462 fail2ban.actions: WARNING [ssh] Ban 43.229.53.49
2015-11-24 22:33:10,466 fail2ban.actions: WARNING [ssh] Ban 43.229.53.87
2015-11-24 22:43:11,085 fail2ban.actions: WARNING [ssh] Unban 195.154.46.203
2015-11-24 22:43:11,090 fail2ban.actions: WARNING [ssh] Unban 59.47.0.157
2015-11-24 22:43:11,094 fail2ban.actions: WARNING [ssh] Unban 43.229.53.49
2015-11-24 22:43:11,098 fail2ban.actions: WARNING [ssh] Unban 43.229.53.87
Fail2ban banned and then unbanned the IPs 10 minutes later (default settings).
What I need to study is how Fail2ban is implementing the bans. Also, do I want to outright permanently ban these IPs...is that even feasible? We'll see.
UPDATE 2 - 12/24/2016:
I checked on things. I checked today's bans since I've been out of touch with the server and Linux in general (been doing work-related things but nothing close to this type of stuff). I didn't even remember how log Fail2ban was blocking but I see I changed the default from 10 minutes to 7 days. I was too lazy to check the logs, so what I did was pick an IP from the ban logs and grep for it. I saw it banned and saw it unbanned 7 days later.
The logs go as far back as 11/20. The trend seems to be mid teens for Nov, although I saw several spikes to the mid twenties. I'm just checking to see what the norm is, so that as I begin to get back into the swing of things, I have a baseline to compare. It would be nice if I could archive these files somehow.
What I need to study is how Fail2ban is implementing the bans. Also, do I want to outright permanently ban these IPs...is that even feasible? We'll see.
UPDATE 2 - 12/24/2016:
I checked on things. I checked today's bans since I've been out of touch with the server and Linux in general (been doing work-related things but nothing close to this type of stuff). I didn't even remember how log Fail2ban was blocking but I see I changed the default from 10 minutes to 7 days. I was too lazy to check the logs, so what I did was pick an IP from the ban logs and grep for it. I saw it banned and saw it unbanned 7 days later.
The logs go as far back as 11/20. The trend seems to be mid teens for Nov, although I saw several spikes to the mid twenties. I'm just checking to see what the norm is, so that as I begin to get back into the swing of things, I have a baseline to compare. It would be nice if I could archive these files somehow.
Labels:
brute force,
Fail2ban,
IPTables,
ssh,
tcpwrappers,
Ubuntu
Tuesday, November 17, 2015
IPTables and SSH - Resetting Brute Force Traffic
In my prior blog post, I described an issue with brute force attempts of my Postfix server. Due to the weird way xinetd was handling services and me not wanting to spend inordinate amounts of time tuning xinetd's tcpwrapper functionality, I uninstalled xinetd. I will continue to rely on Postfix to reject the traffic.
That does me no good when it comes to SSH, though. With Slackware, I rely on either tcpwrapper or packages that leverage tcpwrappers. This works well when it comes to blocking SSH, but I can't use that method on my Ubuntu server without substantial rebuilding (building by source, which I want to avoid).
My solution? Leverage IPtables.
I wanted to use a different method than maintaining block lists. They work but I wanted to learn something new. I found this.
I added the following rules to the firewall:
The second rule says:
The third and fourth rules mean:
That does me no good when it comes to SSH, though. With Slackware, I rely on either tcpwrapper or packages that leverage tcpwrappers. This works well when it comes to blocking SSH, but I can't use that method on my Ubuntu server without substantial rebuilding (building by source, which I want to avoid).
My solution? Leverage IPtables.
I wanted to use a different method than maintaining block lists. They work but I wanted to learn something new. I found this.
I added the following rules to the firewall:
I added the
following rules:
The first rule tells the system:-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 30 --hitcount 4 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j LOG --log-prefix "SSH brute force "
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m recent --update --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp -s kangaroo.pocket.net --dport 22 -j ACCEPT
TCP packets are going to come in, that will
attempt to establish an SSH connection. Mark them as SSH. Pay
attention to the source of the packet.
The second rule says:
If a packet attempting to establish an SSH
connection comes, and it's the fourth packet to come from the same source
in thirty seconds, just reject it with prejudice and stop thinking about
it.
The third and fourth rules mean:
If an SSH connection packet comes in, and it's the
third attempt from the same guy in thirty seconds, log it to the system
log once, then immediately reject it and forget about it.
The 5th rule allows SSH traffic from a certain domain to pass into the environment.
It has cut down my syslogs significantly. I'm pretty sure the firewall isn't suffering, because all it's doing is tracking the source IPs that are coming in on destination port 22. I've not noticed the server suffering under any significant load. Some IPs are still making it through, but I'm counting between 10-20 IP entries in a 24 hour period. I can tell they're making it through because the traffic is hitting my clean-up rule. I've had 8 make it through all the rules before being blocked by the clean-up rule.
It has cut down my syslogs significantly. I'm pretty sure the firewall isn't suffering, because all it's doing is tracking the source IPs that are coming in on destination port 22. I've not noticed the server suffering under any significant load. Some IPs are still making it through, but I'm counting between 10-20 IP entries in a 24 hour period. I can tell they're making it through because the traffic is hitting my clean-up rule. I've had 8 make it through all the rules before being blocked by the clean-up rule.
root@linode:/var/log# grep -i 'dpt=22' syslog | grep -i 'clean-up rule'
Nov 17 07:03:20 linode kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:a6:41:08:00 SRC=113.108.21.16 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=32204 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
Nov 17 07:05:13 linode kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=203.129.217.5 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=46595 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
Nov 17 07:10:17 linode kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:a6:41:08:00 SRC=113.108.21.16 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=32203 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
Nov 17 11:19:15 linode kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:a6:41:08:00 SRC=106.57.172.14 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=49995 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
Nov 17 16:55:46 linode kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:a6:41:08:00 SRC=14.160.13.174 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=25601 DF PROTO=TCP SPT=16895 DPT=22 WINDOW=16591 RES=0x00 ACK FIN URGP=0
Nov 17 16:55:46 linode kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:a6:41:08:00 SRC=14.160.13.174 DST=xxx.xxx.xxx.xxx LEN=140 TOS=0x00 PREC=0x00 TTL=116 ID=25772 DF PROTO=TCP SPT=16895 DPT=22 WINDOW=16591 RES=0x00 ACK PSH FIN URGP=0
Nov 17 19:17:40 linode kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=113.108.21.16 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=32205 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
Nov 17 19:24:37 linode kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=113.108.21.16 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=32202 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
root@linode:/var/log# grep -i 'dpt=22' syslog | grep -i 'clean-up rule' | wc -l
8
root@linode:/var/log#
Sunday, October 19, 2014
Refreshing My Slackware Box
I have been trying to refresh my lab a bit. My Slackware machine hasn't been used in a few years and has 4 older hard drives. I decided to replace the older drives (4 drives - 60-, 80-, 160-, and 60-GB, 3 IDE drives and one SATA drive) and invest in 4 newer drives (4 x 500-GB SATA III).
I want to set up 2 x 500-GB in RAID 0, if possible (software RAID, if possible, hardware RAID if not). I've never set up a RAID array before, and if I can set up 2 x 500-GB in RAID 0, I'll essentially have a 1-TB drive.
I ran into a problem, though. My system seems to not want to always detect the CD drive anymore. Initially, it did, but stopped when I tried to install Slackware 14.1 last night. I got as far as selection of the source drive, even though it detected the CD drive when booting the install CD. I changed the jumper on the back of the drive but it did nothing, and now it won't see the install CD at all. So I decided to try using a USB flash drive as an install source. I also just now noticed that the .iso I'm trying to use is 64-bit, which is the wrong arch. :( I'll download the proper image right now.
I tried using my Alienware system to set up a Slackware install USB flash drive...it was a mess! I ended up just going to my Ubuntu machine and giving it a shot...it is far less confusing. Part of the confusion is that I don't see flushed-out documentation on how to do this in Windows. Most people are either using Unetbootin but the Windows tool for that wasn't detecting the USB flash drive, for some reason. Then, when I tried to use manual instructions, most of the HOWTOs I found weren't clear enough and were a bit vague (trust me...I know how to follow instructions and I've written HOWTOs before).
Hopefully, I can get this working so I can push myself into using Slackware again.
UPDATE --
Just as I finished this post, 'dd' finished. Here's what I did:
This took maybe 10 minutes to do. Again, I have the wrong image, so I'll have to do this all over again...shouldn't be an issue, though.
UPDATE 2 --
Annnnddd...after 2 days of trying getting CDs to be read by the CD reader, I swapped it out with a known working reader. It worked and I threw out the non-working reader. The swapped reader worked for a bit then stopped working too. I then swapped out the IDE cable (yep...no SATA reader in this particular system). It started working again. So, it was the cable and not the readers. Oh, and I went to the trash can and reclaimed the trashed CD reader. :) Slackware 14.1 is now installing, although I still need to read the RAID HOWTO to see what's needed to set that up.
UPDATE 3 --
About that CD reader...it ain't the reader(s). The one I swapped in is intermittent as well, even when paired with known working cabling. It has to be the motherboard that's acting flakey. As well, LILO won't install on my RAID 5 setup...it keeps erroring out and telling me to use another bootup method or to fix the issue (issue has to do with using "--metadata=0.90" on my boot partition setup...I've tried it without setting this particular metadata configuration and it flat-out won't boot). I'd use an alternative boot-up method but the damned motherboard is so old that it doesn't support removable drives such as flash drives as boot-up options. And since the BIOS update utility for this motherboard requires a Windows OS to be installed (and I'm not going to install Windows on this system just to update the BIOS, which might not even fix what I'm complaining about). I'm thinking of just upgrading the motherboard, but if I do that, I'm going to upgrade the CPU as well...gonna go Intel Core i5 and Gigabyte GA-Z87-HD3, more than likely...and if I do that, I'm just going to use it as my main desktop gaming rig, which means I won't be using it as a Linux machine. That might be ideal, since I've a gaming rig that is acting up (its a 6-core AMD CPU system that keeps powering down)...I can relegate that machine to Linux duty after also upgrading it's motherboard and CPU (going Intel i5 as well). I have some decisions to make, I guess.
I want to set up 2 x 500-GB in RAID 0, if possible (software RAID, if possible, hardware RAID if not). I've never set up a RAID array before, and if I can set up 2 x 500-GB in RAID 0, I'll essentially have a 1-TB drive.
I ran into a problem, though. My system seems to not want to always detect the CD drive anymore. Initially, it did, but stopped when I tried to install Slackware 14.1 last night. I got as far as selection of the source drive, even though it detected the CD drive when booting the install CD. I changed the jumper on the back of the drive but it did nothing, and now it won't see the install CD at all. So I decided to try using a USB flash drive as an install source. I also just now noticed that the .iso I'm trying to use is 64-bit, which is the wrong arch. :( I'll download the proper image right now.
I tried using my Alienware system to set up a Slackware install USB flash drive...it was a mess! I ended up just going to my Ubuntu machine and giving it a shot...it is far less confusing. Part of the confusion is that I don't see flushed-out documentation on how to do this in Windows. Most people are either using Unetbootin but the Windows tool for that wasn't detecting the USB flash drive, for some reason. Then, when I tried to use manual instructions, most of the HOWTOs I found weren't clear enough and were a bit vague (trust me...I know how to follow instructions and I've written HOWTOs before).
Hopefully, I can get this working so I can push myself into using Slackware again.
UPDATE --
Just as I finished this post, 'dd' finished. Here's what I did:
ron@Ubuntu1:~$ isohybrid slackware64-14.1-install-dvd.iso
isohybrid: Warning: more than 1024 cylinders: 2326
isohybrid: Not all BIOSes will be able to boot this device
ron@Ubuntu1:~$
ron@Ubuntu1:~$
ron@Ubuntu1:~$ sudo dd if=slackware64-14.1-install-dvd.iso of=/dev/sdb
4763648+0 records in
4763648+0 records out
2438987776 bytes (2.4 GB) copied, 1150.13 s, 2.1 MB/s
This took maybe 10 minutes to do. Again, I have the wrong image, so I'll have to do this all over again...shouldn't be an issue, though.
UPDATE 2 --
Annnnddd...after 2 days of trying getting CDs to be read by the CD reader, I swapped it out with a known working reader. It worked and I threw out the non-working reader. The swapped reader worked for a bit then stopped working too. I then swapped out the IDE cable (yep...no SATA reader in this particular system). It started working again. So, it was the cable and not the readers. Oh, and I went to the trash can and reclaimed the trashed CD reader. :) Slackware 14.1 is now installing, although I still need to read the RAID HOWTO to see what's needed to set that up.
UPDATE 3 --
About that CD reader...it ain't the reader(s). The one I swapped in is intermittent as well, even when paired with known working cabling. It has to be the motherboard that's acting flakey. As well, LILO won't install on my RAID 5 setup...it keeps erroring out and telling me to use another bootup method or to fix the issue (issue has to do with using "--metadata=0.90" on my boot partition setup...I've tried it without setting this particular metadata configuration and it flat-out won't boot). I'd use an alternative boot-up method but the damned motherboard is so old that it doesn't support removable drives such as flash drives as boot-up options. And since the BIOS update utility for this motherboard requires a Windows OS to be installed (and I'm not going to install Windows on this system just to update the BIOS, which might not even fix what I'm complaining about). I'm thinking of just upgrading the motherboard, but if I do that, I'm going to upgrade the CPU as well...gonna go Intel Core i5 and Gigabyte GA-Z87-HD3, more than likely...and if I do that, I'm just going to use it as my main desktop gaming rig, which means I won't be using it as a Linux machine. That might be ideal, since I've a gaming rig that is acting up (its a 6-core AMD CPU system that keeps powering down)...I can relegate that machine to Linux duty after also upgrading it's motherboard and CPU (going Intel i5 as well). I have some decisions to make, I guess.
Labels:
dd,
distribution,
install,
linux,
Slackware,
Ubuntu,
USB,
usb flash dirve
Friday, December 27, 2013
nmon - Linux
Found this little tidbit (nmon) on Google+ (Ubuntu group):
https://plus.google.com/101635552034658832984/posts/BoQk2BibQkJ
It may come in handy during my next troubleshooting crisis.
Saturday, January 05, 2013
PSAD
I decided to give PSAD a spin on the Linode since I've never tried it before. I'm impressed at the features of it. I've been running it maybe a bit over a month. I get alerts whenever PSAD detects a scan or when it logs and drops specific traffic, so I'm aware of what's going on (instead of having to check my firewall logs). One of the main reasons I decided to give PSAD a spin is because my fwanalog setup stopped working due to a code bug that affects Ubuntu v12.04.
One of the things I've been doing (I used to do this in the past) is I send my dropped logs to Dshield.org (or isc.sans.org). One of PSAD's features enables me to send the logs, vs. using third-party or Dshield apps.
I noticed when sending my logs that I'm catching bidirectional traffic and my server IP is being flagged as a result. Why? I was blocking 118.0.0.0/8 (a large segment of APAC). I was not only blocking but sending resets, which requires my firewall to send resets when means my IP is talking back, even though it's ending the session. My firewall logs it as a drop. To fix this, I just configured the firewall to drop the traffic, although I could've just changed the --log-prefix tag to something other than DROP, which by default PSAD looks for. I'll monitor the Dshield logs to see how PSAD is now reporting.
One of the things I've been doing (I used to do this in the past) is I send my dropped logs to Dshield.org (or isc.sans.org). One of PSAD's features enables me to send the logs, vs. using third-party or Dshield apps.
I noticed when sending my logs that I'm catching bidirectional traffic and my server IP is being flagged as a result. Why? I was blocking 118.0.0.0/8 (a large segment of APAC). I was not only blocking but sending resets, which requires my firewall to send resets when means my IP is talking back, even though it's ending the session. My firewall logs it as a drop. To fix this, I just configured the firewall to drop the traffic, although I could've just changed the --log-prefix tag to something other than DROP, which by default PSAD looks for. I'll monitor the Dshield logs to see how PSAD is now reporting.
Tuesday, October 23, 2012
Postfix Install, OSSIM, Slack 14, Ubuntu, and VPNs
This isn't really a technical post, but I did want to share that I have Postfix running on my server. I'd never had the need to run my own mail server until I moved my wigglit.com domain. It was initially hosted at 1and1.com, but I got fed up with their service (or lack thereof). I had several e-mail accounts set up there and still needed them to stay active, so I was pretty much forced to migrate the accounts as well as the domain. The domain migration was pretty simple. The Postfix install was much more difficult, even when using Webmin to set it up. I used a Ubuntu tutorial (searched on 'webmin', 'ubuntu', 'postfix', and 'configuration') and used it exclusively to set up the server. I think I have it tuned pretty well so far, only I found some bounced e-mails going back maybe a month or so...I fixed those today. Those weren't actually related to Postfix, though. When I stood up the new server and domain, I forgot to adjust the scripts that kicked off the e-mails (cronjobs). I'll double-check tomorrow, but I think I've fixed those (was able to test the cronjob successfully...generated a test e-mail). I've since been editing the main.cf file to make configuration changes (and restarting the mail server afterward).
I've also been trying to use OSSIM, but I think I need a dedicated machine. I tried to use an install of it within VirtualBox, with very limited success. It seems it needs considerable resources and doesn't run well on a virtual instance with limited CPU/memory resources. I ran VirtualBox on my M17xR3...that machine definitely has enough horsepower, but only has 8GB of RAM...it may need a bit more so that I can give OSSIM ample memory. As well, my RAID 0 drive set may be hindering OSSIM. I got a taste of it, though, and like it much better than Aanval. Unfortunately, I don't have a good spare box at the moment, otherwise I'd be running it already. That was my first time using VirtualBox, also...it's not that much different than VMware...much simpler, though.
So, Slackware v14.0 was released not long ago. I took the liberty of installing it within VirtualBox. It runs very nice! I'm in the process of evaluating it and will soon upgrade my two v12.0 machines. No, I'm not using Slackware on my public server. I opted to use Ubuntu (v12.04) instead. While I love Slack, I needed something less high-maintenance on the public server. No complaints so far and it's been about a year since I flushed it and gave Ubuntu a try...no complaints whatsoever. KISS is where it's at.
Lastly, since I've had success with Postfix, I plan to eventually start evaluating security tools again. I've been out of the loop for awhile and need to push myself to continue to be familiar with Linux and security. I've never used any of the VPN software before, so I plan to establish a VPN conduit between my LAN and my public server. We'll see how that goes soon.
I've also been trying to use OSSIM, but I think I need a dedicated machine. I tried to use an install of it within VirtualBox, with very limited success. It seems it needs considerable resources and doesn't run well on a virtual instance with limited CPU/memory resources. I ran VirtualBox on my M17xR3...that machine definitely has enough horsepower, but only has 8GB of RAM...it may need a bit more so that I can give OSSIM ample memory. As well, my RAID 0 drive set may be hindering OSSIM. I got a taste of it, though, and like it much better than Aanval. Unfortunately, I don't have a good spare box at the moment, otherwise I'd be running it already. That was my first time using VirtualBox, also...it's not that much different than VMware...much simpler, though.
So, Slackware v14.0 was released not long ago. I took the liberty of installing it within VirtualBox. It runs very nice! I'm in the process of evaluating it and will soon upgrade my two v12.0 machines. No, I'm not using Slackware on my public server. I opted to use Ubuntu (v12.04) instead. While I love Slack, I needed something less high-maintenance on the public server. No complaints so far and it's been about a year since I flushed it and gave Ubuntu a try...no complaints whatsoever. KISS is where it's at.
Lastly, since I've had success with Postfix, I plan to eventually start evaluating security tools again. I've been out of the loop for awhile and need to push myself to continue to be familiar with Linux and security. I've never used any of the VPN software before, so I plan to establish a VPN conduit between my LAN and my public server. We'll see how that goes soon.
Sunday, May 20, 2012
FreeBSD Pains
My 'new' BSD machine (FreeBSD 8.2) crapped out again. Actually, I think either my wife or one of my kids accidentally shut it down. Now it tries to boot up and immediately shuts down during the boot-up process. I can't look at logs because it keeps shutting down. I tried single mode and it does the same thing. I've been trying to see the last line of the boot-up process before it shuts down...that's like trying to capture (with your mind) one frame of a film...very hard to do. Well, it looks like it can't mount the root partition (just from what I've seen the milli-second before it shuts down). I need to run fsck on it but I can't do that if it's not booting up properly into single mode.
I cheated and tried to boot up live install of Linux Mint, Ubuntu (both of the latter are on USB sticks), and FreeBSD (on DVD)...they must be trying to mount the drive that the FreeBSD install is on, because they all shut down too. So, I'm going to try a rescue version of FreeBSD (for memory sticks).
Once I fix this, I'm sure there's a rc.conf setting that I'll need to set to force an fsck during boot-up if needed. This has happened ever since I installed FreeBSD and I'm a bit irritated...this should be enabled by default so that someone doesn't get 'locked' out of their system. :/
I cheated and tried to boot up live install of Linux Mint, Ubuntu (both of the latter are on USB sticks), and FreeBSD (on DVD)...they must be trying to mount the drive that the FreeBSD install is on, because they all shut down too. So, I'm going to try a rescue version of FreeBSD (for memory sticks).
Once I fix this, I'm sure there's a rc.conf setting that I'll need to set to force an fsck during boot-up if needed. This has happened ever since I installed FreeBSD and I'm a bit irritated...this should be enabled by default so that someone doesn't get 'locked' out of their system. :/
Monday, July 13, 2009
Main Slackbox (named slackbox) back online
I finally had time to figure out what was going on with my Slackware tower. It has been down for so long I forget when it actually started having issues. I believe it began having problems since the beginning of 2009.
The culprit? Either the SATA drive that I installed in it awhile back or the SATA controllers on teh board. It's difficult to tell without swapping the SATA drive out for another. I just disabled it (the drive) for now. It works fine without it connected...that tells me its the drive and not the controller.
I began by trying to boot it up by using a Ubuntu LiveCD. It wouldn't boot up and showed many ATA-based errors in the logs. I tried a different Ubuntu LiveCD (v8.10, I believe)...still, same issue.
It was then that I started focusing on the SATA drive. I just unplugged it and tried to reboot...got a reboot and the system has been running for about a week without any issues.
So, I lost a drive. It's not a big deal, as that drive was hosting Windows, I believe. Weird, because that drive is rather young. I believe its a WD (I have seriously bad luck with that brand). I can do without replacing that drive for now, though.
The culprit? Either the SATA drive that I installed in it awhile back or the SATA controllers on teh board. It's difficult to tell without swapping the SATA drive out for another. I just disabled it (the drive) for now. It works fine without it connected...that tells me its the drive and not the controller.
I began by trying to boot it up by using a Ubuntu LiveCD. It wouldn't boot up and showed many ATA-based errors in the logs. I tried a different Ubuntu LiveCD (v8.10, I believe)...still, same issue.
It was then that I started focusing on the SATA drive. I just unplugged it and tried to reboot...got a reboot and the system has been running for about a week without any issues.
So, I lost a drive. It's not a big deal, as that drive was hosting Windows, I believe. Weird, because that drive is rather young. I believe its a WD (I have seriously bad luck with that brand). I can do without replacing that drive for now, though.
Subscribe to:
Posts (Atom)