So I had wigglit.com hosted at 1and1.com, but ran into issues with them that appear to be recurring. I previously purchased MobileMe for my mac machines (I can archive data as well as use it's e-mail system and web page authoring), but since Apple is killing MM and migrating to iCloud, some of those capabilities are disappearing. I decided to host my pages myself, using 1and1.com, but apparently they are idiots. I sometimes need to shell into the 1and1.com environment to make changes and I've been trying to pipe the data hosted on MM to 1and1.com but they keep locking my account. I've sent several nastygrams asking them to lessen the lockout threshold on their shell accounts, but they keep blaming the user and not really investigating, sending cookie-cutter responses and such. So I told them I'm going to discontinue their services as soon as I migrate the data.
So far, I've moved wigglit.com over to my Linode account. I've moved my SV1000 blog and site to sv1000s.wigglit.com, and my Apple blog was moved to apple.wigglit.com. I'd never used subdomains before, so that was new to me. I also had never delved in DNS, as I had to map my subdomains to my Linode account. Using the Linode tools and a bit of research, I was able to do this seamlessly. I now have functional subdomains.
I'm going to eventually have everything consolidated on the Linode. The big one will be migrating my e-mail to my Linode system...I think that's going to be painful.
I will move the rest of the data soon and discontinue using 1and1.com's services within 30 days.
Note that this has nothing to do with Slackware in itself, but I wanted to capture this move in one of my blogs.
The 'S' Files
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).
Wednesday, February 01, 2012
Thursday, August 04, 2011
Snort and Thresholding Noisy Alerts
I'm trying to stay sharp as a security techie, so I've been trying to contribute to Linux and security forums. There's a guy who was asking how to use bpf.conf with Snort. I suggested he use threshold.conf instead. I actually referenced this (I love TaoSecurity) to help him. He was being flooded with "SHELLCODE x86 inc ecx NOOP" alerts. The assistance thread is here, at LinuxQuestions.org.
Labels:
linux,
linuxquestions.org,
Snort,
TaoSecurity,
thresholding
Wednesday, May 04, 2011
Connection Tracking and IPTables
Conntrack entries
I'm making a point of trying to read through this Iptables document. The connection tracking function is pretty cool, though. I was aware of the functionality but had never seen the logs at /proc/net/ip_conntrack until this morning.
Thursday, April 14, 2011
BASE and Snorby: packet captures
Noticed that someone on the interwebz stated that Snorby captures full payload while BASE doesn't. I read this as a comment on the Snorby pages. Unless I'm totally off-base here, that's not the case, unless they're taking about something like netflows or something akin to it. I believe one of the dev guys stated that only Snorby and Sguil offer full packet capturing. That does NOT sound right and I believe he should clarify.
I'll dig up the link later, but it should be very apparent on their pages (it was to me, when I was perusing).
So, I pulled up my BASE console and looked at a sample packet. To look at payload/packets within BASE, you go to a line item then click on the "ID", which would look akin to "2-278900".
BASE capture view:
Snorby capture view:
Now, I don't see either lacking in that regard. This is enough for the analyst to determine a false positive vs. a real attack/concern.
Now, if I wanted to further investigate, I can (in BASE), go to a listing, then click the offending IP (or the other IP...doesn't matter). Then I click "Unique alerts" or "Unique IP links" under "Summary Statistics":
This is basic stuff here. It shows the history of that particular IP...it shows everything that was ever recorded from that IP, and you can dig down from there. Source/Destination would show bidirectional traffic between the offending IP and whatever it was communicating with. I'll get payload every time, IF (BIG IF HERE) the Snort signature is designed to capture payload and if the traffic even has payload.
I don't understand the argument of saying that BASE doesn't capture full payload. Of course, BASE won't. It's just a SEM. Snort would actually do the capturing. It would also totally depend on who sets up Snort and their requirements. The admin that configures Snort may not even have all the sigs enabled. But, BASE will show any payload that Snort does capture.
At this point, Snorby's search and analytical functionality is lacking. I've said this before and got ridiculed by one of the Snorby developers. We all know Snorby is relatively new when comparing it to BASE, but until the Snorby dev team enables better query functionality and better ways to quickly track activity, I'm going to stick to my guns. A pretty (and even simplified) interface is one thing, but when it comes to the meat and potatoes, candy apples doesn't cut it. As an analyst, I'd not want to lose any type of query features, as this will make a sometimes frustrating job all the more frustrating (been there, done that).
Lastly, I will NOT HAVE A PISSING MATCH over this. I've been doing such comparisons for YEARS and am fully capable of judging what is acceptable and what is not regarding most security tools (that's why I get paid the big bucks), although I'm always objective in my opinions. I definitely know what "best of breed" entails. I'm going to put it out there: Snorby is NOT best of breed. I'd love it to be, but right now, it is NOT. It has to help me sort/organize/filter information that helps me catch malware and such...much more that what it currently offers. Right now, with Snorby, there's no such thing as digging down or simplifying the search through thousands of potentially bad security events. "Packet capture options/Customer" isn't going to cut it. It is good for the small investigation but for the bigger tasks. Let's be grown-ups about this topic and offer objective opinions. If you can't do that, don't even try to leave some nasty comment on this blog. Comments moderation is enabled. Yes, I do require clarification on what is considered "full payload analysis", as I feel that's not enough of a description and could actually be relating to something else entirely different that the above (I doubt it, though).
I'll dig up the link later, but it should be very apparent on their pages (it was to me, when I was perusing).
So, I pulled up my BASE console and looked at a sample packet. To look at payload/packets within BASE, you go to a line item then click on the "ID", which would look akin to "2-278900".
BASE capture view:
Snorby capture view:
Now, I don't see either lacking in that regard. This is enough for the analyst to determine a false positive vs. a real attack/concern.
Now, if I wanted to further investigate, I can (in BASE), go to a listing, then click the offending IP (or the other IP...doesn't matter). Then I click "Unique alerts" or "Unique IP links" under "Summary Statistics":
| |
| Unique alerts |
I don't understand the argument of saying that BASE doesn't capture full payload. Of course, BASE won't. It's just a SEM. Snort would actually do the capturing. It would also totally depend on who sets up Snort and their requirements. The admin that configures Snort may not even have all the sigs enabled. But, BASE will show any payload that Snort does capture.
At this point, Snorby's search and analytical functionality is lacking. I've said this before and got ridiculed by one of the Snorby developers. We all know Snorby is relatively new when comparing it to BASE, but until the Snorby dev team enables better query functionality and better ways to quickly track activity, I'm going to stick to my guns. A pretty (and even simplified) interface is one thing, but when it comes to the meat and potatoes, candy apples doesn't cut it. As an analyst, I'd not want to lose any type of query features, as this will make a sometimes frustrating job all the more frustrating (been there, done that).
Lastly, I will NOT HAVE A PISSING MATCH over this. I've been doing such comparisons for YEARS and am fully capable of judging what is acceptable and what is not regarding most security tools (that's why I get paid the big bucks), although I'm always objective in my opinions. I definitely know what "best of breed" entails. I'm going to put it out there: Snorby is NOT best of breed. I'd love it to be, but right now, it is NOT. It has to help me sort/organize/filter information that helps me catch malware and such...much more that what it currently offers. Right now, with Snorby, there's no such thing as digging down or simplifying the search through thousands of potentially bad security events. "Packet capture options/Customer" isn't going to cut it. It is good for the small investigation but for the bigger tasks. Let's be grown-ups about this topic and offer objective opinions. If you can't do that, don't even try to leave some nasty comment on this blog. Comments moderation is enabled. Yes, I do require clarification on what is considered "full payload analysis", as I feel that's not enough of a description and could actually be relating to something else entirely different that the above (I doubt it, though).
Monday, March 21, 2011
GUIs for Snort
GUIs for Snort --
http://blog.snort.org/2011/01/guis-for-snort.html
Some of these might appeal to you, the network/security administrator, depending on your organization's needs. Note: there is NO best in breed tool...it totally depends on your organization's needs, which will vary when comparing org X to org Y.
http://blog.snort.org/2011/01/guis-for-snort.html
Some of these might appeal to you, the network/security administrator, depending on your organization's needs. Note: there is NO best in breed tool...it totally depends on your organization's needs, which will vary when comparing org X to org Y.
Wednesday, February 02, 2011
HTTP Viewers
I found something that is very similar to Web-sniffer.net (an HTTP viewer/proxy)...it is called "Rex Swain's HTTP Viewer". That's a mouthful, so I'll call it RSHV.
One thing that Web-sniffer can't do is allow for referer configuration. RSHV will let you configure the referer (in fact, this appears to be a recently added feature). Why is this sometimes important? Read here. In comparison to Web-Sniffer.net, RSHV is better documented. A con of RSHV is that it won't do HTTPS.
Why do I call these HTTP viewers proxies? Well, they are. When you utilize those tools to view, for example, pages/headers at wigglit.ath.cx, if you check the web logs at wigglit.ath.cx, you'll see the traffic you generated came from someone else's IP (and not the one that was assigned to your machine when you visited wigglit.ath.cx). That's a protection, in my opinion...this means you can conduct research without having to use a lab system to prevent infection.
Note that the services these two tools provide can be done on pretty much any computer (*nix or win32/64). Just use telnet. Of course, wget can also be used (or fetch or curl), but I consider that to be a more cumbersome solution (although you may be able to create scripts that you can use wget/fetch/curl with).
Utilizing such tools in such a manner is important when conducting security analysis (for instance, validating that a certain website is or isn't compromised and serving malware).
One thing that Web-sniffer can't do is allow for referer configuration. RSHV will let you configure the referer (in fact, this appears to be a recently added feature). Why is this sometimes important? Read here. In comparison to Web-Sniffer.net, RSHV is better documented. A con of RSHV is that it won't do HTTPS.
Why do I call these HTTP viewers proxies? Well, they are. When you utilize those tools to view, for example, pages/headers at wigglit.ath.cx, if you check the web logs at wigglit.ath.cx, you'll see the traffic you generated came from someone else's IP (and not the one that was assigned to your machine when you visited wigglit.ath.cx). That's a protection, in my opinion...this means you can conduct research without having to use a lab system to prevent infection.
Note that the services these two tools provide can be done on pretty much any computer (*nix or win32/64). Just use telnet. Of course, wget can also be used (or fetch or curl), but I consider that to be a more cumbersome solution (although you may be able to create scripts that you can use wget/fetch/curl with).
Utilizing such tools in such a manner is important when conducting security analysis (for instance, validating that a certain website is or isn't compromised and serving malware).
Tuesday, October 05, 2010
58.221.32.117 hammering my server
I've been seeing 58.221.32.117 in my logs, especially within the last week or so. So far, I've 5,356 instances of blocking by the firewall for this particular IP. All traffic is coming from source port 80 of that IP. Yes, every single instance was blocked.
Has anyone else seen similar activity from this IP?
A whois shows the following:
Has anyone else seen similar activity from this IP?
A whois shows the following:
| IP address [?]: | 58.221.32.117 [Whois] [Reverse IP] | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IP country code: | CN | |||||||||||
| IP address country: | China | |||||||||||
| IP address state: | Beijing | |||||||||||
| IP address city: | Beijing | |||||||||||
| IP address latitude: | 39.9289 | |||||||||||
| IP address longitude: | 116.3883 | |||||||||||
| ISP of this IP [?]: | CHINANET jiangsu province network | |||||||||||
| Organization: | CHINANET jiangsu province network | |||||||||||
| Local time in China: | 2010-10-06 10:29 | |||||||||||
Subscribe to:
Posts (Atom)



China